Arjun Ranade <ranade@xxxxxxxxxxxxxxxxx> writes: > So we had a maintenance window scheduled today and I restarted the DB. > When it came back up, it reported the same toast error when vacuum'ing > pg_statistic. It also reported the "oldest xmin is far in the past" error. > I even brought the DB into single user mode and tried to manually vacuum > pg_statistic but got the same error. I also tried to TRUNCATE pg_statistic > in single user mode which failed (see below). > At this point, I am not sure what to make of the issue. The DB is still > complaining about old XMIN even when there are no users connected to it > after a fresh restart: Clearly, something is holding back the xmin horizon, and if the behavior persisted past a DB restart then it surely isn't a regular transaction. Are you *really* sure there are no prepared transactions? It now occurs to me that there's one other mechanism that could hold back the xmin horizon, and that is replication slots. Looking into the pg_replication_slots view should show you what's up there. I'm not an expert on replication slots, but I do know that they were new as of 9.4. I am thinking maybe your replication setup has "leaked" a slot that's not being used but is still preventing global xmin from advancing. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
