Skip site navigation (1) Skip section navigation (2)

Re: Interface for pg_autovacuum

From: Russell Smith <mr-russ(at)pws(dot)com(dot)au>
To: Jim Nasby <jim(dot)nasby(at)enterprisedb(dot)com>
Cc: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Interface for pg_autovacuum
Date: 2006-12-21 00:27:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jim Nasby wrote:
> On Dec 20, 2006, at 7:56 AM, Florian G. Pflug wrote:
>> Jim Nasby wrote:
>>> I'm teaching a class this week and a student asked me about OIDs. He 
>>> related the story of how in Sybase, if you moved a database from one 
>>> server from another, permissions got all screwed up because user IDs 
>>> no longer matched. I explained that exposing something like an 
>>> integer ID in a user interface or an API is just a bad idea and 
>>> PostgreSQL doesn't do that.
>>> Then I got to pg_autovacuum....
>>> So... is there any reason there isn't a prescribed interface to 
>>> pg_autovacuum that doesn't expose vacrelid? Can we get that added to 
>>> TODO?
>> Wouldn't it be sufficient to change the type of vacrelid from oid
>> to regclass? Then just dumping and restoring pg_autovacuum like any
>> other table should Just Work.
> I think that would work, though as I mentioned we'd also want to set 
> reasonable defaults on the table if we decide to keep that as our 
> interface.
> On the other hand, this would be the only part of the system where the 
> official interface/API is a system catalog table. Do we really want to 
> expose the internal representation of something as our API? That 
> doesn't seem wise to me...
> Additionally, AFAIK it is not safe to go poking data into catalogs 
> willy-nilly. Having one table where this is the interface to the 
> system seems like it could lead to some dangerous confusion.
I thought the plan was to change the ALTER TABLE command to allow vacuum 
settings to be set.  I may be totally away from the mark.  But if this 
was the case it would mean that dumps would just need an alter table 
statement to maintain autovacuum information.  There is an advantage 
that if you only dump some tables, their autovac settings would go with 
them. But is that a good thing?


Russell Smith
> -- 
> Jim Nasby                               jim(dot)nasby(at)enterprisedb(dot)com
> EnterpriseDB      512.569.9461 (cell)
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

In response to


pgsql-hackers by date

Next:From: Takayuki TsunakawaDate: 2006-12-21 00:52:38
Subject: Re: Load distributed checkpoint
Previous:From: Russell SmithDate: 2006-12-21 00:00:38
Subject: Re: Autovacuum Improvements

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group