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
