Re: including PID or backend ID in relpath of temp rels

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: including PID or backend ID in relpath of temp rels
Дата
Msg-id AANLkTimIXQL3cQzJb6Zy5EAJpfEkk4mHd4CWpZFESt-x@mail.gmail.com
обсуждение исходный текст
Ответ на Re: including PID or backend ID in relpath of temp rels  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Apr 27, 2010 at 9:59 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> [storage.c,xact.c,twophase.c] smgrGetPendingDeletes returns via an out
> parameter (its second argument) a list of RelFileNodes pending delete,
> which we then write to WAL or to the two-phase state file.

It appears that we are playing a little bit fast and loose with this.
I think that the two-phase code path is solid because we prohibit
PREPARE TRANSACTION if the transaction has referenced any temporary
tables, so when we read the two-phase state file it's safe to assume
that all the tables mentioned are non-temporary.  But the ordinary
one-phase commit writes permanent and temporary relfilenodes to WAL
without distinction, and then, in xl_redo_commit() and
xl_redo_abort(), does this:
               XLogDropRelation(xlrec->xnodes[i], fork);               smgrdounlink(srel, fork, false, true);

The third argument to smgrdounlink() is "isTemp", which we're here
passing as false, but might really be true.  I don't think it
technically matters at present because the only effect of that
parameter right now is that we pass it through to
DropRelFileNodeBuffers(), which will drop shared buffers rather than
local buffers as a result of the incorrect setting.  But that won't
matter because the WAL replay process shouldn't have any local buffers
anyway, since temp relations are not otherwise WAL-logged.  For the
same reason, I don't think the call to XLogDropRelation() is an issue
because its only purpose is to remove entries from invalid_page_tab,
and there won't be any temporary pages in there anyway.

Of course if we're going to do $SUBJECT this will need to be changed
anyway, but assuming the above analysis is correct I think the
existing coding at least deserves a comment...  then again, maybe I'm
all mixed up?

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: max_standby_delay considered harmful
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: max_standby_delay considered harmful