From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby. |
Date: | 2008-10-22 19:52:24 |
Message-ID: | 1224705144.27145.450.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Wed, 2008-10-22 at 15:18 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > These traces look weird. Look at the way the xid changes value as we
> > move from call to call. It looks like something is screwy there. If
> > those values are correct we should have failed an earlier assertion.
>
> No, that's normal behavior on this platform + optimization setting.
> Some of those registers have gotten re-used for other values. If
> I were desperate to figure out how it got from point A to point B
> I'd recompile with -O0, but this particular call stack doesn't seem
> to hold any surprises: as you say, it seems to be trying to commit
> an aborted xact. I looked far enough to see that the subxact ID
> was a couple counts higher than the main, so I doubt that bad data
> in the WAL record is the issue.
>
> Are you able to reproduce the crash?
Took a while, but yes, I can reproduce this now. Analysing...
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-10-22 20:17:52 | pgsql: Dept of better ideas: refrain from creating the planner's |
Previous Message | Tom Lane | 2008-10-22 19:18:51 | Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby. |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-10-22 20:27:39 | Re: [COMMITTERS] pgsql: Rework subtransaction commit protocol for hot standby. |
Previous Message | Heikki Linnakangas | 2008-10-22 19:38:39 | Re: Deriving Recovery Snapshots |