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

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
whileprocessing 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);
LOG:  server process (PID 25753) was terminated by signal 6: Aborted
LOG:  terminating any other active server processes
LOG:  database system was interrupted while in recovery at log time 2010-02-18 16:38:39 CET
HINT:  If this has occurred more than once some data might be corrupted and you might need to
choose an earlier recovery target.
cp: cannot stat `/var/data1/pg_stuff/dump/hotslave/replication_archive/0000000100000088000000E7':
No such file or directory
LOG:  entering standby mode
LOG:  redo starts at 88/E500E4E8
LOG:  consistent recovery state reached at 89/2C800000
LOG:  database system is ready to accept read only connections
[...]


It doesn't happen with just any table (I tried that), so maybe it has some connection with this
specific table, sequence, or sequence name.


There is another (500 GB) replication connection running from a 9.0devel primary to this same
9.0devel slave; the slave seems to pick up that work OK after the restart.  I want to mention that
here, but I don't think it causes/influences this panic.

And to be clear: I realize that one cannot expect a pg_dump at a slave to work: I only did this
accidentally.  Nevertheless, ISTM it shouldn't PANIC...

hth,

Erik Rijkers