On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown <t...@linux.com> wrote: > On 9 March 2012 14:09, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown <t...@linux.com> wrote: >>> I've also since found that if I issue a VACUUM, CLUSTER or REINDEX on >>> a read-only standby, the BEFORE ANY COMMAND trigger fires. I don't >>> think any trigger should fire on a read-only standby. >> >> Why ever not? > > Sorry, I meant any command trigger. It's because none of the commands > can be run on a standby, so the triggers don't seem appropriate.
I'm not convinced. Right now, it's fairly useless - all the triggers could possibly do is throw an error, and an error is going to get thrown anyway, so it's only a question of which error message the user will see. But we discussed before the idea of adding a capability for BEFORE triggers to request that the actual execution of the command get skipped, and then it's possible to imagine this being useful. Someone could even use a command trigger that detects which machine it's running on, and if it's the standby, uses dblink to execute the command on the master, or something crazy like that. Command triggers could also be useful for logging all attempts to execute a particular command, which is probably still appropriate on the standby. I think that it will be a good thing to try to treat Hot Standby mode as much like regular operation as is reasonably possible, across the board. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
