* Josh Berkus (josh@agliodbs.com) wrote:
> 1) I've confirmed at the 2nd site that the issue doesn't happen if
> pg_stat_statements.so is not loaded. So this seems to be confirmation
> that either auto_explain, pg_stat_statements, or both need to be loaded
> (but not necessarily created as extensions) in order to have the issue.
Interesting...
> 2) I've been unable to reproduce the issue using a naive test case, but
> I'll keep trying.
Thanks.
> 3) The XID information is interesting.
>
> a) I've confirmed that this is a case of having multiple row versions
> rather than allowing a duplicate PK to be inserted.
>
> b) the end result of this corruption is XIDs which go backwards:
>
> xmin | xmax | ctid | step_id | workitem_id | status
> ---------+---------+-----------+---------+-------------+---------
> 3362707 | 3362707 | (6177,31) | 1 | 446469 | pending
> 3362710 | 3362707 | (6177,32) | 1 | 446469 | working
>
> 5520953 | 5520953 | (5064,105) | 1 | 727946 | pending
> 5520954 | 5520953 | (5064,108) | 1 | 727946 | working
>
> What's additionally problematic is that the current snapshot minxid is
> in the 9000000 range, so it's not clear why any of the above rows are
> visible at all.
Can you get the infomask bits..? What's does pg_controldata report wrt
the MultiXid's?
THanks,
Stephen