RE: Transactions involving multiple postgres foreign servers, take 2 - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: Transactions involving multiple postgres foreign servers, take 2
Date
Msg-id TYAPR01MB299036FF6C50A9B6C637E0D4FE1C0@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Transactions involving multiple postgres foreign servers, take 2  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
> >         if (PQstatus(entry->conn) != CONNECTION_OK ||
> >             PQtransactionStatus(entry->conn) != PQTRANS_IDLE ||
> >             entry->changing_xact_state)
> >         {
> >             elog(DEBUG3, "discarding connection %p", entry->conn);
> >             disconnect_pg_server(entry);
> >         }
>
> Right.  Although it's not directly relevant to this discussion,
> precisely, that part is not visited just after the remote "COMMIT
> TRANSACTION" failed. If that commit fails or is canceled, an exception
> is raised while entry->changing_xact_state = true. Then the function
> is called again within AbortCurrentTransaction() and reaches the above
> code.

Ah, then the connection to the foreign server is closed after failing to cancel the query.  Thanks.


Regards
Takayuki Tsunakawa




pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Next
From: vignesh C
Date:
Subject: Re: Parallel copy