Re: pglogical_output - a general purpose logical decoding output plugin

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Tomasz Rybak <tomasz(dot)rybak(at)post(dot)pl>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Subject: Re: pglogical_output - a general purpose logical decoding output plugin
Date: 2016-01-07 07:58:33
Message-ID: CAMsr+YHvYQL_uY=O6G6GaVEJyCs_-paTq4FWQ1wo3NS8FYrnAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7 January 2016 at 02:32, Greg Stark <stark(at)mit(dot)edu> wrote:

> However you also need to keep in mind that any of these other purposes
> will be more or less equally large projects as logical replication.
> There's no particular reason to expect one to be able to start up
> today and provide feedback faster than the replication code that's
> already been under development for ages.

Good point. Though it's been out there for a while now.

> The one project that does seem like it should be fairly fast to get
> going and provide a relatively easy way to test the APIs separately
> would be an auditing tool.

Yep. The json stream is very simple to consume for that purpose too,
providing pre-jsonified data from the upstream so you don't have to deal
with all the mess of maintaining matching type and table definitions on the
downstream to construct HeapTuple s, etc.

You generally don't want to write audit logs into a relation of the same
form as the original table plus some extra columns. It's nicer to work
with, sure, but it means you're almost totally locked in to your original
table definition. You can add new nullable columns but that's about it,
since there's no way to retroactively construct audit data for already
logged entries. So I think the json output mode is more interesting for
auditing.

An interesting hiccup for audit is that AFAIK nothing in WAL associates
user identity information with a change, so we can't decode and send info
on which user performed which xact or changed a given tuple. SET ROLE and
SECURITY DEFINER mean there isn't a 1:1 mapping of xact to user either, and
info would probably have to be tuple level. Fun. The WAL messages patch
would be helpful for this sort of thing, allowing apps to use triggers to
add arbitrary info to xlog; XLOG_NOOP could help too, just in an uglier way
with more room for confusion between unrelated products using it.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2016-01-07 08:02:27 Re: Add numeric_trim(numeric)
Previous Message Craig Ringer 2016-01-07 07:50:46 Re: pglogical_output - a general purpose logical decoding output plugin