On Tue, Dec 14, 2010 at 5:14 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Dec 14, 2010 at 4:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Tue, Dec 14, 2010 at 4:24 PM, Heikki Linnakangas
>>> <heikki.linnakangas@enterprisedb.com> wrote:
>>>> 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.
>>
>>> That doesn't seem ideal, either, because now you're eating up some
>>> number of bytes per page in every GIST index just on the off chance
>>> that one of them is unlogged.
>>
>> On-disk compatibility seems problematic here as well.
>
> Good point.
Given the foregoing discussion, I see only two possible paths forward here.
1. Just decide that that unlogged tables can't have GIST indexes, at
least until someone figures out a way to make it work. That's sort of
an annoying limitation, but I think we could live with it.
2. Write WAL records even though the GIST index is supposedly
unlogged. We could either (1) write the usual XLOG_GIST_* records,
and arrange to ignore them on replay when the relation in question is
unlogged, or (2) write an XLOG_NOOP record to advance the current LSN.The latter sounds safer to me, but it will mean
thatthe XLOG code
for GIST needs three separate cases (temp, perm, unlogged). Either
way we give up a significant chunk of the benefit of making the
relation unlogged in the first place.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company