Baptiste LHOSTE wrote:
> We are still trying to fix our issue and we found following logs :
>
> 2013-01-17 09:55:01 CET LOG: automatic vacuum of table
> "flows.public.agg_t1213_incoming_a6_dst_port_and_proto_f5": index scans: 1
> pages: 0 removed, 136547 remain
> tuples: 0 removed, 40
Hi,
We are still trying to fix our issue and we found following logs :
2013-01-17 09:55:01 CET LOG: automatic vacuum of table
"flows.public.agg_t1213_incoming_a6_dst_port_and_proto_f5": index scans: 1
pages: 0 removed, 136547 remain
tuples: 0 removed, 4044679 remain
syst
Hi,
> Could you show that output you base that on?
EXPLAIN on table which was recently analyzed by the autovacuum process :
explain delete from agg_t1343_incoming_a3_src_net_and_dst_net_f5 where
start_date < 1353317127200;
Baptiste LHOSTE wrote:
> These queries are very simple : delete from table where
> start_date < availableTimestamp. We performed an EXPLAIN to try
> to understand what could be the problem. The query planner said
> that the index on start_date could not be used because it was not
> up-to-date.
Co
Hi,
> Thanks. I wasn't suggesting you increase the duration; I just
> wanted perspective on whether it could be the result of unusually
> long run times rather than blocking, and how severe that increase
> was known ot be.
> Thank you very much, With that much information we should be much
> bett
Baptiste LHOSTE wrote:
>> Just so we know how to interpret that, how many minutes, hours,
>> or days did you wait to see whether it would ever end?
>
> I have waiting for 15 minutes in this state. I can not wait more
> time without losing some data for our client.
Thanks. I wasn't suggesting you
Suhas --
>
>Can i cancel ongoing autovacuum on a large table? Is it safe?
>
>I am trying to do pg_cancel_backend(procid).Please suggest whether its safe
>to do ?
>
>Rgrds
>Suhas
>
>
I've killed autovac processes manually with no malign effects other than the
consequences of not vacuuming the
Hi,
Can i cancel ongoing autovacuum on a large table? Is it safe?
I am trying to do pg_cancel_backend(procid).Please suggest whether its safe
to do ?
Rgrds
Suhas
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/autovacuum-tp5738332.html
Sent from the PostgreSQL - adm
Baptiste LHOSTE wrote:
>> Was the blocking you described occurring at the time you
>> captured this? It doesn't seem to be showing any problem.
>
> Yes indeed. We have noticed that any process seems to be in
> waiting situation but :
> - before the autovacuum process starts to work on the both k
> Was the blocking you described occurring at the time you captured
> this? It doesn't seem to be showing any problem.
Yes indeed. We have noticed that any process seems to be in waiting situation
but :
- before the autovacuum process starts to work on the both kind of tables,
truncate and ind
Baptiste LHOSTE wrote:
> Here's the pg_stat_activity during the issue :
> [no processes waiting]
> Here's the pg_locks during the issue :
> [all locks granted]
Was the blocking you described occurring at the time you captured
this? It doesn't seem to be showing any problem.
> Is there a way to
>> Would it be possible to update your 8.4 installation to the latest
>> bug fix (currently 8.4.15) to rule out the influence of any bugs
>> which have already been fixed?
> Is there a way to upgrade without having to dump all data and restore them
> after the upgrade ?
I have check but debian
> Would it be possible for you to create such a situation and capture
> the contents of pg_stat_activity and pg_locks while it is going on?
> What messages related to autovacuum or deadlocks do you see in the
> server log while this is going on?
Before the change we can only see only automatic a
Baptiste LHOSTE wrote:
> - finally we delete old data of the second kind of tables
> Then the autovacuum process starts to work on the second kind of
> tables, but our process blocks into step 3 (truncate) or step 5
> (create index).
>
> As soon as I reset the autovacuum thresholds for the seco
Hi everybody,
We are having issues with the autovacuum process.
Our database is composed by two kinds of tables :
- the first ones are partitions,
- the second ones are classic tables.
Each five minutes we execute the following process :
- we drop constraint of the target partition
- we drop
Thanks both of you for your help.
The autovacuum process did the work yesterday.
Best regards,
Baptiste
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone : +33 (0) 5 59 41 51 10
www.alaloop.com
--
Sent via pgsql-admin mailing list (p
> Does "select * from pg_prepared_xacts" find anything?
Yes indeed, so I rollback our old prepared transactions.
I will check tomorrow, and I will let you know.
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone :
Baptiste LHOSTE writes:
>> As I said, because they are still visible to other transactions. Try to
>> see if you have long-lasting transactions.
> How can I do that ? I check running query in pg_stat_activity, but there is
> no query on that table.
Does "select * from pg_prepared_xacts" find an
I run a select on the pg_stat_all_tables and it returns that there is 0
n_dead_tup.
I am really confused.
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
Téléphone : +33 (0) 5 59 41 51 10
www.alaloop.com
--
Sent via
>As I said, because they are still visible to other transactions. Try to
>see if you have long-lasting transactions.
How can I do that ? I check running query in pg_stat_activity, but there is no
query on that table.
Best regards,
Baptiste.
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP
On Mon, 2012-12-17 at 17:10 +0100, Baptiste LHOSTE wrote:
> > It could be dead rows, still visible for other transactions.
>
> Ok but in this case, why the automatic vacuum task of the autovacuum process
> does not delete theses dead rows ?
>
As I said, because they are still visible to other
> It could be dead rows, still visible for other transactions.
Ok but in this case, why the automatic vacuum task of the autovacuum process
does not delete theses dead rows ?
Best regards,
Baptiste
---
Baptiste LHOSTE
blho...@alaloop.com
ALALOOP S.A.S. - Technopole Izarbel - 64210 Bidart
On Mon, 2012-12-17 at 16:57 +0100, Baptiste LHOSTE wrote:
> Hi everybody,
>
> I have trouble understanding some logs of postgreSQL.
>
> Here you can find a log from the auto-vacuum process :
>
> 2012-12-17 16:38:58 CET LOG: automatic vacuum of table
> "flows.public.agg_t344_outgoing_a41_src_ne
Hi everybody,
I have trouble understanding some logs of postgreSQL.
Here you can find a log from the auto-vacuum process :
2012-12-17 16:38:58 CET LOG: automatic vacuum of table
"flows.public.agg_t344_outgoing_a41_src_net_and_dst_net_f5": index scans: 0
pages: 0 removed, 59820 remain
Greg Williamson writes:
>> So far, my guess is that this is fixed by commits a1f064fc2 + d7598aeea.
> Is there any idea of when this will be released ?
No. I'd guess that there will be update releases before the end of the
year, but they are not imminent. We have some open issues that have to
Tom --
<...>
>> A cron job dropdb one of the databases and createdb it and then pg_restore.
> Roughly 80GB dump.
>
> So far, my guess is that this is fixed by commits a1f064fc2 + d7598aeea.
>
>> Out production PostgreSQL running a 9.1 variant does not have this problem.
> It does not have
Tore Halset writes:
> On Oct 15, 2012, at 2:27 AM, Tom Lane wrote:
>> Tore Halset writes:
>>> On this box I drop a 80GB database each night followed by a restore of a
>>> similar sized database. It is a restore of our production database to a
>>> development server. This box is running 9.2rc1
On Oct 15, 2012, at 2:27 AM, Tom Lane wrote:
> Tore Halset writes:
>> On this box I drop a 80GB database each night followed by a restore of a
>> similar sized database. It is a restore of our production database to a
>> development server. This box is running 9.2rc1 (sorry).
>
>> du and df r
Tore Halset writes:
> On this box I drop a 80GB database each night followed by a restore of a
> similar sized database. It is a restore of our production database to a
> development server. This box is running 9.2rc1 (sorry).
> du and df reported quite different numbers and lsof show that auto
Hello.
On this box I drop a 80GB database each night followed by a restore of a
similar sized database. It is a restore of our production database to a
development server. This box is running 9.2rc1 (sorry).
du and df reported quite different numbers and lsof show that autovacuum is
holding lo
Hi all,
in postgresql log file i found a lots of rows like:
autovacuum: found orphan temp table "pg_temp_32"."test11" in database "Test"
I tried to select this table:
select * from "pg_temp_32"."test11"
but i received the follow error:
ERROR: could not open file "base/16385/t32_13288115": No
Excerpts from Pablo Delgado Díaz-Pache's message of lun nov 15 04:52:53 -0300
2010:
> > But it strikes me that the code comment is wrong in one significant way:
> > if the postmaster were failing to heed SIGUSR1 at all, you could reach
> > the timeout here, because the fork-failed signal wouldn't
Excerpts from Pablo Delgado Díaz-Pache's message of jue nov 18 08:57:16 -0300
2010:
> 2) We did a strace to the postmaster pid. However we had 2 postmasters not
> dead
>
> # ps -fea |grep -i postmaster
> postgres 3889 1 0 Nov16 ?00:01:24 /usr/bin/postmaster -p 5432
> -D /var/lib/pg
Excerpts from Pablo Delgado Díaz-Pache's message of jue nov 18 08:57:16 -0300
2010:
> Well, we had the problem again. This is what we did
>
> 1) A "ps" to check what processes were running. Many "postmaster" processes
> in defunct state. A few postgres connections still working. A few "psql" (by
Excerpts from Pablo Delgado Díaz-Pache's message of mar nov 16 12:18:09 -0300
2010:
> Not sure what you mean.
>
> Once we start getting that error in the postgres log, there is no autovacuum
> entry. Only that error message once every minute (and as i wrote in my last
> email, the same message al
Not sure what you mean.
Once we start getting that error in the postgres log, there is no autovacuum
entry. Only that error message once every minute (and as i wrote in my last
email, the same message all the time).
The question is what is causing postgres to stop working. Autovacuum or
another r
Hi all,
I'm having a strange problem with postgres & autovacuum
Everything is working fine until I start getting the following errors ...
and postgres stops working shortly after (it stops accepting connections)
2010-11-13 12:34:08.599 CET|1|||7104||4cde77b0.1bc0|2010-11-13 12:34:08
CET|1/44303|0
Hi Tom, thanks for your detailed responses. I really appreciate it.
My comments below inline ...
> > I'm having a strange problem with postgres & autovacuum
> > Everything is working fine until I start getting the following errors ...
> > and postgres stops working shortly after (it stops accepti
=?ISO-8859-1?Q?Pablo_Delgado_D=EDaz=2DPache?= writes:
> I'm having a strange problem with postgres & autovacuum
> Everything is working fine until I start getting the following errors ...
> and postgres stops working shortly after (it stops accepting connections)
> 2010-11-13 12:34:08.599 CET|1||
Hi all,
I'm having a strange problem with postgres & autovacuum
Everything is working fine until I start getting the following errors ...
and postgres stops working shortly after (it stops accepting connections)
2010-11-13 12:34:08.599 CET|1|||7104||4cde77b0.1bc0|2010-11-13 12:34:08
CET|1/44303|0
Excerpts from Tom Lane's message of lun nov 08 12:15:02 -0300 2010:
> Alvaro Herrera writes:
> > Patch for this is attached (applies cleanly to 9.0 and HEAD; 8.4 doesn't
> > need to be patched, but I'll run the test case now just to be sure.)
>
> Possibly s/cxt/resultcxt/, or some other less-gene
Alvaro Herrera writes:
> Patch for this is attached (applies cleanly to 9.0 and HEAD; 8.4 doesn't
> need to be patched, but I'll run the test case now just to be sure.)
Possibly s/cxt/resultcxt/, or some other less-generic name. Seems
pretty sane other than that cosmetic issue.
Excerpts from Tom Lane's message of lun oct 25 16:57:10 -0300 2010:
> It looks to me like the problem is that get_database_list()
> intentionally pushes its result into a long-lived context, and then the
> result is never cleaned up. It doesn't help any that it does a lot of
> leaky things like h
Nick writes:
> It seems like the problem is a function of how many databases there are.
Yeah, I can reproduce this in HEAD. Create a hundred or so databases,
and make sure there's a stats table entry for each, eg
create database d0;
\c d0
create table t1 as select generate_series(1,10) x;
c
Nick wrote:
> Kevin Grittner wrote:
>
>> I've not seen anything remotely like that. I wonder what's
>> different
>
> I did a test with the same postgres build (and autovacuum_naptime
> = 1 as well) on the same OS with only the system databases
> (postgres, template0, template1), and after
On Fri, Oct 22, 2010 at 11:17 AM, Kevin Grittner
wrote:
> I've not seen anything remotely like that. I wonder what's
> different
I did a test with the same postgres build (and autovacuum_naptime = 1
as well) on the same OS with only the system databases (postgres,
template0, template1), and
Nick wrote:
> Here is a vmstat 1 right after postgres has been started:
>
> procs ---memory--
> r b swpd free buff cache
> 0 0 55480 760172 1709424 3758492
> Here is another chunk after it's been running for about 18 hours:
>
> procs ---memory--
>
Yes I was using top, but I am not adding up anything. I'm only ever
looking at the one process called "postgres: autovacuum launcher
process", not any of the other postgres processes.
Here is a vmstat 1 right after postgres has been started:
procs ---memory-- ---swap-- -io---
On Thu, Oct 21, 2010 at 3:14 PM, Nick wrote:
> I have a production server running postgres 8.3.11. I did a dump all
> and loaded up postgres 9.0.1 on another server. On the new server,
> the postgres autovacuum launcher process eats up an insane amount of
> ram (I have seen 17G virt with 6.5G re
Nick wrote:
> I have a production server running postgres 8.3.11. I did a dump
> all and loaded up postgres 9.0.1 on another server. On the new
> server, the postgres autovacuum launcher process eats up an insane
> amount of ram (I have seen 17G virt with 6.5G res).
You're not looking at thi
I have a production server running postgres 8.3.11. I did a dump all
and loaded up postgres 9.0.1 on another server. On the new server,
the postgres autovacuum launcher process eats up an insane amount of
ram (I have seen 17G virt with 6.5G res). On the older version, it's
at a reasonable 9MB re
Kevin Grittner pisze:
Ireneusz Pluta wrote:
Is there
any ready tool, which, for instance when given a path to database
cluster, would traverse all cluster directories and files and
check all page headers? I probably answered myself - manual VACUUM
[VERBOSE] would do - but it fails when find
Tom Lane pisze:
Alvaro Herrera writes:
Yeah, maybe we should make it put the failed table at the end of the
list, for the next run. This is not simple to implement, if only
because autovac workers don't have any way to persist state from one run
to the next. But this kind of thing causes e
"Gnanakumar" writes:
> Does autovacuum daemon work on tables created with TEMPORARY syntax?
No. It can't, because it's unsafe for any session except the creating
session to touch a temporary table. The performance optimizations used
for temp tables have that unfortunate side-effect.
Hi,
Does autovacuum daemon work on tables created with TEMPORARY syntax?
CREATE [ { TEMPORARY | TEMP } ] TABLE table_name ...
Regards,
Gnanam
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Thanks..all the info is present in the table
2010/8/18 Devrim GÜNDÜZ :
> See pg_stat_user_tables table.
>
> --
> Devrim GÜNDÜZ
> PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
> devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> http://www.gunduz.org Twitter: ht
See pg_stat_user_tables table.
--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
18.Ağu.2010 tarihinde 18:30 saatinde, Anj Adu
şunl
We are using postgres 8.4.x on a few boxes.
Is there a way to check if autovac vacuumed a particular table?
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Thanks for the update.
> The main difference is that 8.2 has only one process working at a time,
> whereas in 8.3 and later there can be several. When there's only one
> process, the only way for it to process several databases is
> sequentially; the naptime is how long to sleep between each item
Excerpts from Gnanakumar's message of jue ago 12 00:56:34 -0400 2010:
> > in 8.2 "naptime" means "time to sleep after we finish a job". So even
> > if the previous task takes an hour, it will still sleep a minute before
> > doing another round. (Note that this setting has a different meaning in
>
> in 8.2 "naptime" means "time to sleep after we finish a job". So even
> if the previous task takes an hour, it will still sleep a minute before
> doing another round. (Note that this setting has a different meaning in
> later releases).
I couldn’t understand the difference in meaning of "autov
"Gnanakumar" wrote:
> Our production server is running PostgreSQL v8.2.3
There are a lot of bug fixes and security fixes you're missing by
not using a recent minor release:
http://www.postgresql.org/support/versioning
http://www.postgresql.org/docs/8.2/static/release.html
-Kevin
--
Sen
Excerpts from Gnanakumar's message of mié ago 11 01:07:08 -0400 2010:
Hi,
> 1. Does autovacuum daemon works with one table at a time or does it work
> with multiple tables at the same time?
Only one.
> Reason to ask this question is, let's say I've "autovacuum_naptime" set to 1
> minute, and t
Hi,
Our production server is running PostgreSQL v8.2.3 on Red Hat Enterprise
Linux Server release 5 (Tikanga).
I need a clarification on how autovacuum daemon internally works/handles in
the following specific use case/situation:
1. Does autovacuum daemon works with one table at a time or does i
Autovacuum is sometimes skipping certain tables. The tables in question
are pretty busy. A vacuum analyze works fine when run manually. The
tables in question were successfully autovacuumed this morning, but that
is the first time since the 23rd where it worked. I'm not finding any
logging info
On 10-07-30 11:44 AM, Bryan Payne wrote:
Yeah, this is one that is only occasionally busy. The other tables in
question have been getting autovacuumed as of late, but we had a span
of about a week where it was getting passed up. I'm going to check out
the vacuum_cost_limit someone mentioned and
Yeah, this is one that is only occasionally busy. The other tables in
question have been getting autovacuumed as of late, but we had a span of
about a week where it was getting passed up. I'm going to check out the
vacuum_cost_limit someone mentioned and see where that takes me. Thanks
for ever
Excerpts from Bryan Payne's message of vie jul 30 11:10:42 -0400 2010:
> Table info (this table shows last autovacuum on 7/28):
> hostname=> VACUUM ANALYZE VERBOSE hierarchy_pull;
> INFO: vacuuming "public.hierarchy_pull"
> INFO: "hierarchy_pull": found 0 removable, 1906 nonremovable row
> vers
age-
> From: pgsql-admin-ow...@postgresql.org [mailto:pgsql-admin-
> ow...@postgresql.org] On Behalf Of Bryan Payne
> Sent: Friday, July 30, 2010 9:11 AM
> To: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Autovacuum missing tables
>
> Version:
> PostgreSQL 8.3.7 on i486-pc
On 10-07-30 11:10 AM, Bryan Payne wrote:
Version:
PostgreSQL 8.3.7 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.4
(Ubuntu 4.2.4-1ubuntu3)
Postgresql.conf:
data_directory = '/var/lib/postgresql/8.3/main'
hba_file = '/etc/postgresql/8.3/main/pg_hba.conf'
ident_file = '/etc/postgresql/8.3/m
Version:
PostgreSQL 8.3.7 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.4
(Ubuntu 4.2.4-1ubuntu3)
Postgresql.conf:
data_directory = '/var/lib/postgresql/8.3/main'
hba_file = '/etc/postgresql/8.3/main/pg_hba.conf'
ident_file = '/etc/postgresql/8.3/main/pg_ident.conf'
external_pid_file = '/v
Bryan Payne wrote:
> Autovacuum is sometimes skipping certain tables. The tables in
> question are pretty busy. A vacuum analyze works fine when run
> manually. The tables in question were successfully autovacuumed
> this morning, but that is the first time since the 23rd where it
> worked. I'm
Autovacuum is sometimes skipping certain tables. The tables in question
are pretty busy. A vacuum analyze works fine when run manually. The
tables in question were successfully autovacuumed this morning, but that
is the first time since the 23rd where it worked. I'm not finding any
logging info
Excerpts from Fábio Gibon - Comex System's message of mar jul 20 16:13:39 -0400
2010:
> Perfect!!!
>
> I'm starting with PostgreSQL (my knowledge is Oracle). Can you explain more
> about autovacuum? for example...
> 1 - on windows SO, autovacuum start works (postgres.exe as
> autovacuum_max_wor
Comex System"
Sent: Tuesday, July 20, 2010 4:55 PM
Subject: Re: [ADMIN] Autovacuum on defined interval
Excerpts from Fábio Gibon - Comex System's message of mar jul 20
15:18:06 -0400 2010:
thanks for your reply... but i can't shutdown database (24/7)
I didn't say sh
Excerpts from Fábio Gibon - Comex System's message of mar jul 20 12:20:36 -0400
2010:
> Hi everybody,
> are there how define autovacuum to ON and define the period time (for
> example, 00h - 06h) that it's can run?
You could have a script that toggles the value in postgresql.conf and do
On Tue, 2010-07-20 at 13:20 -0300, Fábio Gibon - Comex System wrote:
> Hi everybody,
> are there how define autovacuum to ON and define the period
> time (for example, 00h - 06h) that it's can run?
>
No. You would need to write your own job manager (or use one of the many
that already ex
Hi everybody,
are there how define autovacuum to ON and define the period time (for
example, 00h - 06h) that it's can run?
tks
Fábio Henrique Gibon
Comex System Consultoria
Alvaro Herrera writes:
> Yeah, maybe we should make it put the failed table at the end of the
> list, for the next run. This is not simple to implement, if only
> because autovac workers don't have any way to persist state from one run
> to the next. But this kind of thing causes enough problems
Excerpts from Kevin Grittner's message of jue may 13 10:25:04 -0400 2010:
> Ireneusz Pluta wrote:
>
> > many different autovacuums on the same table cycling in start-fail
> > scenario because of invalid page headers of some indexes of the
> > table. Manual VACUUM VERBOSE said me that, now I can
Ireneusz Pluta wrote:
> many different autovacuums on the same table cycling in start-fail
> scenario because of invalid page headers of some indexes of the
> table. Manual VACUUM VERBOSE said me that, now I can also see that
> in related ERROR-CONTEXT log message pairs. I dropped the damaged
>
I had a problem with neverending forced autovacuum process, running as
preventing xid wraparound. As I finally (?) found, following some
advices given here: ->
http://forums.enterprisedb.com/posts/list/2028.page, that autovacuum in
question was not just one autovacuum, but many different autov
Benjamin Krajmalnik wrote:
> I did not find any errors pertaining to the autovacuum task.
Hmm. I think it would be good to find out what is the launcher doing,
if anything. If you strace it, do you see it sending signals to
postmaster?
--
Alvaro Herrerahttp://ww
ssage-
> From: Alvaro Herrera [mailto:alvhe...@commandprompt.com]
> Sent: Monday, May 03, 2010 7:48 AM
> To: Benjamin Krajmalnik
> Cc: Tom Lane; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Autovacuum stopped running
>
> Benjamin Krajmalnik wrote:
> > OK.
> &
Tom,
1. I had to restart the postgres server, otherwise I would have been in
deep problems.
2. I just tried installing strace from the ports system - unfortunately
it appears that FreeBSD only has it for i38s, not amd64. Any
alternatives so that if this happens again I can take care of this?
>
Tom Lane wrote:
> Also, I've forgotten exactly which PG version you're running?
The original post said:
PostgreSQL 8.4.3 amd64 on FreeBSD 7.2.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
"Benjamin Krajmalnik" writes:
> This happened again on another server with these same settings.
> I did not see any long running transaction, and the autovacuum launch
> process was running.
Hmm ... could you strace the launcher for a couple of minutes to see
whether it's doing anything?
Also, I
"Benjamin Krajmalnik" wrote:
> This happened again on another server with these same settings.
> I did not see any long running transaction, and the autovacuum
> launch process was running.
Like last time, all ten autovacuum workers were running? What does
CPU and disk activity look like in t
Benjamin Krajmalnik wrote:
> OK.
> This happened again on another server with these same settings.
> I did not see any long running transaction, and the autovacuum launch
> process was running.
Did you check the server log for FATAL or ERROR lines? Maybe it's dying
trying to vacuum some table and
;
> Cc: Kevin Grittner; pgsql-admin@postgresql.org
> Subject: RE: [ADMIN] Autovacuum stopped running
>
> # - Cost-Based Vacuum Delay -
>
> #vacuum_cost_delay = 0ms # 0-100 milliseconds
> #vacuum_cost_page_hit = 1 # 0-1 credits
> #vacuum_c
t; -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Saturday, May 01, 2010 5:10 PM
> To: Benjamin Krajmalnik
> Cc: Kevin Grittner; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Autovacuum stopped running
>
> "Benjamin Krajmalnik" w
"Benjamin Krajmalnik" writes:
> TO be truthful, I did not check that.
> I arrived at the conclusion because although I have 10 autovacuum
> threads, none of the tables had been autoanalyzed or autovacuumed in
> hours (and due to the nature of the activity they do so every minute).
> If I ever see
for :) Thx.
> -Original Message-
> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
> Sent: Saturday, May 01, 2010 8:27 AM
> To: Benjamin Krajmalnik; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Autovacuum stopped running
>
> "Benjamin Krajmalnik
"Benjamin Krajmalnik" wrote:
> I had a very strange occurrence 2 days ago where autovacuum
> appears to have stopped running.
What did you see which led you to that conclusion? Did ps show the
'autovacuum launcher process'?
> I did not see any error messages in pg_log. The problem caused a
>
I had a very strange occurrence 2 days ago where autovacuum appears to
have stopped running.
I did not see any error messages in pg_log. The problem caused a file
which is usually around 50Mb but which gets updated extensively to grow
to 105GB, which in turn brought the server's performance down
Gnanakumar wrote:
> >There are two separate counters for live and dead tuples, IIRC (though
> >they may not be exposed in the pg_stat views)
>
> I've a stop/start of PostgreSQL service on a daily basis. Since these 2
> counters are not stored/saved in tables and not available in pg_stat views
>
>> 1. Why need to have 2 parameters (base threshold and scale factor) to
define
>> the threshold value, when either one of the parameter is more than enough
to
>> define the threshold value. Can you explain the significance of having
both
>> parameters. What is the real-time advantage of this?
>
Gnanakumar wrote:
> 1. Why need to have 2 parameters (base threshold and scale factor) to define
> the threshold value, when either one of the parameter is more than enough to
> define the threshold value. Can you explain the significance of having both
> parameters. What is the real-time advant
Hi,
I'm using PostgreSQL 8.2.
I want to configure autovacuum daemon process in our production server in an
efficient way and take advantage of this daemon to perform vacuum and
analyze more aggressively.
I also read about autovacuum daemon at
http://www.postgresql.org/docs/8.2/interactive/routi
I recently built a test server running 8.4/FreeBSD 7.2/amd64, built from
the ports.
I am seeing the following message in the logs:
"autovacuum: found orphan table "pg_temp_1""."pga_tmp_zombies" in
database "postgres"
"autovacuum: found orphan table "pg_temp_2""."pga_tmp_zombies" in
databas
1 - 100 of 221 matches
Mail list logo
