Re: The ability of postgres to determine loss of files of the main fork
От | Aleksander Alekseev |
---|---|
Тема | Re: The ability of postgres to determine loss of files of the main fork |
Дата | |
Msg-id | CAJ7c6TMYvYBQpgv8k+4QnajqPcroOzrj7d3snBBTKX4tHQfVYw@mail.gmail.com обсуждение исходный текст |
Ответ на | The ability of postgres to determine loss of files of the main fork (Frits Hoogland <frits.hoogland@gmail.com>) |
Ответы |
Re: The ability of postgres to determine loss of files of the main fork
Re: The ability of postgres to determine loss of files of the main fork |
Список | pgsql-hackers |
Hi Frits, > Therefore, I would like to request an enhancement: add an option to > verify_heapam() that causes the primary key index to be scanned and makes > sure that all line pointers in the index point to existing tuples. I'm a bit puzzled by your emphasis on primary keys. In Postgres it is legal to have tables without PKs, indexes, or even columns: =# create table my_table(); =# select * from my_table; To clarify, are you proposing not to check such tables? > An alternative might be to track the number of segments of a relation in > pg_class, but that may be difficult to make crash-safe. Hm... the fact that we have a segment on disk doesn't mean it is not empty or not corrupted. Let's say we will add a check you are proposing. The next person will complain that we don't check the size of the segments. The next one - about the fact that we don't verify checksums. So IMO there is little value in adding a check for the existence of the segments for a single table. And the *real* check will not differ much from something like SELECT * FROM my_table, or from making a complete backup of the database. -- Best regards, Aleksander Alekseev
В списке pgsql-hackers по дате отправления: