| 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: | Whole Thread | Raw Message | 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
| 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 |