Re: Should commit_delay be PGC_SIGHUP?
От | Tom Lane |
---|---|
Тема | Re: Should commit_delay be PGC_SIGHUP? |
Дата | |
Msg-id | 19501.1363918493@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Should commit_delay be PGC_SIGHUP? (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Should commit_delay be PGC_SIGHUP?
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: > Only one setting will be best for the whole cluster, so neither the > user nor the DBA gains if a user sets this to a different value than > the one that has been determined to be optimal. > Since we wait while holding the lock it is actually harmful to > everyone if anybody sets a stupid value and might even be considered a > denial of service attack. > So there is a very good reason to make this SIGHUP, not just a whim. Hmm. If a malicious user could hurt performance for other sessions with a bad setting of commit_delay, then USERSET is clearly a bad idea. But it still seems like it could be SUSET rather than SIGHUP. regards, tom lane
В списке pgsql-hackers по дате отправления: