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
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 |