On 4/18/2013 11:44 AM, Jan Wieck wrote:
Yes, that was the rationale behind it combined with "don't change
function call sequences and more" all over the place.
function call signatures
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
S
On 4/12/2013 2:08 PM, Alvaro Herrera wrote:
Tom Lane escribió:
Are you saying you intend to revert that whole concept? That'd be
okay with me, I think. Otherwise we need some thought about how to
inform the stats collector what's really happening.
Maybe what we need is to consider table tru
On 4/12/2013 1:57 PM, Tom Lane wrote:
Kevin Grittner writes:
Tom Lane wrote:
I think that the minimum appropriate fix here is to revert the hunk
I quoted, ie take out the suppression of stats reporting and analysis.
I'm not sure I understand -- are you proposing that is all we do
for both
Kevin Grittner writes:
> For now what I'm suggesting is generating statistics in all the
> cases it did before, plus the case where it starts truncation but
> does not complete it. The fact that before this patch there were
> cases where the autovacuum worker was killed, resulting in not
> genera
[some relevant dropped bits of the thread restored]
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> Kevin Grittner writes:
Jeff Janes wrote:
I propose to do the following:
(1) Restore the prior behavior of the VACUUM command. This
was only ever intended
Tom Lane escribió:
> Are you saying you intend to revert that whole concept? That'd be
> okay with me, I think. Otherwise we need some thought about how to
> inform the stats collector what's really happening.
Maybe what we need is to consider table truncation as a separate
activity from vacuum
Kevin Grittner writes:
> Tom Lane wrote:
>> I think that the minimum appropriate fix here is to revert the hunk
>> I quoted, ie take out the suppression of stats reporting and analysis.
> I'm not sure I understand -- are you proposing that is all we do
> for both the VACUUM command and autovacuu
Andres Freund writes:
> On 2013-04-12 13:09:02 -0400, Tom Lane wrote:
>> However, we're still thinking too small. I've been wondering whether we
>> couldn't entirely remove the dirty, awful kluges that were installed in
>> the lock manager to kill autovacuum when somebody blocked behind it.
>> Th
Tom Lane wrote:
> Kevin Grittner writes:
>> OK, will review that to confirm;but assuming that's right, and
>> nobody else is already working on a fix, I propose to do the
>> following:
>
>> (1) Restore the prior behavior of the VACUUM command. This was
>> only ever intended to be a fix for a se
On 2013-04-12 13:09:02 -0400, Tom Lane wrote:
> Kevin Grittner writes:
> > OK, will review that to confirm;but assuming that's right, and
> > nobody else is already working on a fix, I propose to do the
> > following:
>
> > (1)� Restore the prior behavior of the VACUUM command.� This was
> > only
Kevin Grittner writes:
> OK, will review that to confirm;but assuming that's right, and
> nobody else is already working on a fix, I propose to do the
> following:
> (1) Restore the prior behavior of the VACUUM command. This was
> only ever intended to be a fix for a serious autovacuum problem
Jeff Janes wrote:
>> If we're going to have the message, we should make it useful.
>> My biggest question here is not whether we should add this info,
>> but whether it should be DEBUG instead of LOG
> I like it being LOG. If it were DEBUG, I don't think anyone
> would be likely to see it when
On Thursday, April 11, 2013, Kevin Grittner wrote:
>
> > I also log the number of pages truncated at the time it gave up,
> > as it would be nice to know if it is completely starving or
> > making some progress.
>
> If we're going to have the message, we should make it useful. My
> biggest questi
On Thursday, April 11, 2013, Tom Lane wrote:
> Jeff Janes writes:
> > I guess I'm a couple releases late to review the "autovacuum truncate
> > exclusive lock" patch (a79ae0bc0d454b9f2c95a), but this patch did not
> only
> > affect autovac, it affects manual vacuum as well (as did the original
>
Jeff Janes wrote:
> I guess I'm a couple releases late to review the "autovacuum
> truncate exclusive lock" patch (a79ae0bc0d454b9f2c95a), but this
> patch did not only affect autovac, it affects manual vacuum as
> well (as did the original behavior it is a modification of). So
> the compiler co
Jeff Janes writes:
> I guess I'm a couple releases late to review the "autovacuum truncate
> exclusive lock" patch (a79ae0bc0d454b9f2c95a), but this patch did not only
> affect autovac, it affects manual vacuum as well (as did the original
> behavior it is a modification of). So the compiler cons
I guess I'm a couple releases late to review the "autovacuum truncate
exclusive lock" patch (a79ae0bc0d454b9f2c95a), but this patch did not only
affect autovac, it affects manual vacuum as well (as did the original
behavior it is a modification of). So the compiler constants are misnamed,
and the
17 matches
Mail list logo
