Re: Transactional enum additions - was Re: Alter or rename enum value

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Transactional enum additions - was Re: Alter or rename enum value
Дата
Msg-id 19053.1473008472@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Transactional enum additions - was Re: Alter or rename enum value  (Emre Hasegeli <emre@hasegeli.com>)
Список pgsql-hackers
Emre Hasegeli <emre@hasegeli.com> writes:
>> +   /*
>> +    * If the row is hinted as committed, it's surely safe.  This provides a
>> +    * fast path for all normal use-cases.
>> +    */
>> +   if (HeapTupleHeaderXminCommitted(enumval_tup->t_data))
>> +       return;
>> +
>> +   /*
>> +    * Usually, a row would get hinted as committed when it's read or loaded
>> +    * into syscache; but just in case not, let's check the xmin directly.
>> +    */
>> +   xmin = HeapTupleHeaderGetXmin(enumval_tup->t_data);
>> +   if (!TransactionIdIsInProgress(xmin) &&
>> +       TransactionIdDidCommit(xmin))
>> +       return;

> This looks like transaction internal logic inside enum.c to me.  Maybe
> it is because I am not much familiar with the internals.  I couldn't
> find a similar pattern anywhere else, but it might still be useful to
> invent something like HeapTupleHeaderXminReallyCommitted().

I wondered about that too, but there are no other roughly similar cases
that I could find, and abstracting from a single use-case is perilous ---
especially when there's no compelling reason to think there will ever be
any other similar use-cases.  I'd originally wondered whether we could
replace this logic with a call to something in tqual.c, but none of the
available functions there produce the required behavior either.
        regards, tom lane



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Make better use of existing enums in plpgsql
Следующее
От: Emre Hasegeli
Дата:
Сообщение: Re: Floating point comparison inconsistencies of the geometric types