From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: pg_receivexlog sometimes fails on first start |
Date: | 2015-02-06 00:02:09 |
Message-ID: | CAHGQGwHa37F4gmH3_+p6qoePhTueqonzTqnj=AZq1sDa_0neWw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Feb 6, 2015 at 6:17 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> When starting pg_receivexlog for the first time, i.e. with an empty
> directory, it sometimes fails like this:
>
> pg_receivexlog: unexpected termination of replication stream: ERROR:
> requested starting point 56/70000000 is ahead of the WAL flush position of
> this server 56/6FFC4000
>
> This is easier to reproduce if you have a steady stream of updates, with no
> commits, running concurrently. A bulk load, for example.
>
> The problem is that pg_receivexlog issues the IDENTIFY_SYSTEM command, which
> returns the current WAL insert position. It then requests to start streaming
> from that position. Or to be precise, from the beginning of the WAL segment
> containing that position. That's wrong; the WAL might not be flushed up to
> the insert position yet.
>
> I think returning the insert position in IDENTIFY_SYSTEM is a bad idea. We
> even mention in the documentation that that field is "useful to get a known
> location in the transaction log where streaming can start", but the insert
> position is wrong for that purpose.
Good catch.
> Any objections to changing IDENTIFY_SYSTEM to return the flush position,
> instead of insert position? We haven't heard any complaints from the field
> about this, but IMHO that should also be back-patched. It's a design bug,
> and the fix is simple and unlikely to cause any harm.
+1 with your idea.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-02-06 00:27:04 | Re: pg_receivexlog sometimes fails on first start |
Previous Message | lstrupinskaya | 2015-02-05 21:22:31 | BUG #12739: to_timestamp function conver string to time incorrectly |