From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | "Bossart, Nathan" <bossartn(at)amazon(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-25 23:50:59 |
Message-ID: | CAB7nPqQXXXv-VbEdpH5Bq6OKAg5Rqo6Yg=mhhvxSwqk6H8C8Aw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 26, 2017 at 1:47 AM, Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
> On 9/24/17, 10:12 PM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)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.
Thanks for the review, Nathan!
> + * 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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Vaishnavi Prabakaran | 2017-09-26 00:04:36 | Re: Simplify ACL handling for large objects and removal of superuser() checks |
Previous Message | Michael Paquier | 2017-09-25 23:48:40 | Re: Shaky coding for vacuuming partitioned relations |