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@xxxxxxxxxxxxxxxx> http://www.stuartbishop.net/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
