(Прочитал patch) Извините, получается, что я просто перепутал — patch с самого начала был только про static partition creation (т.е. никаких принципиально новых возможностей он не даёт, это просто "сахар"). ;(

Кажется откатываться должно при коммите. Сразу не откатывается, даже когда PG понял, что одну из транзакции нужно бдует откатить, он всё равно будет ждать комит.

это логично, т.к. во второй может еще случиться роллбэк, и откатывать не придется )

Кстати
коллеги, а можно нубский вопрос?

а возможны вообще долгоживущие транзакции, хотя бы в теории?

стартовал - получил id транзакции
делаешь что-то в ней
закоммитил, указав id

не привязанные к коннекту?

Ребята, что я не так делаю? Дамплю с помощью pg_dump, потом восстанавливаю в базу с другим именем, пишу \dt и получаю:

Did not find any relations.

Не получилось воспроизвести "эффекты" с attach partition (

Таблицы/партиции/данные:

postgres=# \d+ l
                               Partitioned table "public.l"
 Column |  Type   | Collation | Nullable | Default | Storage  | Stats target | Description 
--------+---------+-----------+----------+---------+----------+--------------+-------------
 period | text    |           |          |         | extended |              | 
 id     | integer |           | not null |         | plain    |              | 
 data   | text    |           |          |         | extended |              | 
Partition key: LIST (period)
Indexes:
    "l_id_idx" btree (id)
Partitions: l_y2019q4 FOR VALUES IN ('y2019q4'),
            l_y2021q1 FOR VALUES IN ('y2021q1'),
            l_y2021q2 FOR VALUES IN ('y2021q2'),
            l_y2021q3 FOR VALUES IN ('y2021q3'),
            l_y2021q4 FOR VALUES IN ('y2021q4')

postgres=# select * from l;
 period  | id |     data     
---------+----+--------------
 y2019q4 |  1 | text y2019q4
 y2021q2 |  1 | some text 1
 y2021q3 |  1 | text y2021q3
(4 rows)

Выполняю следующие дейстия:

Сессия 1:

begin isolation level serializable;
select * from pg_class limit 1;

Сессия 2:

begin isolation level serializable;
create table l_y2019q3 (like l including defaults including constraints);
alter table l attach partition l_y2019q3 for values in ('y2019q3');
insert into l values ('y2019q3', 1, 'test y2019q3');
commit;

Сессия 1:

select * from l;
 period  | id |     data     
---------+----+--------------
 y2019q4 |  1 | text y2019q4
 y2021q2 |  1 | some text 1
 y2021q3 |  1 | text y2021q3
(3 rows)

Вижу вполне консистентный снимок данных.

show search_path. Наверняка таблица в какой-то схеме, а в новой базе search_path отличается от оригинальной.

Таблицы в схеме public, единственной существующей. Или при дампе/восстановлении это нужно как-то указать?

Забыл добавить, что у меня тут скорей всего нет конфликтов никаких и "блокировок" SIRead.
Не знаю, как их добавить с attach partition

Ну так требование SERIALIZABLE — это serializability, а не всего лишь "консистентные снимки". ;)
Т.е. показанное не провоцирует никаких аномалий, для которых "не хватает" RR, нет?
Вот, например, то, что провоцирует:

DROP TABLE demo_anomaly;

CREATE TABLE demo_anomaly(part_key int, x int, PRIMARY KEY (part_key, x)) PARTITION BY LIST (part_key);
CREATE TABLE demo_anomaly_1 PARTITION OF demo_anomaly FOR VALUES IN (1);
CREATE TABLE demo_anomaly_2 PARTITION OF demo_anomaly FOR VALUES IN (2);
CREATE TABLE demo_anomaly_3 PARTITION OF demo_anomaly FOR VALUES IN (3);

CREATE OR REPLACE FUNCTION check_anomaly()
RETURNS TRIGGER
LANGUAGE plpgsql
AS $function$
DECLARE
BEGIN
IF (SELECT COUNT(*)
      FROM demo_anomaly
     WHERE demo_anomaly.x = NEW.x) > 2
THEN
  RAISE EXCEPTION 'Triplicates X''s are not allowed (%)!', NEW.x;
END IF;
RETURN NEW;
END;
$function$;

CREATE TRIGGER demo_anomaly_ins
 AFTER INSERT ON demo_anomaly
   FOR EACH ROW EXECUTE PROCEDURE check_anomaly();

INSERT INTO demo_anomaly(part_key, x)
VALUES (1, 1);

--------------------------------------------------------------------------------
-- session 1:
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
INSERT INTO demo_anomaly(part_key, x) VALUES (2, 1);

   -- session 2:
   BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
   CREATE TABLE demo_anomaly_4 PARTITION OF demo_anomaly FOR VALUES IN (4);

-- session 1:
COMMIT;

   -- session 2:
   INSERT INTO demo_anomaly(part_key, x) VALUES (4, 1);
   COMMIT;

Транзакция всегда в коннекте существует, иначе никак.
А долгоживущая может быть, но такие подходы бьют по перформанса

Может быть - как?

просто открыть транзакцию и не закрывать )

This 😂

Если-бы вы были хоть на секунду правы, то в pg_stat_activity (или как оно там) на всех коннектах, которые сейчас не делают ничего было-бы idle in transaction и база умерла-бы (так как idle in transaction это самое плохое что может быть для Пг).

Привет. Кто-нибудь юзает pgwatch2?

Two phase commit ближе всего по смыслу, но он не для того.

а это разве не сломает ACID?

А как тогда гарантировать СУБД что вы не начнете параллельно кучей потоков что-то с одним id делать с недетерминированным конечным результатом? Тут тогда придется транзакции внутри транзакции пилить.