Re: [HACKERS] PG10 partitioning - odd behavior/possible bug

From: Joe Conway <mail(at)joeconway(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] PG10 partitioning - odd behavior/possible bug
Date: 2017-11-28 23:42:54
Message-ID: ec855acc-e258-07d2-2daf-b9d6194c15e4@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/28/2017 04:40 PM, Robert Haas wrote:
> On Sun, Sep 3, 2017 at 5:28 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:
>> I was playing around with partitioning and found an oddity that is best
>> described with the following reasonably minimal test case:
>
> I can reproduce this without partitioning, just by creating two
> independent tables with the same schema and tweaking a few things from
> your test case to refer to the correct table rather than relying on
> tuple routing:

[snip]

> There's no error here because I didn't bother putting constraints on
> the table, but that tsr = empty bit is still happening. I think the
> problem is that you're updating the same row twice in the same
> transaction, and now() returns the same value both times because
> that's how now() works, so the second time the range ends up with the
> lower and endpoints that are equal.

Yeah, Tom already pointed that out a while back:

https://www.postgresql.org/message-id/20986.1504478066%40sss.pgh.pa.us

FWIW, I have working version of this now (using clock_timestamp()) here
(see last part of the appendix):

https://www.joeconway.com/presentations/SecurePostgreSQL-PGOpen2017.pdf

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-11-29 00:25:04 Re: [HACKERS] PG10 partitioning - odd behavior/possible bug
Previous Message Michael Paquier 2017-11-28 23:26:59 Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently