RE: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.

From: "egashira(dot)yusuke(at)fujitsu(dot)com" <egashira(dot)yusuke(at)fujitsu(dot)com>
To: 'Noah Misch' <noah(at)leadboat(dot)com>
Cc: "'pgsql-bugs(at)lists(dot)postgresql(dot)org'" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: RE: Reconnect a single connection used by multiple threads in embedded SQL in C application causes error.
Date: 2022-02-25 11:29:55
Message-ID: TYWPR01MB72023E15214B3EF77D53D0A3FF3E9@TYWPR01MB7202.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Noah,

> Would you like to propose a patch?

Sure. I will work on creating a document patch.

However, I found another problem while testing to make sure that the use cases were valid.

> - Each thread does its own CONNECT, DISCONNECT, and other commands.
> Each thread has its own default connection. No sharing at all."

In that case, if I execute CONNECT with same connection-string on each threads without connection-name, the later CONNECT was skipped.
Then, ECPGdebug shows following message.

ECPGconnect: connection identifier (null) is already in use

This seems to indicate that CONNECT need to specify connection-name even if we use the default connection in each thread.
This also seems to me to be an undesirable behavior in multiple thread.
Or do we need to name all connections if we use multiple connections, even in multiple thread?

Regards,
Yusuke Egashira

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mark Murawski 2022-02-25 20:15:09 Re: Bug plperl.c
Previous Message Kyotaro Horiguchi 2022-02-25 01:59:21 Re: Wal sender process not moving past wait_event_type: IO and wait_event: WALRead