Re: assertion failure 9.3.4

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)heroku(dot)com>
Subject: Re: assertion failure 9.3.4
Date: 2014-04-21 16:14:26
Message-ID: 535543E2.9020404@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

All,

More on this:

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.

2) I've been unable to reproduce the issue using a naive test case, but
I'll keep trying.

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.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alfred Perlstein 2014-04-21 16:20:28 Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Previous Message Stephen Frost 2014-04-21 16:13:38 Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD