On 2015-01-04 01:53:24 +0100, Andres Freund wrote:
Ah, interesting, I didn't remember we had that. I guess one possible
tweak is to discount the pages we skip from pinned_pages; or we could
keep a separate count of pages waited for. Jim, up for a patch?
This is still wrong. I think just
On 2014-12-18 16:05:23 -0600, Jim Nasby wrote:
On 12/18/14, 3:02 PM, Alvaro Herrera wrote:
Andres Freund wrote:
On 2014-12-18 16:41:04 -0300, Alvaro Herrera wrote:
+ if (scan_all)
+ appendStringInfo(buf, _(waited for %d buffer
pins\n),
+
On Wed, Dec 17, 2014 at 11:20 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
LOG: automatic vacuum of table postgres.public.foo: index scans: 0
pages: 0 removed, 7256 remain, 0 pinned
tuples: 79415 removed, 513156 remain, 0 are dead but not yet
removable
buffer
On 12/18/14, 7:56 AM, Robert Haas wrote:
On Wed, Dec 17, 2014 at 11:20 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
LOG: automatic vacuum of table postgres.public.foo: index scans: 0
pages: 0 removed, 7256 remain, 0 pinned
tuples: 79415 removed, 513156 remain, 0 are
Jim Nasby wrote:
We have to decide on a tradeoff here. Either we end up with two
different log messages (depending on scan_all) that require two
different translations, or we end up with a generic message that isn't
as clear.
The best option I can think of for the later is something like
On 12/18/2014 09:41 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
We have to decide on a tradeoff here. Either we end up with two
different log messages (depending on scan_all) that require two
different translations, or we end up with a generic message that isn't
as clear.
The best option I can
Heikki Linnakangas wrote:
On 12/18/2014 09:41 PM, Alvaro Herrera wrote:
Here's my proposal. Instead of punting, I split the message in
separately translatable units, and emit only the ones that apply. The
code is messier this way, but I think we can live with that.
Works for me.
Great,
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Great, thanks, pushed. I tweaked it a bit more, so that it would say
either skipped N pages or waited N pins in both autovacuum and
vacuum verbose cases, but only if N 0.
Not directly relevant but ... I think probably all those BlockNumber
On 2014-12-18 16:41:04 -0300, Alvaro Herrera wrote:
+ if (scan_all)
+ appendStringInfo(buf, _(waited for %d buffer
pins\n),
+
vacrelstats-pinned_pages);
+ else
Andres Freund wrote:
On 2014-12-18 16:41:04 -0300, Alvaro Herrera wrote:
+ if (scan_all)
+ appendStringInfo(buf, _(waited for %d buffer
pins\n),
+
vacrelstats-pinned_pages);
+
On 12/18/14, 3:02 PM, Alvaro Herrera wrote:
Andres Freund wrote:
On 2014-12-18 16:41:04 -0300, Alvaro Herrera wrote:
+ if (scan_all)
+ appendStringInfo(buf, _(waited for %d buffer
pins\n),
+
On 2014-12-18 16:05:23 -0600, Jim Nasby wrote:
On 12/18/14, 3:02 PM, Alvaro Herrera wrote:
Andres Freund wrote:
On 2014-12-18 16:41:04 -0300, Alvaro Herrera wrote:
+ if (scan_all)
+ appendStringInfo(buf, _(waited for %d buffer
pins\n),
+
On 12/01/2014 08:55 PM, Jim Nasby wrote:
On 12/1/14, 11:57 AM, Andres Freund wrote:
On 2014-11-30 20:46:51 -0600, Jim Nasby wrote:
On 11/10/14, 7:52 PM, Tom Lane wrote:
On the whole, I'm +1 for just logging the events and seeing what we learn
that way. That seems like an appropriate amount
On 12/17/14, 10:20 AM, Heikki Linnakangas wrote:
* Change the new bit in the errdetail. could not acquire cleanup lock
sounds too much like an error to me. skipped %u pinned pages maybe?
Seems reasonable.
Well, that's not always true either; when freezing, it doesn't skip the pinned
On 12/17/2014 08:02 PM, Jim Nasby wrote:
BTW, what is it about a dynamic message that makes it untranslatable?
Doesn't the translation happen down-stream, so that at most we'd just
need two translation messages?
I'm not sure what you mean by down-stream. There is some explanation on
this in
Jim Nasby wrote:
On 12/17/14, 10:20 AM, Heikki Linnakangas wrote:
* Change the new bit in the errdetail. could not acquire cleanup lock
sounds too much like an error to me. skipped %u pinned pages maybe?
Seems reasonable.
Well, that's not always true either; when freezing, it
On 12/7/14, 6:16 PM, Simon Riggs wrote:
On 20 October 2014 at 10:57, Jim Nasby jim.na...@bluetreble.com wrote:
Currently, a non-freeze vacuum will punt on any page it can't get a cleanup
lock on, with no retry. Presumably this should be a rare occurrence, but I
think it's bad that we just
On 9 December 2014 at 06:28, Jim Nasby jim.na...@bluetreble.com wrote:
On 12/7/14, 6:16 PM, Simon Riggs wrote:
What I'm more interested in is what you plan to do with the
information once we get it?
The assumption that skipping blocks is something bad is strange. I
added it because VACUUM
On 20 October 2014 at 10:57, Jim Nasby jim.na...@bluetreble.com wrote:
Currently, a non-freeze vacuum will punt on any page it can't get a cleanup
lock on, with no retry. Presumably this should be a rare occurrence, but I
think it's bad that we just assume that and won't warn the user if
On 12/1/14, 11:57 AM, Andres Freund wrote:
On 2014-11-30 20:46:51 -0600, Jim Nasby wrote:
On 11/10/14, 7:52 PM, Tom Lane wrote:
On the whole, I'm +1 for just logging the events and seeing what we learn
that way. That seems like an appropriate amount of effort for finding out
whether there is
On 11/10/14, 7:52 PM, Tom Lane wrote:
On the whole, I'm +1 for just logging the events and seeing what we learn
that way. That seems like an appropriate amount of effort for finding out
whether there is really an issue.
Attached is a patch that does this.
--
Jim Nasby, Data Architect, Blue
On 11/11/14, 2:01 AM, Andres Freund wrote:
On 2014-11-10 19:36:18 -0600, Jim Nasby wrote:
On 11/10/14, 12:56 PM, Andres Freund wrote:
On 2014-11-10 12:37:29 -0600, Jim Nasby wrote:
On 11/10/14, 12:15 PM, Andres Freund wrote:
If what we want is to quantify the extent of the issue, would it be
On 2014-11-12 11:34:04 -0600, Jim Nasby wrote:
On 11/11/14, 2:01 AM, Andres Freund wrote:
On 2014-11-10 19:36:18 -0600, Jim Nasby wrote:
Towards that simple end, I'm a bit torn. My preference would be to
simply log, and throw a warning if it's over some threshold. I believe
that would give
On Wed, Nov 12, 2014 at 12:37 PM, Andres Freund and...@2ndquadrant.com wrote:
Stop overdesigning this.
Add it to the existing mesage and let us be done with this. This thread
has already wasted far too much time.
That's a little harsh, but I agree. Producing a warning here is just
going to
On 2014-11-10 19:36:18 -0600, Jim Nasby wrote:
On 11/10/14, 12:56 PM, Andres Freund wrote:
On 2014-11-10 12:37:29 -0600, Jim Nasby wrote:
On 11/10/14, 12:15 PM, Andres Freund wrote:
If what we want is to quantify the extent of the issue, would it be more
convenient to save counters to pgstat?
On 11/7/14, 8:21 PM, Robert Haas wrote:
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The problem right now is there's no way to actually obtain evidence that
this is (or isn't) something to worry about, because we just silently skip
pages. If we had any kind of
Jim Nasby wrote:
On 11/7/14, 8:21 PM, Robert Haas wrote:
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The problem right now is there's no way to actually obtain evidence that
this is (or isn't) something to worry about, because we just silently skip
pages. If we
On 11/10/14, 11:28 AM, Alvaro Herrera wrote:
Jim Nasby wrote:
On 11/7/14, 8:21 PM, Robert Haas wrote:
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The problem right now is there's no way to actually obtain evidence that
this is (or isn't) something to worry about,
On 2014-11-10 14:28:30 -0300, Alvaro Herrera wrote:
Jim Nasby wrote:
On 11/7/14, 8:21 PM, Robert Haas wrote:
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The problem right now is there's no way to actually obtain evidence that
this is (or isn't) something to
Andres Freund wrote:
On 2014-11-10 14:28:30 -0300, Alvaro Herrera wrote:
If what we want is to quantify the extent of the issue, would it be more
convenient to save counters to pgstat? Vacuum already sends pgstat
messages, so there's no additional traffic there.
I'm pretty strongly
On 11/10/14, 12:15 PM, Andres Freund wrote:
If what we want is to quantify the extent of the issue, would it be more
convenient to save counters to pgstat? Vacuum already sends pgstat
messages, so there's no additional traffic there.
I'm pretty strongly against that one in isolation. They'd
On 2014-11-10 15:36:55 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
On 2014-11-10 14:28:30 -0300, Alvaro Herrera wrote:
If what we want is to quantify the extent of the issue, would it be more
convenient to save counters to pgstat? Vacuum already sends pgstat
messages, so
On 2014-11-10 12:37:29 -0600, Jim Nasby wrote:
On 11/10/14, 12:15 PM, Andres Freund wrote:
If what we want is to quantify the extent of the issue, would it be more
convenient to save counters to pgstat? Vacuum already sends pgstat
messages, so there's no additional traffic there.
I'm pretty
On 11/10/14, 12:56 PM, Andres Freund wrote:
On 2014-11-10 12:37:29 -0600, Jim Nasby wrote:
On 11/10/14, 12:15 PM, Andres Freund wrote:
If what we want is to quantify the extent of the issue, would it be more
convenient to save counters to pgstat? Vacuum already sends pgstat
messages, so
Jim Nasby jim.na...@bluetreble.com writes:
On 11/10/14, 12:56 PM, Andres Freund wrote:
If you want to do this - and I sure don't want to stop you from it - you
should look at it from a general perspective, not from the perspective
of how skipped cleanup locks are logged.
Honestly, my desire
Greg Stark wrote:
I agree bloat isn't really a threat, but what about the relfrozenxid?
If we skip even one page we don't get to advance it and retrying could
eliminate those skipped pages and allow us to avoid a vacuum freeze
which can be really painful. Of course that only works if you can
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby jim.na...@bluetreble.com wrote:
The problem right now is there's no way to actually obtain evidence that
this is (or isn't) something to worry about, because we just silently skip
pages. If we had any kind of tracking on this we could stop guessing. :(
On 10/29/14, 11:49 AM, Jim Nasby wrote:
On 10/21/14, 6:05 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
- What happens if we run out of space to remember skipped blocks?
You forget some, and are no worse off than today. (This might be an
event worthy of logging, if the
On 2014-11-06 14:55:37 -0600, Jim Nasby wrote:
On 10/29/14, 11:49 AM, Jim Nasby wrote:
On 10/21/14, 6:05 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
- What happens if we run out of space to remember skipped blocks?
You forget some, and are no worse off than today. (This
On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund and...@2ndquadrant.com wrote:
I think the retry logical is a largely pointless complication of already
complex enough code. You're fixing a problem for which there is
absolutely no evidence of its existance. Yes, this happens
occasionally. But it's
On 11/6/14, 5:40 PM, Greg Stark wrote:
On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund and...@2ndquadrant.com wrote:
I think the retry logical is a largely pointless complication of already
complex enough code. You're fixing a problem for which there is
absolutely no evidence of its existance.
On 2014-11-06 23:40:18 +, Greg Stark wrote:
On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund and...@2ndquadrant.com wrote:
I think the retry logical is a largely pointless complication of already
complex enough code. You're fixing a problem for which there is
absolutely no evidence of its
On 2014-11-06 19:03:20 -0600, Jim Nasby wrote:
On 11/6/14, 5:40 PM, Greg Stark wrote:
On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund and...@2ndquadrant.com wrote:
I think the retry logical is a largely pointless complication of already
complex enough code. You're fixing a problem for which
On 10/21/14, 6:05 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
- What happens if we run out of space to remember skipped blocks?
You forget some, and are no worse off than today. (This might be an
event worthy of logging, if the array is large enough that we don't
expect it
Jim Nasby wrote:
Currently, a non-freeze vacuum will punt on any page it can't get a
cleanup lock on, with no retry. Presumably this should be a rare
occurrence, but I think it's bad that we just assume that and won't
warn the user if something bad is going on.
I think if you really want to
On 10/21/14, 5:39 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
Currently, a non-freeze vacuum will punt on any page it can't get a
cleanup lock on, with no retry. Presumably this should be a rare
occurrence, but I think it's bad that we just assume that and won't
warn the user if something bad
Jim Nasby jim.na...@bluetreble.com writes:
- What happens if we run out of space to remember skipped blocks?
You forget some, and are no worse off than today. (This might be an
event worthy of logging, if the array is large enough that we don't
expect it to happen often ...)
On Mon, Oct 20, 2014 at 2:57 AM, Jim Nasby jim.na...@bluetreble.com wrote:
Currently, a non-freeze vacuum will punt on any page it can't get a cleanup
lock on, with no retry. Presumably this should be a rare occurrence, but I
think it's bad that we just assume that and won't warn the user if
On 10/20/14, 10:29 AM, Greg Stark wrote:
On Mon, Oct 20, 2014 at 2:57 AM, Jim Nasby jim.na...@bluetreble.com wrote:
Currently, a non-freeze vacuum will punt on any page it can't get a cleanup
lock on, with no retry. Presumably this should be a rare occurrence, but I
think it's bad that we just
On 2014-10-20 19:18:31 -0500, Jim Nasby wrote:
In the meantime, I think it's worth adding this logging. If in fact this
basically never happens (the current assumption), it doesn't hurt anything.
If it turns out our assumption is wrong, then we'll actually be able to fin
that out. :)
It
On 10/20/14, 7:31 PM, Andres Freund wrote:
On 2014-10-20 19:18:31 -0500, Jim Nasby wrote:
In the meantime, I think it's worth adding this logging. If in fact this
basically never happens (the current assumption), it doesn't hurt anything. If it
turns out our assumption is wrong, then we'll
On 2014-10-20 19:43:38 -0500, Jim Nasby wrote:
On 10/20/14, 7:31 PM, Andres Freund wrote:
On 2014-10-20 19:18:31 -0500, Jim Nasby wrote:
In the meantime, I think it's worth adding this logging. If in fact this
basically never happens (the current assumption), it doesn't hurt
anything. If it
Currently, a non-freeze vacuum will punt on any page it can't get a cleanup
lock on, with no retry. Presumably this should be a rare occurrence, but I
think it's bad that we just assume that and won't warn the user if something
bad is going on.
My thought is that if we skip any pages
53 matches
Mail list logo
