"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
