postgres_fdw: dead lock in a same transaction when postgres_fdw server is lookback

From: Xiaoran Wang <wxiaoran(at)vmware(dot)com>
To: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: postgres_fdw: dead lock in a same transaction when postgres_fdw server is lookback
Date: 2022-10-01 04:02:09
Message-ID: SN6PR05MB44620E572CF94BDA81184E9BBA599@SN6PR05MB4462.namprd05.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I created a postgers_fdw server lookback as the test does. Then run the following SQLs

create table t1(c0 int);

insert into t1 values(1);

create foreign table ft1(
c0 int
) SERVER loopback OPTIONS (schema_name 'public', table_name 't1');

Then started a transaction that runs queries on both t1 and ft1 tables:

begin;

select * from ft1;
c0
----
1
(1 row)

select * from t1;
c0
----
1
(1 row)

insert into ft1 values(2);

select * from ft1;
c0
----
1
2
(2 rows)

select * from t1;
c0
----
1
(1 row)

Though t1 and ft1 actually share the same data, and in the same transaction, they have different transaction ids and different snapshots, and queries are run in different processes, they see different data.

Then I attempted to run the update on them

update t1 set c0=8;

update ft1 set c0=9;

Then the transaction got stuck. Should the "lookback" server be disabled in the postgres_fdw?

Thoughts?

thanks,
Xiaoran

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2022-10-01 04:20:54 Re: Bloom filter Pushdown Optimization for Merge Join
Previous Message Zhihong Yu 2022-10-01 03:40:36 Re: Bloom filter Pushdown Optimization for Merge Join