Hi.
I've found a situation on one of my PG 9.1 servers where pg_dump
running on a hot standby gets terminated when a tble on the master is
vacuumed. This is PostgreSQL 9.1.4, and purely streaming replication.
pg_dump: Error message from server: ERROR: canceling statement due to
conflict with recovery
DETAIL: User was holding shared buffer pin for too long.
pg_dump: The command was: COPY public.webcatalog_machine (id,
owner_id, uuid, hostname, packages_checksum, package_list,
logo_checksum) TO stdout;
pg_dump: *** aborted because of error
hot_standby_feedback is on, and my understanding is that this should
instruct the master that there is still an open transaction and vacuum
should not clean stuff up that is still in use on the hot standby.
Replication is otherwise working flawlessly, and I've confirmed that
the walstreamer has been alive the whole time.
The pg_dump works when no vacuum kicks in, but I have reproduced the
fault by manually running vacuum on the master once the pg_dump has
started on this larger table.
I think I must be missing something, as I don't see this on my other
servers. This database isn't particularly large, with pg_dump
finishing in a few minutes. I'm successfully using pg_dump on other
hot standbys that take half a day to dump with tables active enough
that they certainly should have triggered autovacuums.
--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/
