Re: PITR, checkpoint, and local relations

I said:
> In short, the proposal runs something like this:

> * Regular tables that happen to be in their first transaction of
> existence are not treated differently from any other regular table so
> far as buffer management or WAL or PITR go.  (rd_myxactonly either goes
> away or is used for much less than it is now.)

> * TEMP tables use the local buffer manager for their entire existence.
> (This probably means adding an "rd_istemp" flag to relcache entries, but
> I can't see anything wrong with that.)

> * Local bufmgr semantics are twiddled to reflect this reality --- in
> particular, data in local buffers can be held across transactions, there
> is no end-of-transaction write (much less fsync).  A TEMP table that
> isn't too large might never touch disk at all.

> * Data operations in TEMP tables do not get WAL-logged, nor do we
> WAL-log page images of local-buffer pages.

I've committed changes to implement these ideas.  One thing that proved
interesting was that transactions that only made changes in existing
TEMP tables failed to commit --- RecordTransactionCommit thought it
didn't need to do anything, because no WAL entries had been made!  This
was fixed by introducing another flag that gets set when we skip making
a WAL record because we're working in a TEMP relation.

I have not done anything about exporting NLocBuffer as a GUC parameter.
The algorithms in localbuf.c are, um, pretty sucky, and would run very
slowly if NLocBuffer were large.  It'd make sense to install a hash
index table similar to the one used for shared buffers, and then we
could allow people to set NLocBuffer as large as their system can stand.
I figured that was a task for another day, however.

			regards, tom lane