Re: pg_receivewal starting position - Mailing list pgsql-hackers
From | Bharath Rupireddy |
---|---|
Subject | Re: pg_receivewal starting position |
Date | |
Msg-id | CALj2ACUOkq=w4jFZiRxEgh3wBk8B=GvB5KjH0m+HO3b1mBuKwQ@mail.gmail.com Whole thread Raw |
In response to | Re: pg_receivewal starting position (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Responses |
Re: pg_receivewal starting position
|
List | pgsql-hackers |
On Thu, Sep 2, 2021 at 11:15 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > > At Wed, 1 Sep 2021 10:30:05 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in > > On Mon, Aug 30, 2021 at 3:26 PM Ronan Dunklau <ronan.dunklau@aiven.io> wrote: > > > > 7) How about we let pg_receivewal use READ_REPLICATION_SLOT as an option? > > > > > > From my point of view, I already expected it to use something like that when > > > using a replication slot. Maybe an option to turn it off could be useful ? > > > > IMO, pg_receivewal should have a way to turn off/on using > > READ_REPLICATION_SLOT. Imagine if the postgres server doesn't support > > READ_REPLICATION_SLOT (a lower version) but for some reasons the > > pg_receivewal(running separately) is upgraded to the version that uses > > READ_REPLICATION_SLOT, knowing that the server doesn't support > > READ_REPLICATION_SLOT why should user let pg_receivewal run an > > unnecessary code? > > If I read the patch correctly the situation above is warned by the > following message then continue to the next step giving up to identify > start position from slot data. > > > "server does not suport fetching the slot's position, resuming from the current server position instead" > > (The message looks a bit too long, though..) > > However, if the operator doesn't know the server is old, pg_receivewal > starts streaming from unexpected position, which is a kind of > disaster. So I'm inclined to agree to Bharath, but rather I imagine of > an option to explicitly specify how to determine the start position. > > --start-source=[server,wal,slot] specify starting-LSN source, default is > trying all of them in the order of wal, slot, server. > > I don't think the option doesn't need to accept multiple values at once. If --start-source = 'wal' fails, then pg_receivewal should show up an error saying "cannot find start position from <<user-specified-wal>> directory, try with "server" or "slot" for --start-source". We might end having similar errors for other options as well. Isn't this going to create unnecessary complexity? The existing way the pg_receivewal fetches start pos i.e. first from wal directory and then from server start position, isn't known to the user at all, no verbose message or anything specified in the docs. Why do we need to expose this with the --start-source option? IMO, we can keep it that way and we can just have a way to turn off the new behaviour that we are proposing here, i.e.fetching the start position from the slot's restart_lsn. Regards, Bharath Rupireddy.
pgsql-hackers by date: