| From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Subject: | Re: Shaky coding for vacuuming partitioned relations |
| Date: | 2017-09-26 00:04:38 |
| Message-ID: | 7FC1B544-8D6D-491C-AD8C-718374F8D1E3@amazon.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9/25/17, 6:51 PM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2017-09-26 00:51:57 | Re: Shaky coding for vacuuming partitioned relations |
| Previous Message | Vaishnavi Prabakaran | 2017-09-26 00:04:36 | Re: Simplify ACL handling for large objects and removal of superuser() checks |