Re: unlogged tables vs. GIST

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, pgsql-hackers@postgresql.org
Date: 2010-12-17T19:32:20Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. The GiST scan algorithm uses LSNs to detect concurrent pages splits, but

On Fri, Dec 17, 2010 at 2:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> On 17.12.2010 21:07, Tom Lane wrote:
>>> 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.
>
>> I'm not very fond of expanding buffer manager's knowledge of the page
>> layout. How about a new flag in the buffer desc, BM_UNLOGGED?
>
> That could work too, if you can explain how the flag comes to be set
> without a bunch of ugliness all over the system.  I don't want callers
> of ReadBuffer to have to supply the bit for example.

That's easy enough to solve - ReadBuffer() takes a Relation as an
argument, so you can easily check RelationNeedsWAL(reln).

I guess the question is whether it's right to conflate "table is
unlogged" with "LSN is fake".  It's not immediately obvious to me that
those concepts are isomorphic, although though the reverse isn't
obvious to me either.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company