Re: [HACKERS] Shaky coding for vacuuming partitioned relations - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Shaky coding for vacuuming partitioned relations
Date
Msg-id CAB7nPqQXXXv-VbEdpH5Bq6OKAg5Rqo6Yg=mhhvxSwqk6H8C8Aw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Shaky coding for vacuuming partitioned relations  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: [HACKERS] Shaky coding for vacuuming partitioned relations  ("Bossart, Nathan" <bossartn@amazon.com>)
List pgsql-hackers
On Tue, Sep 26, 2017 at 1:47 AM, Bossart, Nathan <bossartn@amazon.com> wrote:
> 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.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Shaky coding for vacuuming partitioned relations
Next
From: Vaishnavi Prabakaran
Date:
Subject: Re: [HACKERS] Simplify ACL handling for large objects and removal ofsuperuser() checks