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 t
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
> >>>pin
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
> >>>pin
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"),
+
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_pa
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);
> +
Alvaro Herrera 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
counters should be pr
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.
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
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 l
On 12/18/14, 7:56 AM, Robert Haas wrote:
On Wed, Dec 17, 2014 at 11:20 AM, Heikki Linnakangas
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
remov
On Wed, Dec 17, 2014 at 11:20 AM, Heikki Linnakangas
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 usage: 14532 hit
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;
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 th
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/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 of
On 9 December 2014 at 06:28, Jim Nasby 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 could and did r
On 12/7/14, 6:16 PM, Simon Riggs wrote:
On 20 October 2014 at 10:57, 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 th
On 20 October 2014 at 10:57, 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
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 r
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 Tre
On Wed, Nov 12, 2014 at 12:37 PM, Andres Freund 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 be log-spam. We've
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 wo
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-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 co
Jim Nasby 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 at this point is
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 there'
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.
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
> > > messag
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
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 stro
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 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 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 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
Jim Nasby wrote:
> On 11/7/14, 8:21 PM, Robert Haas wrote:
> >On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby 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 o
On 11/7/14, 8:21 PM, Robert Haas wrote:
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby 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 sto
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby 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. :(
I could see logging i
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 c
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 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
> >>absol
On 2014-11-06 23:40:18 +, Greg Stark wrote:
> On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund 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,
On 11/6/14, 5:40 PM, Greg Stark wrote:
On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund 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
occasio
On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund 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 going to be so abs
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 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
On 10/29/14, 11:49 AM, Jim Nasby wrote:
On 10/21/14, 6:05 PM, Tom Lane wrote:
Jim Nasby 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
On 10/21/14, 6:05 PM, Tom Lane wrote:
Jim Nasby 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 ...)
M
Jim Nasby 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 ...)
regards, tom lane
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 is
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
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
> >>>a
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 ac
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. :)
I
On 10/20/14, 10:29 AM, Greg Stark wrote:
On Mon, Oct 20, 2014 at 2:57 AM, 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 war
On Mon, Oct 20, 2014 at 2:57 AM, 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
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 elog(LOG)
53 matches
Mail list logo
