From: Michael Paquier [mailto:mich...@paquier.xyz]
> Okay, I have pushed the patch with all your suggestions included.
Thanks so much!
Regards
Takayuki Tsunakawa
On Sun, Sep 23, 2018 at 10:47:44AM -0400, Tom Lane wrote:
> Andres Freund writes:
>> Have there been discussions about the security effects of this change?
>> Previously the server admin could control the timeout, which could
>> affect things like syncrep, after this it's not possible anymore. I
Andres Freund writes:
> Have there been discussions about the security effects of this change?
> Previously the server admin could control the timeout, which could
> affect things like syncrep, after this it's not possible anymore. I
> *think* that's ok, but it should be discussed.
Hm. An evil
Hi,
On 2018-09-22 15:27:24 +0900, Michael Paquier wrote:
> On Fri, Sep 21, 2018 at 06:26:19AM +, Tsunakawa, Takayuki wrote:
> > Agreed.
>
> Okay, I have pushed the patch with all your suggestions included.
Have there been discussions about the security effects of this change?
Previously the
On Fri, Sep 21, 2018 at 06:26:19AM +, Tsunakawa, Takayuki wrote:
> Agreed.
Okay, I have pushed the patch with all your suggestions included.
--
Michael
signature.asc
Description: PGP signature
On Fri, Sep 21, 2018 at 06:26:19AM +, Tsunakawa, Takayuki wrote:
> Agreed. Sorry to cause you to take this long time for such a tiny
> patch...
Well, that is arguing about how to shape things and agree on those,
which is not wasted time, far from that.
--
Michael
signature.asc
Description:
From: Michael Paquier [mailto:mich...@paquier.xyz]
> I think that the description of wal_sender_timeout and its properties should
> remain where the parameter is defined, so (3) is not a good option in my
> opinion. (2) has a point with the use of quotes actually, so why not just
> mention options
On Fri, Sep 21, 2018 at 05:37:42AM +, Tsunakawa, Takayuki wrote:
> I think all of these are almost equally good. I chose (1) at first,
> and you chose (3). But (2) may be the best, because it's the natural
> place the user will see when configuring the standby, and it already
> contains an ex
From: Michael Paquier [mailto:mich...@paquier.xyz]
> But that does not apply to this single parameter, no? I would think that
> a section in recovery.conf is more adapted. I can see that the patch I
> proposed up-thread could be more precise though, so why not adding at an
> extra paragraph? Her
On Fri, Sep 21, 2018 at 02:28:07AM +, Tsunakawa, Takayuki wrote:
> I find it more user friendly to include a description somewhere that
> the user can tune the timeout per standby, like I added a tip in the
> description of wal_sender_timeout. I'm afraid users won't know
> whether and how to t
From: Michael Paquier [mailto:mich...@paquier.xyz]
> Thanks for the new version. Per my comments up-thread here, you cannot
> actually use PGC_BACKEND:
> https://www.postgresql.org/message-id/20180919061303.GB19808@paquier.x
> yz
>
> This would break the case where this parameter is reloaded when
On Wed, Sep 19, 2018 at 06:21:52AM +, Tsunakawa, Takayuki wrote:
> How embarrassing... I'm sorry to cause you trouble to point out a
> silly mistake like this (I thought I would write as you suggested, but
> it seems that I was not who I usually am.) The revised patch
> attached.
Thanks for
From: Michael Paquier [mailto:mich...@paquier.xyz]
> Parameters classified as PGC_BACKEND can be updated by any users, and those
> marked as PGC_SU_BACKEND can only be updated by superusers.
> Replication users are not superusers, which is why PGC_BACKEND is most
> adapted. Your description should
On Wed, Sep 19, 2018 at 02:40:31PM +0900, Michael Paquier wrote:
> Parameters classified as PGC_BACKEND can be updated by any users, and
> those marked as PGC_SU_BACKEND can only be updated by superusers.
> Replication users are not superusers, which is why PGC_BACKEND is most
> adapted. Your desc
On Wed, Sep 19, 2018 at 12:14:57AM +, Tsunakawa, Takayuki wrote:
> From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> > I didn't follow the first sentence of the above hunk. Is the
> > wal_sender_timeout relevant with %q?
>
> Ouch, that's a careless mistake. I copied the paragraph from an
From: Masahiko Sawada [mailto:sawada.m...@gmail.com]
> I didn't follow the first sentence of the above hunk. Is the
> wal_sender_timeout relevant with %q?
Ouch, that's a careless mistake. I copied the paragraph from another parameter
and failed to remove some sentence. Patch revised.
Regards
T
On Tue, Sep 18, 2018 at 5:27 PM, Tsunakawa, Takayuki
wrote:
> From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
>> At Fri, 14 Sep 2018 18:22:33 +0900, Masahiko Sawada
>> wrote in
>>
>> > On Thu, Sep 13, 2018 at 12:32 PM, Michael Paquier
>> wrote:
>> > > On Thu, Sep 13, 2018 at 01
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> At Fri, 14 Sep 2018 18:22:33 +0900, Masahiko Sawada
> wrote in
>
> > On Thu, Sep 13, 2018 at 12:32 PM, Michael Paquier
> wrote:
> > > On Thu, Sep 13, 2018 at 01:14:12AM +, Tsunakawa, Takayuki wrote:
> > >> Some customer wants
On Tue, Sep 18, 2018 at 11:20:03AM +0900, Kyotaro HORIGUCHI wrote:
> +1, and we need a means to see the actual value, in
> pg_stat_replication?
Well, being able to see what another session is using as settings is
not a trivial problem, perhaps not worth solving, and orthogonal to
what's discussed
At Fri, 14 Sep 2018 18:22:33 +0900, Masahiko Sawada
wrote in
> On Thu, Sep 13, 2018 at 12:32 PM, Michael Paquier wrote:
> > On Thu, Sep 13, 2018 at 01:14:12AM +, Tsunakawa, Takayuki wrote:
> >> Some customer wants to change the setting per standby, i.e., a shorter
> >> timeout for a standby
On Thu, Sep 13, 2018 at 12:32 PM, Michael Paquier wrote:
> On Thu, Sep 13, 2018 at 01:14:12AM +, Tsunakawa, Takayuki wrote:
>> Some customer wants to change the setting per standby, i.e., a shorter
>> timeout for a standby in the same region to enable faster detection
>> failure and failover,
On Thu, Sep 13, 2018 at 01:14:12AM +, Tsunakawa, Takayuki wrote:
> Some customer wants to change the setting per standby, i.e., a shorter
> timeout for a standby in the same region to enable faster detection
> failure and failover, and a longer timeout for a standby in the remote
> region (for
Hello,
What do you think about changing wal_sender_timeout from PGC_HUP to PGC_BACKEND
or PGC_USERSET?
Some customer wants to change the setting per standby, i.e., a shorter timeout
for a standby in the same region to enable faster detection failure and
failover, and a longer timeout for a sta
23 matches
Mail list logo
