Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Note that it doesn't matter that it doesn't show up in the pg_stat
views, because we don't use those; rather we access the hash tables
directly.
Ah, but this is only true in the integrated version no? The contrib
version sure
Tom Lane wrote:
I'm having some second thoughts about allowing VACUUM on a toast table
independently of its parent table --- it's a bit scary to be messing
with the toast table when we have no lock at all on the parent. It
might work OK, but I'm not sure I want to take the risk. If we simply
e
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Hmm. With integrated autovacuum, we could set something up to issue
vacuums separately to TOAST tables and the main table. It'd probably be
a tad easier if the toast stats are separate from the main table; and an
autovac of the main table not necessar
Tom Lane wrote:
"Matthew T. O'Connor" writes:
Shouldn't the update to the toast table just be considered an update to
table t1? The fact that there is an underlying toast table is an
implementation detail that I don't think should show up in the stats system.
Tom Lane wrote:
I think Mark is probably on to something. The activity in the toast
table will show as deletes *in the toast table* ... and that activity
fails to show at all in the pg_stat_activity view, because it shows
only plain relations! So unless autovacuum is ignoring the stats views
a
mark reid wrote:
I've been using pg_autovacuum for a while, and for the most part it's
been great. There's one case in my system where it won't run on a
particular type of table, even though the table apparently needs it.
I have a table called "properties" that has key->value pairs. Usually
Karl Denninger wrote:
I have a process which does backups by mounting a disk into a RAID array,
allowing it to sync, then it must stop the database before detaching it so
as to insure that the DBMS is consistent on the backup disk.
Once detached, Postgres must be restarted, of course..
This pro
Why would you run pg_autovacuum from cron?
Karl Denninger wrote:
Hi folks.
There's a problem in the console detach code for pg_autovacuum.
"setsid()" is NOT sufficient. Specifically, you must disassociate the
control terminal (standard in, out and error) for it to be complete.
This causes any atte
I believe that pg_autovacuum will work with a .pgpass file just like any
libpq based application.
Olivier Thauvin wrote:
The following bug has been logged online:
Bug reference: 1567
Logged by: Olivier Thauvin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating
Tom Lane wrote:
John R Pierce <[EMAIL PROTECTED]> writes:
more fun. I just checked the environment of the postmaster service on a
win2000 Pro system (using www.sysinternals.com's excellent Process Explorer
tool, btw). HOME is not set. USERPROFILE is set to "C:\Documents and
Settings\postg
Tom Lane wrote:
OK ... are you supposed to find it out by looking at the environment
vars, or is there another API defined?
I am planning to consolidate the platform dependency into a function
defined like
static bool pqGetHomeDirectory(char *buf, int bufsize)
{
-- O
Tom Lane wrote:
I wrote:
win32 hackers, anyone know why it's like this?
Looking through the code, it seems that it's because someone thought
that breaking SSL would be easier than replacing the pqGetpwuid() calls
that are used to find out the user's home directory.
Does Windows even have a
Just a quick guess, the user account that you are logged in as while
attempting to install the service, is it an admin account that has the
required privileges?
Steve McWilliams wrote:
I am unable to run pg_autovacuum as a windows service. I am using
8.0.0beta4 on Windows XP Pro. When I execut
Just a quick guess, the user account that you are logged in as while
attempting to install the service, is it an admin account that has the
required privileges?
Steve McWilliams wrote:
I am unable to run pg_autovacuum as a windows service. I am using
8.0.0beta4 on Windows XP Pro. When I execut
This is a known bug, and if fixed in CVS. It will be released as part
of 7.4.3, or just download pg_autovacuum.c and pg_autovacuum.h from cvs
and compile a new executable.
Matthew O'Connor
Jim C. Nasby wrote:
There's a bug in pg_autovacuum that makes it vacuum large tables way to
frequently.
og
Bruno Wolff III wrote:
On Thu, Mar 25, 2004 at 16:08:49 +0100,
Martin Pitt <[EMAIL PROTECTED]> wrote:
A while ago we received the bug report below against pg_autovacuum.
Since it runs as a daemon, it should detach from its controlling
terminal by executing sth like
int nullfd = open("/d
16 matches
Mail list logo
