list of TransactionIds

On Sat, May 14, 2022 at 1:57 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

We didn't have any use of TransactionId as members of List, until
RelationSyncEntry->streamed_txns was introduced (464824323e57, pg14).
It's currently implemented as a list of int. This is not wrong at
present, but it may soon be, and I'm sure it rubs some people the wrong
way.

But is the rubbing way wrong enough to add support for TransactionId in
pg_list.h, including, say, T_XidList?

+1. I don't know if we have a need for this at other places but I feel
it is a good idea to make its current use better.

--
With Regards,
Amit Kapila.

On 2022-May-14, Amit Kapila wrote:

On Sat, May 14, 2022 at 1:57 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

We didn't have any use of TransactionId as members of List, until
RelationSyncEntry->streamed_txns was introduced (464824323e57, pg14).
It's currently implemented as a list of int. This is not wrong at
present, but it may soon be, and I'm sure it rubs some people the wrong
way.

But is the rubbing way wrong enough to add support for TransactionId in
pg_list.h, including, say, T_XidList?

+1. I don't know if we have a need for this at other places but I feel
it is a good idea to make its current use better.

I hesitate to add this the day just before beta. This is already in
pg14, so maybe it's not a big deal if pg15 remains the same for the time
being. Or we can change it for beta2. Or we could just punt until
pg16. Any preferences?

(Adding this to pg14 seems out of the question. It's probably okay
ABI-wise to add a new node tag at the end of the list, but I'm not sure
it's warranted.)

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"No deja de ser humillante para una persona de ingenio saber
que no hay tonto que no le pueda enseñar algo." (Jean B. Say)

On Sun, May 15, 2022 at 5:05 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

On 2022-May-14, Amit Kapila wrote:

On Sat, May 14, 2022 at 1:57 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

We didn't have any use of TransactionId as members of List, until
RelationSyncEntry->streamed_txns was introduced (464824323e57, pg14).
It's currently implemented as a list of int. This is not wrong at
present, but it may soon be, and I'm sure it rubs some people the wrong
way.

But is the rubbing way wrong enough to add support for TransactionId in
pg_list.h, including, say, T_XidList?

+1. I don't know if we have a need for this at other places but I feel
it is a good idea to make its current use better.

I hesitate to add this the day just before beta. This is already in
pg14, so maybe it's not a big deal if pg15 remains the same for the time
being. Or we can change it for beta2. Or we could just punt until
pg16. Any preferences?

I prefer to do this for pg16 unless we see some bug due to this.

--
With Regards,
Amit Kapila.

On Mon, May 16, 2022 at 07:58:37AM +0530, Amit Kapila wrote:

I prefer to do this for pg16 unless we see some bug due to this.

Agreed. This does not seem worth taking any risk with after beta1,
and v14 got released this way.
--
Michael

On 2022-May-16, Amit Kapila wrote:

On Sun, May 15, 2022 at 5:05 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

I hesitate to add this the day just before beta. This is already in
pg14, so maybe it's not a big deal if pg15 remains the same for the time
being. Or we can change it for beta2. Or we could just punt until
pg16. Any preferences?

I prefer to do this for pg16 unless we see some bug due to this.

Pushed now, to master only.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

On Monday, July 4, 2022 9:27 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

Hi,

Pushed now, to master only.

Thanks for introducing these APIs!

While trying to use the newly introduced list_member_xid(), I noticed that it
internally use lfirst_oid instead of lfirst_xid. It works ok for now. Just in
case we change xid to 64 bits in the future, I think we’d better use lfirst_xid
here.

Here is a tiny patch to fix that.

Best regards,
Hou Zhijie

Hello

On 2022-Oct-20, houzj.fnst@fujitsu.com wrote:

While trying to use the newly introduced list_member_xid(), I noticed that it
internally use lfirst_oid instead of lfirst_xid. It works ok for now. Just in
case we change xid to 64 bits in the future, I think we’d better use lfirst_xid
here.

Egad.

Here is a tiny patch to fix that.

Pushed, thanks.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"I can't go to a restaurant and order food because I keep looking at the
fonts on the menu. Five minutes later I realize that it's also talking
about food" (Donald Knuth)