Re: Use of RangeVar for partitioned tables in autovacuum

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>
Subject: Re: Use of RangeVar for partitioned tables in autovacuum
Date: 2017-09-27 21:51:46
Message-ID: CAB7nPqTDs_F9mBXJuo7SuMwaZLpzQ6jsRGwcAdo84UMwoKcBPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 28, 2017 at 3:11 AM, Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
> On 9/26/17, 9:28 PM, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
>> In conclusion, I think that the open item of $subject should be
>> removed from the list, and we should try to get the multi-VACUUM patch
>> in to cover any future problems. I'll do so if there are no
>> objections.
>
> If someone did want to add logging for vacuum_rel() and analyze_rel() in
> v10 after your patch was applied, wouldn't the NULL RangeVars force us to
> skip the new log statements for partitions? I think we might instead
> want to back-patch the VacuumRelation infrastructure so that we can
> appropriately log for partitions.

Yes, in this case that would be a problem. But that problem does not
exist yet. If that was to happen, something like the patch I attached
would be actually enough. It is simple and non-intrusive as well.

> However, I'm dubious that it is necessary to make such a big change so
> close to release for hypothetical log statements. So, in the end, I agree
> with you.

Yeah... As long as there is no problem yet.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomasz Ostrowski 2017-09-27 21:52:19 Re: Multicolumn hash indexes
Previous Message Alexander Korotkov 2017-09-27 21:45:15 Re: GSoC 2017: weekly progress reports (week 6)