From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Adding missing object access hook invocations |
Date: | 2020-03-17 19:39:35 |
Message-ID: | 330CE9A8-47A4-4C6C-8435-E6A86F3D2E6B@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Mar 17, 2020, at 11:49 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On 2020-03-16 16:03:51 -0700, Mark Dilger wrote:
>> While working on object access hooks, I noticed several locations
>> where I would expect the hook to be invoked, but no actual invocation.
>> I think this just barely qualifies as a bug. It's debatable because
>> whether it is a bug depends on the user's expectations and whether not
>> invoking the hook in these cases is defensible. Does anybody have any
>> recollection of an intentional choice not to invoke in these
>> locations?
>
> I am strongly against treating this as a bug, which'd likely imply
> backpatching. New hook invocations are a noticable behavioural change,
> and very plausibly will break currently working extensions. That's fine
> for a major version upgrade, but not for a minor one, unless there are
> very good reasons.
I agree that this does not need to be back-patched. I was debating whether it constitutes a bug for the purpose of putting the fix into v13 vs. punting the patch forward to the v14 cycle. I don't have a strong opinion on that.
Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2020-03-17 19:42:07 | Re: Berserk Autovacuum (let's save next Mandrill) |
Previous Message | Peter Geoghegan | 2020-03-17 19:37:57 | Re: [PATCH] Btree BackwardScan race condition on Standby during VACUUM |