Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery
От | Andres Freund |
---|---|
Тема | Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery |
Дата | |
Msg-id | 201002182332.16729.andres@anarazel.de обсуждение исходный текст |
Ответ на | testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery ("Erik Rijkers" <er@xs4all.nl>) |
Ответы |
Re: testing cvs HEAD - HS/SR - PANIC: cannot make new
WAL entries during recovery
Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery |
Список | pgsql-hackers |
On Thursday 18 February 2010 22:25:35 Erik Rijkers wrote: > When accidentally running pg_dump from an 8.4.2 instance into a 9.0devel > (cvs as of 2010.02.17) slave as below, this causes a PANIC. The slave can > be restarted. > > localhost:55432 => 8.4.2 instance (ssh tunnel) > /tmp:7575 => a 9.0devel standby > > time pg_dump -h localhost -p 55432 -t public.tab_jobs --clean --no-owner > --no-privileges ms | psql -q -h /tmp -p 7575 -d replicas > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > ERROR: transaction is read-only > PANIC: cannot make new WAL entries during recovery > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > connection to server was lost > > real 0m5.569s > > > After re-starting the slave, its logfile shows this: > > [...] > STATEMENT: ALTER TABLE ONLY tab_jobs ALTER COLUMN db SET STATISTICS 10000; > ERROR: transaction is read-only > STATEMENT: CREATE SEQUENCE tab_jobs_id_seq > START WITH 1 > INCREMENT BY 1 > NO MINVALUE > NO MAXVALUE > CACHE 1; > ERROR: transaction is read-only > STATEMENT: ALTER SEQUENCE tab_jobs_id_seq OWNED BY tab_jobs.id; > PANIC: cannot make new WAL entries during recovery > STATEMENT: SELECT pg_catalog.setval('tab_jobs_id_seq', 31907, true); Hm, yea. setval() simply misses a check there (it was added for nextval though). I wonder if there are other functions bypassing the layers like setval/nextval? Trivial patch attached. Andres
В списке pgsql-hackers по дате отправления: