Robert Haas <robertmh...@gmail.com> writes:
> Given the foregoing discussion, I see only two possible paths forward here.
> 1. Just decide that that unlogged tables can't have GIST indexes, at
> least until someone figures out a way to make it work. That's sort of
> an annoying limitation, but I think we could live with it.
> 2. Write WAL records even though the GIST index is supposedly
> unlogged. We could either (1) write the usual XLOG_GIST_* records,
> and arrange to ignore them on replay when the relation in question is
> unlogged, or (2) write an XLOG_NOOP record to advance the current LSN.
> The latter sounds safer to me, but it will mean that the XLOG code
> for GIST needs three separate cases (temp, perm, unlogged). Either
> way we give up a significant chunk of the benefit of making the
> relation unlogged in the first place.
> Thoughts?
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
