Hi,
> On December 3, 2014 at 5:04 PM Tom Lane wrote:
> ...
> which suggests that getaddrinfo() preferentially looks in /etc/hosts
> before contacting any DNS server. So perhaps that "dig" call is not
> telling you the real state of affairs, and what you need to do is
> see if there's a bogus ent
=?UTF-8?Q?Tim_Sch=C3=A4fer?= writes:
>> On December 2, 2014 at 4:51 PM Tom Lane wrote:
>> Yes, this will break autovacuum, because it won't have any way to find out
>> what it should vacuum. The cause probably is a DNS issue: "localhost"
>> isn't resolving to anything sensible. "dig localhost"
Hi,
on the netstat question: it bound the default postgres port (5432) sucessfully
on both interfaces (lo and
eth0) it seems:
postgres@ixion41:~/data> netstat -na | grep postg
unix 2 [ ACC ] STREAM LISTENING 21156728
/var/run/postgresql/.s.PGSQL.5432
postgres@ixion41:~/data> netstat -na | grep 54
On 12/03/2014 12:36 AM, Tim Schäfer wrote:
Hi,
On December 2, 2014 at 4:51 PM Tom Lane wrote:
=?UTF-8?Q?Tim_Sch=C3=A4fer?= writes:
After starting the server with pg_ctl start, I get the following entries in
the
logs:
2014-12-02 15:27:36 CET LOG: could not bind socket for statistics
Hi,
> On December 2, 2014 at 4:51 PM Tom Lane wrote:
> =?UTF-8?Q?Tim_Sch=C3=A4fer?= writes:
> > After starting the server with pg_ctl start, I get the following entries in
> > the
> > logs:
>
> > 2014-12-02 15:27:36 CET LOG: could not bind socket for statistics
> > collector: Cannot assig
=?UTF-8?Q?Tim_Sch=C3=A4fer?= writes:
> After starting the server with pg_ctl start, I get the following entries in
> the
> logs:
> 2014-12-02 15:27:36 CET LOG: could not bind socket for statistics
> collector: Cannot assign requested address
> 2014-12-02 15:27:36 CET LOG: disabling sta
Dear list,
I am having trouble running PostgreSQL 9.3 under OpenSuSE because auto vacuum
does not seem to work.
Here are the details on my version:
# select version();
PostgreSQL 9.3.5 on x86_64-suse-linux-gnu, compiled by gcc (SUSE Linux) 4.8.1
20130909 [gcc-4_8-branch revision 202388], 64-bit
Hi Tom,
On the test box this seems to have completely resolved our problem.
I'll be scheduling an upgrade on the production cluster to verify it.
Thanks
On Thu, Sep 13, 2012 at 11:08 AM, Tom Lane wrote:
> Mike Roest writes:
> >We have a interesting thing happening on one of our DB's t
Mike Roest writes:
>We have a interesting thing happening on one of our DB's that when
> autovacuum runs against the pg_catalog tables (or we run a manual vacuum)
> we get a large delay in opening new connections.
I think you're hitting the problem that was fixed here:
Author: Tom Lane
Bran
Good Morning everyone,
We have a interesting thing happening on one of our DB's that when
autovacuum runs against the pg_catalog tables (or we run a manual vacuum)
we get a large delay in opening new connections. If this happens during a
busy period on our system we end up getting 200-300 con
On Tue, Apr 26, 2011 at 12:59 PM, Guillaume Lelarge
wrote:
> > I do not believe analyze is part of the restore process. You must
> > explicitly run it.
> >
>
> That's almost true. If autovacuum is on, it can start an ANALYZE on the
> big tables.
>
>
So that just means you need some luck of timing
Le 26/04/2011 18:38, Vick Khera a écrit :
> On Tue, Apr 26, 2011 at 11:36 AM, Willy-Bas Loos wrote:
>
>> I don't get it, they should have been analyzed at restore, should they not?
>>
>
> I do not believe analyze is part of the restore process. You must
> explicitly run it.
>
That's almost tr
On Tue, Apr 26, 2011 at 11:36 AM, Willy-Bas Loos wrote:
> I don't get it, they should have been analyzed at restore, should they not?
>
I do not believe analyze is part of the restore process. You must
explicitly run it.
Hi,
i've tested on 8.3 and 8.4 and i found that autovacuum works during restore
uin my test scenario, which is:
a new database wit two tables. tab1 has 1M recs, tab2 has 10 recs.
When i drop the database and restore, pg_stat_all tables tells me good
estimations for the number of live tuples.
But
On Mon, May 24, 2010 at 6:23 PM, venu madhav wrote:
> Hi All,
> In my application we are using postgres which runs on an
> embedded box. I have configured autovacuum to run once for every one
> hour. It has 5 different databases in it. When I saw the log messages,
> I found that it is runnin
Hi All,
In my application we are using postgres which runs on an
embedded box. I have configured autovacuum to run once for every one
hour. It has 5 different databases in it. When I saw the log messages,
I found that it is running autovacuum on one database every hour. As a
result, on my da
In response to Herouth Maoz :
> > If the problem is that overall performance slows too much when vacuum is
> > running, then you'll probably have to get more/faster hardware. Vacuum
> > has to run occasionally or your table will bloat. Bloated tables perform
> > lousy and waste a lot of space, a
ציטוט Bill Moran:
In response to Herouth Maoz :
Did I understand the original problem correctly? I thought you were saying
that _lack_ of analyzing was causing performance issues, and that running
vacuum analyze was taking too long and causing the interval between
analyze runs to be too lo
Herouth Maoz wrote:
> First, I'd like to thank Bill and Alvaro as well as you for your replies.
>
> Quoting Tom Lane:
> >Hmm. Given the churn rate on the table, I'm having a very hard time
> >believing that you don't need to vacuum it pretty dang often. Maybe the
> >direction you need to be movi
In response to Herouth Maoz :
> First, I'd like to thank Bill and Alvaro as well as you for your replies.
>
> Quoting Tom Lane:
> > Hmm. Given the churn rate on the table, I'm having a very hard time
> > believing that you don't need to vacuum it pretty dang often. Maybe the
> > direction you n
First, I'd like to thank Bill and Alvaro as well as you for your replies.
Quoting Tom Lane:
Hmm. Given the churn rate on the table, I'm having a very hard time
believing that you don't need to vacuum it pretty dang often. Maybe the
direction you need to be moving is to persuade autovac to vacu
Alvaro Herrera writes:
> Herouth Maoz wrote:
>> We found out that the table's response depends on the rate of ANALYZE being
>> performed. We have tuned the values in pg_autovacuum so that we have around
>> one analyze per minute.
>>
>> What is bothering me is that sometimes the auto vacuum daem
Herouth Maoz wrote:
> We found out that the table's response depends on the rate of ANALYZE being
> performed. We have tuned the values in pg_autovacuum so that we have around
> one analyze per minute.
>
> What is bothering me is that sometimes the auto vacuum daemon decides to
> perform a vac
In response to Herouth Maoz :
> Hi all.
>
> We had a crisis this week that was resolved by tuning pg_autovacuum for a
> particular table. The table is supposed to contain a small number of items at
> any given point in time (typically around 10,000-30,000). The items are
> inserted when we sen
Hi all.
We had a crisis this week that was resolved by tuning pg_autovacuum for a
particular table. The table is supposed to contain a small number of items at
any given point in time (typically around 10,000-30,000). The items are
inserted when we send out a message, and are selected, then del
Thanks for the help. Will do that.
Regards
On Fri, Mar 5, 2010 at 10:35 AM, Joao Ferreira gmail <
joao.miguel.c.ferre...@gmail.com> wrote:
> On Fri, 2010-03-05 at 10:03 -0500, akp geek wrote:
> > Hi All -
> >
> > I am still having the issue, even after I turned on the
> > auto vaccu
On Fri, 2010-03-05 at 10:03 -0500, akp geek wrote:
> Hi All -
>
> I am still having the issue, even after I turned on the
> auto vaccum. I have quick question. How do I know that auto vacuum
> process is running. When I restarted my database , I got the message
> auto vacuum launcher
Hi All -
I am still having the issue, even after I turned on the auto
vaccum. I have quick question. How do I know that auto vacuum process is
running. When I restarted my database , I got the message auto vacuum
launcher started. But is there a way that I can check that the process i
On Thu, 2010-03-04 at 11:04 -0500, akp geek wrote:
> My RAM size is 8GB. I have set the maintenance_work_mem = 500MB this
> morning.
>
> ERROR: canceling autovacuum task with table name
>
> Thanks for the help
You likely have a lock that is conflicting with autovacuum and it
cancels itself
My RAM size is 8GB. I have set the maintenance_work_mem = 500MB this
morning.
ERROR: canceling autovacuum task with table name
Thanks for the help
Regards
On Wed, Mar 3, 2010 at 4:31 PM, Igor Neyman wrote:
> What's the complete error message?
> Vacuum is using maintenance_work_mem. What
What's the complete error message?
Vacuum is using maintenance_work_mem. What is your setting
maintenance_work_mem compared to your RAM size.
Igor Neyman
> -Original Message-
> From: akp geek [mailto:akpg...@gmail.com]
> Sent: Wednesday, March 03, 2010 1:10 PM
> To: Joao Ferreira gmai
thank you . I changed the value to 1M and I started seeing the autovacuum
being triggered. But I am getting the following message
ERROR: canceling autovacuum task, is it because the table are getting
updated and the vacuum process in place and vacuum happens at a later point
of time
Regards
On Wed, 2010-03-03 at 12:46 -0500, akp geek wrote:
> Hi All -
>
> I need some help from you. this question is in follow up
> with my earlier questions. I turned the autovacuum and restarted the
> db and the settings I have as follows. It seems the autovacuum process
> has not been turne
Hi All -
I need some help from you. this question is in follow up with my
earlier questions. I turned the autovacuum and restarted the db and the
settings I have as follows. It seems the autovacuum process has not been
turned on. It's almost more than 3 hours I have restarted my DB with
On 3/12/2009 7:24 AM, Rikard Bosnjakovic wrote:
On Wed, Dec 2, 2009 at 13:46, wrote:
Is it fine to do that or should we manually perform vacuum and analyze.
Will it automatically take care of vacuuming the tables and analyzing them?
Have a look at this wiki-page that was posted by Craig on
On Wed, Dec 2, 2009 at 5:46 AM, wrote:
> Hello All,
>
> I am using Postgres 8.3.5 on windows and was using manually VACCUM and
> ANALYZE commands in my scripts but now I have turned on the AutoVaccum
> daemon by changing the postgresql conf file.
>
> Is it fine to do that or should we manually pe
On Wed, Dec 2, 2009 at 13:46, wrote:
> Is it fine to do that or should we manually perform vacuum and analyze.
>
> Will it automatically take care of vacuuming the tables and analyzing them?
Have a look at this wiki-page that was posted by Craig on this list a
few days ago:
http://wiki.postgre
Hello All,
I am using Postgres 8.3.5 on windows and was using manually VACCUM and
ANALYZE commands in my scripts but now I have turned on the AutoVaccum
daemon by changing the postgresql conf file.
Is it fine to do that or should we manually perform vacuum and analyze.
Will it automaticall
On Thu, May 8, 2008 at 12:10 PM, John Gateley <[EMAIL PROTECTED]> wrote:
>
> On Thu, 8 May 2008 10:58:47 -0700
> Alan Hodgson <[EMAIL PROTECTED]> wrote:
>
> > On Thursday 08 May 2008, John Gateley <[EMAIL PROTECTED]> wrote:
> > > But the new database, mydbtest, always has slow queries.
> > > I
On Thu, 8 May 2008 10:58:47 -0700
Alan Hodgson <[EMAIL PROTECTED]> wrote:
> On Thursday 08 May 2008, John Gateley <[EMAIL PROTECTED]> wrote:
> > But the new database, mydbtest, always has slow queries.
> > I run an analyze and they speed up.
>
> Do the query plans actually change, or are you jus
On Thursday 08 May 2008, John Gateley <[EMAIL PROTECTED]> wrote:
> But the new database, mydbtest, always has slow queries.
> I run an analyze and they speed up.
Do the query plans actually change, or are you just seeing caching effects
from running the analyze?
--
Alan
signature.asc
Descrip
On Thu, 8 May 2008 10:54:32 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> John Gateley wrote:
> > Hi, I have a couple of questions on the auto-vacuum daemon:
> >
> > 1) How do I know it is running.
>
> Open a session and run "SHOW autovacuum". If it says "on", it's
> vacuuming. Keep an eye
John Gateley wrote:
> Hi, I have a couple of questions on the auto-vacuum daemon:
>
> 1) How do I know it is running. I suspect it has not been, and
> I carefully checked the documentation and found a variable that
> wasn't set (stats_row_level defaults to off in 8.1, should be
> "on"). So I chang
Hi, I have a couple of questions on the auto-vacuum daemon:
1) How do I know it is running. I suspect it has not been, and
I carefully checked the documentation and found a variable that
wasn't set (stats_row_level defaults to off in 8.1, should be
"on"). So I changed that and restarted, but how d
Collin Peters escribió:
> Where is the definitive source for all things autovacuuming? I have
> seen http://www.postgresql.org/docs/8.1/static/maintenance.html#AUTOVACUUM.
The source code ;-)
> Ultimately the issue I am having is that the postgresql logs show each
> of the databases being 'autov
Where is the definitive source for all things autovacuuming? I have
seen http://www.postgresql.org/docs/8.1/static/maintenance.html#AUTOVACUUM.
Ultimately the issue I am having is that the postgresql logs show each
of the databases being 'autovacuumed' (actually quite often), but when
I click aro
On Mon, Jun 04, 2007 at 04:15:12AM -0700, [EMAIL PROTECTED] wrote:
> after i executed the command " vaccumdb -f -z testdb", but the size
> just decreased 1 or 2MB...
> what's the problem?
vacuumdb -f does a FULL vacuum, which is blocking and compacts the
tables. If it only compacted 1 or 2 M, the
i set the auto vacuum option to enable. but my database size(hard-disk
space) still increased from 420MB to 440MB in 8 hours. most of the
operations in this database are the "Select" query command, just few
of "Update or Insert".
why it can be increased so strongly?
after i executed the command " v
Tom Lane wrote:
The reason I didn't patch it myself is that I'm not quite clear on what
*should* be happening here. What effect should a large delete have on
the ANALYZE threshold, exactly? You could argue that a deletion
potentially changes the statistics (by omission), and therefore inserts,
Hi Tom, Alvaro,Thanks for your work on this. Please keep me posted as to which version in CVS this fix will be applied to and I will do my best to test it.Thanks again! --Dylan HansenEnterprise Systems DeveloperOn 27-Jun-06, at 5:42 AM, Alvaro Herrera wrote:Tom Lane wrote: Alvaro Herrera <[EMAIL P
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > + /* last_anl_tuples must never exceed n_live_tuples */
>
> If we actually believe the above statement, it seems like your patch
> to pgstat_recv_tabstat() opens a new issue: with that patch, it is
> possible for pgstat_rec
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> + /* last_anl_tuples must never exceed n_live_tuples */
If we actually believe the above statement, it seems like your patch
to pgstat_recv_tabstat() opens a new issue: with that patch, it is
possible for pgstat_recv_tabstat() to decrease n_
Dylan Hansen wrote:
> So can I assume that this is a bug?
Definitively a bug.
> The only resolution I can see right now is to setup a cron job that
> will perform an ANALYZE periodically, as the pg_autovacuum ANALYZE
> threshold is never reached.
>
> Any other suggestions? Thanks for the in
So can I assume that this is a bug?The only resolution I can see right now is to setup a cron job that will perform an ANALYZE periodically, as the pg_autovacuum ANALYZE threshold is never reached.Any other suggestions? Thanks for the input! --Dylan HansenEnterprise Systems DeveloperOn 24-Jun-06,
Tom Lane wrote:
Dylan Hansen <[EMAIL PROTECTED]> writes:
I have been spending some time looking into how auto-vacuum is
performing on one of our servers. After putting the PostgreSQL logs
in debug I noticed that the threshold for ANALYZE was never being hit
for a particular table becaus
Hi Tom, Alvaro. Thanks so much for your replies.On 22-Jun-06, at 12:56 PM, Alvaro Herrera wrote:Hmm ... I'd think that the number of dead tuples plus live tuples shouldnever be smaller than the number of tuples seen at last analyze. Unlesssome stats messages are lost (say, stop the server, start
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Apparently somehow last_anl_tuples has managed to get to be bigger than
>> n_live_tuples, which maybe could happen after a delete. Should we be
>> clamping last_anl_tuples to not exceed n_live_tuples somewhere?
>> Alvaro and Matthew,
Tom Lane wrote:
> Dylan Hansen <[EMAIL PROTECTED]> writes:
> > I have been spending some time looking into how auto-vacuum is
> > performing on one of our servers. After putting the PostgreSQL logs
> > in debug I noticed that the threshold for ANALYZE was never being hit
> > for a particular
Dylan Hansen <[EMAIL PROTECTED]> writes:
> I have been spending some time looking into how auto-vacuum is
> performing on one of our servers. After putting the PostgreSQL logs
> in debug I noticed that the threshold for ANALYZE was never being hit
> for a particular table because the calcula
Greetings all,I have been spending some time looking into how auto-vacuum is performing on one of our servers. After putting the PostgreSQL logs in debug I noticed that the threshold for ANALYZE was never being hit for a particular table because the calculated value becomes increasingly negative.W
60 matches
Mail list logo
