Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?
Date
Msg-id CAB7nPqSaWrJD0fVN4uX=e=D9FqEYqPq-S2X_TC60kJ0YX2-5eQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least9.5)?  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?
List pgsql-hackers
On Thu, Oct 26, 2017 at 3:05 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> The largest obstacle to do that is that walreceiver is not
> utterly concerned to record internals. In other words, it doesn't
> know what a record is. Teaching that introduces much complexity
> and the complexity slows down the walreceiver.
>
> Addition to that, this "problem" occurs also on replication
> without a slot. The latest patch also help the case.

That's why replication slots have been introduced to begin with. The
WAL receiver gives no guarantee that a segment will be retained or not
based on the beginning of a record. That's sad that the WAL receiver
does not track properly restart LSN and instead just uses the flush
LSN. I am beginning to think that a new message type used to report
the restart LSN when a replication slot is in use would just be a
better and more stable solution. I haven't looked at the
implementation details yet though.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Timeline ID in backup_label file
Next
From: Sokolov Yura
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions