On Mon, Aug 17, 2009 at 4:02 PM, Greg Stark wrote:
> For what it's worth at EDB I dealt with another case like this and I
> imagine others have too. I think it's too easy to do things in the
> wrong order or miss a step and end up with these kinds of problems.
>
> I would really like to know what
On Mon, Aug 17, 2009 at 7:59 PM, Tom Lane wrote:
> Greg Stark writes:
>> Excluding the cases where our own xid is in the tuple I think the
>> relevant cases are either
>
>> xmin aborted or in progress (or in future)
>> MOVED_OFF and xvac committed
>> MOVED_IN and xvac aborted or is in progress (or
Greg Stark writes:
> Excluding the cases where our own xid is in the tuple I think the
> relevant cases are either
> xmin aborted or in progress (or in future)
> MOVED_OFF and xvac committed
> MOVED_IN and xvac aborted or is in progress (or in future)
Ah. I hadn't bothered to check the code in
On Mon, Aug 17, 2009 at 12:41 PM, Tom Lane wrote:
> Bryan Murphy writes:
> > On Mon, Aug 17, 2009 at 12:17 PM, Tom Lane wrote:
> >> Hm, what's your current XID counter? (pg_controldata would give an
> >> approximate answer.) I'm wondering if the xmax's are marked committed
> >> but are in the
On Mon, Aug 17, 2009 at 6:17 PM, Tom Lane wrote:
> Hm, what's your current XID counter? (pg_controldata would give an
> approximate answer.) I'm wondering if the xmax's are marked committed
> but are in the future ...
>
FWIW that doesn't look right. That would result in
HeapTupleBeingUpdated. Th
On Mon, Aug 17, 2009 at 6:17 PM, Tom Lane wrote:
> Bryan Murphy writes:
>> Here's the xmin/xmax/ctid for three problematic records:
>
>> prodpublic=# select xmin,xmax,ctid from items_extended where id in
>> ('34537ed90d7546d78f2c172fc8eed687', '3e1d99b7124742b7aaf2f869f7637b0e',
>> '499b464f141a48
Bryan Murphy writes:
> On Mon, Aug 17, 2009 at 12:17 PM, Tom Lane wrote:
>> Hm, what's your current XID counter? (pg_controldata would give an
>> approximate answer.) I'm wondering if the xmax's are marked committed
>> but are in the future ...
> Latest checkpoint's NextXID: 0/3088298
On Mon, Aug 17, 2009 at 12:17 PM, Tom Lane wrote:
> Bryan Murphy writes:
> > Here's the xmin/xmax/ctid for three problematic records:
>
> > prodpublic=# select xmin,xmax,ctid from items_extended where id in
> > ('34537ed90d7546d78f2c172fc8eed687', '3e1d99b7124742b7aaf2f869f7637b0e',
> > '499b464
Bryan Murphy writes:
> Here's the xmin/xmax/ctid for three problematic records:
> prodpublic=# select xmin,xmax,ctid from items_extended where id in
> ('34537ed90d7546d78f2c172fc8eed687', '3e1d99b7124742b7aaf2f869f7637b0e',
> '499b464f141a48619c5ce0475cbe9150');
>xmin| xmax|ctid
Could I run pg_resetxlog on a warm spare? Would that give the same result?
Unfortunately, this is our production system and I simply cannot bring it
down at the moment to run pg_resetxlog.
Bryan
On Mon, Aug 17, 2009 at 11:35 AM, Greg Stark wrote:
> On Mon, Aug 17, 2009 at 4:23 PM, Bryan Murphy
On Mon, Aug 17, 2009 at 11:35 AM, Greg Stark wrote:
> On Mon, Aug 17, 2009 at 4:23 PM, Bryan Murphy
> wrote:
> > I've identified 82 bad records. When I try to query for the records,
> > we get the following:
> > ERROR: missing chunk number 0 for toast value 25692661 in
> pg_toast_25497233
> >
On Mon, Aug 17, 2009 at 4:23 PM, Bryan Murphy wrote:
> I've identified 82 bad records. When I try to query for the records,
> we get the following:
> ERROR: missing chunk number 0 for toast value 25692661 in pg_toast_25497233
> That's fine. I've run into that in a few other tables and have just
We had a hardware failure last week and had to switch over to our spare.
Unfortunately, at some point we managed to get some data corruption. I've
been going through the database table by table, record by record, trying to
find the problems and fix them.
This one has me stumped. We have one tab
13 matches
Mail list logo
