Dear Osumi-san, > I mainly followed the steps there and > replaced the command "SELECT" for the remote table at 6-9 with "INSERT" > command. > Then, after waiting for few seconds, the "COMMIT" succeeded like below output, > even after the server stop of the worker side.
> Additionally, the last reference "SELECT" which failed above can succeed, > if I restart the worker server before the "SELECT" command to the remote > table. > This means the transaction looks successful but the data isn't there ? > Could you please have a look at this issue ? Good catch. This was occurred because we disconnected the crashed server. Previously the failed server had been disconnected in the pgfdw_connection_check(). It was OK if the transaction(or statement) was surely cacneled. But currently the statement might be not canceled because QueryCancelPending might be cleaned up[1]. If we failed to cancel statements and reached pgfdw_xact_callback(), the connection would not be used because entry->conn is NULL. That's why you sucseeded to do "COMMIT". However, the backend did not send "COMMIT" command to the srever, so inserted data was vanished on remote server. I understood that we should not call disconnect_pg_server(entry->conn) even if we detect the disconnection. If should be controlled in Xact callback. This will be modified in next version. Moreover, I noticed that we should enable timer even if the QueryCancelMessage was not NULL. If we do not turn on here, the checking will be never enabled again. [1]: https://www.postgresql.org/message-id/TYAPR01MB5866CE34430424A588F60FC2F55D9%40TYAPR01MB5866.jpnprd01.prod.outlook.com Best Regards, Hayato Kuroda FUJITSU LIMITED
