Re: Misleading comment in prologue of ReorderBufferQueueMessage

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Misleading comment in prologue of ReorderBufferQueueMessage
Дата
Msg-id CAA4eK1JxQ9ywJiV6YxFCt9p-NJASWErb=18EdT05HNWXS=cE3g@mail.gmail.com
обсуждение исходный текст
Ответ на Misleading comment in prologue of ReorderBufferQueueMessage  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Ответы Re: Misleading comment in prologue of ReorderBufferQueueMessage  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список pgsql-hackers
On Mon, Dec 14, 2020 at 2:45 PM Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
>
> The name of the function suggests that the given message will be queued in ReorderBuffer. The prologue of the
functionsays so too 
>  776 /*
>  777  * Queue message into a transaction so it can be processed upon commit.
>  778  */
> It led me to think that a non-transactional message is processed along with the surrounding transaction, esp. when it
hasan associated xid. 
>
> But in reality, the function queues only a transactional message and decoders a non-transactional message immediately
withoutwaiting for a commit. 
>
> We should modify the prologue to say
> "Queue a transactional message into a transaction so that it can be processed upon commit. A non-transactional
messageis processed immediately." and also change the name of the function to ReorderBufferProcessMessage(), but the
latermay break API compatibility. 
>

+1 for the comment change but I am not sure if it is a good idea to
change the API name.

--
With Regards,
Amit Kapila.



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

Предыдущее
От: Benoit Lobréau
Дата:
Сообщение: Re: pg_shmem_allocations & documentation
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: HASH_BLOBS hazards (was Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions)