Re: Race condition in TransactionIdIsInProgress
От | Andres Freund |
---|---|
Тема | Re: Race condition in TransactionIdIsInProgress |
Дата | |
Msg-id | 20220212004124.ikuh7zxpcauk6olz@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Race condition in TransactionIdIsInProgress (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Race condition in TransactionIdIsInProgress
|
Список | pgsql-hackers |
Hi, On 2022-02-10 22:11:38 -0800, Andres Freund wrote: > Looks lik syncrep will make this a lot worse, because it can drastically > increase the window between the TransactionIdCommitTree() and > ProcArrayEndTransaction() due to the SyncRepWaitForLSN() inbetween. But at > least it might make it easier to write tests exercising this scenario... FWIW, I've indeed reproduced this fairly easily with such a setup. A pgbench r/w workload that's been modified to start 70 savepoints at the start shows pgbench: error: client 22 script 0 aborted in command 12 query 0: ERROR: t_xmin 3853739 is uncommitted in tuple (2,159)to be updated in table "pgbench_branches" pgbench: error: client 13 script 0 aborted in command 12 query 0: ERROR: t_xmin 3954305 is uncommitted in tuple (2,58) tobe updated in table "pgbench_branches" pgbench: error: client 7 script 0 aborted in command 12 query 0: ERROR: t_xmin 4017908 is uncommitted in tuple (3,44) tobe updated in table "pgbench_branches" after a few minutes of running with a local, not slowed down, syncrep. Without any other artifical slowdowns or such. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: