| From: | Ian Lawrence Barwick <barwick(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: Review: pre-commit triggers |
| Date: | 2013-11-20 11:12:17 |
| Message-ID: | CAB8KJ=j3s98YrGqEFx+9KhPPSmzwCp4zs-X4vXBc6XtMp5Wraw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2013/11/20 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Nov 18, 2013 at 9:39 AM, Ian Lawrence Barwick <barwick(at)gmail(dot)com> wrote:
>>> I'd expect this to lead to a failed transaction block,
>>> or at least some sort of notice that the transaction itself
>>> has been rolled back.
>
>> Ending up in a failed transaction block would be wrong. If the user
>> does a BEGIN, a bunch of stuff, and a COMMIT, they're entitled to
>> assume without checking that they are no longer in a transaction
>> block.
>
> Absolutely. There are plenty of ways to fail at COMMIT already,
> eg deferred foreign key constraints. This shouldn't act any
> different.
Ah OK, I see how that works. Thanks for the explanation.
Ian Barwick
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rajeev rastogi | 2013-11-20 11:27:54 | Re: Add min and max execute statement time in pg_stat_statement |
| Previous Message | Heikki Linnakangas | 2013-11-20 10:48:50 | Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1 |