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
