Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > ! /* no need to allocate more space than we have pages */
> > ! maxtuples = LAZY_ALLOC_TUPLES * relblocks;
>
> Uh ... you need to guard against integer overflow in this calculation.
Done this way. I applied i
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Also, note that the worst thing that can happen is that the wrong
> process gets a SIGUSR1 signal, and the launcher misses an opportunity
> for starting another worker and rebalancing the vacuum cost parameters.
Hmmm ... okay, but I note that part of th
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > It continues with the next table if interrupted (SIGINT), but the worker
> > exits on any other error. I would ask you to review that code -- it's
> > in do_autovacuum, the PG_TRY block at the end. It was committed in rev
> > 1.5
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> It continues with the next table if interrupted (SIGINT), but the worker
> exits on any other error. I would ask you to review that code -- it's
> in do_autovacuum, the PG_TRY block at the end. It was committed in rev
> 1.52 of autovacuum.c.
While loo
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Maybe we could load it in a more compact form after the heap cleanup
>> pass, instead of a plain TID list.
>
> Hmm ... a non-lossy bitmap would be an interesting alternative.
> I think I went with bsearch mainly
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> ! /* no need to allocate more space than we have pages */
> ! maxtuples = LAZY_ALLOC_TUPLES * relblocks;
Uh ... you need to guard against integer overflow in this calculation.
Perhaps leave the current initialization alone, and t
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm not having much luck really. I think the problem is that ANALYZE
> > stores reltuples as the number of live tuples, so if you delete a big
> > portion of a big table, then ANALYZE and then VACUUM, there's a huge
> > misestimat
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Maybe we could load it in a more compact form after the heap cleanup
> pass, instead of a plain TID list.
Hmm ... a non-lossy bitmap would be an interesting alternative.
I think I went with bsearch mainly because I knew I could generate
the TID list alr
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> VACUUM getting "Out of memory" may not sound like a big problem, but
> >> the scary thing is - the last VACUUM's memory request may succeed and
> >> that means following queries start failing and that is big problem.
>
> > Maybe
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> VACUUM getting "Out of memory" may not sound like a big problem, but
>> the scary thing is - the last VACUUM's memory request may succeed and
>> that means following queries start failing and that is big problem.
> Maybe what we should do is spill the
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane escribió:
> >> BTW, if an autovac worker gets an elog(ERROR) on one table, does it die
> >> or continue on with the next table?
>
> > It continues with the next table if interrupted (SIGINT), but the worker
> > exits on a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> BTW, if an autovac worker gets an elog(ERROR) on one table, does it die
>> or continue on with the next table?
> It continues with the next table if interrupted (SIGINT), but the worker
> exits on any other error.
Hmm, that seems
Tom Lane escribió:
> BTW, if an autovac worker gets an elog(ERROR) on one table, does it die
> or continue on with the next table?
It continues with the next table if interrupted (SIGINT), but the worker
exits on any other error. I would ask you to review that code -- it's
in do_autovacuum, the
On 8/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Note that it's much better to err on the smaller values.
>
> > Extra index pass is really no problem.
>
> I beg to differ ...
Well, if Postgres tries to cut down passes by using max memory
then admin is
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> Yeah ... so just go with a constant estimate of say 200 deletable tuples
>> per page?
> How about we use a constant estimate using the average tuple width code?
I think that's overthinking the problem. The point here is mostly fo
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm not having much luck really. I think the problem is that ANALYZE
> > stores reltuples as the number of live tuples, so if you delete a big
> > portion of a big table, then ANALYZE and then VACUUM, there's a huge
> > misestimat
Tom Lane escribió:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > Note that it's much better to err on the smaller values.
>
> > Extra index pass is really no problem.
>
> I beg to differ ...
>
> What this may actually suggest is that autovacuum needs its own value of
> "maintenance_work_mem",
Marko Kreen escribió:
> On 8/29/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > I'm not having much luck really. I think the problem is that ANALYZE
> > > stores reltuples as the number of live tuples, so if you delete a big
> > > portion of a big table
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Note that it's much better to err on the smaller values.
> Extra index pass is really no problem.
I beg to differ ...
What this may actually suggest is that autovacuum needs its own value of
"maintenance_work_mem", or that it should automatically divid
On 8/29/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I'm not having much luck really. I think the problem is that ANALYZE
> > stores reltuples as the number of live tuples, so if you delete a big
> > portion of a big table, then ANALYZE and then VACUUM,
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm not having much luck really. I think the problem is that ANALYZE
> stores reltuples as the number of live tuples, so if you delete a big
> portion of a big table, then ANALYZE and then VACUUM, there's a huge
> misestimation and extra index cleanup p
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Given that the worst-case consequence is extra index vacuum passes,
> >> which don't hurt that much when a table is small, maybe some smaller
> >> estimate like 100 TIDs per page would be enough. Or, instead of
> >> using a hard
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Given that the worst-case consequence is extra index vacuum passes,
> >> which don't hurt that much when a table is small, maybe some smaller
> >> estimate like 100 TIDs per page would be enough. Or, instead of
> >> using a hard
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> We could set a hard limit at RelationGetNumberOfBlocks *
>> MaxHeapTuplesPerPage TIDs, but that is *extremely* conservative
>> (it'd work out to allocating about a quarter of the table's actual size
>> in bytes, if I did the math r
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Marko Kreen escribi�:
> >> I've experienced something similar. The reason turned out to be
> >> combination of overcommit=off, big maint_mem and several parallel
> >> vacuums for fast-changing tables. Seems like VACUUM allocates
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Marko Kreen escribió:
>> I've experienced something similar. The reason turned out to be
>> combination of overcommit=off, big maint_mem and several parallel
>> vacuums for fast-changing tables. Seems like VACUUM allocates
>> full maint_mem before star
Erik Jones escribió:
> On Aug 28, 2007, at 4:33 PM, Marko Kreen wrote:
>
>> I've experienced something similar. The reason turned out to be
>> combination of overcommit=off, big maint_mem and several parallel
>> vacuums for fast-changing tables. Seems like VACUUM allocates
>> full maint_mem befor
Marko Kreen escribió:
> I've experienced something similar. The reason turned out to be
> combination of overcommit=off, big maint_mem and several parallel
> vacuums for fast-changing tables. Seems like VACUUM allocates
> full maint_mem before start, whatever the actual size of the table.
Hmm.
On Aug 28, 2007, at 4:33 PM, Marko Kreen wrote:
On 8/24/07, Jeff Amiel <[EMAIL PROTECTED]> wrote:
Over last 2 days, have spotted 10 "Out of Memory"
errors in postgres logs (never saw before with same
app/usage patterns on tuned hardware/postgres under
FreeBSD)
Aug 22 18:08:24 db-1 postgres[164
On 8/24/07, Jeff Amiel <[EMAIL PROTECTED]> wrote:
> Over last 2 days, have spotted 10 "Out of Memory"
> errors in postgres logs (never saw before with same
> app/usage patterns on tuned hardware/postgres under
> FreeBSD)
>
> Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
> local0.warning] [6-1] 2
On Aug 28, 2007, at 3:55 PM, Tom Lane wrote:
Jeff Amiel <[EMAIL PROTECTED]> writes:
I notice in the log entries for the out of memory events have no
username, database name or host
identifier (while regular logged events do) Does that mean
anything to anybody?
Means they're coming from a
--- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>2.168.20.44 28785LOG: duration: 22606.146 ms execute : select
>
> Interesting. What's your log_line_prefix? Does it have "%q" somewhere?
No, no %q...not quite sure what it means: "stop here in non-session processes"
__
Jeff Amiel <[EMAIL PROTECTED]> writes:
> I notice in the log entries for the out of memory events have no username,
> database name or host
> identifier (while regular logged events do) Does that mean anything to
> anybody?
Means they're coming from autovacuum, likely?
Autovacuum probably *sho
Jeff Amiel wrote:
> I notice in the log entries for the out of memory events have no username,
> database name or host
> identifier (while regular logged events do) Does that mean anything to
> anybody?
>
> Aug 28 08:25:50 db-1 postgres[29019]: [ID 748848 local0.warning] [111900-1]
> 2007-08-2
I notice in the log entries for the out of memory events have no username,
database name or host
identifier (while regular logged events do) Does that mean anything to anybody?
Aug 28 08:25:50 db-1 postgres[29019]: [ID 748848 local0.warning] [111900-1]
2007-08-28
08:25:50.081 CDT29019ERROR:
Yes, but fortunately for me, unfortunately for the list, it's only
happened to me once so I don't really have anything to go on wrt
repeating the problem. I can only say, "Yep! It's happened!" I am
watching my db closely, though. Well, my monitoring scripts are :)
On Aug 27, 2007, at 1:
--- "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
> The machine we are tracking this problem on is also 64bit.
H.looks like 3 different people are tracking a similar issue on 64 bit
platforms.you,
Erik and myself.
_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Jones wrote:
>
> On Aug 27, 2007, at 12:15 PM, Martijn van Oosterhout wrote:
>
>> On Mon, Aug 27, 2007 at 09:12:17AM -0700, Jeff Amiel wrote:
>>> Tracking for last few days.
>>> Does not appear to happen when little or no user
>>> activity (like
On Aug 27, 2007, at 12:15 PM, Martijn van Oosterhout wrote:
On Mon, Aug 27, 2007 at 09:12:17AM -0700, Jeff Amiel wrote:
Tracking for last few days.
Does not appear to happen when little or no user
activity (like Saturday) I don't know if that rules
out autovacuum or not (if no update threshho
On Mon, Aug 27, 2007 at 09:12:17AM -0700, Jeff Amiel wrote:
> Tracking for last few days.
> Does not appear to happen when little or no user
> activity (like Saturday) I don't know if that rules
> out autovacuum or not (if no update threshholds are
> reached, no vacuuming will take place anyway)
Jeff Amiel <[EMAIL PROTECTED]> writes:
> Tracking for last few days.
> Does not appear to happen when little or no user
> activity (like Saturday) I don't know if that rules
> out autovacuum or not (if no update threshholds are
> reached, no vacuuming will take place anyway)
Can you correlate the
--- "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> We are actually diagnosing a similar problem on this
> end, where we get a
> failure at 1920... I am currently trying to get some
> DEBUG output.
Tracking for last few days.
Does not appear to happen when little or no user
activity (like Saturday
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Jeff Amiel <[EMAIL PROTECTED]> writes:
> > is log_min_messages one of them that requires a
> > restart?
>
> No, SIGHUP (pg_ctl reload) should be sufficient.
Weird
looks like some items are going to syslog and some to
my defined postgres logfile (from
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Jeff Amiel <[EMAIL PROTECTED]> writes:
> > is log_min_messages one of them that requires a
> > restart?
>
> No, SIGHUP (pg_ctl reload) should be sufficient.
Weird
looks like some items are going to syslog and some to
my defined postgres logfile (from
Jeff Amiel <[EMAIL PROTECTED]> writes:
> is log_min_messages one of them that requires a
> restart?
No, SIGHUP (pg_ctl reload) should be sufficient.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our exte
--- "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> Having log_line_prefix with at least %p and %m (or
> %t) plus a
> log_min_messages of DEBUG2 would be great.
i am getting the additional timestampt/pid on my log
lines nowbut no additional debug output...
is log_min_messages one of them tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeff Amiel wrote:
> --- "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
>
>
>> We are actually diagnosing a similar problem on this
>> end, where we get a
>> failure at 1920... I am currently trying to get some
>> DEBUG output.
>
> We are actually gett
--- "Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> We are actually diagnosing a similar problem on this
> end, where we get a
> failure at 1920... I am currently trying to get some
> DEBUG output.
We are actually getting it semi-regularly today (3
times already)I would be happy to provide s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Jones wrote:
> On Aug 24, 2007, at 11:46 AM, Tom Lane wrote:
>
>> Jeff Amiel <[EMAIL PROTECTED]> writes:
>>> Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
>>> local0.warning] [6-1] 2007-08-22 18:08:24 CDT ERROR:
>>> out of memory.
>>> Aug 2
On Aug 24, 2007, at 11:46 AM, Tom Lane wrote:
Jeff Amiel <[EMAIL PROTECTED]> writes:
Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
local0.warning] [6-1] 2007-08-22 18:08:24 CDT ERROR:
out of memory.
Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
local0.warning] [6-2] 2007-08-22 18:08:24
Jeff Amiel <[EMAIL PROTECTED]> writes:
> Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
> local0.warning] [6-1] 2007-08-22 18:08:24 CDT ERROR:
> out of memory.
> Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
> local0.warning] [6-2] 2007-08-22 18:08:24 CDT
> DETAIL: Failed on request of s
On Aug 24, 2007, at 10:09 AM, Jeff Amiel wrote:
"PostgreSQL 8.2.4 on i386-pc-solaris2.10, compiled by
GCC gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)"
Week-old installstill tuning and tweaking this
thing.
Over last 2 days, have spotted 10 "Out of Memory"
errors in postgres logs (nev
"PostgreSQL 8.2.4 on i386-pc-solaris2.10, compiled by
GCC gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)"
Week-old installstill tuning and tweaking this
thing.
Over last 2 days, have spotted 10 "Out of Memory"
errors in postgres logs (never saw before with same
app/usage patterns on tuned
53 matches
Mail list logo
