Re: External Replication

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: "md\(at)rpzdesign(dot)com" <md(at)rpzdesign(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: External Replication
Date: 2012-09-24 16:20:25
Message-ID: m2vcf3fl4m.fsf@2ndQuadrant.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"md(at)rpzdesign(dot)com" <md(at)rpzdesign(dot)com> writes:
> You may want to consider changing the command TRIGGER into a command FILTER
> and possibly post processing TRIGGER that
> is determined to be called INSIDE the FILTER. Or some way to pass
> information between the FILTER and the post processing trigger.

The only current "event" supported by the system is the
"ddl_command_start" one. We mean to add some more, and triggers wanting
to communicate data in between "ddl_command_start" and "ddl_command_end"
(for example) will have to use something like a table.

> Also, something information as to whether a series of statements was ROLLED
> BACK would be helpful.

Event Triggers are not an autonomous transaction: any effect they have
in the database is rolled-backed when the main transaction is rolled
backed. You can use LISTEN/NOTIFY or PGQ that both know how to handle
that semantics.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Roberto Mello 2012-09-24 16:22:25 Re: pg_reorg in core?
Previous Message Tom Lane 2012-09-24 15:44:36 Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed