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

From: "Erik Rijkers" <er(at)xs4all(dot)nl>
To: "Andres Freund" <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: testing cvs HEAD - HS/SR - PANIC: cannot make new WAL entries during recovery
Date: 2010-02-19 15:33:43
Message-ID: f20d2701fbb347054cd483f605090708.squirrel@webmail.xs4all.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-02-19 15:43:04 Re: PGXS: REGRESS_OPTS=--load-language=plpgsql
Previous Message Teodor Sigaev 2010-02-19 15:10:01 Fwd: Re: Merge join and index scan strangeness