(except DEALLOCATE which is entirely
untracked).
statemets -> statements
statements's -> statements' or statement's?
Regards,
--
Atsushi Torikoshi
On Wed, Apr 8, 2020 at 11:38 PM Julien Rouhaud wrote:
> On Tue, Apr 7, 2020 at 8:40 AM Tatsuro Yamada
> wrote:
> >
> > Hi
On Mon, May 25, 2020 at 10:54 AM Atsushi Torikoshi wrote:
> On Thu, May 21, 2020 at 5:10 PM Kyotaro Horiguchi
> wrote:
>
>> Cost numbers would look better if it is cooked a bit. Is it worth
>> being in core?
>
>
> I didn't come up with ideas about how to use
On Fri, May 22, 2020 at 11:37 PM Fujii Masao
wrote:
>
>
> On 2020/05/15 9:50, Atsushi Torikoshi wrote:
> > Thanks for reviewing!
> >
> > On Wed, May 13, 2020 at 11:27 PM Fujii Masao <
> masao.fu...@oss.nttdata.com <mailto:masao.fu...@oss.nttdata.com>>
rhaps plan_generation is not needed there.
>
+1.
Now 'calls' is sufficient and 'plan_generation' may confuse users.
BTW, considering 'calls' in pg_stat_statements is the number of times
statements were EXECUTED and 'plans' is the number of times
statements were PLANNED, how about substituting '
On Wed, May 20, 2020 at 1:32 PM Kyotaro Horiguchi
wrote:
> At Tue, 19 May 2020 22:56:17 +0900, Atsushi Torikoshi
> wrote in
> > On Sat, May 16, 2020 at 6:01 PM legrand legrand <
> legrand_legr...@hotmail.com>
> > wrote:
> >
> > BTW, I'd also appreciate ot
g the number
of generic and custom plans on pg_stat_statemtents.
Regards,
--
Atsushi Torikoshi
'm wondering it's necessary to add a hook to get Portal
or CachedPlanSource.
Are these too much change for getting plan types?
Regards,
--
Atsushi Torikoshi
Thanks for reviewing!
On Wed, May 13, 2020 at 11:27 PM Fujii Masao
wrote:
> What about the attached patch based on yours?
It looks better.
Regards,
--
Atsushi Torikoshi
-COLUMNS
Regards,
--
Atsushi Torikoshi
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 579ccd34d4..186d1c10ca 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -2706,13 +2706,17 @@ SELECT pid, wait_event_type, wait_event FROM
failed, this
presumption can be wrong.
Thoughts?
Regards,
--
Atsushi Torikoshi
On Sat, May 2, 2020 at 11:05 PM Tomas Vondra
wrote
> Pushed. Thanks for the report.
>
Thanks!
--
Atsushi Torikoshi
-01 17:37:02.525006+09
commit_timestamp | 0 |0 | 0 |0 |
0 | 0 | 0 | 2000-01-01 09:00:00+09
(snip)
Attached a patch.
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATION
diff --git a/src/backend/postmaster/pgstat.c b/src/backend
,
--
Atsushi Torikoshi
On Fri, Feb 28, 2020 at 5:17 PM imai.yoshik...@fujitsu.com <
imai.yoshik...@fujitsu.com> wrote:
> On Wed, Feb 26, 2020 at 1:39 AM, Kyotaro Horiguchi wrote:
> > Hello. I had a brief look on this and have some comments on this.
>
> Hi, Horiguchi-san.
On Mon, Mar 23, 2020 at 1:58 PM Michael Paquier wrote:
> On Thu, Mar 19, 2020 at 12:04:45AM -0300, Alvaro Herrera wrote:
> > None here.
>
> Thanks Álvaro. Applied and back-patched down to 9.5 then.
> --
> Michael
>
Thanks for applying the patch.
Regards,
--
Atsushi Torikoshi
ropriate name.
>
I've confirmed the patch works as you described above.
And I also poked around it a little bit but found no problems.
Regards,
--
Atsushi Torikoshi
d the patch, I didn't find any problems.
Regards,
--
Atsushi Torikoshi
On Wed, Mar 18, 2020 at 6:59 PM Fujii Masao
wrote:
>
> I meant the following part in the doc.
>
> -
> At startup, the standby begins by restoring all WAL available in the
> archive
> location, calling restore_command. Once it reaches the end of WAL available
> there and
On Tue, Mar 17, 2020 at 11:55 AM Fujii Masao
wrote:
> > >Waiting when WAL data is not available from any kind of sources
> > >(local, archive or stream) before trying again to retrieve WAL
> data,
> >
> > I think 'local' means pg_wal here, but the comment on
> >
On Mon, Mar 16, 2020 at 11:32 PM Alvaro Herrera
wrote:
>
> > Should I also change it to "enum"?
>
> Yeah, these were strings until recently (commit 773df883e8f7 Sept 2019).
>
Thanks!
Attached a patch for manuals on create and alter view.
check_option is also described in
Thanks for your comments!
On Mon, Mar 16, 2020 at 11:49 AM Fujii Masao
wrote:
> -buffering
> +buffering (string)
>
> Isn't it better to use "enum" rather than "string"?
> In the docs about enum GUC parameters, "enum" is used there.
>
Agreed. I've fixed it to "enum".
But I'm now
Hi,
The current manual on CREATE TABLE[1] describes storage
parameters with their types.
But manual on CREATE INDEX[2] describes storage parameters
WITHOUT their types.
I think it'll be better to add types to storage parameters
on CREATE INDEX for the consistency.
Attached a patch.
Any thought?
Hi,
As far as I read the reloptions.c, autovacuum_vacuum_cost_delay,
autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor
are the members of relopt_real, so their type seems the same, real.
But the manual about storage parameters[1] says two of their type
are float4 and the other
Hi,
It seems the comments on SharedHotStandbyActive and
SharedRecoveryInProgress are the same in XLogCtlData.
How about modifying the comment on SharedHotStandbyActive?
Attached a patch.
Regards,
--
Torikoshi Atsushi
fix_comments_on_SharedHotStandbyActive_v1.patch
Description: Binary data
On 2020/02/19 21:46 Fujii Masao :
>> I agree to the former, I think RecoveryWalInterval works well enough.
>RecoveryWalInterval sounds confusing to me...
IMHO as a user, I prefer RecoveryRetrieveRetryInterval because
it's easy to understand this wait_event is related to the
parameter
), but won't be allowed to do so by default
> as it won't have EXECUTE privilege on the functions.
>
I see, thanks for your explanation.
--
Regards,
Atsushi Torikoshi
ch or voluntary.
It's not directly related to the patch, but as far as I read the
manual below, I expected pg_write_server_files users could execute
adminpack functions.
| Table 21.1 Default Roles
| pg_write_server_files: Allow writing to files in any location the
database can access on the server with COPY and other file-access functions.
--
Atsushi Torikoshi
26 matches
Mail list logo
