FDW and transaction management - Mailing list pgsql-general

From Michael Holzman
Subject FDW and transaction management
Date
Msg-id CAPNViJqAmJd9h9sQU8En432Gi6_V41nO-BXkY1TKpi0u2B7Jbw@mail.gmail.com
Whole thread Raw
Responses Re: FDW and transaction management
List pgsql-general
Greetings,

I am trying to understand the subject. I see in the documentation (http://www.postgresql.org/docs/current/static/postgres-fdw.html) that

F.31.3. Transaction Management

During a query that references any remote tables on a foreign server, postgres_fdw opens a transaction on the remote server if one is not already open corresponding to the current local transaction. The remote transaction is committed or aborted when the local transaction commits or aborts. Savepoints are similarly managed by creating corresponding remote savepoints.

The remote transaction uses SERIALIZABLE isolation level when the local transaction has SERIALIZABLE isolation level; otherwise it uses REPEATABLE READ isolation level. This choice ensures that if a query performs multiple table scans on the remote server, it will get snapshot-consistent results for all the scans. A consequence is that successive queries within a single transaction will see the same data from the remote server, even if concurrent updates are occurring on the remote server due to other activities. That behavior would be expected anyway if the local transaction uses SERIALIZABLE or REPEATABLE READ isolation level, but it might be surprising for a READ COMMITTED local transaction. A future PostgreSQL release might modify these rules.

Unfortunately, the Postgres Wiki (https://wiki.postgresql.org/wiki/SQL/MED#No_transaction_management) states quite the opposite:

No transaction management

FDW for PostgreSQL never emit transaction command such as BEGIN, ROLLBACK and COMMIT. Thus, all SQL statements are executed in each transaction when 'autocommit' was set to 'on'.


What is the correct state of the subject?


--
Regards,
    Michael Holzman

pgsql-general by date:

Previous
From: Ben Leslie
Date:
Subject: Re: Is PRIMARY KEY the same as UNIQUE NOT NULL?
Next
From: Harald Fuchs
Date:
Subject: log_min_duration question