On Sat, Nov 13, 2010 at 9:09 PM, Robert Haas <robertmhaas@gmail.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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company