Re: Shouldn't flush dirty buffers at shutdown ?
От | Tom Lane |
---|---|
Тема | Re: Shouldn't flush dirty buffers at shutdown ? |
Дата | |
Msg-id | 13650.957892807@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: Shouldn't flush dirty buffers at shutdown ? ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes: >> Hmm, good point, but that doesn't seem like the right answer. >> Suppose the system crashes before we are able to flush the >> dirty buffers? > You are right but we could hardly expect the completeness > of indexes in case of system crash because indexes are out > of transactional control currently. What? We do flush the index blocks before committing, just the same as heap blocks, so I do not see the risk there. If we have committed a tuple then its index entries should be on disk too. The risk I think you have shown is that there may be extra index entries that correspond to no tuple because we wrote the index blocks first and then crashed before writing the tuple. > Probably an index entry that points to a non-existent heap > block doesn't cause a problem immediately because heap_ > fetch() ignores UNUSED heap blocks. > However it will not be long before the heap block is filled with > another tuple. heap_insert/update() could hardly check that > the inserting heap block is already pointed from some index > entry. Yes. We need some way of cross-checking that an index entry actually does match the tuple it thinks it's pointing at. The first thought that comes to mind is that the index tuple should contain the OID of the tuple it is for, and then we can check that against the pointed-to tuple. If they don't match, the index entry is bogus and can be discarded at the next VACUUM. regards, tom lane
В списке pgsql-hackers по дате отправления: