| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hot Standby (v9d) |
| Date: | 2009-01-23 19:50:00 |
| Message-ID: | 20090123195000.GO4047@alvh.no-ip.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> If you have a serializable transaction with subtransactions that suffers
>> a serializability error it only cancels the current subtransaction. That
>> means it's snapshot is still valid and can be used again. By analogy, as
>> long as a transaction does not see any data that is inconsistent with
>> its snapshot it seems OK for it to continue. So I think it is correct.
>
> Yeah, you're right. How bizarre.
It was argued this way to me way back when subtransactions were written.
Originally I had written it in such a way as to abort the whole
transaction, on the rationale that if you're blindly restarting the
subtransaction after a serialization error, it would result in a (maybe
infinite) loop. I think the reason it only aborts the subxact is that
that's what all other errors do, so why would this one act differently.
Hmm, now that I think about it, I think it was deadlock errors not
serialization errors ...
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-01-23 19:58:43 | Re: AIX 4.3 getaddrinfo busted |
| Previous Message | Andrew Chernow | 2009-01-23 19:39:20 | Re: AIX 4.3 getaddrinfo busted |