On 4/12/2013 1:57 PM, Tom Lane wrote:
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us 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
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
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
--
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 question here
Jeff Janes jeff.ja...@gmail.com 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
Kevin Grittner kgri...@ymail.com 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
On 2013-04-12 13:09:02 -0400, Tom Lane wrote:
Kevin Grittner kgri...@ymail.com 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com 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
Andres Freund and...@2ndquadrant.com 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
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us 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
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
[some relevant dropped bits of the thread restored]
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Jeff Janes jeff.ja...@gmail.com wrote:
I propose to do the following:
(1) Restore
Kevin Grittner kgri...@ymail.com 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
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
Jeff Janes jeff.ja...@gmail.com 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
Jeff Janes jeff.ja...@gmail.com 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
On Thursday, April 11, 2013, Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com 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
17 matches
Mail list logo
