On 9 March 2012 14:30, Robert Haas <robertmh...@gmail.com> wrote: > 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.
I see your point. My suggestion to Dimitri in another email was either enable triggers for all commands or none. At the moment it's only available on utility commands. -- Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
