| 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.
| 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 |
| 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 |