From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: contrib modules and relkind check |
Date: | 2017-03-10 00:53:55 |
Message-ID: | CAB7nPqQARd9q6fzp=YUSSkSy7dJEGneRjnvir+wxBqtnVE36ZA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 10, 2017 at 9:34 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Michael Paquier (michael(dot)paquier(at)gmail(dot)com) wrote:
>> Thanks. Shouldn't this fix be back-patched? pg_visibility should fail
>> properly for indexes and other relkinds even in 9.6. pgstattuple can
>> also trigger failures. It would be confusing for users to face "could
>> not open file" kind of errors instead of a proper error message. Note
>> that I am fine to produce those patches if there is a resource issue
>> for any of you two.
>
> I'm not really convinced that back-patching this is worthwhile, which is
> why I didn't go through the effort to do so. A reasonable error will be
> thrown in either case, after all, without any bad behavior happening,
> from what I can see.
Okay, I don't mind as nobody has complained about pgstattuple in particular.
> That said, if you feel strongly enough about it to propose appropriate
> patches for the back-branches, I'll try and look at them before the next
> set of point releases, but I'm not going to deal with them this month as
> I'd like to get through as much of the CF for PG10 as we can.
Nah, let's see if somebody else complains.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-03-10 01:00:25 | Re: Should buffer of initialization fork have a BM_PERMANENT flag |
Previous Message | Michael Paquier | 2017-03-10 00:52:00 | Re: [COMMITTERS] pgsql: Throw an error if a DATA() line contains wrong # of attributes. |