Horton

Re: Command Triggers, patch v11

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Thom Brown <thom@linux.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>, pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2012-03-09T14:30:14Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix SPGiST vacuum algorithm to handle concurrent tuple motion properly.

  2. Remove useless const qualifier

  3. Make executor's SELECT INTO code save and restore original tuple receiver.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company