Re: Rows missing from table despite FK constraint
От | Tom Lane |
---|---|
Тема | Re: Rows missing from table despite FK constraint |
Дата | |
Msg-id | 8590.1262971019@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Rows missing from table despite FK constraint (Konrad Garus <konrad.garus@gmail.com>) |
Ответы |
Re: Rows missing from table despite FK constraint
|
Список | pgsql-general |
Konrad Garus <konrad.garus@gmail.com> writes: > 2010/1/8 Alvaro Herrera <alvherre@commandprompt.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
В списке pgsql-general по дате отправления: