From: | "Mark Scheffer" <pg2401k(at)pinkwin(dot)com> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | pg2401k(at)pinkwin(dot)com |
Subject: | Re: BUG #15026: Deadlock using GIST index |
Date: | 2018-02-03 10:02:24 |
Message-ID: | d39ad742dc96e28a498c86fa84a925be.squirrel@mail.pinkwin.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
Digging deeper into source code of backend/executor/execIndexing.c, I
found following:
* 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...
I'm not so happy with "That's fairly harmless". In my case I'm processing
messages from several sessions at a rate of more than 1000 messages per
second per session.
With default deadlock timeout of 1 second, at least two sessions may block
and this may have impact on other sessions which may cascade into a lot of
sessions being in a dead-lock. I had a situation where throughput dropped
to 6 messages per second....
Very simple example of this problem:
1. lookup a record for entity E using exclusion constraint
2. if it does not exist: insert the record
3. If this insert fails, back to 1.
If n sessions try to execute this in parallel, the wait time will be n-1
seconds.
Any chance in changing current Postgresql behavior?
Regards,
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-02-03 16:05:41 | Re: BUG #14912: Undocumented: 'psql -l' assumes database 'postgresql' not $USER |
Previous Message | Srikanth M K | 2018-02-03 09:32:41 | Re: Difference in behaviour between 9.6 and 10.1: GROUPING with ROLLUP , difference in order and error with unnest |