Re: Assertion failure in walreceiver
От | Heikki Linnakangas |
---|---|
Тема | Re: Assertion failure in walreceiver |
Дата | |
Msg-id | 4B858C42.4080501@enterprisedb.com обсуждение исходный текст |
Ответ на | Assertion failure in walreceiver (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Assertion failure in walreceiver
|
Список | pgsql-hackers |
Greg Stark wrote: > I tried to set up a simple master/slave setup and immediately ran into > this assertion failure. The slave is just a cold copy of the database > immediately after initdb. The first WAL segment hasn't been archived > yet. It sees that the first archive fail hasn't been archived yet, > starts up walreceiver but it looks like the start point hasn't been > initialized yet because it hasn't processed any checkpoint WAL records > yet. > > $ /usr/local/pgsql/bin/postgres -D /var/tmp/pg85/s/ > LOG: database system was shut down at 2010-02-23 14:30:08 GMT > cp: cannot stat `/var/tmp/pg85/w/000000010000000000000000': No such > file or directory > TRAP: FailedAssertion("!(startpoint.xlogid != 0 || startpoint.xrecoff > != 0)", File: "libpqwalreceiver.c", Line: 87) > LOG: WAL receiver process (PID 3536) was terminated by signal 6: Aborted > LOG: terminating any other active server processes > LOG: startup process (PID 3534) exited with exit code 2 > LOG: aborting startup due to startup process failure Hmm, interesting corner case. That assertion is checking that the streaming starting point is initialized correctly, but 0/0 is actually a valid value when you start streaming from the very first WAL segment. I guess we can just remove the assertion. If an incorrect zero value finds its way there due to some bug, nothing particularly bad will happen; you'll just get an error because the WAL segment most likely doesn't exist in the primary anymore. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: