Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

From: Noah Misch <noah(at)leadboat(dot)com>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, David Fetter <david(at)fetter(dot)org>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Subject: Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)
Date: 2017-05-11 07:38:59
Message-ID: 20170511073859.GA1305565@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 06, 2017 at 06:54:37PM +0000, Noah Misch wrote:
> On Mon, May 01, 2017 at 11:10:52AM -0500, Kevin Grittner wrote:
> > On Mon, May 1, 2017 at 10:01 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > > It seems pretty clear to me that this is busted.
> >
> > I don't think you actually tested anything that is dependent on any
> > of my patches there.
> >
> > > Adding this as an open item. Kevin?
> >
> > It will take some time to establish what legacy behavior is and how
> > the new transition tables are impacted. My first reaction is that a
> > trigger on the parent should fire for any related action on a child
> > (unless maybe the trigger is defined with an ONLY keyword???) using
> > the TupleDesc of the parent. Note that the SQL spec mandates that
> > even in a AFTER EACH ROW trigger the transition tables must
> > represent all rows affected by the STATEMENT. I think that this
> > should be independent of triggers fired at the row level. I think
> > the rules should be similar for updateable views.
> >
> > This will take some time to investigate, discuss and produce a
> > patch. I think best case is Friday.
>
> [Action required within three days. This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 10 open item. Kevin,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> v10 open item, please let us know. Otherwise, please observe the policy on
> open item ownership[1] and send a status update within three calendar days of
> this message. Include a date for your subsequent status update. Testers may
> discover new open items at any time, and I want to plan to get them all fixed
> well in advance of shipping v10. Consequently, I will appreciate your efforts
> toward speedy resolution. Thanks.
>
> [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

This PostgreSQL 10 open item is past due for your status update. Kindly send
a status update within 24 hours, and include a date for your subsequent status
update. Refer to the policy on open item ownership:
https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2017-05-11 08:10:40 Re: Get stuck when dropping a subscription during synchronizing table
Previous Message Noah Misch 2017-05-11 07:32:03 Re: Time based lag tracking for logical replication