From: | Luca Ferrari <fluca1978(at)infinito(dot)it> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: xmin increasing within a transaction block? |
Date: | 2017-11-06 15:01:47 |
Message-ID: | CAKoxK+6K3gjONB6qkviTa-==b1XWcvx5Lu11zKRHFYydh860fg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Nov 6, 2017 at 3:26 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
>> Luca Ferrari wrote:
>>> Why is xmin greater than the current transaction id (and most notably
>>> not "fixed")?
>
>> Something is using subtransactions there. My first guess would be that
>> there are triggers with EXCEPTION blocks, but your example doesn't show
>> any. Or maybe you have event triggers.
>
> I can reproduce the example if I "\set ON_ERROR_ROLLBACK on" in psql.
>
Shame on me, I did forgot to have enabled that in my ~/.psqlrc file
(and did not hit an error within the transaction block to see it was
aborting). And in fact, the manual page for psql reports that
ON_ERROR_ROLLBACK:
The error rollback mode works by issuing an implicit SAVEPOINT for you,
just before each command that is in a transaction block, and
then rolling back to the savepoint if the command fails.
Sorry for the noise.
Thanks,
Luca
From | Date | Subject | |
---|---|---|---|
Next Message | Karsten Hilbert | 2017-11-06 15:04:14 | Re: Naming conventions for column names |
Previous Message | Sachin Kotwal | 2017-11-06 14:53:07 | Re: Naming conventions for column names |