Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery - Mailing list pgsql-hackers

From Andres Freund
Subject Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery
Date
Msg-id 201002182332.16729.andres@anarazel.de
Whole thread Raw
In response to testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery  ("Erik Rijkers" <er@xs4all.nl>)
Responses 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
List 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 by date:

Previous
From: "Erik Rijkers"
Date:
Subject: Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery
Next
From: Tom Lane
Date:
Subject: Re: auto_explain causes regression failures