From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Shaky coding for vacuuming partitioned relations |
Date: | 2017-09-26 02:14:15 |
Message-ID: | CAB7nPqTBvRwXjYWPAFX=xGjpty7VXq+F+ha8otHz-VHgZ21HSw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 26, 2017 at 10:55 AM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> On 2017/09/26 9:51, Michael Paquier wrote:
>> 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.
>
> +1.
Let's track it then and spawn a separate thread with a patch. Do you
want to work on it or should I? The solution proposed by Tom seems
like the correct answer. I am adding an item for now, we could always
link it to a thread later on.
Let's also track the problem that has been reported on this thread.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-09-26 02:34:31 | Re: Setting pd_lower in GIN metapage |
Previous Message | Michael Paquier | 2017-09-26 02:12:09 | Re: Shaky coding for vacuuming partitioned relations |