Cross-database SERIALIZABLE safe snapshots

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Cross-database SERIALIZABLE safe snapshots
Date: 2023-03-09 05:34:27
Message-ID: CA+hUKGLqUAbpvO-aRznvF2LXnVBuRkYa7NcEG65C7Z0nziWKqw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Here is a feature idea that emerged from a pgsql-bugs thread[1] that I
am kicking into the next commitfest. Example:

s1: \c db1
s1: CREATE TABLE t (i int);
s1: BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
s1: INSERT INTO t VALUES (42);

s2: \c db2
s2: BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE READ ONLY DEFERRABLE;
s2: SELECT * FROM x;

I don't know of any reason why s2 should have to wait, or
alternatively, without DEFERRABLE, why it shouldn't immediately drop
from SSI to SI (that is, opt out of predicate locking and go faster).
This change relies on the fact that PostgreSQL doesn't allow any kind
of cross-database access, except for shared catalogs, and all catalogs
are already exempt from SSI. I have updated this new version of the
patch to explain that very clearly at the place where that exemption
happens, so that future hackers would see that we rely on that fact
elsewhere if reconsidering that.

[1] https://www.postgresql.org/message-id/flat/17368-98a4f99e8e4b4402%40postgresql.org

Attachment Content-Type Size
0001-Optimize-cross-database-SERIALIZABLE-safe-snapshots.patch text/x-patch 5.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2023-03-09 06:05:21 Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher
Previous Message Amit Kapila 2023-03-09 05:30:46 Re: Time delayed LR (WAS Re: logical replication restrictions)