Tom Lane [tgl@xxxxxxxxxxxxx] wrote:
They might have been blocked behind some other process that was sitting
in an open transaction for some reason. The other likely cause is badly
chosen autovacuum delay, but I think that was already covered.
Well, after I noticed this running for a while, I shutdown the postgres
port and restarted postgres. The autovacuum of these tables kicked in
promptly when postgres was back up. I then let them run. So, I don't
think that surmise #1 is likely.
As for #2, I'm using the default. These tables get updated once a day
with each row (potentially) being updated 1-24 times over many minutes
to a handful of hours. Dp you think it would be better to manually
vacuum these tables? If so, would it be best to disable autovacuum of
them? And while I'm at it, if you disable autovacuum of the master table
will that disable it for the actual partitions?
> Don't assume every row in pg_locks has a join partner in pg_class.
You could use an outer join ...
Yes, of course. It never occurred that there could be db locks not
associated with tables.
Thanks,
Brian
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
