hello,
thanks for replies, Adrian, Steven.
>So calling it can advance the xid manually. Some testing here showed
>that what xmin or xmax is created depends on when you call txid_current
>in either the original session or the concurrent sessions.
I understand this and I am executing my statements inside a Transaction
block so the xid is not incremented when calling it.
>Also worth noting that an UPDATE in Postgres is a DELETE/INSERT process.
>The clue is the ctid value. In Session 2 you are looking at the
>original row(ctid=(0, 2) which has been marked as deleted(non-zero
>xmax). In Session 3 you are looking at the new row(ctid(0, 4)).
Yes. But why (ctid(0,4)) in *Session 3* carries the xmax of the txid 519115
in which the update failed with *UPDATE 0* . This is where I can not
understand,
1. Row (0,4) is updated with correct value and (0,3) is not visible in
Session 2, which is good.
2. but in *Session 3* (0,4) also carries xmax which means what? Is it also
marked for deletion? It can't be, right?
-----
--
Thanks,
Rajan.
--
View this message in context:
http://www.postgresql-archive.org/Re-have-trouble-understanding-xmin-and-xmax-with-update-operations-from-two-different-sessions-tp5969644p5969656.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.