Re: SSI rw-conflicts and 2PC
От | Dan Ports |
---|---|
Тема | Re: SSI rw-conflicts and 2PC |
Дата | |
Msg-id | 20120215003250.GS11222@csail.mit.edu обсуждение исходный текст |
Ответ на | Re: SSI rw-conflicts and 2PC ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: SSI rw-conflicts and 2PC
|
Список | pgsql-hackers |
On Tue, Feb 14, 2012 at 09:27:58AM -0600, Kevin Grittner wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > > On 14.02.2012 04:57, Dan Ports wrote: > >> The easiest answer would be to just treat every prepared > >> transaction found during recovery as though it had a conflict in > >> and out. This is roughly a one-line change, and it's certainly > >> safe. > > Dan, could you post such a patch, please? Sure. See attached. > Should we add anything to the docs to warn people that if they crash > with serializable prepared transactions pending, they will see this > behavior until the prepared transactions are either committed or > rolled back, either by the transaction manager or through manual > intervention? Hmm, it occurs to me if we have to abort a transaction due to serialization failure involving a prepared transaction, we might want to include the prepared transaction's gid in the errdetail. This semes like it'd be especially useful for prepared transactions. We can generally pick the transaction to abort to ensure the safe retry property -- if that transaction is immediately retried, it won't fail with the same conflict -- but we can't always guarantee that when prepared transactions are involved. And prepared transactions already have a convenient, user-visible ID we can report. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/
Вложения
В списке pgsql-hackers по дате отправления: