From: | Tommi Maekitalo <t(dot)maekitalo(at)epgmbh(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: BEGIN inside transaction should be an error |
Date: | 2006-05-11 06:05:57 |
Message-ID: | 200605110805.57392.t.maekitalo@epgmbh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Am Mittwoch, 10. Mai 2006 22:23 schrieb Mark Dilger:
> Martijn van Oosterhout wrote:
> > On Wed, May 10, 2006 at 09:41:46AM +0200, Mario Weilguni wrote:
> >>>>Could we make BEGIN fail when we already are in a transaction?
...
>
> Or if you really want to screw things up, you could require COMMIT; COMMIT;
> to finish off the transaction started by BEGIN; BEGIN; We could just
> silently keep the transaction alive after the first COMMIT; ;)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
I would expect after a COMMIT without an error, that my transaction is
committed. When the system accidently issued a second BEGIN, this would not
be the case.
And what about BEGIN; BEGIN; ROLLBACK; COMMIT; then? Should the rollback be
ignored also?
I'd vote for breaking broken applications and leave the database-administrator
reactivate this currently broken behavior of postgresql via GUC.
Tommi
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-05-11 07:28:16 | Re: .pgpass file and unix domain sockets |
Previous Message | Josh Berkus | 2006-05-11 05:11:30 | Warning -- PostgreSQL Anniversary Cutoff Approaching |
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-05-11 07:17:36 | Re: [PATCH] Improve EXPLAIN ANALYZE overhead by sampling |
Previous Message | Dennis Bjorklund | 2006-05-11 04:41:35 | Re: BEGIN inside transaction should be an error |