On 17 February 2016 at 18:39, Konstantin Knizhnik <k.knizh...@postgrespro.ru > wrote:
> Ok, what about the following plan: > > 1. Support custom WAL records (as far as I know 2ndQuadrant has such > patch). > 2. Add one more function to logical decoding allowing to deal with custom > records. > > So the idea is that we somehow record DDL in WAL (for example using > executor hook), > then them are proceeded using logical decoding, calling special logical > deocding plugin function to handle this records. > For example we can store DDL in WAL just as SQL statements and so easily > replay them. > > In this case DDL will be replicated using the same mechanism and through > the same channel as DML. > > Sure, you can do that, but you don't need to. Go read the relevant BDR code again, you've missed how it works. When DDL is fired the registered event trigger captures the DDL and passes it to DDL deparse to extract a normalized representation. It is inserted into a queued ddl commands table in the BDR schema during the transaction that performed the DDL. Later, when that transaction is decoded by logical decoding we see an insert into the queued ddl commands table and replicate that to the client(s). Clients see the inserts into the queued DDL commands table and special-case them on replay. As well as executing the original insert they also execute the DDL command that was inserted into the table. This happens at the same point in the transaction as the original insert, which is when the DDL was run. So it's all consistent. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
