Re: SSI rw-conflicts and 2PC
От | Heikki Linnakangas |
---|---|
Тема | Re: SSI rw-conflicts and 2PC |
Дата | |
Msg-id | 4F4E2E9B.1020702@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: SSI rw-conflicts and 2PC (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: SSI rw-conflicts and 2PC
|
Список | pgsql-hackers |
On 23.02.2012 01:36, Jeff Davis wrote: > On Tue, 2012-02-14 at 19:32 -0500, Dan Ports wrote: >> 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. > > +1. > > I don't even see this as much of a problem. Prepared transactions > hanging around for arbitrary periods of time cause all kinds of problems > already. Those using them need to be careful to resolve them quickly -- > and if there's a crash involved, I think it's reasonable to say they > should be resolved before continuing normal online operations. Committed this now. (sorry for the delay) >> 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. > > I like this idea. +1. Anyone want to put together a patch? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: