On Fri, Mar 22, 2013 at 12:42 PM, Robert Haas wrote:
> This is fine with me, too, and I agree that it's warranted... but your
> commit message supposes that this behavior is new in 9.3, and I think
> it dates to 9.2.
No, it doesn't. It just missed the deadline for 9.2.
I'm happy enough to have t
On Fri, Mar 22, 2013 at 8:06 AM, Simon Riggs wrote:
>> 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 the
On 22 March 2013 02:14, Tom Lane wrote:
> Simon Riggs 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
Simon Riggs 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
On Wed, Mar 20, 2013 at 09:50:55PM +, Peter Geoghegan wrote:
> The fact is that whichever backend happens to end up becoming the
> group commit leader from one XLogFlush() call to the next is, for all
> practical purposes, unpredictable. You cannot reasonably hope to avoid
> a delay within an i
On Thu, Mar 21, 2013 at 6:27 PM, Robert Haas wrote:
> This may be true, but so what? We don't generally restrict changing
> GUC settings on the grounds that people probably won't wish to do so
> because it isn't useful. We restrict it in situations where it is not
> technically possible or is li
On 21 March 2013 18:27, Robert Haas wrote:
> This may be true, but so what? We don't generally restrict changing
> GUC settings on the grounds that people probably won't wish to do so
> because it isn't useful. We restrict it in situations where it is not
> technically possible or is liable to
On Wed, Mar 20, 2013 at 5:50 PM, Peter Geoghegan wrote:
> I realize that this isn't terribly critical, but I'd like to suggest
> that commit_delay be made PGC_SIGHUP on 9.3 (it's currently
> PGC_USERSET). It's not that a poorly chosen commit_delay setting has
> the potential to adversely affect ot
On 20 March 2013 21:50, Peter Geoghegan wrote:
> I realize that this isn't terribly critical, but I'd like to suggest
> that commit_delay be made PGC_SIGHUP on 9.3 (it's currently
> PGC_USERSET). It's not that a poorly chosen commit_delay setting has
> the potential to adversely affect other backe
I realize that this isn't terribly critical, but I'd like to suggest
that commit_delay be made PGC_SIGHUP on 9.3 (it's currently
PGC_USERSET). It's not that a poorly chosen commit_delay setting has
the potential to adversely affect other backends where the setting
*has* been set in those other back
10 matches
Mail list logo
