|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||masao(dot)fujii(at)gmail(dot)com, jdnelson(at)dyn(dot)com, pgsql-hackers(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org|
|Subject:||Re: [BUGS] Bug in Physical Replication Slots (at least 9.5)?|
|Views:||Raw Message | Whole Thread | Download mbox|
At Thu, 2 Feb 2017 15:34:33 +0900, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqQ05G15JooRMEONgPkW0osot77yaFAUF9_6Q8G+v+2+xg(at)mail(dot)gmail(dot)com>
> On Thu, Feb 2, 2017 at 1:26 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> > I'm afraid that many WAL segments would start with a continuation record
> > when there are the workload of short transactions (e.g., by pgbench), and
> > which would make restart_lsn go behind very much. No?
> I don't quite understand this argument. Even if there are many small
> transactions, that would cause restart_lsn to just be late by one
> segment, all the time.
> > The discussion on this thread just makes me think that restart_lsn should
> > indicate the replay location instead of flush location. This seems safer.
> That would penalize WAL retention on the primary with standbys using
> recovery_min_apply_delay and a slot for example...
> We can attempt to address this problem two ways. The patch proposed
> (ugly btw and there are two typos!) is doing it in the WAL sender by
> not making restart_lsn jump to the next segment if a continuation
> record is found.
Sorry for the ug..:p Anyway, the previous version was not the
latest. The attached one is the revised version. (Sorry, I
haven't find a typo by myself..)
> Or we could have the standby request for the next
> segment instead if the record it wants to replay from is at a boundary
> and that it locally has the beginning of the record, and it has it
> because it already confirmed to the primary that it flushed to the
> next segment. Not sure which fix is better though.
We could it as I said, with some refactoring ReadRecord involving
reader plugin mechanism..
NTT Open Source Software Center
|Next Message||Ranjeet Singh03||2017-02-03 11:13:54||postgres client connection issue|
|Previous Message||Tom Lane||2017-02-02 22:48:05||Re: BUG #14524: Commands compare with nested subquery expressions fail with "should not reference subplan var"|
|Next Message||Robert Haas||2017-02-03 03:32:43||pgsql: pageinspect: Try to fix some bugs in previous commit.|
|Previous Message||Kyotaro HORIGUCHI||2017-02-03 02:47:16||Re: Logical Replication and Character encoding|