Re: Misleading comment in prologue of ReorderBufferQueueMessage - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Misleading comment in prologue of ReorderBufferQueueMessage
Date
Msg-id CAA4eK1JxQ9ywJiV6YxFCt9p-NJASWErb=18EdT05HNWXS=cE3g@mail.gmail.com
Whole thread Raw
In response to Misleading comment in prologue of ReorderBufferQueueMessage  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: Misleading comment in prologue of ReorderBufferQueueMessage
List 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 by date:

Previous
From: Benoit Lobréau
Date:
Subject: Re: pg_shmem_allocations & documentation
Next
From: Peter Eisentraut
Date:
Subject: Re: HASH_BLOBS hazards (was Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions)