From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Konrad Garus <konrad(dot)garus(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Rows missing from table despite FK constraint |
Date: | 2010-01-08 17:16:59 |
Message-ID: | 8590.1262971019@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Konrad Garus <konrad(dot)garus(at)gmail(dot)com> writes:
> 2010/1/8 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
>> I'm a bit surprised by the block numbers in the block header vs. t_self ...
>> I would have guessed that they come from a different segment (and
>> the numbers seem to match, as 603713 % 131072 = 79425), but Konrad
>> doesn't seem to be using the foo.4 file.
> I am not sure I understand what you say, but the 922494 file has 12
> parts (922494, 922494.1 through 922494.11). The file I gave you is,
> indeed, dumped from 922494.4.
Yeah, it sounds like you did it right, and anyway the block ids prove
this is the right block --- the forward links in HOT-updated tuples
have to point to the same block.
I'm just completely baffled at this point. The data appears perfectly
okay according to pg_filedump, and if pg_filedump can read the page
then the backend should be able to as well.
Just to confirm, if you try to select any of these rows by ctid, ie
select * from tablename where ctid = '(603713,1)';
you get nothing? What *should* happen is that you get the row if you
mention offset 1, 3, or 5, but nothing if you say 2 or 4.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Konrad Garus | 2010-01-08 17:24:51 | Re: Rows missing from table despite FK constraint |
Previous Message | Adrian Klaver | 2010-01-08 17:12:09 | Re: Server name in psql prompt |