On Thu, Apr 30, 2026 at 7:03 AM Hannu Krosing <[email protected]> wrote: > > On Wed, Apr 29, 2026 at 2:10 PM Andres Freund <[email protected]> wrote: > > > > Hi, > > > > On 2026-04-29 10:07:04 +0200, Hannu Krosing wrote: > > > On Wed, Apr 29, 2026 at 5:39 AM Dilip Kumar <[email protected]> wrote: > > > > > > > I am trying to understand your idea. If we are trying to deparse from > > > > an actual system table using a snapshot, why don't we just use the > > > > WAL? I mean, the WAL should contain the actual catalog modifications > > > > it has made. > > > > > > We have the full data in the catalog and we would likely need catalog > > > queries for any change, even when de-parsing the tree. > > > > > > And we should not add the extra load on the original DDL side, just as > > > we don't for DML. > > > > That can't be a relevant cost compared to everything else. > > Probably not. But unless we somehow encode "everything" at that point > we will make building different DDL decoders harder down the line. > > So why not just save the normally serialised parse tree at this point > and let the decoders decide to do whatever they need. > > > > At most we could just serialize the statement tree into the WAL, > > > though even that may be an overkill if we can get the change from > > > existing records. > > > > > > - insert new row in pg_class --> extract the CREATE TABLE (or INDEX, or > > > ...) > > > - update row in pg_class or insert, update or delete a row in > > > pg_attribute --> extract ALTER TABLE > > > - except when it just updates relfilenod --> extract TRUNCATE > > > - delete row in pg_class --> DROP TABLE > > > - dml on pg_constraint --> ALTER TABLE > > > > > > ... etc > > > > That doesn't work in the general case, think of > > ALTER TABLE ... ALTER COLUMN ... TYPE foo USING (...) > > > > There's a big difference between USING(foo::int8) and USING > > (pg_size_bytes(foo)) > > but it's nowhere visible in the WAL. > > It can't be a big difference if it is not visible in the WAL.
If we send the rewritten tuples made during ALTER TABLE execution via logical replication, there would not be a big difference. However, if we send only the re-constructed ALTER TABLE statement, there is. I think that replicating ALTER TABLE should behave the latter because we might not need table rewrites in more ALTER TABLE cases in newer PostgreSQL versions. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
