Search Postgresql Archives

Re: Rows missing from table despite FK constraint

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Konrad Garus <konrad.garus@xxxxxxxxx> writes:
> 2010/1/8 Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx>:
>> 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

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux