On 9 March 2012 14:30, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown <thom@linux.com> wrote:
>> On 9 March 2012 14:09, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Wed, Mar 7, 2012 at 4:53 PM, Thom Brown <thom@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