Re: Re: Otvet: WAL and indexes (Re: [HACKERS] WAL status & todo)

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [001016 09:47] wrote:
> "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
> >> I don't understand why WAL needs to log internal operations of any of
> >> the index types. Seems to me that you could treat indexes as black
> >> boxes that are updated as side effects of WAL log items for heap tuples:
> >> when adding a heap tuple as a result of a WAL item, you just call the
> >> usual index insert routines, and when deleting a heap tuple as a result
>
> > On recovery backend *can't* use any usual routines:
> > system catalogs are not available.
>
> OK, good point, but that just means you can't use the catalogs to
> discover what indexes exist for a given table. You could still create
> log entries that look like "insert indextuple X into index Y" without
> any further detail.

One thing you guys may wish to consider is selectively fsyncing on
system catelogs and marking them dirty when opened for write:

postgres: i need to write to a critical table...
opens table, marks dirty
completes operation and marks undirty and fsync

-or-

postgres: i need to write to a critical table...
opens table, marks dirty
crash, burn, smoke (whatever)

Now you may still have the system tables broken, however the chances
of that may be siginifigantly reduced depending on how often writes
must be done to them.

It's a hack, but depending on the amount of writes done to critical
tables it may reduce the window for these inconvient situations
signifigantly.

--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."