Apologies resending to the list as used wrong account...
Was this expected behaviour with temporary tables?
It's more expected behavior when you have long running transactions.
I haven't seen it caused by temp tables. Was the parent process in a
really long transaction or just open a long ti
"John Lister" writes:
On another bizarre note, A database wide vacuum has just finished, but
I'm
still getting the warnings:
GMT WARNING: database "backend" must be vacuumed within 10205310
transactions
Did you do that vacuum as a superuser?
Thanks for your help, but
On 21/01/2011 23:40, Tom Lane wrote:
"John Lister" writes:
On another bizarre note, A database wide vacuum has just finished, but I'm
still getting the warnings:
GMT WARNING: database "backend" must be vacuumed within 10205310
transactions
Did you do that vacuum a
"John Lister" writes:
On another bizarre note, A database wide vacuum has just finished, but
I'm
still getting the warnings:
GMT WARNING: database "backend" must be vacuumed within 10205310
transactions
Did you do that vacuum as a superuser?
yes
John
Hi, I'm running 8.3.9 on ubuntu with autovacuum enabled and seemingly
working properly., however I've started getting messages saying that I'm
near the transaction limit and I need to do a database wide vacuum, which
I've started.
From reading the docs, though I thought that autovacuum would do
Hi, I'm running 8.3.9 on ubuntu with autovacuum enabled and seemingly working
properly., however I've started getting messages saying that I'm near the
transaction limit and I need to do a database wide vacuum, which I've started.
>From reading the docs, though I thought that autovacuum would d
t off to shoot the developer in the leg as we speak..
John
- Original Message -
From: "robin"
To: "John Lister"
Cc:
Sent: Wednesday, March 31, 2010 8:00 AM
Subject: Re: [ADMIN] Strange deletion problem
You could create a statement level delete trigger on the rele
2010/3/30 John Lister
Hi, I have a table which is constantly updated through out the day with no
problems, I'm running Postgresql 8.3.8 in ubuntu karmic. However, within the
last week for some reason overnight it is being emptied and I can't work out
why
Hi, I have a table which is constantly updated through out the day with no
problems, I'm running Postgresql 8.3.8 in ubuntu karmic. However, within the
last week for some reason overnight it is being emptied and I can't work out
why. I've set log_min_duration_statement to 0 so that postgresql du
Hi, I've successfully set up a slave system using WAL archiving and pg_standby,
but I have a couple of questions.
I have a couple of questions:
Is it possible to stop the database server (for maintenance for example) and
resume the recovery without starting afresh and making a complete backup o
"Kevin Grittner" wrote:
When we first started using PostgreSQL we initially had problems
with bloat and the autovacuum process started creating significant
load. Our first reaction was to make autovacuum less aggressive,
but this just made things worse. The counter-intuitive step of
making aut
"Kevin Grittner" wrote:
"John Lister" wrote:
I'm using 8.3.8
That's recent. :-)
Thanks for the reply, wasn't sure if 8.4 had fixed anything :)
If you have index bloat you either have some
process has held open a database transaction for a very
"Kevin Grittner" kevin.gritt...@wicourts.gov wrote
>"John Lister" wrote:
> When you do a vacuum it marks the deleted rows as being usable
> again and I can see that it reports that "xxx index row versions
> were removed", however are these rows marked
Hi, excuse my ignorance, but I have a couple of quick questions regarding
vacuuming and indexes.
When you do a vacuum it marks the deleted rows as being usable again and I
can see that it reports that "xxx index row versions were removed", however
are these rows marked for reuse in an index in
John Lister wrote:
Hi, I've set up a warm standby box with postgresql 8.3.8 and
pg_standby. Everything seems to be ok except and the wal files are
being copied across and being processed during the recovery as you'd
expect but I have one question. The recovery seems to be processing
Hi, I've set up a warm standby box with postgresql 8.3.8 and pg_standby.
Everything seems to be ok, the wal files are being copied across and being
processed during the recovery as you'd expect but I have one question. The
recovery seems to be processing the final wal files at the same rate as t
Hi, I've set up a warm standby box with postgresql 8.3.8 and pg_standby.
Everything seems to be ok except and the wal files are being copied
across and being processed during the recovery as you'd expect but I
have one question. The recovery seems to be processing the final wal
files (about 30)
Have you got any copies of psql or tools like pgadmin open. I've been
caught out by this. try
select * from pg_stat_activity
it should tell you what connections are open on the table (look at the
datname column)
Carol Walter wrote:
This has happened or is happening to me again, only this ti
VACUUM FULL VERBOSE ANALYZE pg_class
2009-02-12 21:06:40 GMT WARNING: index "pg_class_relname_nsp_index"
contains 1818 row versions, but table contains 1813 row versions
If that helps...
Thanks
John Lister writes:
I seem to have more dead rows now..
doing a vacuum full on pg
I seem to have more dead rows now..
doing a vacuum full on pg_class gives me
INFO: vacuuming "pg_catalog.pg_class"INFO: "pg_class": found 37
removable, 1845 nonremovable row versions in 18905 pages
DETAIL: 27 dead row versions cannot be removed yet.
Nonremovable row versions range from 160
jesh Kumar Mallah"
To: "Tom Lane"
Cc: "John Lister" ;
Sent: Wednesday, February 11, 2009 3:37 PM
Subject: Re: [ADMIN] controlling autovacuum during the day.
On Wed, Dec 17, 2008 at 7:17 PM, Tom Lane wrote:
"John Lister" writes:
I'd like to use autova
Sorry, had exported it - bad cut/pasting...
I even tried it in single-user mode passing -P directly but got the same
result
Also confused/concerned by the 7 dead rows in pg_class. as i've
restarted the server all transaction should have finished so i'd like to
reclaim these - especially as vacu
>Yeah, if you have reason not to trust the system indexes then -P is
>a good idea until they are fixed. Standalone mode per se isn't that
>important --- you could do this from a regular session with -P specified
>via PGOPTIONS.
still getting the same problem.
> PGOPTIONS="-P"
> psql backend
>>
Cheers tom, that did it - i've removed the duplicates and seeing what else
is broken.
.
"John Lister" writes:
ERROR: could not create unique index "pg_class_oid_index"
a quick inspection of the pg_class table doesn't show any duplicates, is
there anyway i
Hi, my wal archiving broke and postgresql filled up the local disk with
transaction logs, which i foolishly deleted in a moment of madness, after
resetting the transaction log a few of my tables are damaged but repairable.
However the system tables also seemed to have suffered. My main problem i
check a warning/error is harmless and filter it out rather than fix
it and i don't have a lot of time left in the day for fixing messages i can
live with :(
On Sat, Dec 20, 2008 at 12:26 AM, John Lister
mailto:john.lister...@kickstone.com>>
wrote:
The pg_maintenance scripts che
Looks like /etc/cron.d/postgresql-common
# Run VACUUM ANALYSE on all databases every 5 hours if pg_autovacuum is not
# running
2 0,5,10,15,20 * * 1-6 root if [ -x /usr/sbin/pg_maintenance ]; then
/usr/sbin/pg_maintenance --analyze >/dev/null; fi
Is deprecated for postgresql versions 8.1 and highe
John Lister wrote:
bizarre... Its been turned off for a while, but from memory the
autovacuum process was causing the table it was running on to be locked
- I assumed this was an equivalent to VACUUM FULL - causing all other
connections to wait until it had finished. Could this happen another
"John Lister" writes:
Cheers for the quick reply. I've tweaked them quite a bit, but we have
quite
a few heavily updated tables that i'd like vacuuming to keep them in
check.
Unfortunately the autovacuum does a FULL vacuum every so often locking
the
tables for quite a
"John Lister" writes:
I'd like to use autovacuum to clean up the tables rather than schedule a
full vacuum with cron as it will be more selective/intelligent about what
gets cleaned. But is it possible to stop it running during peak/office
hours?
No. Instead, set the vacuum
I'd like to use autovacuum to clean up the tables rather than schedule a
full vacuum with cron as it will be more selective/intelligent about what
gets cleaned. But is it possible to stop it running during peak/office
hours?
I've seen a post mention using pg_autovacuum.enabled to do this, but
31 matches
Mail list logo
