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 по дате отправления: