Re: unlogged tables vs. GIST

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: unlogged tables vs. GIST
Date: 2010-12-18 01:50:54
Message-ID: AANLkTikuCukaVdQK2xLH0ViuFF3qzCOb4=V3JjQAZDdQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 17, 2010 at 4:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Since these bits will only be set/cleared when the buffer mapping is
>> changed, can we examine this bit without taking the spinlock?
>
> Only if you're willing for the result to be unreliable.

If we read the bits while someone else is writing them, we'll get
either the old or the new value, but the BM_FLUSH_XLOG bit will be the
same either way. When FlushBuffer() is called, a shared content log
and a pin are held, so the buffer can't be renamed under us. If
that's really unacceptable, we can do something like the attached, but
I think this is unnecessarily gross. We already assume in other
places that the read or write of an integer is atomic. In this case
we don't even need it to be fully atomic - we just need the particular
byte that contains this bit not to go through some intermediate state
where the bit is unset. Is there really a memory architecture out
there that's crazy enough to let such a thing happen? If so, I'd
expect things to be breaking right and left on that machine anyway.

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

Attachment Content-Type Size
bm-flush-xlog-paranoid.patch application/octet-stream 7.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-12-18 02:00:15 Re: Tab completion for ALTER ... SET SCHEMA
Previous Message andreas 2010-12-18 01:34:54 Tab completion for ALTER ... SET SCHEMA