Re: [HACKERS] Why is vacuum_defer_cleanup_age PGC_USERSET?
On 7/3/10 10:07 AM, Tom Lane wrote: It seems to me it ought to be PGC_SIGHUP. +1 I believe it's userset because the other vacuum parameters are, and that nobody thought about it much. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Why is vacuum_defer_cleanup_age PGC_USERSET?
It seems to me it ought to be PGC_SIGHUP. In the first place, the actually important value under normal circumstances is going to be that seen by autovac workers. There is also some impact on HOT cleanup, but I can't see any sane argument why you don't want all backends to be applying the same value for that, since it's difficult or impossible to predict which session is actually going to HOT-clean any page. In the second place, it seems completely foolish to let ordinary unprivileged users mess with the value. Arguably an individual user could produce a denial of service on HS slaves by cutting his local value of vacuum_defer_cleanup_age and then vacuuming tables that queries on the slaves will look at. To the extent that the variable does anything useful at all, it is the system-wide behavior that is important, so I see no use-case for changing it in individual sessions anyway. It also appears to me to be misclassified. WAL_STANDBY_SERVERS should be the category for variables that you'd adjust on an HS slave, no? But this is something that has to be set on the master. Possibly the best place for it is WAL_REPLICATION. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why is vacuum_defer_cleanup_age PGC_USERSET?
On Sat, 2010-07-03 at 13:07 -0400, Tom Lane wrote: It seems to me it ought to be PGC_SIGHUP. In the first place, the actually important value under normal circumstances is going to be that seen by autovac workers. There is also some impact on HOT cleanup, but I can't see any sane argument why you don't want all backends to be applying the same value for that, since it's difficult or impossible to predict which session is actually going to HOT-clean any page. In the second place, it seems completely foolish to let ordinary unprivileged users mess with the value. Arguably an individual user could produce a denial of service on HS slaves by cutting his local value of vacuum_defer_cleanup_age and then vacuuming tables that queries on the slaves will look at. To the extent that the variable does anything useful at all, it is the system-wide behavior that is important, so I see no use-case for changing it in individual sessions anyway. Happy with that argument, so agreed. It also appears to me to be misclassified. WAL_STANDBY_SERVERS should be the category for variables that you'd adjust on an HS slave, no? But this is something that has to be set on the master. Possibly the best place for it is WAL_REPLICATION. Those didn't exist when it was originally classified, thats all. Yes, those categories sounds good. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
