Re: Shaky coding for vacuuming partitioned relations

On Tue, Sep 26, 2017 at 8:48 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Mon, Sep 25, 2017 at 11:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yeah, I'd noticed that while reviewing the vacuum-multiple-tables patch.
>> My thought about fixing it was to pass a null RangeVar when handling a
>> table we'd identified through inheritance or pg_class-scanning, to
>> indicate that this wasn't a table named in the original command. This
>> only works conveniently if you decide that it's appropriate to silently
>> ignore relation_open failure on such table OIDs, but I think it is.
>>
>> Not sure about whether we ought to try to fix that in v10. It's a
>> mostly-cosmetic problem in what ought to be an infrequent corner case,
>> so it might not be worth taking risks for post-RC1. OTOH, I would
>> not be surprised to get bug reports about it down the road.
>
> Something like that looks like a good compromise for v10. I would
> rather see a more complete fix with each relation name reported
> correctly on HEAD though. The information provided would be useful for
> users when using autovacuum when skipping a relation because no lock
> could be taken on it.

Actually, perhaps this should be tracked as an open item? A simple fix
is leading to the path that no information is better than misleading
information in this case.
--
Michael