| 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: | Whole Thread | Raw Message | 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 |