At Wed, 1 Sep 2021 10:30:05 +0530, Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote in > On Mon, Aug 30, 2021 at 3:26 PM Ronan Dunklau <ronan.dunk...@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. regards. -- Kyotaro Horiguchi NTT Open Source Software Center