On Wed, Aug 05, 2020 at 02:52:42PM +0200, Magnus Hagander wrote:
> On Sat, Jul 18, 2020 at 4:57 AM Noah Misch <noah@leadboat.com> wrote:
> > Such a doc addition is fine with me. I agree with Tom that it will be prone
> > to staleness, but I don't conclude that the potential for staleness reduces
> > its net value below zero. Having said that, if the consequences of doc
> > staleness are "very bad", you may consider documenting the debug1 user
> > interface (https://postgr.es/m/20121202020736.GD13163@tornado.leadboat.com)
> > instead of documenting the exact rules. Either way is fine with me.
>
> The DEBUG1 method is only after the fact though, isn't it?
>
> That makes it pretty hard for someone to say review a migration script and
> see "this is going to cause problems". And if it's going to be run in an
> env, I personally find it more useful to just stick an event trigger in
> there per our documentation and block it (though it might be a good idea to
> link to that from the alter table reference page, and not just have it
> under event trigger examples).
The "after the fact" aspect is basically the same for the DEBUG1 method and
the event trigger method. Each fires after lock acquisition and before
rewriting the first tuple.
Event trigger drawbacks include the requirement for superuser cooperation.
DEBUG1/statement_timeout drawbacks include an ambiguity: if it reaches
statement_timeout without printing the DEBUG1, that could mean a lack of
rewrite, or it could mean some other cause of slowness. I have a weak
preference for promoting the DEBUG1/statement_timeout approach, because cloud
deployments find the superuser obstacle insurmountable. The ambiguity is
surmountable; one can always remove the statement_timeout and run the command
to completion in a pre-production environment.
