Hello
Yep, I think it's useful and I already posted patch in this thread:
https://www.postgresql.org/message-id/flat/3090621585393698%40myt5-1466095fe4e5.qloud-c.yandex.net#ee6574e93982b5628d140f15cb44
Currently without consensus
regards, Sergei
On 2020-03-28 02:39, Alvaro Herrera wrote:
On 2020-Mar-27, Alvaro Herrera wrote:
On 2020-Mar-27, Alvaro Herrera wrote:
> I pushed the wal_receiver_create_temp_slot bugfix, because I realized
> after looking for long enough at WalReceiverMain() that the code was
> beyond saving. I'll be
On 2020-03-28 11:49, Sergei Kornilov wrote:
I attached updated patch: walreceiver will use configured primary_slot_name as
temporary slot name if wal_receiver_create_temp_slot is enabled.
The original setup worked consistently with pg_basebackup. In
pg_basebackup, if you specify -S/--slot,
Hello
Thank you very much!
I attached updated patch: walreceiver will use configured primary_slot_name as
temporary slot name if wal_receiver_create_temp_slot is enabled.
regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 2de21903a1..8983cb5f5e 100644
---
On 2020-Mar-27, Alvaro Herrera wrote:
> On 2020-Mar-27, Alvaro Herrera wrote:
>
> > I pushed the wal_receiver_create_temp_slot bugfix, because I realized
> > after looking for long enough at WalReceiverMain() that the code was
> > beyond saving. I'll be pushing the rest of this later today.
>
Hello
Thank you!
> I think I should set aside your new draft for now
I agree, this patch definitely needs a bit more time to review. (currently it
applies on top of v13 patch cleanly)
> but I think we should still get it in pg13 to avoid having the change the
> semantics of the
> walreceiver
On 2020-Mar-27, Alvaro Herrera wrote:
> I pushed the wal_receiver_create_temp_slot bugfix, because I realized
> after looking for long enough at WalReceiverMain() that the code was
> beyond saving. I'll be pushing the rest of this later today.
So here's the next one. I still have to go over
On 2020-Mar-27, Sergei Kornilov wrote:
> Hello
>
> > I realized that the reason the tests broke after Sergei's patch is that
> > recovery/t/001_stream_rep.pl's get_slot_xmins() is broken for temp
> > walreceiver slots, since it's using the non-temp name it tries to give
> > to the slot, rather
Hello
In other words, patches in reverse order:
0001 will change primary_conninfo and primary_slot_name to reloadable
0002 will move wal_receiver_create_temp_slot logic to startup process (without
changing to PGC_POSTMASTER)
0003 is new draft patch: wal_receiver_create_temp_slot will use the
Hello
> I realized that the reason the tests broke after Sergei's patch is that
> recovery/t/001_stream_rep.pl's get_slot_xmins() is broken for temp
> walreceiver slots, since it's using the non-temp name it tries to give
> to the slot, rather than the temp name under which it is actually
>
On Thu, Mar 26, 2020 at 09:39:17PM -0300, Alvaro Herrera wrote:
> Now, would anyone be too upset if I push these in this other order? I
> realized that the reason the tests broke after Sergei's patch is that
> recovery/t/001_stream_rep.pl's get_slot_xmins() is broken for temp
> walreceiver slots,
Now, would anyone be too upset if I push these in this other order? I
realized that the reason the tests broke after Sergei's patch is that
recovery/t/001_stream_rep.pl's get_slot_xmins() is broken for temp
walreceiver slots, since it's using the non-temp name it tries to give
to the slot, rather
Hello
Thank you! You were ahead of me. I wanted to double-check my changes this
morning before posting.
> Sergei included LOG messages to indicate which setting has been changed.
> I put these in "#if 0" for now, but I'm thinking to remove these
> altogether;
No objections.
> Not sure if we
On Wed, Mar 25, 2020 at 09:08:12PM -0300, Alvaro Herrera wrote:
> ... as in the attached version.
Patch 0001 is one that has already been discussed previously (thanks
for keeping the extra comments about GUCs and WAL receivers). That
looks fine to me.
> Sergei included LOG messages to indicate
On 2020-Mar-24, Alvaro Herrera wrote:
> I think the startup sighup handler should be in startup.c, not xlog.c,
> which has enough random code already. We can add an accessor in xlog.c
> to let changing the walrcv status flag, to be called from the signal
> handler.
... as in the attached
I think the startup sighup handler should be in startup.c, not xlog.c,
which has enough random code already. We can add an accessor in xlog.c
to let changing the walrcv status flag, to be called from the signal
handler.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL
Hello
>> Well, it seems better to move this patch to next commitfest?
>
> What? You want to make wal_receiver_create_temp_slot unchangeable and
> default to off in pg13, and delay the patch that fixes those things to
> pg14? That makes no sense to me.
I want to handle similar things in a
On 2020-Mar-17, Sergei Kornilov wrote:
> Well, it seems better to move this patch to next commitfest?
What? You want to make wal_receiver_create_temp_slot unchangeable and
default to off in pg13, and delay the patch that fixes those things to
pg14? That makes no sense to me. Please keep them
Hello
Sorry for late replies.
> Yes. In my opinion, patch 0002 should not change the GUC mode of
> wal_receiver_create_temp_slot as the discussion here is about
> primary_conninfo, even if both may share some logic regarding WAL
> receiver shutdown and its restart triggered by the startup
On Fri, Mar 13, 2020 at 11:17:38AM -0300, Alvaro Herrera wrote:
> ... oh, that's exactly what 0002 does. So patch 0001 is only about
> making a temporary change to the create_temp_slot to be consistent with
> existing policy, before changing the policy.
Yes. In my opinion, patch 0002 should not
On 2020-Jan-22, Michael Paquier wrote:
> On Tue, Jan 21, 2020 at 06:03:18PM +0300, Sergei Kornilov wrote:
> > PS: also, I surprised why it's ok for wal_receiver_create_temp_slot
> > to be PGC_SIGHUP and ignore change of this setting until walreceiver
> > will reconnect by unrelated reason. I
On 2020-Mar-13, Alvaro Herrera wrote:
> What are the downsides of changing wal_receiver_create_temp_slot to
> PGC_POSTMASTER? It seems pretty nasty to requires a full server
> restart. Maybe we can signal all walreceivers at that point so that
> they restart with the correct setting? That's
Hello
Small rebase due to merge conflict of the tests. No functional changes since v7.
PS: also it is end of current CF, I will mark patch entry as moved to the next
CF.diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 2e2af9e96e..7887391bbb 100644
---
Hello
> Yeah, you are right. I was not paying much attention but something
> does not stick here. My understanding is that we should have the WAL
> receiver receive the value it needs to use from the startup process
> (aka via RequestXLogStreaming from xlog.c), and that we ought to make
> this
On Tue, Jan 21, 2020 at 06:03:18PM +0300, Sergei Kornilov wrote:
> PS: also, I surprised why it's ok for wal_receiver_create_temp_slot
> to be PGC_SIGHUP and ignore change of this setting until walreceiver
> will reconnect by unrelated reason. I means walreceiver does nothing
> special on SIGHUP.
Hello
"Waiting on Author" is the right status. I found logical conflict with recently
added wal_receiver_create_temp_slot GUC and my tests are currently broken. Will
fix it and post new version.
PS: also, I surprised why it's ok for wal_receiver_create_temp_slot to be
PGC_SIGHUP and ignore
Hi,
I'm a bit confused by the status of this patch - it's marked as Waiting
on Author (since last week), but that status was set by Sergei Kornilov
who is also the patch author. And there have been no messages since the
beginning of 2019-11 CF.
So what's the current status of this patch?
Hello
> So, I'd like to propose to move the stuff to the second switch().
> (See the attached incomplete patch.) This is rather similar to
> Sergei's previous proposal, but the structure of the state
> machine is kept.
Very similar to my v4 proposal (also move RequestXLogStreaming call), but
Hello.
At Sat, 21 Sep 2019 13:06:25 +0300, Sergei Kornilov wrote in
<41171569060...@myt5-b646bde4b8f3.qloud-c.yandex.net>
> Hello
>
> Thank you for review! Can you please also check v4 version? v5 implements
> design suggested by Kyotaro Horiguchi-san, while v4 has another design. Which
>
Hi,
On 2019-09-19 17:46:06 +0300, Sergei Kornilov wrote:
>
> - This parameter can only be set at server start.
> + This parameter can only be set in the
> postgresql.conf
> + file or on the server command line.
>This setting has no effect if the
Hello
Thank you for review!
> - This parameter can only be set at server start.
> + This parameter can only be set in the postgresql.conf
> + file or on the server command line.
>
> I'm not sure it's good to change the context of this
> description. This was mentioning that changing of this
Hello. I looked this and have some comments.
At Wed, 28 Aug 2019 12:49:46 +0300, Sergei Kornilov wrote in
<34084371566985...@sas1-0a6c2e2b59d7.qloud-c.yandex.net>
sk> Hello
sk>
sk> Updated patch attached. (also I merged into one file)
sk>
sk> > +
sk> > + WAL receiver will be restarted after
Hello
Thank you for review!
> ISTM that you need to update the above parts in postgresql.conf.sample.
Good catch, I forgot about conf sample.
> ISTM that you need to update the above comment in walreceiver.c.
Changed
> If primary_conninfo is set to an empty string, walreceiver just shuts
On Wed, Aug 28, 2019 at 6:50 PM Sergei Kornilov wrote:
>
> Hello
>
> Updated patch attached. (also I merged into one file)
Thanks for updating the patch! Here are some comments from me.
#primary_conninfo = '' # connection string to sending server
# (change requires restart)
Hello
Updated patch attached. (also I merged into one file)
> +
> + WAL receiver will be restarted after primary_slot_name
> + was changed.
>
> The sentence sounds strange. Here is a suggestion:
> The WAL receiver is restarted after an update of primary_slot_name (or
>
Hello
> It has been some time, and I am finally catching up with this patch.
Thank you!
> +
> + WAL receiver will be restarted after primary_slot_name
> + was changed.
>
> The sentence sounds strange. Here is a suggestion:
> The WAL receiver is restarted after an update of
On Thu, Aug 01, 2019 at 09:06:59PM +1200, Thomas Munro wrote:
> Unfortunately this comes right that the end of the CF, but the good
> news is that there is another one just around the corner. Moved to
> September.
Moving it to the next CF is fine, thanks. The author had no time to
reply since
On Tue, Jul 30, 2019 at 6:42 PM Michael Paquier wrote:
> On Mon, Jul 01, 2019 at 02:33:39PM +0300, Sergei Kornilov wrote:
> > Updated version attached. Merge conflict was about tests count in
> > 001_stream_rep.pl. Nothing else was changed. My approach can be
> > still incorrect, any redesign
On Mon, Jul 01, 2019 at 02:33:39PM +0300, Sergei Kornilov wrote:
> Updated version attached. Merge conflict was about tests count in
> 001_stream_rep.pl. Nothing else was changed. My approach can be
> still incorrect, any redesign ideas are welcome. Thanks in advance!
It has been some time, and
Hello
Updated version attached. Merge conflict was about tests count in
001_stream_rep.pl. Nothing else was changed. My approach can be still
incorrect, any redesign ideas are welcome. Thanks in advance!
regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index
On 2019-04-04 11:06:05 +0900, Michael Paquier wrote:
> On Thu, Apr 04, 2019 at 12:27:55AM +0300, Sergei Kornilov wrote:
> > Not agree. Latest patch version perform walreceiver restart without
> > switch to a different method as discussed. Here is no race condition
> > between startup process and
On Thu, Apr 04, 2019 at 12:27:55AM +0300, Sergei Kornilov wrote:
> Not agree. Latest patch version perform walreceiver restart without
> switch to a different method as discussed. Here is no race condition
> between startup process and walreceiver because conninfo passed via
> WalRcvData struct as
Hi
>> > I think we unfortunately got to mark this as returned with
>> > feedback. I've not done so, but just switched the entry to waiting on
>> > author.
>>
>> Why returned with feedback? Why waiting on author? I didn't receive a
>> feedback for latest published patch version. What can I
Hi,
On 2019-04-03 23:49:54 +0300, Sergei Kornilov wrote:
> > I think we unfortunately got to mark this as returned with
> > feedback. I've not done so, but just switched the entry to waiting on
> > author.
>
> Why returned with feedback? Why waiting on author? I didn't receive a
> feedback for
Hi
> I think we unfortunately got to mark this as returned with
> feedback. I've not done so, but just switched the entry to waiting on
> author.
Why returned with feedback? Why waiting on author? I didn't receive a feedback
for latest published patch version. What can I do as author? Patch
Hi,
On 2019-03-25 12:32:21 +0400, David Steele wrote:
> On 3/4/19 7:19 AM, Michael Paquier wrote:
> > On Sat, Mar 02, 2019 at 01:49:51PM +0300, Sergei Kornilov wrote:
> > > This might be not the right way, but I can't think of a better way
> > > to not switch to a different method than split of
Hi Michael,
On 3/4/19 7:19 AM, Michael Paquier wrote:
On Sat, Mar 02, 2019 at 01:49:51PM +0300, Sergei Kornilov wrote:
This might be not the right way, but I can't think of a better way
to not switch to a different method than split of lastSourceFailed
processing and starting new source.
On Sat, Mar 02, 2019 at 01:49:51PM +0300, Sergei Kornilov wrote:
> This might be not the right way, but I can't think of a better way
> to not switch to a different method than split of lastSourceFailed
> processing and starting new source. Something like refactoring in
> first attached patch. I
Hello
This might be not the right way, but I can't think of a better way to not
switch to a different method than split of lastSourceFailed processing and
starting new source. Something like refactoring in first attached patch. I move
RequestXLogStreaming logic from lastSourceFailed processing
On Mon, Feb 18, 2019 at 12:06:05AM +0300, Sergei Kornilov wrote:
> Ok. This was not mentioned before Michael response
> yesterday. restore_command is much faster compared to database
> restart [...]
The startup process would not switch back to streaming with archiving
enabled until it has
Hi
> For one, it's not ok to just let the startup process think that the
> walreceiver failed - that'll make it change source of WAL to the next
> available method. Something we definitely do not want, as
> restore_command is very commonly slower.
Ok. This was not mentioned before Michael
Hi,
On 2019-02-16 14:50:35 +0300, Sergei Kornilov wrote:
> > I don't quite think this is the right design. IMO the startup process
> > should signal the walreceiver to shut down, and the wal receiver should
> > never look at the config.
>
> Ok, i can rewrite such way. Please check attached
Hi
> If you do that, the startup process would try to jump to a different
> source to fetch WAL if archiving is enabled. Is that really what we
> want?
Yes, similar behavior with exit walreceiver by any reason. Same as in all
previous patch versions.
(not sure this can be changed in some small
On Sat, Feb 16, 2019 at 02:50:35PM +0300, Sergei Kornilov wrote:
> + if ((strcmp(conninfo, PrimaryConnInfo) != 0 ||
> + strcmp(slotname, PrimarySlotName) != 0) &&
> + WalRcvRunning())
> + {
> + ereport(LOG,
> +
Hi
> I don't quite think this is the right design. IMO the startup process
> should signal the walreceiver to shut down, and the wal receiver should
> never look at the config.
Ok, i can rewrite such way. Please check attached version.
> Otherwise there's chances for knowledge of
> pg.conf to
Hi,
On 2019-02-03 15:33:38 +0300, Sergei Kornilov wrote:
> +/*
> + * Actual processing SIGHUP signal
> + */
> +static void
> +ProcessWalRcvSigHup(void)
> +{
> + ProcessConfigFile(PGC_SIGHUP);
> +
> + /*
> + * If primary_conninfo has been changed while walreceiver is running,
> +
Hi
> I agree that this doesn't need to be solved as part of this patch.
Thank you!
> Are you planning to update the patch?
Sorry, i was busy last month. But, well, i already did such update:
https://www.postgresql.org/message-id/9653601544523383%40iva8-37fc2ad204cd.qloud-c.yandex.net
v003
Hi,
On 2019-01-31 16:13:22 +0300, Sergei Kornilov wrote:
> Hello
>
> Yeah, we have no consensus.
>
Are you planning to update the patch? Given there's not been much
progress here, I think we ough tot mark the CF entry as returned with
feedback for now.
> Another open question is about
On Thu, Jan 31, 2019 at 04:13:22PM +0300, Sergei Kornilov wrote:
> I my opinion this is not issue, database logs can have sensitive
> data. User queries, for example. If we not want expose such info -
> it is ok just hide new value from logs with new GUC flag? Or i need
> implement masked
Hello
Yeah, we have no consensus.
Another open question is about logging new primary_conninfo:
> LOG: parameter "primary_conninfo" changed to "host=/tmp port=5432
> password=hoge"
I my opinion this is not issue, database logs can have sensitive data. User
queries, for example.
If we not want
Hi,
On 2018-12-14 16:55:42 +0900, Michael Paquier wrote:
> On Thu, Dec 13, 2018 at 01:51:48PM +0300, Sergei Kornilov wrote:
> > Depends on this discussion:
> > https://www.postgresql.org/message-id/20181212053042.gk17...@paquier.xyz
> > If walreceiver will use GUC conninfo for startup - then
Hi
> I would recommend waiting for the conclusion of other thread before
> moving on with this one.
Agreed.
I mark this patch as Waiting on Author. Not quite correct for waiting another
discussion, but most suitable.
> We could also consider using
> the show hook function of a parameter to
On Thu, Dec 13, 2018 at 01:51:48PM +0300, Sergei Kornilov wrote:
> Depends on this discussion:
> https://www.postgresql.org/message-id/20181212053042.gk17...@paquier.xyz
> If walreceiver will use GUC conninfo for startup - then yes, we can
> remove such static variables. If walreceiver will
Hello
> Do we no longer need static version of conninfo/slotname in
> walreceiver.c? We can detect a change of the variables without
> them (as you did in the previous version.).
Depends on this discussion:
https://www.postgresql.org/message-id/20181212053042.gk17...@paquier.xyz
If walreceiver
At Tue, 11 Dec 2018 13:16:23 +0300, Sergei Kornilov wrote in
<9653601544523...@iva8-37fc2ad204cd.qloud-c.yandex.net>
sk> oops, forgot attach patch
sk>
sk> 11.12.2018, 13:14, "Sergei Kornilov" :
sk> > Hello
sk> >
sk> > After some thinking i can rewrite this patch in another way.
sk> >
sk> > This
On Tue, Dec 11, 2018 at 11:59:08AM +0300, Sergei Kornilov wrote:
>> but I think that this patch should document clearly that if
>> primary_conninfo or primary_slot_name are changed then the WAL receiver
>> is stopped immediately.
>
> Good idea, will change.
+
+ walreceiver will
oops, forgot attach patch
11.12.2018, 13:14, "Sergei Kornilov" :
> Hello
>
> After some thinking i can rewrite this patch in another way.
>
> This is better or worse?
>
> regards, Sergeidiff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 4a7121a..bce99ce 100644
---
Hello
After some thinking i can rewrite this patch in another way.
This is better or worse?
regards, Sergei
Hello
thank you for review!
> but I think that this patch should document clearly that if
> primary_conninfo or primary_slot_name are changed then the WAL receiver
> is stopped immediately.
Good idea, will change.
> /*
> - * replication slot name; is also used for walreceiver to connect
On Mon, Nov 26, 2018 at 09:46:36AM -0800, Andres Freund wrote:
> I'm not sure I understand what you mean? The way I'd solve this is that
> that only walreceiver, at startup, writes out its conninfo/slot_name,
> sourcing the values from the GUCs. That way there's no issue with values
> being
Hi
>> Hmm... I considered SIGHUP processing was in fast loop and therefore
>> shutdown should be fast. But i recheck code and found a possible long loop
>> without processing SIGHUP (in case we receive new data faster than writes to
>> disk). Ok, i will revert back.
>> How about write to
Hi,
On 2018-11-26 12:30:06 +0300, Sergei Kornilov wrote:
> Hmm... I considered SIGHUP processing was in fast loop and therefore shutdown
> should be fast. But i recheck code and found a possible long loop without
> processing SIGHUP (in case we receive new data faster than writes to disk).
>
Hi
>> I think we have no futher reason to have a copy of conninfo and slot name
>> in WalRcvData, so i propose remove these fields from
>> pg_stat_get_wal_receiver() (and pg_stat_wal_receiver view). This data can be
>> accesible now via regular GUC commands.
>
> Is that wise? It seems
On Sun, Nov 25, 2018 at 01:43:13PM -0800, Andres Freund wrote:
> On 2018-11-26 00:25:43 +0300, Sergei Kornilov wrote:
>> I think we have no futher reason to have a copy of conninfo and slot
>> name in WalRcvData, so i propose remove these fields from
>> pg_stat_get_wal_receiver() (and
Hi,
On 2018-11-26 00:25:43 +0300, Sergei Kornilov wrote:
> Now we integrate recovery.conf into GUC system. So i would like to start
> discussion to make primary_conninfo and primary_slot_name PGC_SIGHUP.
> My work-in-progress patch attached.
Cool!
> I think we have no futher reason to have a
75 matches
Mail list logo
