| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Luca Ferrari <fluca1978(at)gmail(dot)com> |
| Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: xmax not zero? |
| Date: | 2023-10-30 13:24:45 |
| Message-ID: | b8e727ca85abb6e36a946c39cd4b1789110390d4.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, 2023-10-30 at 13:53 +0100, Guillaume Lelarge wrote:
> Le lun. 30 oct. 2023 à 13:45, Luca Ferrari <fluca1978(at)gmail(dot)com> a écrit :
> > I have a table that presents an xmax not zeroed outside of a
> > transaction block, and it does not look normal to me.
> > I have no idea about how this happened, it is one of my "toy"
> > PostgreSQL virtual machines.
> > But how to dig an better understand why there is an xmax with a non-zero value?
>
> There are many reasons for a non-zero value: row updated or deleted in a rollbacked
> transaction, row updated or deleted in a current transaction, row locked by a
> SELECT FOR UPDATE, and perhaps others I don't remember right now.
INSERT ... ON CONFLICT could also cause this.
As long as the transaction corresponding to the "xid" is marked as "aborted",
that number is not valid and is treated like a 0.
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron | 2023-10-30 13:46:21 | Re: pg_checksums? |
| Previous Message | Paul Förster | 2023-10-30 13:18:13 | Re: pg_checksums? |