Fred Habash writes:
> According to pgstattuple, dead_tuple_count = 0. If this is the case, then
> what other explanations do we have?
Could be that old tuple(s) now require freezing.
> I mean, how can I find out what blocker
> session is holding the bufferpin to terminate it?
I don't think ther
According to pgstattuple, dead_tuple_count = 0. If this is the case, then
what other explanations do we have? I mean, how can I find out what blocker
session is holding the bufferpin to terminate it?
SELECT * FROM pgstattuple('.*'::regclass);
table_len | tuple_count | tuple_len | tuple_p
Fred Habash writes:
> pg_locks shows no blockers while this is happening. This view shows a
> constant 13 sessions running SELECT statements on this table posting
> AccessShareLock. Of course, these is also the AV sessions
> with ShareUpdateExclusiveLock
> ...
> Why is AV blocked by bufferpin give
I have a very small table of 28 rows that is less than 10kB. One of the AV
workers has been stuck autovac'ing it for over 20 hrs now with no progress
in heap blocks scanned or vac'd. I terminated the AV worker and ran a
manual vac which also ended up stuck waiting for a bufferpin.
pg_locks shows n
