Re: Logical insert/update/delete WAL records for custom table AMs - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Logical insert/update/delete WAL records for custom table AMs
Date
Msg-id 636d5bac67c824720e6ece27402af942b0e0d451.camel@j-davis.com
Whole thread Raw
In response to Re: Logical insert/update/delete WAL records for custom table AMs  (Simon Riggs <simon.riggs@enterprisedb.com>)
Responses Re: Logical insert/update/delete WAL records for custom table AMs  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, 2022-02-24 at 20:35 +0000, Simon Riggs wrote:
> The approach is perfectly fine, it just needs to be finished and
> rebased.

Attached a new version. The scope expanded, so this is likely to slip
v15 at this late time. For 15, I'll focus on my extensible rmgr work,
which can serve similar purposes.

The main purpose of this patch is to be able to emit logical events for
a table (insert/update/delete/truncate) without actually modifying a
table or relying on the heap at all. That allows table AMs to support
logical decoding/replication, and perhaps allows a few other
interesting use cases (maybe foreign tables?). There are really two
advantages of this approach over relying on a custom rmgr:

  1. Easier for extension authors
  2. Doesn't require an extension module to be loaded to start the
server

Those are very nice advantages, but they come at the price of
flexibility and performance. I think there's room for both, and we can
discuss the merits individually.

Changes:
  * Support logical messages for INSERT/UPDATE/DELETE/TRUNCATE
    (before it only supported INSERT)
  * SQL functions pg_logical_emit_insert/update/delete/truncate
    (callable by superuser)
  * Tests (using test_decoding)
  * Use replica identities properly
  * In general a lot of cleanup, but still not quite ready

TODO:
  * Should SQL functions be callable by the table owner? I would lean
toward superuser-only, because logical replication is used for
administrative purposes like upgrades, and I don't think we want table
owners to be able to create inconsistencies.
  * Support for multi-insert
  * Docs for SQL functions, and maybe docs in the section on Generic
WAL
  * Try to get away from reliance on heap tuples specifically

Regards,
    Jeff Davis


Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: pgsql: Add 'basebackup_to_shell' contrib module.
Next
From: Robert Haas
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT