Re: unlogged tables vs. GIST

On 14.12.2010 23:06, Robert Haas wrote:
> On Sat, Nov 13, 2010 at 9:09 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>>> The fact that it's easy doesn't make it workable. I would point out for
>>> starters that AMs might (do) put WAL locations and/or XIDs into indexes.
>>> Occasionally copying very old LSNs or XIDs back into active files seems
>>> pretty dangerous.
>>
>> I haven't examined the GIST, GIN, or hash index code in detail so I am
>> not sure whether there are any hazards there; the btree case does not
>> seem to have any issues of this type. Certainly, if an index AM puts
>> an XID into an empty index, that's gonna break. I would consider that
>> a pretty odd thing to do, though. An LSN seems less problematic since
>> the LSN space does not wrap; it should just look like an index that
>> was created a long time ago and never updated (which, in effect, it
>> is).
>
> I'm still not convinced there's any hazard of this type, but there is,
> apparently, a problem with failing to emit XLOG records for GIST
> indexes, because they apparently use LSNs to detect concurrent page
> splits (see Heikki's commit on November 16th, aka
> 2edc5cd493ce3d7834026970e9d3cd00e203f51a) and the hack he inserted to
> work around that problem for temporary tables isn't going to work for
> unlogged tables. I suppose we could disallow unlogged GIST indexes.
> Or we could allow them but still XLOG some operations anyway to make
> sure that the LSN advances at the appropriate time. That seems pretty
> ugly, though. Any other ideas?

Hmm, the first idea that comes to mind is to use a counter like the
GetXLogRecPtrForTemp() counter I used for temp tables, but global, in
shared memory. However, that's a bit problematic because if we store a
value from that counter to LSN, it's possible that the counter overtakes
the XLOG insert location, and you start to get xlog flush errors. We
could avoid that if we added a new field to the GiST page header, and
used that to store the value in the parent page instead of the LSN.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com