| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: synchronized snapshots |
| Date: | 2011-08-16 22:53:43 |
| Message-ID: | 06090E92-DC66-479A-B7B2-8BF5B047865E@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Aug 16, 2011, at 5:40 PM, Jeff Davis wrote:
> On Tue, 2011-08-16 at 11:01 -0500, Jim Nasby wrote:
>> Also, an invalid transaction seems to be the result of least
>> surprise... if you cared enough to begin a transaction, you're going
>> to expect that either everything between that and the COMMIT succeeds
>> or fails, not something in-between.
>
> Agreed.
>
> Perhaps we need a new utility command to set the snapshot to make the
> error handling a little more obvious?
Well, it appears we have a larger problem, as Robert pointed out that trying to start a writable transaction on a hot standby leaves you not in a transaction (which I feel is a problem).
So IMHO the right thing to do here is make it so that runtime errors in BEGIN leave you in an invalid transaction. Then we can decide on the API for synchronized snapshots that makes sense instead of working around the behavior of BEGIN.
I guess the big question to answer now is: what's the backwards compatibility impact of changing how BEGIN deals with runtime errors?
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2011-08-17 00:10:32 | Finding tables dropped by DROP TABLE CASCADE |
| Previous Message | Jeff Davis | 2011-08-16 22:40:06 | Re: synchronized snapshots |