From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | "Erik Rijkers" <er(at)xs4all(dot)nl> |
Subject: | Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery |
Date: | 2010-02-18 22:32:14 |
Message-ID: | 201002182332.16729.andres@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
prevent-setval-during-recovery.patch | text/x-patch | 519 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-02-18 23:22:48 | Re: auto_explain causes regression failures |
Previous Message | Erik Rijkers | 2010-02-18 22:13:19 | Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery |