possibly happen? What research
could help find the root cause and fix the database?
Thanks.
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
?
I suspect it is a bug in PostgreSQL. Does it resemble an already
submitted issue?
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
haven't spotted anything
suspicious (searching by table name, grepping for error and vacuum,
quick scan from when the state was consistent until when it was not).
Also, reindex on the master table did not help.
Is there anything I could do on logs or the database that could help
diagnose
ow what other information could be helpful.
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
oint. It's a write-only table with
thousands of inserts daily, and the lost rows were written 7 months
ago.
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/1/8 Tom Lane :
> Do you know that the rows disappeared recently?
Yes. They are present in dump from 9 PM and missing from dump from 1
AM. It must've happened within this 4-hour window.
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
3714. I checked by text in
VARCHAR columns.
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/1/8 Konrad Garus :
> I'm unsure about it, because the resulting file does not seem to have
> the rows I saw listed for block 603712 or 603714. I checked by text in
> VARCHAR columns.
I must've done something wrong.
I found that row liste
OK, I got it. Attached is the dump of the missing block.
--
Konrad Garus
missing_block
Description: Binary data
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/1/8 Tom Lane :
> So which of these rows are invisible? According to the flags
> items 1, 3 and 5 should be visible while 2 and 4 are dead versions
> (of 3 and 5 respectively).
All 3 are invisible, and at the same time they are the only 3 rows
missing from the table.
--
Kon
03712,75) | 17140369 | 15460682
(603712,78) | 17140373 | 15460873
(603714,1) | 17140379 | 15460685
(603714,3) | 17140380 | 15460473
(603714,5) | 17140381 | 15460875
(603714,7) | 17140382 | 15460686
(603714,9) | 17140383 | 15460474
--
Konrad Garus
--
Just a reminder - these rows are over 6 months old and were lost at
night when the system was lightly used.
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Could the damage be done by vacuum?
--
Konrad Garus
missing_block
Description: Binary data
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
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.
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to y
or 4.
How about this?
# select attachment_id from attachment where ctid = '(603713,1)';
attachment_id
---
15460683
(1 row)
# select attachment_id from attachment where attachment_id = 15460683;
attachment_id
---
(0 rows)
--
Konrad Garus
--
Sent via p
ble. I also tried looking for the row with another index and
with seq scan and could not see it.
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
; FOREIGN KEY (attached_by) REFERENCES usr(usr_id)
Rules:
attachment_no_delete AS
ON DELETE TO attachment DO INSTEAD SELECT no_delete() AS no_delete
Has OIDs: no
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
time zone)
(3 rows)
# select count(*) from attachment where when_uploaded < '2010-01-01';
count
--
22523639
(1 row)
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
n resolved.
Thank you all for help.
--
Konrad Garus
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
19 matches
Mail list logo
