Re: Rearranging ALTER TABLE to avoid multi-operations bugs

On 2019-Oct-29, Tom Lane wrote:

> The thing I think you are actually worried about is the interaction
> with event triggers, which is already a pretty horrid mess in this
> code today.  I don't really follow the comment here about
> "ordering of queued commands".  It looks like that comment dates to
> Alvaro's commit b488c580a ... can either of you elucidate that?

The point of that comment is that if you enqueue the commands as they
are returned by pg_event_trigger_ddl_commands() (say by writing them to
a table) they must be emitted in an order that allows them to be
re-executed in a remote server that duplicates this one, and the final
state should be "the same".

> Now, if we move things around like that, it will have some effects
> on what event triggers see --- certainly the order of operations
> at least.  But do we feel a need to retain the same sort of
> "encapsulation" that is currently happening due to the aforesaid
> logic in utility.c?  I don't fully understand what that's for.

Sadly, the DDL replay logic is not being used for anything at present,
so I don't have a good test case to ensure that a proposed change is
good in this regard.  I've been approached by a couple people interested
in finishing the DDL conversion thing, but no takers so far.  I know
there's people using code based on the src/test/modules/test_ddl_deparse
module, but not for replicating a server's state to a different server, as
far as I know.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services