Re: Dirty buffers with suppress_redundant_updates_trigger

From: Mike Noordermeer <mike(at)normi(dot)net>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Dirty buffers with suppress_redundant_updates_trigger
Date: 2020-09-14 05:53:08
Message-ID: CAF0ozquHAvsWdr1XYJ8cP-Gohzt-CuZHnatdUpwCoWm7UrupXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

So it seems that when before triggers are handled, a SELECT FOR UPDATE
row-level lock is taken before the triggers are run. This causes a
write to the heap, as row-level locks are stored on-heap. This has the
unfortunate effect that suppress_redundant_updates_trigger() is not
able to prevent all writes to the heap.

I do not yet understand why these locks are taken in this case, and
not when I compare the fields in the UPDATE WHERE-clause, but that may
have something to do with transactional guarantees, or some other
tradeoffs during development.

If anyone has a brilliant idea on how to improve this situation,
please let me know. Otherwise I guess I will have to resort to
comparing all data values, either manually or in the WHERE clause, to
prevent the data loads from flooding the WAL.

Kind regards,

Mike

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Matthias Apitz 2020-09-14 06:09:44 Why SELECT COUNT(*) takes so long?
Previous Message nandha kumar 2020-09-14 05:17:10 Reg:CHARSET_COVERSION_LATIN_TO_UTF8