Jan Wieck wrote: > Thinking about it, I'm not really happy with removing the > autovacuum_truncate_lock_check GUC at all. > > Fact is that the deadlock detection code and the configuration > parameter for it should IMHO have nothing to do with all this in > the first place. A properly implemented application does not > deadlock.
I don't agree. I believe that in some cases it is possible and practicable to set access rules which would prevent deadlocks in application access to a database. In other cases the convolutions required in the code, the effort in educating dozens or hundreds of programmers maintaining the code (and keeping the training current during staff turnover), and the staff time required for compliance far outweigh the benefit of an occasional transaction retry. However, it is enough for your argument that there are cases where it can be done. > Someone running such a properly implemented application should be > able to safely set deadlock_timeout to minutes without the > slightest ill side effect, but with the benefit that the deadlock > detection code itself does not add to the lock contention. The > only reason one cannot do so today is because autovacuum's > truncate phase could then freeze the application with an > exclusive lock for that long. > > I believe the check interval needs to be decoupled from the > deadlock_timeout again. OK > This will leave us with 2 GUCs at least. Hmm. What problems do you see with hard-coding reasonable values? Adding two or three GUC settings for a patch with so little user-visible impact seems weird. And it seems to me (and also seemed to Robert) as though the specific values of the other two settings really aren't that critical as long as they are anywhere within a reasonable range. Configuring PostgreSQL can be intimidating enough without adding knobs that really don't do anything useful. Can you show a case where special values would be helpful? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers