On 14.12.2010 23:06, Robert Haas wrote:
On Sat, Nov 13, 2010 at 9:09 PM, Robert Haas<robertmh...@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?
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
