[HACKERS] Re: transition table behavior with inheritance appears broken (was:Declarative partitioning - another take) - Mailing list pgsql-hackers

From Noah Misch
Subject [HACKERS] Re: transition table behavior with inheritance appears broken (was:Declarative partitioning - another take)
Date
Msg-id 20170511073859.GA1305565@rfd.leadboat.com
Whole thread Raw
In response to [HACKERS] Re: transition table behavior with inheritance appears broken (was:Declarative partitioning - another take)  (Noah Misch <noah@leadboat.com>)
Responses [HACKERS] Re: transition table behavior with inheritance appears broken (was:Declarative partitioning - another take)
List 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@gmail.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



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [HACKERS] Time based lag tracking for logical replication
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Get stuck when dropping a subscription duringsynchronizing table