Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery
От | Erik Rijkers |
---|---|
Тема | Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery |
Дата | |
Msg-id | f20d2701fbb347054cd483f605090708.squirrel@webmail.xs4all.nl обсуждение исходный текст |
Ответ на | Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Thu, February 18, 2010 23:32, Andres Freund wrote: > On Thursday 18 February 2010 22:25:35 Erik Rijkers wrote: >> 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 [...] >> 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 >> [...] >> 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. That worked - and I see has already been committed, thanks. There is another small issue related to this dumping into a readonly slave: With multiline columns (at least, I think that's the reason), there are on STDERR endless occurrences of: invalid command \N and invalid command \ There can be millions of these lines (obviously). On top of that, the logfile gets appended with 'syntax error', follwed by the whole dump: ERROR: syntax error at or near "18726" at character 1 STATEMENT: 18726 16883 [...] [whole dump follows here] This does maybe not really qualify as a bug, but it does seem unnecessary to spam a readonly standby with all this. (come to think of it, 'syntax error' is a bit off in any case) Thanks, Erik Rijkers
В списке pgsql-hackers по дате отправления: