Re: Should commit_delay be PGC_SIGHUP?
От | Simon Riggs |
---|---|
Тема | Re: Should commit_delay be PGC_SIGHUP? |
Дата | |
Msg-id | CA+U5nMJtUv5cNc2PAJdeWDygurU7Au6Y8fN6FjtWH+c_dnaysw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should commit_delay be PGC_SIGHUP? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Should commit_delay be PGC_SIGHUP?
|
Список | pgsql-hackers |
On 22 March 2013 02:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Agreed; everybody gets what they want. Committed. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: