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
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
> "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
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
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
> "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
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
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
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
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.
> "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
> "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
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 &&
>
> "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,
> "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
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
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
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
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
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.
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
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
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
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
>>>
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,
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 ==
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
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
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.
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
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
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
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
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
[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
>
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
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
>
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:
>>
>>
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:
>
>
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
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
>>>
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
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
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
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
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
>
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
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
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
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
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.
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
> >
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
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
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
>
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
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
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
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
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,
60 matches
Mail list logo