From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Arjun Ranade <ranade(at)nodalexchange(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Missing Chunk Error when doing a VACUUM FULL operation - DB Corruption? |
Date: | 2017-10-31 22:12:39 |
Message-ID: | 29089.1509487959@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Arjun Ranade <ranade(at)nodalexchange(dot)com> writes:
> There is nothing in pg_prepared_xacts, however, in pg_stat_activity there
> are two pglogical processes that have a "backend_start" of "2017-06-17"
> when the last time we restarted this server. Both are not waiting and have
> null for "state." This might be expected behavior for pglogical.
I don't know much about pglogical, but if it's holding back the xmin
horizon (as it appears to be doing) that is a really bad pglogical bug.
If you try vacuum verbose (doesn't have to be FULL) on some table that
gets lots of update traffic, does it report a large number of dead-but-
not-removable rows?
> I did try TRUNCATE before but even as the postgres user, but for some
> reason it didn't allow me to truncate because it was a system table.
Mmm. You could get around that, but possibly not without restarting
in single-user mode, which is probably more interruption in service
than you want. It might be easier to force-quit the pglogical sessions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Arjun Ranade | 2017-11-01 02:37:28 | Re: Missing Chunk Error when doing a VACUUM FULL operation - DB Corruption? |
Previous Message | Arjun Ranade | 2017-10-31 22:08:20 | Re: Missing Chunk Error when doing a VACUUM FULL operation - DB Corruption? |