From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Mark Scheffer <pg2401k(at)pinkwin(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15026: Deadlock using GIST index |
Date: | 2018-02-10 22:55:29 |
Message-ID: | CAH2-WznqAdDvbsZA4CSM4T8AXO6nTfkVMYW3XaQY8+m-E2r9KA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, Feb 3, 2018 at 2:02 AM, Mark Scheffer <pg2401k(at)pinkwin(dot)com> wrote:
> * Exclusion Constraints
> * ---------------------
> ...
> *
> * There is a chance of deadlock, if two backends insert a tuple at the
> * same time, and then perform the scan to check for conflicts. They will
> * find each other's tuple, and both try to wait for each other. The
> * deadlock detector will detect that, and abort one of the transactions.
> * That's fairly harmless, as one of them was bound to abort with a
> * "duplicate key error" anyway, although you get a different error
> * message.
>
> I guess that my example has this deadlock...
> Any chance in changing current Postgresql behavior?
While I think that your complaint is a legitimate one, I'd say that
it's very unlikely to be fixed. Ordinary (non-deferrable) unique
constraints don't have this problem because they pessimistically lock
the first leaf page the value could be on ahead of inserting. In
contrast, exclusion constraints generally optimistically detect any
conflict in a separate pass. That's how you can get concurrent
insertions to wait on each other, rather than having a clear "winner"
at the precise point that insertion occurs.
I can't imagine what it would take to avoid this issue with GiST, but
I'm sure it would be very difficult.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-02-11 01:17:04 | Re: BUG #15036: Un-killable queries Hanging in BgWorkerShutdown |
Previous Message | Andrew Gierth | 2018-02-10 11:48:17 | Re: BUG #15057: Issue with UNKNOW type when calling a PostgreSQL function from java code |