I'm thinking about attacking pg_dump's lack of knowledge about using
dependencies to determine a safe dump order. But if there's someone
out there actively working on the problem, I don't want to tread on
your toes ... anyone?
I've done a whole lot of _thinking_, but basically no _doing_, so go
r
Tom Lane <[EMAIL PROTECTED]> writes:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > BTW, do we have any provisions to avoid overlapping vacuums? That is, to
> > prevent a second vacuum on a table if an earlier one is still running?
>
> Yes, VACUUM takes a lock that prevents another VACUUM on the
Josh Berkus <[EMAIL PROTECTED]> writes:
> BTW, do we have any provisions to avoid overlapping vacuums? That is, to
> prevent a second vacuum on a table if an earlier one is still running?
Yes, VACUUM takes a lock that prevents another VACUUM on the same table.
regards, t
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> When you get around to it, can you commit the patch I submitted that
> dumps conversions in pg_dump. I need that in to complete my COMMENT ON
> patch.
Just for the record, this is committed as part of the COMMENT ON patch.
Josh Berkus wrote:
Matthew,
I certainly agree that less than 10% would be excessive, I still feel
that 10% may not be high enough though. That's why I kinda liked the
sliding scale I mentioned earlier, because I agree that for very large
tables, something as low as 10% might be useful, but
I was at the ObjectWeb Conference today; ObjectWeb
(http://www.objectweb.org) being a consortium that has amassed quite an
impressive array of open-source, Java-based middleware under their
umbrella, including for instance our old friend Enhydra. And they
regularly kept mentioning PostgreSQL in th
Matthew,
> Basically, I don't like the idea of modifying users databases, besides,
> in the long run most of what needs to be tracked will be moved to the
> system catalogs. I kind of consider the pg_autvacuum database to
> equivalent to the changes that will need to be made to the system cata
Josh Berkus wrote:
Matthew,
I don't see how a seperate database is better than a table in the databases.,
except that it means scanning only one table and not one per database. For
one thing, making it a seperate database could make it hard to back up and
move your database+pg_avd config.
Matthew,
> Actually, this might be a necessary addition as pg_autovacuum currently
> suffers from the startup transients that the FSM used to suffer from,
> that is, it doesn't remember anything that happened the last time it
> ran. A pg_autovacuum database could also be used to store threshol
On Friday 21 November 2003 01:13 pm, Lamar Owen wrote:
> I have uploaded a first cut at the RPM's to ftp.postgresql.org. While I am
> not 100% convinced of the need to do so, I have restructured the
> directories, and await comment on that.
> I expect RH 7.3, RH9, and RH 6.2 packages shortly fro
Josh Berkus wrote:
Matthew,
But we could create a config file that would store stuff in a flatfile table,
OR we could add our own "system table" that would be created when one
"initializes" pg_avd.
I don't want to add tables to existing databases, as I consider that
clutter and I never li
Hello hackers
Sorry when I am talking to the gurus...
There is a database, which has a concept called "Transportable
Tablespace" (TTS). Would it not be a verry easy and fast solution to
just do this with the Tables, Index and all non catalog related files.
- You create a new db cluster (e.g 8.0
Tom Lane wrote:
I think the main value of a build farm is that we'd get nearly immediate
feedback about the majority of simple porting problems. Your previous
arguments that it wouldn't smoke everything out are certainly valid ---
but we wouldn't abandon the regression tests just because they don
Jan Wieck <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> One of the most complex would be to avoid the need of pg_dump for
>> upgrades ...
> We don't need a simple way, we need a way to create some sort of catalog
> diff and "a safe" way to apply that to an existing installation during
>
Tom Lane wrote:
If the ALTER is changing the column type, it's not really the same
column anymore;
This doesn't strike. "If the ALTER is changing the number of columns,
it's not really the same table anymore" is as true as your statement.
Still, pg_class.oid remains the same for ADD and DROP col
Andreas Pflug <[EMAIL PROTECTED]> writes:
> To put it differently: a ALTER COLUMN command may never-ever change the
> identifier of the column, i.e. attrelid/attnum.
If the ALTER is changing the column type, it's not really the same
column anymore; I see nothing wrong with assigning a new attnum
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Andrew Dunstan writes:
>> Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I
>> have an open mind about it. I don't think incompleteness is an argument
>> against it, though.
> If you want to do it, by all means go for it. I'm s
strk <[EMAIL PROTECTED]> writes:
> It seems that the build system is missing something
> (make distclean made it work)
If you aren't using configure --enable-depend, you should count on doing
at least "make clean", preferably "make distclean" anytime you do a CVS
update. The default behavior is n
Alvaro Herrera wrote:
On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote:
>Yeah, I think the main issue in all this is that for real production
>sites, upgrading Postgres across major releases is *painful*. We have
>to find a solution to that before it makes sense to speed up
I have uploaded a first cut at the RPM's to ftp.postgresql.org. While I am
not 100% convinced of the need to do so, I have restructured the directories,
and await comment on that.
Currently the upload is for Fedora Core 1 only. The source RPM should compile
on most recent Red Hat's and close
Hello:
Are you using the extended query protocol? If so you probably have
forgotten the need for a Sync message.
You are right, thanks very much, it's working well now.
--
Best regards
Carlos Guzmán Álvarez
Vigo-España
---(end of broadcast)--
Max Jacob <[EMAIL PROTECTED]> writes:
> I'm trying to call plpgsql functions from c functions directly through
> the Oid, but i have a problem: it seems that the plpgsql interpreter
> calls SPI_connect and fails even if the caller has already
> spi-connected.
This is a safety check. If you are
On Thu, 2003-11-20 at 22:20, Tom Lane wrote:
> It should be noted that "because Oracle does it that way" is a
> guaranteed nonstarter as a rationale for any Postgres feature proposal.
A method of doing something is not a "feature"; making something
possible that couldn't be done before is a "feat
On Fri, Nov 21, 2003 at 02:49:28AM -0500, Tom Lane wrote:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
> > It's still logging the "recycled transation log file". Is that
> > send to stdout instead of stderr maybe?
>
> No, it all goes to stderr. But that output comes from a different
> subprocess.
Matthew,
> As long as pg_autovacuum remains a contrib module, I don't think any
> changes to the system catelogs will be make. If pg_autovacuum is
> deemed ready to move out of contrib, then we can talk about the above.
But we could create a config file that would store stuff in a flatfile tabl
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Maybe my proposal wasn't clear enough:
Just as an index references a pg_class entry by it's OID, not some value
identifying it's physical storage, all objects might continue
referencing columns by attnum.
That's exactly the same t
I'm thinking about attacking pg_dump's lack of knowledge about using
dependencies to determine a safe dump order. But if there's someone
out there actively working on the problem, I don't want to tread on
your toes ... anyone?
Also, if you've got uncommitted patches for pg_dump, please let me kno
=?ISO-8859-1?Q?Carlos_Guzm=E1n_=C1lvarez?= <[EMAIL PROTECTED]> writes:
> After send the rollbact transaction command i'm not receiving any
> response from the server, instead, if the SQL command is a valid SQL
> command all runs fine, any idea about what can be the problem ??
Are you using the e
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Maybe my proposal wasn't clear enough:
> Just as an index references a pg_class entry by it's OID, not some value
> identifying it's physical storage, all objects might continue
> referencing columns by attnum.
That's exactly the same thing I am saying
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
I don't quite understand your argumentation.
My point is that to change attnum into a logical position without
breaking client apps (which is the ostensible reason for doing it
that way), we would need to redefine all system catalog
Hello:
I'm having a little problem with my .net data provider for postgresql 7.4.
I'm executing a little sample that does:
1. Connect to the server.
2. Start transaction.
3. Execution of an invalid SQL command.
4. Catch exception and rollback transaction.
After send the rollbact transaction comm
Shridhar Daithankar wrote:
Matthew T. O'Connor wrote:
But we track tuples because we can compare against the count given by
the stats system. I don't know of a way (other than looking at the
FSM, or contrib/pgstattuple ) to see how many dead pages exist.
I think making pg_autovacuum dependent
Andreas Pflug <[EMAIL PROTECTED]> writes:
> I don't quite understand your argumentation.
My point is that to change attnum into a logical position without
breaking client apps (which is the ostensible reason for doing it
that way), we would need to redefine all system catalog entries that
referenc
Matthew T. O'Connor wrote:
But we track tuples because we can compare against the count given by
the stats system. I don't know of a way (other than looking at the FSM,
or contrib/pgstattuple ) to see how many dead pages exist.
I think making pg_autovacuum dependent of pgstattuple is very good
Josh Berkus wrote:
Matthew,
True, but I think it would be one hour once, rather than 30 minutes 4
times.
Well, generally it would be about 6-8 times at 2-4 minutes each.
Are you saying that you can vacuum a 1 million row table in 2-4
minutes? While a vacuum of the same table with an a
Robert Treat wrote:
Just thinking out loud here, so disregard if you think its chaff but...
if we had a system table pg_avd_defaults
[snip]
As long as pg_autovacuum remains a contrib module, I don't think any
changes to the system catelogs will be make. If pg_autovacuum is
deemed ready to m
On Thu, 2003-11-20 at 23:27, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Actually, I deliberately chose attpos rather than attlognum (which is
> > what some people had been calling this feature earlier). My reasoning
> > was that the "logical number" is really a nonsensical idea:
On Thu, 2003-11-20 at 19:40, Matthew T. O'Connor wrote:
> I'm open to discussion on changing the defaults. Perhaps what it would
> be better to use some non-linear (perhaps logorithmic) scaling factor.
> So that you wound up with something roughly like this:
>
> #tuples activity% for vacuum
On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote:
> >Yeah, I think the main issue in all this is that for real production
> >sites, upgrading Postgres across major releases is *painful*. We have
> >to find a solution to that before it makes sense to speed up the
> >major-rel
Tom Lane wrote:
It's completely fallacious to imagine that we could make this change be
transparent to external applications. To take two examples:
1. How many places do you think know that pg_attribute.attnum links to
pg_attrdef.adnum? pg_dump, psql, and the JDBC driver all appear to
know that,
On Fri, 21 Nov 2003, Andreas Joseph Krogh wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Friday 21 November 2003 09:42, Oleg Bartunov wrote:
> > On Fri, 21 Nov 2003, Teodor Sigaev wrote:
> > > No problem, dictionary with support of compounds will be avaliable as
> > > separate con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 21 November 2003 09:42, Oleg Bartunov wrote:
> On Fri, 21 Nov 2003, Teodor Sigaev wrote:
> > No problem, dictionary with support of compounds will be avaliable as
> > separate contrib module from our site till 7.5.
>
> Hmm, I think better not
On Fri, 21 Nov 2003, Teodor Sigaev wrote:
> No problem, dictionary with support of compounds will be avaliable as separate
> contrib module from our site till 7.5.
Hmm, I think better not to introduce another dictionary, which require
additional efforts to configure tsearch2, but maintain whole m
No problem, dictionary with support of compounds will be avaliable as separate
contrib module from our site till 7.5.
Hannu Krosing wrote:
Tom Lane kirjutas N, 20.11.2003 kell 17:18:
Oleg Bartunov <[EMAIL PROTECTED]> writes:
we have a patch for contrib/tsearch2 we'd like to commit for 7.4.1.
Is
Neil Conway <[EMAIL PROTECTED]> writes:
> Under what circumstances do we "convert a relation to a view"? Is this
> functionality exposed to the user?
This is a backwards-compatibility hangover. pg_dump scripts from
somewhere back in the Dark Ages (6.something) would represent a view
as
CR
Kurt Roeckx <[EMAIL PROTECTED]> writes:
> It's still logging the "recycled transation log file". Is that
> send to stdout instead of stderr maybe?
No, it all goes to stderr. But that output comes from a different
subprocess. Not sure why that subprocess would still have working
stderr if others
On Thu, Nov 20, 2003 at 04:08:28PM -0500, Tom Lane wrote:
> Kurt Roeckx <[EMAIL PROTECTED]> writes:
> > I just installed a 7.4 on windows/cygwin. I restored a dump but
> > ran out of disk space during the creating of an index. In psql I
> > saw the "ERROR: could not extend relation ".
> > Fro
strk <[EMAIL PROTECTED]> writes:
> Does with(isStrict) still work ?
regression=# create function foo(int) returns int as
regression-# 'select $1' language sql with(isStrict);
CREATE FUNCTION
regression=# select version();
version
-
48 matches
Mail list logo
