On Fri, Oct 10, 2014 at 11:38 AM, Peter Geoghegan <p...@heroku.com> wrote: >> That seems a lot cleaner than the proposal on the Wiki page. If we >> go that route, it makes sense to fire the BEFORE INSERT triggers >> before attempting the insert and then fire BEFORE UPDATE triggers >> before attempting the UPDATE.
By the way, there is no problem with failing to UPDATE, because we lock rows ahead of the UPDATE. Once a row is locked, the UPDATE cannot conflict. There is no danger of UPDATE before row-level triggers firing without then updating (unless the xact aborts, but you know what I mean). In general, there is no danger of triggers firing more often than you might consider that they should, with the sole exception of the fact that we always fire before insert row-level triggers, even when an UPDATE is the ultimate outcome. Restarting for conflicts (e.g. handling concurrent insertions with promise tuples) necessitates a restart, but to the point after before row-level insert triggers fire, and from a point before any other triggers have the opportunity to fire. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
