Re: Shaky coding for vacuuming partitioned relations

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

In response to

Responses

Browse pgsql-hackers by date

  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