I have a (hopefully simple) question regarding locale.
I am migrating a postgresql database from a server running FC1 &
PostgreSQL 7.4 to a newer machine running FC2 and PostgreSQL 8.0. I
dumped the data from the old server using pg_dumpall and restored it to
the new server with no problems, an
If you could connect to the database server from the web server and get
data with PGAdmin then it doesn't' sound like a database or database
server problem. How is your web app connecting to the database? ODBC?
That might be a bit of an issue. PgAdmin doesn't use ODBC, it uses
libpq directl
Enzo D'addario wrote:
Hi All,
I currently have postgres 7.4.2 running on a dedicated server which has
1GB RAM, a Pentium 4 2600 Mhz processor, uses ReiserFS filesystem and is
running Debian stable.
After approximately 1 month I have to dump & restore the database
because vacuum time spirals ou
Joe Maldonado wrote:
I have not seen any information so far on this but is there a way to
get the autovacuum daemon in PostgreSQL 8.1 to log the tables which it
is perfoming vacuum or analyze operation on?
I think the autovacuum daemon does log it's activity however all it's
output is set at
Tom Lane wrote:
This would be a pretty bad idea IMHO, since it would lead to bloating
the logs with autovacuum progress messages by default --- and whatever
you may think about it, I really doubt that the average DBA will want
those messages there all the time.
I wonder whether it would be pract
Scott Marlowe wrote:
I would appreciate an easy way to keep tabs on autovacuum's activity.
A stat table seems like a practical way to have this info readily
available.
No need to keep values across dump/reloads, right?
This sounds more and more like a good idea. I don't think there's a
Scott Marlowe wrote:
On Thu, 2005-11-10 at 09:56, Matthew T. O'Connor wrote:
Scott Marlowe wrote:
I would appreciate an easy way to keep tabs on autovacuum's activity.
A stat table seems like a practical way to have this info readily
available.
No need to keep values a
Jeff Bohmer wrote:
I assumed (perhaps incorrectly) that you were talking about
maintaining the data in the theoretical / not yet in existence
autovacuum stats table through database restart, the stats system
already has a GUC var that dictates whether or not it dumps it's data
upon DB restart
I don't have any RHES 4.0 boxen, but I do have a CentOS 4.1 box. You
can get RPMS for the new version of PostgreSQL, you will probably want
to install a compat rpm that has the libraries that the other software
on the system requires. I forget where I downloaded mine from, but
someone on one
Unfortunately, you are correct, there is no way to tell
contrib/autovacuum to rotate it's logs.
Ameet Kini wrote:
Hello,
I'm using postgresql 8.0 and am using contrib/pg_autovacuum. Is there a
way to tell pg_autovacuum to rotate the log that it generates after
it reaches a particular size? Fro
As Alvaro already mentioned this is fixed in 8.1 because it was
integrated into the backend and benifits from the logging features that
backend already has developed.
As for the 7.4.x & 8.0.x versions of contrib autovacuum, I don't think
there are any plans for improving it. Also, added it to
Legit concern. However one of the things that autovacuum is supposed to
do is not vacuum tables that don't need it. This can result in an overal
reduction in vacuum overhead. In addition, if you see that autovacuum is
firing off vacuum commands during the day and they are impacting your
response
Alvaro Herrera wrote:
Chris Browne wrote:
It strikes me as a slick idea for autovacuum to take on that
behaviour. If the daily backup runs for 2h, then it is quite futile
to bother vacuuming a table multiple times during that 2h period when
none of the tuples obsoleted during the 2h period wil
Jim C. Nasby wrote:
Small tables are most likely to have either very few updates (ie: a
'lookup table') or very frequent updates (ie: a table implementing a
queue). In the former, even with vacuum_threshold = 0 vacuum will be a
very rare occurance. In the later case, a high threshold is likely to
Alvaro Herrera wrote:
Jim C. Nasby wrote:
On Wed, Mar 29, 2006 at 03:36:36PM +0530, Gourish Singbal wrote:
we are using postgresql 8.1.3 and wanted to enable autovacuuming for only
one of the many databases on the same postgresql cluster.
pg_autovacuum seems to allow to ignore only a particular
I think the closest approximation of disabling autovacuum on a per
database basis is to connect to the database in question and perform:
update pg_autovacuum set enabled = 'false';
This will prevent autovacuum from vacuuming or analyzing any of the
tables in the database, but will still chec
Alvaro Herrera wrote:
Tom Lane wrote:
Hm. I believe that autovac only does database-wide vacuums when it
thinks they're necessary to prevent transaction wraparound failures.
Which would mean that it'd let pg_clog grow to something on the order
of half a gig before any truncation would happen.
Eamonn Kent wrote:
I am using PostgreSQL 8.1.4 for an embedded application. For some
reason, vacuum is not able to identify rows that are candidates for
removal (i.e., mark space as available).
[snip]
If I shutdown our application and run a vacuum full, the space is
recovered and the databa
Arnau wrote:
I'm migrating our DDBB from postgresql 7.4 to postgresql 8.1. In
postgreql 7.4 we don't have autovaccum running. So, every night before
doing the daily backup we do a "vaccuumdb -f -z" for each DB. My doubt
is, the autovaccuum with the version 8.1 is started by default and I
don'
Sriram Dandapani wrote:
Hi
Is it possible to tell autovacuum to ignore certain tables (These
tables are high traffic daily partition tables that get dropped every
other day).
I am trying to get autovacuum to complete quicker and prevent Xactn
wraparound (currently, it takes very long
Csaba Nagy wrote:
On Wed, 2006-09-27 at 18:08, Edoardo Ceccarelli wrote:
How can I configure the vacuum to run after the daily batch insert/update?
Check out this:
http://www.postgresql.org/docs/8.1/static/catalog-pg-autovacuum.html
By inserting the right row you can disable autovacuu
Sriram Dandapani wrote:
>
> If I were to specify in the pg_autovacuum catalog that certain high
> volume partitioned tables(that get dropped daily) be ignored, then
> when autovacuum finishes, will it update the transaction id wraparound
> counter (this way, I can get autovacuum to finish quickly )
Sriram Dandapani wrote:
The only issue I have with autovacuum is the fact that I have to briefly
stop/restart postgres every couple of days, which kills autovacuum and
it has no memory of previous work done. I work with several databases
with partitioned tables having high daily volume. Dropping
Tobias Brox wrote:
[Matthew T. O'Connor - Wed at 02:33:10PM -0400]
In addition autovacuum respects the work of manual or cron based
vacuums, so if you issue a vacuum right after a daily batch insert /
update, autovacuum won't repeat the work of that manual vacuum.
I was exp
Sudhakar Kurumella wrote:
We have to move from Linux based PostgreSQL to Windows based
PostgreSQL. Highly appreciated for Any ideas of smooth export/import
options.
You do know that the native windows version of PostgreSQL is still only
in Beta. The cygwin port has never really been considered
pg_autovacuum should work against Postgresql 7.3.x. I don't know if
compiling it from source, or using a 7.4 rpm will be easier
Theo Galanakis wrote:
Hi,
We are currently running an older version of postgres on linux
redhat, the auto_vacuum is not part of the contrib package for 7.3
Steve Crawford wrote:
On Thursday 17 March 2005 3:15 pm, Steve Crawford wrote:
I'm having trouble with physical growth of postgresql system
tables
Additional info. The most recent autovacuum entries for the
pg_attribute table are:
[2005...] Performing: VACUUM ANALYZE "pg_catalog"."pg
Tom Lane wrote:
Steve Crawford <[EMAIL PROTECTED]> writes:
pg_autovacuum is from 7.4.6 release and is showing periodic vacuums of
the problem tables. I thought that bug was in some release prior to
7.4.6. Does the bug allow it to show a vacuum taking place but not do
it?
I don't recall t
Steve Crawford wrote:
On Monday 21 March 2005 11:40 am, Tom Lane wrote:
"Matthew T. O'Connor" writes:
I believe this discrepancy has to do with the fact that ANALYZE
can return some very bogus values for reltuples, where as vacuum
always returns an accurate count. I&#x
Yes, because all these messages really mean is that autovacuum woke up,
and looked at database xx, it may or may not have decided to do anything
(analyze or vacuum) and judging by the fact that these messages are
almost exactly 1 minute apart, I would say that autovacuum never felt
the need to
Kieran Cooper, Lyris UK wrote:
We're managing a database on version 8.2.3 (running Lyris ListManager
email software). I ran a 'vacuum analyze full verbose' (we haven't been
able to get autovacuum to work properly on Lyris installs so we need to
run a full vacuum every week or so, and we'd been
Hello, I've been looking into having apache log to postgresql, and it
isn't clear to me what the best way to set this up is. The options that
I see so far are:
1) Apache Pipe Logging: This seems simple enough, but I'm not sure what
tool I would as the logging process?
2) pgLOGd: This isn't
Hello, I've been looking into having apache log to postgresql, and it
isn't clear to me what the best way to set this up is. The options
that I see so far are:
1) Apache Pipe Logging: This seems simple enough, but I'm not sure
what tool I would as the logging process?
2) pgLOGd: This isn
Chris Hoover wrote:
Another question.
When autovacuum sleeps, does it release the lock it has on the table?
What we would like to have happen is for vacuum to work for a while,
sleep, and while it is sleeping run an analyze on the table. We need
this due to how quickly our data is changing.
Alvaro Herrera wrote:
Matthew T. O'Connor escribió:
As Alvaro already said this is a case where autovacuum still isn't
great.
While I have your attention ;-) do you have any ideas on how to improve
this? I don't see anything that looks like a solution for this case.
Rafael Domiciano wrote:
I'm not using autovacuum. Regular vacuum goes ok.
To see the last 10 lines of verbose i will need to run vacuum tonight
If a run a reindex before the vacuum full, increase the "speed" of
doing vacuum? I found something about it googling.
It might help a bit, but by the
Michael Monnerie wrote:
Dear list, this is postgres 8.1, and I run a dbmail mailserver where we deleted
most e-mails.
I then did a VACUUM (see below), and just before the "dbmail_messages"
truncated rows
there was a very long time where obviously nothing happened. No CPU usage (<8%)
and
no dis
37 matches
Mail list logo
