From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Glen Eustace <geustace(at)godzone(dot)net(dot)nz> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Weird problem - possibly a bug. |
Date: | 2001-12-10 23:37:19 |
Message-ID: | 440.1008027439@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Glen Eustace <geustace(at)godzone(dot)net(dot)nz> writes:
> The table had 4 rows, all with the same OID. ( It is only supposed to have 1
> !!)
The existence of multiple rows with the same OID is not in itself a bug,
unless you have a unique index on OID on that table.
Jan evidently thinks that you have gotten into this state because a few
UPDATEs failed to invalidate the old copy of the row. That's one
possible scenario but it's somewhat difficult to credit. I'm wondering
about VACUUM dropping the ball while moving the row across page
boundaries, myself.
Can you provide:
1. samples of all the query sequences that update this table. (I'm
particularly interested in whether you use SELECT FOR UPDATE.)
2. A dump of the table including all system columns (ctid, oid, xmin,
cmin, xmax, cmax) as well as the user data. Also, what's the exact
schema declaration of the table? Are there any rules, triggers, foreign
key constraints attached to it?
Also, have you suffered any system crashes that might have interrupted
updates of this table?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-10 23:40:46 | Re: Re: What can I use as a [non-aggregate] minimum function |
Previous Message | Martijn van Oosterhout | 2001-12-10 23:33:59 | Re: Need SQL help, I'm stuck. |