Re: pg_receivexlog and replication slots - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pg_receivexlog and replication slots
Date
Msg-id CABUevEyK4jjfoTBVZEtU2Q0QDvxdRYnaDdbrf8-XxRSPDLie0g@mail.gmail.com
Whole thread Raw
In response to Re: pg_receivexlog and replication slots  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: pg_receivexlog and replication slots
Re: pg_receivexlog and replication slots
List pgsql-hackers
On Tue, Aug 26, 2014 at 9:43 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Aug 19, 2014 at 2:49 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Mon, Aug 18, 2014 at 4:01 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> On Mon, Aug 18, 2014 at 3:48 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>>> On Mon, Aug 18, 2014 at 2:38 PM, Michael Paquier
>>>> <michael.paquier@gmail.com> wrote:
>>> And now looking at your patch there is additional refactoring possible
>>> with IDENTIFY_SYSTEM and pg_basebackup as well...
>> And attached is a rebased patch doing so.
> I reworked this patch a bit to take into account the fact that the
> number of columns to check after running IDENTIFY_SYSTEM is not always
> 4 as pointed out by Andres:
> - pg_basebackup => 3
> - pg_receivexlog => 3
> - pg_recvlogical => 4

As this is a number of patches rolled into one - do you happen to keep
them separate in your local repo? If so can you send them as separate
ones (refactor identify_system should be quite unrelated to supporting
replication slots, right?), for easier review? (if not, I'll just
split them apart mentally, but it's easier to review separately)

On the identify_system part - my understanding of the code is that
what you pass in as num_cols is the number of columns required for it
to work, right? We probably need to adjust the error message as well
in that case, because it's no longer what's "expected", it's what's
"required"? And we might want to include a hint about the reason
(wrong version)?

There's also a note "get LSN start position if necessary", but it
tries to do it unconditionally. What is the "if necessary" supposed to
refer to?

Actually - why do we even care about the 3 vs 4 in RunIdentifySystem,
as it never actually looks at the 4th column anyway? If we do
specifically want it to fail in the case of pg_recvlogical, we really
need to think up a better error message for it, and perhaps a
different way of specifying it?

Do we really want those Asserts? There is not a single Assert in
bin/pg_basebackup today - as is the case for most things in bin/. We
typically use regular if statements for things that "can happen", and
just ignore the others I think - since the callers are fairly simple
to trace.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: COPY and heap_sync
Next
From: Fabrízio de Royes Mello
Date:
Subject: Re: pg_filedump for 9.4?