Re: [COMMITTERS] pgsql: Allow a streaming replication standby to follow a timeline switc
От | Heikki Linnakangas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Allow a streaming replication standby to follow a timeline switc |
Дата | |
Msg-id | 50D30984.2010204@vmware.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Allow a streaming replication standby to follow a timeline switc (hubert depesz lubaczewski <depesz@depesz.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Allow a streaming replication standby to
follow a timeline switc
|
Список | pgsql-general |
On 18.12.2012 13:42, hubert depesz lubaczewski wrote: > In pg_log on ubuntu2 I see: > > 2012-12-18 12:41:34.428 CET [unknown]@[unknown] 1685 LOG: connection received: host=172.28.173.142 port=45842 > 2012-12-18 12:41:34.430 CET replication@[unknown] 1685 172.28.173.142(45842) LOG: replication connection authorized: user=replication > 2012-12-18 12:41:34.432 CET replication@[unknown] 1685 172.28.173.142(45842) ERROR: requested WAL segment 000000020000000000000015has already been removed > 2012-12-18 12:41:34.433 CET replication@[unknown] 1685 172.28.173.142(45842) LOG: disconnection: session time: 0:00:00.005user=replication database= host=172.28.173.142 port=45842 > > Something looks weird. To put it lightly. Hmm, that's a different error than you got before. Thom also reported a "requested WAL segment ... has already been removed" error, but in his test case, and as far as I could reproduce it, the error doesn't reoccur when the standby reconnects. In other words, it eventually worked despite that error. In any case, I just committed a fix for the scenario that Thom reported. Can you try again with a fresh checkout? - Heikki
В списке pgsql-general по дате отправления: