From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Subject: | Re: pg_receivewal starting position |
Date: | 2021-09-02 06:42:22 |
Message-ID: | CALj2ACUOkq=w4jFZiRxEgh3wBk8B=GvB5KjH0m+HO3b1mBuKwQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 2, 2021 at 11:15 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Wed, 1 Sep 2021 10:30:05 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> > On Mon, Aug 30, 2021 at 3:26 PM Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Ronan Dunklau | 2021-09-02 07:02:57 | Re: pg_receivewal starting position |
Previous Message | vignesh C | 2021-09-02 06:35:44 | Re: Added schema level support for publication. |