Re: Shaky coding for vacuuming partitioned relations
Nathan Bossart <bossartn@amazon.com>
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-26T00:04:38Z
Lists: pgsql-hackers
On 9/25/17, 6:51 PM, "Michael Paquier" <michael.paquier@gmail.com> wrote: >> + * 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). > > The comment of the proposed patch matches as much as possible what is > currently on HEAD, so I would still go with something close to that. Sure. This is just a minor point, and I could see the argument that your phrasing is more concise, anyway. Nathan
Commits
-
Fix inadequate locking during get_rel_oids().
- 19de0ab23ccb 11.0 landed
- 2aab70205be0 10.0 landed