Re: pg_receivexlog sometimes fails on first start
От | Fujii Masao |
---|---|
Тема | Re: pg_receivexlog sometimes fails on first start |
Дата | |
Msg-id | CAHGQGwHa37F4gmH3_+p6qoePhTueqonzTqnj=AZq1sDa_0neWw@mail.gmail.com обсуждение исходный текст |
Ответ на | pg_receivexlog sometimes fails on first start (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: pg_receivexlog sometimes fails on first start
|
Список | pgsql-bugs |
On Fri, Feb 6, 2015 at 6:17 AM, Heikki Linnakangas <hlinnakangas@vmware.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
В списке pgsql-bugs по дате отправления: