Re: MERGE/SPLIT PARTITIONS issues/questions

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Subject: Re: MERGE/SPLIT PARTITIONS issues/questions
Date: 2026-08-06 22:59:49
Message-ID: CAN4CZFOFsqqT_2CcFCQJP7Wca8w9Mod8kfcRkbpfcj9ngrUJ2w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

> Copying the value of generated column "as is" can produce data that differs from
> what the generated expression would compute if any merged partition's generation
> expression differs from the partitioned table's.

I think this would be probably fine, as we can get the same effect by
replacing a function used by the expression, a preexisting condition
for many existing cases. But I do agree that requiring the same
expression is a better approach.

Also, not directly related to this patch, but now that I looked into
this, I can still use tableoids for check constraints with a text
cast:

CREATE TABLE t (i int) PARTITION BY RANGE (i);
CREATE TABLE tp_0_1 PARTITION OF t FOR VALUES FROM (0) TO (1);
CREATE TABLE tp_1_2 PARTITION OF t FOR VALUES FROM (1) TO (2);
ALTER TABLE t ADD CONSTRAINT cc CHECK (tableoid::regclass::text <> 'tp_0_2');
INSERT INTO t VALUES (0),(1);
ALTER TABLE t MERGE PARTITIONS (tp_0_1, tp_1_2) INTO tp_0_2; --
SUCCESS, but should ERROR instead?

And another question I realized while looking at differences to other
rewrite operators: currently merge/split doesn't fire a rewrite event
trigger, but shouldn't it?

For the replication changes: shouldn't we also restrict schema
changes? `TABLES IN SCHEMA` can still be problematic if the parent and
the specific partitions are in different schemas, they either get
published or unpublished.

+ <command>ALTER TABLE ... MERGE PARTITIONS</command> is a schema
change and
+ is not itself replicated to logical replication subscribers; to
reflect it
+ on a subscriber, run the equivalent command there, or drop and recreate
+ the affected partitions and refresh the subscription.

I think this still results in my original (3) data loss scenario, so I
don't think it's a good idea to recommend it.

For example if we MERGE + UPDATE/INSERT on the publisher, the
subscriber worker error-loops on the merged partition not existing. We
replay the MERGE locally on the subscriber, the worker continues
before we have a chance to run REFRESH PUBLICATION and discards the
UPDATE/INSERT.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Zexin Li 2026-08-07 01:58:31 Re: BUG #19598: pg_waldump: -s/-e accept out-of-range WAL locations and silently use the low 32 bits
Previous Message Tom Lane 2026-08-06 22:09:17 Re: file corruption goes undetected

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-08-06 23:23:53 Re: pgstat: Flush some statistics within running transactions, take 2
Previous Message Melanie Plageman 2026-08-06 22:16:43 Re: [PATCH] vacuum: stop using stream ring after failsafe