On Mon, Dec 30, 2013 at 11:02 PM, Leonardo M. Ramé wrote:
> On 2013-12-30 13:45:43 +, Haribabu kommi wrote:
>> On 30 December 2013 19:11 Leonardo M. Ramé wrote:
>> > Hi, I want know if I should run the auto-vacuum daemon (from
>> > /etc/init.d/) or it runs automatically and transparently if co
On 2013-12-30 13:45:43 +, Haribabu kommi wrote:
> On 30 December 2013 19:11 Leonardo M. Ramé wrote:
> > Hi, I want know if I should run the auto-vacuum daemon (from
> > /etc/init.d/) or it runs automatically and transparently if configured
> > in postgres.conf?. If it must be configured manuall
On 30 December 2013 19:11 Leonardo M. Ramé wrote:
> Hi, I want know if I should run the auto-vacuum daemon (from
> /etc/init.d/) or it runs automatically and transparently if configured
> in postgres.conf?. If it must be configured manually, what is the
> script to be run, I didn't find pg_autovacu
Hi, I want know if I should run the auto-vacuum daemon (from
/etc/init.d/) or it runs automatically and transparently if configured
in postgres.conf?. If it must be configured manually, what is the script
to be run, I didn't find pg_autovacuum or similar.
I didn't find information about this on t
On Wed, Jun 2, 2010 at 6:40 PM, Wang, Mary Y wrote:
> Hi,
>
> I'm looking at my log file (see my log file below) and it seems like the
> autovacuum daemon is turned on by default in Postgres 8.3.8. Does that mean
> that I no longer need to manually invoke the autovacuum command anymore? I
> u
On Wednesday 02 June 2010 6:17:28 pm Wang, Mary Y wrote:
> I used to execute the VACCUM and ANALYZE commands manually in a Postgres
> 7.x.x version. So my question was that I assume that I no longer have to
> perform those two commands manually anymore. I just wanted to be sure.
> Mary
>
You don'
...@gmail.com]
Sent: Wednesday, June 02, 2010 6:08 PM
To: pgsql-general@postgresql.org
Cc: Wang, Mary Y
Subject: Re: [GENERAL] Autovacuum Daemon is Turned On by Default in Postgres
8.3.8?
On Wednesday 02 June 2010 5:40:58 pm Wang, Mary Y wrote:
> Hi,
>
> I'm looking at my log file (s
On Wednesday 02 June 2010 5:40:58 pm Wang, Mary Y wrote:
> Hi,
>
> I'm looking at my log file (see my log file below) and it seems like the
> autovacuum daemon is turned on by default in Postgres 8.3.8. Does that
> mean that I no longer need to manually invoke the autovacuum command
> anymore? I
Hi,
I'm looking at my log file (see my log file below) and it seems like the
autovacuum daemon is turned on by default in Postgres 8.3.8. Does that mean
that I no longer need to manually invoke the autovacuum command anymore? I
used to do it manually in an older version of Postgres.
tail pos
Raymond O'Donnell wrote on 25.01.2009 19:28:
For WindowsXP the above command can be written as:
tasklist /v /fi "imagename eq postgres.exe"
Cool! I didn't know that one. Must R some more FMs :-)
No need for manuals :)
Just enter "takslist /?"
Regards
Thomas
--
Sent via pgsql-general
On 25/01/2009 13:37, Thomas Kellerer wrote:
> Abdul Rahman wrote on 22.01.2009 07:06:
>> Now, kindly let me know the detail about the solution send by Ray, i.e.
>>
>> ps ax | grep postgres
>
> For WindowsXP the above command can be written as:
>
> tasklist /v /fi "imagename eq postgres.exe"
Cool
Abdul Rahman wrote on 22.01.2009 07:06:
Now, kindly let me know the detail about the solution send by Ray, i.e.
ps ax | grep postgres
For WindowsXP the above command can be written as:
tasklist /v /fi "imagename eq postgres.exe"
Thomas
--
Sent via pgsql-general mailing list (pgsql-general
On 22/01/2009 07:15, Abdul Rahman wrote:
> Your solution of using ps command is for Linux but I am using WinXp.
> That is why it confused me.
No problem! :-) It occurred to me after I sent the email that you might
not be on Linux
It's a good idea, when posting questions, to include as much b
Thanks Ray,
Your solution of using ps command is for Linux but I am using WinXp. That is
why it confused me.
Regards,
Abdul Rehman.
Dear All,
Thanks for fruitful replies. But I checked it by running ANALYZE on psql. First
updated 1 rows in a table and got certain number of dead rows in result of
ANALYZE. After few minutes the number of dead rows becomes zero which assured
me that AUTOVACUUM is running in background.
No
[ Grzegorz, please include some context ]
On Wed, Jan 21, 2009 at 03:01:39PM +, Grzegorz Jaaakiewicz wrote:
> Avdul Rehman wrote:
> > I have set postgresql.conf for autovacuum and need to know weather
> > the process is running/working or not.
>
> select * from pg_autovacuum;
This won't do
select * from pg_autovacuum;
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Abdul Rahman schrieb:
> Deal All,
>
> I have set postgresql.conf for autovacuum and need to know weather the
> process is running/working or not.
Hi Abdul,
1. you could check the log file
2. select setting from pg_settings where name = 'autovacuum'
On 21/01/2009 14:57, Raymond O'Donnell wrote:
> On 21/01/2009 07:47, Abdul Rahman wrote:
>
>> I have set postgresql.conf for autovacuum and need to know weather
>> the process is running/working or not.
>
> ps ax | grep postgres
Also, in psql:
postgres=# show autovacuum;
autovacuum
---
On 21/01/2009 07:47, Abdul Rahman wrote:
> I have set postgresql.conf for autovacuum and need to know weather
> the process is running/working or not.
ps ax | grep postgres
Ray.
--
Raymond O'Donnell, Director of Music, Galway Cath
Deal All,
I have set postgresql.conf for autovacuum and need to know weather the process
is running/working or not.
Regards,
Avdul Rehman.
Tom Lane wrote:
> Anyway, it happens consistently on my HP box. I find that your proposed
> patch fixes it, but makes the "normal" path crash :-( --- the loop in
> do_autovacuum has to be executed in AutovacMemCxt, because it creates an
> Oid List that gets passed to vacuum() and had better not b
"Justin Pasher" writes:
>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> Anyway, it happens consistently on my HP box. I find that your proposed
>> patch fixes it, but makes the "normal" path crash :-( --- the loop in
>> do_autovacuum has to be executed in AutovacMemCxt, because it creates an
>>
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Saturday, January 17, 2009 9:50 AM
> To: Alvaro Herrera
> Cc: Justin Pasher; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Autovacuum daemon terminated by signal 11
>
> Alvaro Herr
Alvaro Herrera writes:
> Hmm, in retrospect this is pretty obviously buggy. I can't say that
> it's that easy for me to reproduce it though; I definitely can't make it
> crash. Maybe by sheer luck, the new TopTransactionContext pointer
> points to the same memory area that the old was stored in.
On Fri, Jan 16, 2009 at 05:13:17PM -0600, Justin Pasher wrote:
> Dang it. I wonder why the --enable-debug option doesn't seem to actually
> be enabling debug. :( For reference, here is the configure command that
> the package uses according to the config.log (in case you spot anything
> wrong).
Tom Lane wrote:
> What is happening is that autovacuum_do_vac_analyze contains
>
> old_cxt = MemoryContextSwitchTo(AutovacMemCxt);
> ...
> vacuum(vacstmt, relids);
> ...
> MemoryContextSwitchTo(old_cxt);
>
> and at the time it is called by process_whole_db, CurrentM
I wrote:
> ... and you've seemingly not managed to install the debug symbols where
> gdb can find them.
But never mind that --- it turns out to be trivial to reproduce the
crash. Just create a database, set its datfrozenxid and datvacuumxid
far in the past (via a manual update of pg_database), en
Tom Lane wrote:
#1 0xb7c37811 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7c38fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0x0828cdf3 in ExceptionalCondition ()
#4 0x082a8cd2 in MemoryContextAlloc ()
#5 0x082a8d67 in MemoryContextStrdup ()
#6 0x0829749c in database_getflat
Justin Pasher wrote:
> Dang it. I wonder why the --enable-debug option doesn't seem to actually
> be enabling debug. :( For reference, here is the configure command that
> the package uses according to the config.log (in case you spot anything
> wrong).
Maybe the executable is getting strip
Tom Lane wrote:
Justin Pasher writes:
I recompiled from the Debian source package and added --enable-cassert
(--enable-debug was already there). I replaced the Debian standard
packages with the recompiled versions and started up the cluster. Now it
is hitting a failure on one of the assert
Justin Pasher writes:
> I recompiled from the Debian source package and added --enable-cassert
> (--enable-debug was already there). I replaced the Debian standard
> packages with the recompiled versions and started up the cluster. Now it
> is hitting a failure on one of the assert lines, and t
Tom Lane wrote:
I read it like this:
#0 0x0827441d in MemoryContextAlloc () <-- real
#1 0x08274467 in MemoryContextStrdup ()<-- real
#2 0x0826501c in database_getflatfilename () <-- real
#3 0x0826504e in database_getflatfilename () <-- must be write_database_file
#4 0x08
Tom Lane wrote:
I read it like this:
#0 0x0827441d in MemoryContextAlloc () <-- real
#1 0x08274467 in MemoryContextStrdup ()<-- real
#2 0x0826501c in database_getflatfilename () <-- real
#3 0x0826504e in database_getflatfilename () <-- must be write_database_file
#4 0x08
Alvaro Herrera writes:
> Tom Lane wrote:
>> Hmm. This isn't very trustworthy for lack of debug symbols (what we're
>> probably looking at are the nearest global function names before the
>> actual locations).
> The lack of debug symbols makes this all mere guesses though. The
> backtrace did no
Tom Lane wrote:
> Hmm. This isn't very trustworthy for lack of debug symbols (what we're
> probably looking at are the nearest global function names before the
> actual locations). However, it strongly suggests that something is
> broken in the active memory context, and the most likely explanat
Justin Pasher writes:
> Program terminated with signal 11, Segmentation fault.
> #0 0x0827441d in MemoryContextAlloc ()
> (gdb) bt
> #0 0x0827441d in MemoryContextAlloc ()
> #1 0x08274467 in MemoryContextStrdup ()
> #2 0x0826501c in database_getflatfilename ()
> #3 0x0826504e in database_getf
Tom Lane wrote:
Having debug symbols would be more useful, but unless the binary is
totally stripped, a backtrace might provide enough info without that.
Try it and see if you get any function names in the trace, or only
numbers.
(BTW, does Debian have anything comparable to Red Hat's debuginfo
Justin Pasher writes:
> I'll let you know when I get a chance to get a core dump from the
> process. I assume I will need a version of Postgres built with debug
> symbols for it to be useful? I'm not seeing one in the standard Debian
> repositories, so I might have to compile from source.
Havi
Tom Lane wrote:
Justin Pasher writes:
Richard Huxton wrote:
Segmentation fault - probably a bug or bad RAM.
It's a relatively new machine, but that's obviously a possibility with
any hardware. I haven't seen any other programs experiencing problems on
the box, but the Postgres
Justin Pasher writes:
> Richard Huxton wrote:
>> Segmentation fault - probably a bug or bad RAM.
> It's a relatively new machine, but that's obviously a possibility with
> any hardware. I haven't seen any other programs experiencing problems on
> the box, but the Postgres daemon is the one that
Richard Huxton wrote:
Justin Pasher wrote:
Hello,
I have a server running PostgreSQL 8.1.15-0etch1 (Debian etch) that was
recently put into production. Last week a developer started having a problem
with his psql connection being terminated every couple of minutes when he
was running a query
>> Justin Pasher wrote:
> Are there any internal Postgres tables I can look at that may shed some
> light on this? Any particular maintenance commands that could be run for
> repair?
Please obtain a backtrace from the core file. If there's no core file,
please set "ulimit -c unlimited" in th
Justin Pasher wrote:
> Hello,
>
> I have a server running PostgreSQL 8.1.15-0etch1 (Debian etch) that was
> recently put into production. Last week a developer started having a problem
> with his psql connection being terminated every couple of minutes when he
> was running a query. When I look th
Hello,
I have a server running PostgreSQL 8.1.15-0etch1 (Debian etch) that was
recently put into production. Last week a developer started having a problem
with his psql connection being terminated every couple of minutes when he
was running a query. When I look through the logs, I noticed this me
In an interesting epilogue to this thread, I just encountered
something unusual.
Since having disabled autovacuum in the cluster in which it was
preventing dropdb from working (because autovacuum the autovacuum
daemon was behaving as a user accessing the database), dropdb has
been working
Tom Lane wrote:
> "Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
>> On Mar 11, 2006, at 4:13 PM, Tom Lane wrote:
>>> For a "real" solution, perhaps DROP DATABASE could somehow look to
>>> determine if there's an autovac daemon active in the target database,
>>> and if so send it a SIGINT and wai
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> On Mar 11, 2006, at 4:13 PM, Tom Lane wrote:
>> For a "real" solution, perhaps DROP DATABASE could somehow look to
>> determine if there's an autovac daemon active in the target database,
>> and if so send it a SIGINT and wait for it to go away.
On Mar 11, 2006, at 4:13 PM, Tom Lane wrote:
For a "real" solution, perhaps DROP DATABASE could somehow look to
determine if there's an autovac daemon active in the target database,
and if so send it a SIGINT and wait for it to go away.
In general, it also seems like a --force option or somet
"Matthew T. O'Connor" writes:
> I suppose you could instead:
> connect to local postmaster
> disable autovacuum
> pg_dump remotedb
> dropdb localdb
> pg_restore remotedb.pgd
> enable autovacuum
For a "real" solution, perhaps DROP DATABASE could somehow look to
determine if there's an autovac dae
On Mar 11, 2006, at 2:44 PM, Matthew T. O'Connor wrote:
Thomas F. O'Connell wrote:
I administer a network where a postgres database on one machine is
nightly dumped to another machine where it is restored (for
verification purposes) once the dump completes. The process is
roughly:
pg_dum
Thomas F. O'Connell wrote:
I administer a network where a postgres database on one machine is
nightly dumped to another machine where it is restored (for verification
purposes) once the dump completes. The process is roughly:
pg_dump remotedb
dropdb localdb
pg_restore remotedb.pgd
We recently
I administer a network where a postgres database on one machine is
nightly dumped to another machine where it is restored (for
verification purposes) once the dump completes. The process is roughly:
pg_dump remotedb
dropdb localdb
pg_restore remotedb.pgd
We recently upgraded the system to 8.
53 matches
Mail list logo
