Horton

Re: Shaky coding for vacuuming partitioned relations

Nathan Bossart <bossartn@amazon.com>

View thread View on postgr.es
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Date: 2017-09-25T16:47:05Z
Lists: pgsql-hackers 
On 9/24/17, 10:12 PM, "Michael Paquier" <michael.paquier@gmail.com> wrote:
> Attached is a proposal of patch.

The patch seems reasonable to me, and I haven't encountered any issues in
my tests, even after applying the vacuum-multiple-relations patch on top
of it.

+		 * Take a lock here for the relation lookup. If ANALYZE or VACUUM spawn
+		 * multiple transactions, the lock taken here will be gone once the
+		 * current transaction running commits, which could cause the relation
+		 * to be gone, or the RangeVar might not refer to the OID looked up here.

I think this could be slightly misleading.  Perhaps it would be more
accurate to say that the lock will be gone any time vacuum() creates a new
transaction (either in vacuum_rel() or when use_own_xacts is true).

Nathan

Commits

  1. Fix inadequate locking during get_rel_oids().