), 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
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
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
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,
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?
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
,
--
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.
-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
On Sat, May 2, 2020 at 11:05 PM Tomas Vondra
wrote
> Pushed. Thanks for the report.
>
Thanks!
--
Atsushi Torikoshi
failed, this
presumption can be wrong.
Thoughts?
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
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
'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
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
d the patch, I didn't find any problems.
Regards,
--
Atsushi Torikoshi
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
> >
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
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
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
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
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 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>>
(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
26 matches
Mail list logo