On Fri, Dec 17, 2010 at 2:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> IIUC, the problem is that the bufmgr might think that a GIST NSN is an
> LSN that should affect when to force out a dirty buffer? What if we
> taught it the difference? We could for example dedicate a pd_flags
> bit to marking pages whose pd_lsn isn't actually an LSN.
>
> This solution would probably imply that all pages in the shared buffer
> pool have to have a standard PageHeaderData header, not just an LSN at
> the front as is assumed now. But that doesn't seem like a bad thing to
> me, unless maybe we were dumb enough to not use a standard page header
> in some of the secondary forks.
Ah, interesting idea. visibilitymap.c has this:
#define MAPSIZE (BLCKSZ - MAXALIGN(SizeOfPageHeaderData))
and fsm_internals.h has this:
#define NodesPerPage (BLCKSZ - MAXALIGN(SizeOfPageHeaderData) - \
offsetof(FSMPageData, fp_nodes))
...which seems to imply, at least on a quick look, that we might be
OK, as far as the extra forks go.
I have a vague recollection that the documentation says somewhere that
a full page header on every page isn't required. And I'm a little
worried about my ability to track down every place in the system that
might get broken by a change in this area. What do you think about
committing the unlogged tables patch initially without support for
GIST indexes, and working on fixing this as a separate commit?
Another possibly-useful thing about mandating a full page header for
every page is that it might give us a way of avoiding unnecessary full
page writes. As I wrote previously:
> However, I think we can avoid this too, by
> allocating an additional bit in pd_flags, PD_FPI. Instead of emitting
> an FPI when the old LSN precedes the redo pointer, we'll emit an FPI
> when the FPI bit is set (in which case we'll also clear the bit) OR
> when the old LSN precedes the redo pointer. Upon emitting a WAL
> record that is torn-page safe (such as a freeze or all-visible
> record), we'll pass a flag to XLogInsert that arranges to suppress
> FPIs, bump the LSN, and set PD_FPI. That way, if the page is touched
> again before the next checkpoint by an operation that does NOT
> suppress FPI, one will be emitted then.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
