Re: pg_receivewal starting position
Ronan Dunklau <ronan.dunklau@aiven.io>
From: Ronan Dunklau <ronan.dunklau@aiven.io>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2021-09-02T07:02:57Z
Lists: pgsql-hackers
Le jeudi 2 septembre 2021, 08:42:22 CEST Bharath Rupireddy a écrit : > 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. Then it should probably be documented. We write in the docs that it is strongly recommended to use a replication slot, but do not mention how we resume from have been already processed. If someone really cares about having control over how the start position is defined instead of relying on the auto detection, it would be wiser to add a -- startpos parameter similar to the endpos one, which would override everything else, instead of different flags for different behaviours. Regards, -- Ronan Dunklau
Commits
-
Add TAP test for pg_receivewal with timeline switch
- 0f9b9938a036 15.0 landed
-
Speed up TAP tests of pg_receivewal
- d680992af540 15.0 landed
-
Allow pg_receivewal to stream from a slot's restart LSN
- f61e1dd2cee6 15.0 landed
-
Add replication command READ_REPLICATION_SLOT
- b4ada4e19fd7 15.0 landed
-
doc: Describe calculation method of streaming start for pg_receivewal
- 438d467a5241 10.19 landed
- e6c5f1b45265 11.14 landed
- fb1aa489e481 12.9 landed
- 7c949f1b3aab 13.5 landed
- affec9f6a2de 14.1 landed
- 1e9475694b0a 15.0 landed
-
Add PostgresNode::command_fails_like()
- de1d4fef71cb 15.0 landed