Re: logical decoding - GetOldestXmin

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: logical decoding - GetOldestXmin
Дата
Msg-id CA+TgmoZK+0DHhwb+MROs=W4twS-w_50xCp2iR1HAr7oss+tNWg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: logical decoding - GetOldestXmin  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Dec 18, 2012 at 7:59 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2012-12-18 19:56:18 -0500, Robert Haas wrote:
>> On Tue, Dec 18, 2012 at 5:25 PM, anarazel@anarazel.de
>> <andres@anarazel.de> wrote:
>> > The problem is that at the time GetSnapshotData returns the xmin horizon might have gone upwards and tuples
requiredfor decoding might get removed by other backends. That needs to be prevented while holding the  procarray lock
exclusively.
>>
>> Well, for the ordinary use of GetSnapshotData(), that doesn't matter,
>> because GetSnapshotData() also updates proc->xmin.  If you're trying
>> to store a different value in that field then of course it matters.
>
> Absolutely right. I don't want to say there's anything wrong with it
> right now. The "problem" for me is that it sets proc->xmin to the newest
> value it can while I want/need the oldest valid value...
>
> I will go with adding a already_locked parameter to GetOldestXmin then.

Or instead of bool already_locked, maybe bool advertise_xmin?   Seems
like that might be more friendly to the abstraction boundaries.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Makefiles don't seem to remember to rebuild everything anymore
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Support for REINDEX CONCURRENTLY