Re: [HACKERS] transition table behavior with inheritance appears broken

On Thu, Jun 29, 2017 at 6:21 AM, Andrew Gierth wrote: > Commits pushed. Great news. Thanks for stepping up to get this committed. Thanks a lot also to Marko, Amit L, Kevin, Robert, Noah and Peter G for the problem reports, reviews and issue chasing. -- Thomas

Re: [HACKERS] transition table behavior with inheritance appears broken

Commits pushed. Unless I broke the buildfarm again (which I'll check up on later), or some new issue arises with the fixes, this should close all 3 related items for transition tables. -- Andrew. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] transition table behavior with inheritance appears broken

> "Noah" == Noah Misch writes: Noah> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is Noah> long past due for your status update. Please reacquaint yourself Noah> with the policy on open item ownership[1] and then reply Noah> immediately. If I do not

Re: [HACKERS] transition table behavior with inheritance appears broken

On Sat, Jun 24, 2017 at 10:57:49PM -0700, Noah Misch wrote: > On Fri, Jun 23, 2017 at 02:39:48PM +0100, Andrew Gierth wrote: > > > "Noah" == Noah Misch writes: > > > > Noah> This PostgreSQL 10 open item is past due for your status update. > > Noah> Kindly send a status

Re: [HACKERS] transition table behavior with inheritance appears broken

On Fri, Jun 23, 2017 at 02:39:48PM +0100, Andrew Gierth wrote: > > "Noah" == Noah Misch writes: > > Noah> This PostgreSQL 10 open item is past due for your status update. > Noah> Kindly send a status update within 24 hours, > > oops, sorry! I forgot to include a date in

Re: [HACKERS] transition table behavior with inheritance appears broken

> "Noah" == Noah Misch writes: Noah> This PostgreSQL 10 open item is past due for your status update. Noah> Kindly send a status update within 24 hours, oops, sorry! I forgot to include a date in the last one, and in fact a personal matter delayed things anyway. I

Re: [HACKERS] transition table behavior with inheritance appears broken

On Sun, Jun 18, 2017 at 11:59:43PM +0100, Andrew Gierth wrote: > > "Andrew" == Andrew Gierth writes: > > Andrew> Unfortunately I've been delayed over the past couple of days, > Andrew> but I have Thomas' latest patchset in hand and will be working > Andrew> on

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

On Mon, Jun 12, 2017 at 2:03 PM, Thomas Munro wrote: > Thanks for the review. New version of patch #1 attached. Here's a version rebased on top of the recently reindented master branch. -- Thomas Munro http://www.enterprisedb.com

Re: [HACKERS] transition table behavior with inheritance appears broken

On Sun, Jun 18, 2017 at 6:59 PM, Andrew Gierth wrote: > (Any preferences for whether it should be one commit or 3 separate ones?) If I were doing it, I would commit them separately. But I'm not doing it, so I won't complain about what you decide to do. -- Robert

Re: [HACKERS] transition table behavior with inheritance appears broken

On 2017/06/19 7:59, Andrew Gierth wrote: >> "Andrew" == Andrew Gierth writes: > > (Any preferences for whether it should be one commit or 3 separate ones?) For my 2c, it would be nice to keep at least the inheritance one (or all of them actually) separate.

Re: [HACKERS] transition table behavior with inheritance appears broken

> "Andrew" == Andrew Gierth writes: Andrew> Unfortunately I've been delayed over the past couple of days, Andrew> but I have Thomas' latest patchset in hand and will be working Andrew> on it over the rest of the week. Status update by 23:59 BST on Andrew> Sun

Re: [HACKERS] transition table behavior with inheritance appears broken

> "Andrew" == Andrew Gierth writes: Andrew> I will post a further status update before 23:59 BST on 14th Andrew> Jun. Unfortunately I've been delayed over the past couple of days, but I have Thomas' latest patchset in hand and will be working on it over the

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

On Sat, Jun 10, 2017 at 6:08 AM, Robert Haas wrote: > I have spent some time now studying this patch. I might be missing > something, but to me this appears to be in great shape. A few minor > nitpicks: > > -if ((event == TRIGGER_EVENT_DELETE && >

Re: [HACKERS] transition table behavior with inheritance appears broken

> "Andrew" == Andrew Gierth writes: Andrew> I have it; I will post a status update before 23:59 BST on 11 Andrew> Jun. This is that status update. I am still studying Thomas' latest patch set; as I mentioned in another message, I've confirmed a memory leak,

Re: [HACKERS] transition table behavior with inheritance appears broken

> "Robert" == Robert Haas writes: Robert> So, Andrew, are you running with this, or should I keep looking Robert> into it? I have it; I will post a status update before 23:59 BST on 11 Jun. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list

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

On Fri, Jun 9, 2017 at 12:19 PM, Robert Haas wrote: > On Thu, Jun 8, 2017 at 11:56 PM, Thomas Munro > wrote: >> [Adding Andrew Gierth] >> >> Here is a rebased version of the patch to fix transition tables with >> inheritance. Fixes a typo in

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

On Thu, Jun 8, 2017 at 11:56 PM, Thomas Munro wrote: > [Adding Andrew Gierth] > > Here is a rebased version of the patch to fix transition tables with > inheritance. Fixes a typo in an error message ("not support on > partitions" -> "... supported ..."), and

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

On Mon, May 22, 2017 at 5:51 PM, Amit Langote wrote: > On 2017/05/20 9:01, Thomas Munro wrote: >> Sent too soon. Several variables should also be renamed to make clear >> they refer to the transition capture state in effect, instead of vague >> names like

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

On 2017/05/20 9:01, Thomas Munro wrote: > On Sat, May 20, 2017 at 10:43 AM, Thomas Munro > wrote: >> On Fri, May 19, 2017 at 6:35 PM, Amit Langote >> wrote: >>> On 2017/05/19 15:16, Thomas Munro wrote: Would

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

On Sat, May 20, 2017 at 10:43 AM, Thomas Munro wrote: > On Fri, May 19, 2017 at 6:35 PM, Amit Langote > wrote: >> On 2017/05/19 15:16, Thomas Munro wrote: >>> Would TransitionCaptureState be a better name for this struct? >> >> Yes.

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

On Fri, May 19, 2017 at 6:35 PM, Amit Langote wrote: > On 2017/05/19 15:16, Thomas Munro wrote: >> Would TransitionCaptureState be a better name for this struct? > > Yes. Although, losing the Trigger prefix might make it sound a bit > ambiguous though. Right above

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

On 2017/05/19 15:16, Thomas Munro wrote: > On Fri, May 19, 2017 at 5:51 PM, Amit Langote > wrote: >> I saw in the latest patch that now ExecSetupTriggerTransitionState() looks >> at mtstate->mt_partition_dispatch_info when setting up the transition >> conversion

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

On Fri, May 19, 2017 at 5:51 PM, Amit Langote wrote: > I saw in the latest patch that now ExecSetupTriggerTransitionState() looks > at mtstate->mt_partition_dispatch_info when setting up the transition > conversion map. In the case where it's non-NULL, you may have

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

On 2017/05/19 14:01, Thomas Munro wrote: > On Fri, May 19, 2017 at 1:38 AM, Kevin Grittner wrote: >> On Thu, May 18, 2017 at 5:16 AM, Amit Langote >> wrote: >> >>> Do we need to update documentation? Perhaps, some clarification on the >>>

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

On Fri, May 19, 2017 at 1:38 AM, Kevin Grittner wrote: > On Thu, May 18, 2017 at 5:16 AM, Amit Langote > wrote: > >> Do we need to update documentation? Perhaps, some clarification on the >> inheritance/partitioning behavior somewhere. > > Yeah,

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

On Thu, May 18, 2017 at 5:16 AM, Amit Langote wrote: > Do we need to update documentation? Perhaps, some clarification on the > inheritance/partitioning behavior somewhere. Yeah, I think so. > -Assert((enrmd->reliddesc == InvalidOid) != (enrmd->tupdesc ==

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

On 2017/05/18 7:13, Thomas Munro wrote: > On Wed, May 17, 2017 at 7:42 PM, Thomas Munro > wrote: >> On Wed, May 17, 2017 at 6:04 PM, Amit Langote >> wrote: >>> targetRelInfo should instead be set to mtstate->rootResultRelInfo that was

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

On Wed, May 17, 2017 at 7:42 PM, Thomas Munro wrote: > On Wed, May 17, 2017 at 6:04 PM, Amit Langote > wrote: >> targetRelInfo should instead be set to mtstate->rootResultRelInfo that was >> set in ExecInitModifyTable() as described

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

On Wed, May 17, 2017 at 6:04 PM, Amit Langote wrote: > On 2017/05/17 11:22, Thomas Munro wrote: >> Here is that patch. Thoughts? > > I looked at the patch and noticed that there might be some confusion about > what's in the EState.es_root_result_relations array.

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

On 2017/05/17 11:22, Thomas Munro wrote: > On Wed, May 17, 2017 at 10:13 AM, Kevin Grittner wrote: >> On Tue, May 16, 2017 at 4:50 PM, Thomas Munro >> wrote: >>> >>> I'm about to post a much simpler patch that collects uniform tuples >>> from

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

On Wed, May 17, 2017 at 10:13 AM, Kevin Grittner wrote: > On Tue, May 16, 2017 at 4:50 PM, Thomas Munro > wrote: >> >> I'm about to post a much simpler patch that collects uniform tuples >> from children, addressing the reported bug, and simply

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

On Tue, May 16, 2017 at 4:50 PM, Thomas Munro wrote: > On Wed, May 17, 2017 at 9:20 AM, Kevin Grittner wrote: >> On Wed, May 10, 2017 at 7:02 AM, Thomas Munro >> wrote: >>> On Wed, May 10, 2017 at 11:10 PM, Thomas

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

On Wed, May 17, 2017 at 9:20 AM, Kevin Grittner wrote: > On Wed, May 10, 2017 at 7:02 AM, Thomas Munro > wrote: >> On Wed, May 10, 2017 at 11:10 PM, Thomas Munro >> wrote: >>> 2. If you attach a row-level trigger

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

On Wed, May 10, 2017 at 7:02 AM, Thomas Munro wrote: > On Wed, May 10, 2017 at 11:10 PM, Thomas Munro > wrote: >> 2. If you attach a row-level trigger with transition tables to any >> inheritance child, it will see transition tuples

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

[Apologies to all for my recent absence from community lists, and special thanks to Thomas and Robert for picking up the slack.] On Tue, May 9, 2017 at 4:51 PM, Thomas Munro wrote: > On Tue, May 9, 2017 at 10:29 PM, Thomas Munro >

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

On Wed, May 10, 2017 at 8:02 AM, Thomas Munro wrote: > On Wed, May 10, 2017 at 11:10 PM, Thomas Munro > wrote: >> 2. If you attach a row-level trigger with transition tables to any >> inheritance child, it will see transition tuples

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

On Wed, May 10, 2017 at 11:10 PM, Thomas Munro wrote: > 2. If you attach a row-level trigger with transition tables to any > inheritance child, it will see transition tuples from all tables in > the inheritance hierarchy at or below the directly named table that >

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

On Wed, May 10, 2017 at 3:55 PM, Robert Haas wrote: > On Tue, May 9, 2017 at 11:48 PM, Thomas Munro > wrote: >> Hmm. DB2 has transition tables (invented them maybe?) and it allows >> OLD/NEW TABLE on row-level triggers: >> >>

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

On Tue, May 9, 2017 at 11:48 PM, Thomas Munro wrote: > Hmm. DB2 has transition tables (invented them maybe?) and it allows > OLD/NEW TABLE on row-level triggers: > >

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

On Wed, May 10, 2017 at 11:22 AM, Thomas Munro wrote: > On Wed, May 10, 2017 at 9:57 AM, Alvaro Herrera > wrote: >> Thomas Munro wrote: >> >>> Recall that transition tables can be specified for statement-level >>> triggers AND row-level

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

On Tue, May 9, 2017 at 11:40 PM, Thomas Munro wrote: > On Wed, May 10, 2017 at 2:31 PM, Amit Langote > wrote: >> On 2017/05/10 6:51, Thomas Munro wrote: >>> No such problem exists for partition hierarchies since the tables all >>>

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

On Wed, May 10, 2017 at 2:31 PM, Amit Langote wrote: > On 2017/05/10 6:51, Thomas Munro wrote: >> No such problem exists for partition hierarchies since the tables all >> appear as the same type to user code (though conversions may be >> happening for technical

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

On 2017/05/10 6:51, Thomas Munro wrote: > No such problem exists for partition hierarchies since the tables all > appear as the same type to user code (though conversions may be > happening for technical reasons). To clarify a bit, there may exist differences in the ordering of columns, either

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

On Wed, May 10, 2017 at 9:57 AM, Alvaro Herrera wrote: > Thomas Munro wrote: > >> Recall that transition tables can be specified for statement-level >> triggers AND row-level triggers. If you specify them for row-level >> triggers, then they can see all rows changed so

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

Thomas Munro wrote: > Recall that transition tables can be specified for statement-level > triggers AND row-level triggers. If you specify them for row-level > triggers, then they can see all rows changed so far each time they > fire. Uhmm ... why do we do this? It seems like a great way to

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

On Tue, May 9, 2017 at 10:29 PM, Thomas Munro wrote: > In master, the decision to populate transition tables happens in > AfterTriggerSaveEvent (called by the ExecAR* functions) in trigger.c. > It does that if it sees that there are triggers on the >

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

On Mon, May 8, 2017 at 7:09 PM, Thomas Munro wrote: > On Fri, May 5, 2017 at 8:29 AM, Thomas Munro > wrote: >> On Fri, May 5, 2017 at 2:40 AM, Robert Haas wrote: >>> On Thu, May 4, 2017 at 4:46 AM, Thomas Munro

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

On Fri, May 5, 2017 at 8:29 AM, Thomas Munro wrote: > On Fri, May 5, 2017 at 2:40 AM, Robert Haas wrote: >> On Thu, May 4, 2017 at 4:46 AM, Thomas Munro >> wrote: >>> On Thu, May 4, 2017 at 4:02 AM, Alvaro

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

On Fri, May 5, 2017 at 2:40 AM, Robert Haas wrote: > On Thu, May 4, 2017 at 4:46 AM, Thomas Munro > wrote: >> On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera >> wrote: >>> Robert Haas wrote: I suspect that most

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

On Thu, May 4, 2017 at 4:46 AM, Thomas Munro wrote: > On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera > wrote: >> Robert Haas wrote: >>> I suspect that most users would find it more useful to capture all of >>> the rows that the statement

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

On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera wrote: > Robert Haas wrote: >> I suspect that most users would find it more useful to capture all of >> the rows that the statement actually touched, regardless of whether >> they hit the named table or an inheritance child.

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

On Wed, May 03, 2017 at 11:47:04AM -0400, Robert Haas wrote: > On Tue, May 2, 2017 at 9:44 PM, Thomas Munro > wrote: > > I think that we should only capture transition tuples captured from > > the explicitly named relation, since we only fire AFTER STATEMENT > >

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

On Wed, May 3, 2017 at 12:02 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> I suspect that most users would find it more useful to capture all of >> the rows that the statement actually touched, regardless of whether >> they hit the named table or an inheritance

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

Robert Haas wrote: > I suspect that most users would find it more useful to capture all of > the rows that the statement actually touched, regardless of whether > they hit the named table or an inheritance child. Yes, agreed. For the plain inheritance cases each row would need to have an

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

On Tue, May 2, 2017 at 9:44 PM, Thomas Munro wrote: > I think that we should only capture transition tuples captured from > the explicitly named relation, since we only fire AFTER STATEMENT > triggers on that relation. I see no inconsistency with the policy of >

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

On Tue, May 2, 2017 at 3:01 AM, Robert Haas wrote: > [...] > Only the rows in the parent show up in the transition table. But now > look what happens if I add an unrelated trigger that also uses > transition tables to the children: > > rhaas=# CREATE FUNCTION u() RETURNS

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

On Mon, May 1, 2017 at 11:53 AM, Robert Haas wrote: > On Mon, May 1, 2017 at 12:10 PM, Kevin Grittner wrote: >> On Mon, May 1, 2017 at 10:01 AM, Robert Haas wrote: >>> It seems pretty clear to me that this is busted. >> >> I don't

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

On Mon, May 1, 2017 at 12:10 PM, Kevin Grittner wrote: > On Mon, May 1, 2017 at 10:01 AM, Robert Haas 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

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

On Mon, May 1, 2017 at 10:01 AM, Robert Haas 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

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

On Mon, May 1, 2017 at 12:51 AM, Amit Langote wrote: > What we could document now is that partitioned tables don't allow > specifying triggers that reference transition tables. Although, I am > wondering where this note really belongs - the partitioning chapter,