Ühel kenal päeval, E, 2006-02-27 kell 15:05, kirjutas Tom Lane:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Mon, 27 Feb 2006, Tom Lane wrote:
This strikes me as a fairly bad idea, because it makes VACUUM dependent
on correct functioning of user-written code --- consider a functional
Ühel kenal päeval, T, 2006-02-28 kell 01:04, kirjutas Tom Lane:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Feb 27, 2006 at 03:05:41PM -0500, Tom Lane wrote:
Moreover, you haven't pointed to any strong reason to adopt this
methodology. It'd only be a win when vacuuming pretty small
Ühel kenal päeval, T, 2006-02-28 kell 10:04, kirjutas Hannu Krosing:
Ühel kenal päeval, E, 2006-02-27 kell 15:05, kirjutas Tom Lane:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Mon, 27 Feb 2006, Tom Lane wrote:
This strikes me as a fairly bad idea, because it makes VACUUM dependent
On Mon, 27 Feb 2006, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Mon, 27 Feb 2006, Tom Lane wrote:
This strikes me as a fairly bad idea, because it makes VACUUM dependent
on correct functioning of user-written code --- consider a functional
index involving a user-written
On 21 Feb 2006, at 10:42, Martijn van Oosterhout wrote:
On Tue, Feb 21, 2006 at 10:02:58AM +0100, Albe Laurenz wrote:
Thank you also for drawing my attention to pg_service.conf - I
have not
been aware of it.
There are two 'shortcomings':
- It still means that you have to change the config
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set, AND the
environment
PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
LDAP name resolution cuts in.
- Before
Mark Woodward wrote:
[TOMLANE]
DATADIR=/vol03/pg74
PORT=5433
POSTMASTER=/usr/local/pg7.4.1/bin/postmaster
Seems better to me to specify PREFIX (the --prefix arg to configure)
instead of POSTMASTER, because then you can search any needed executable
there (pg_config for example). Or maybe use
Albe Laurenz wrote:
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set,
A little off-topic, but related: PeterE recently complained about an
option in pgAdmin which is called service. Its
Hannu Krosing wrote:
In the big table with hotspots case, I doubt that the win from
btbulkdelete will outweight having to scan 10 index pages to get to
the 30 or 50 that can be bulkdeleted.
Remember that WAL traffic is fsync'ed, so it can be _much_ slower than
anything else.
--
Alvaro
On Tue, 2006-02-28 at 01:32 -0500, Tom Lane wrote:
Paul Tillotson [EMAIL PROTECTED] writes:
The topic of improving vacuum for use in heavy-update environments seems
to come up frequently on the list. Has anyone weighed the costs of
allowing VACUUM to reclaim tuples that are not older
Albe Laurenz wrote:
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set, AND the
environment
PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
LDAP name resolution cuts in.
On Tue, Feb 28, 2006 at 09:52:24AM +0200, Hannu Krosing wrote:
WHY does vacuum need to be a tranasction ? I thought it was a programmer
workload optimisation (aka. lazyness :) ) to require ordinary lazy
vacuum to be in transaction.
There is no fundamental reason, why vacuum needs to run in a
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Mark Woodward)
belched out:
Mark Woodward wrote:
Like I have repeated a number of times, sometimes, there is more than one
database cluster on a machine. The proposed pg_clusters.conf, could look
like this:
pg_clusters.conf
[GEO]
On Tue, Feb 28, 2006 at 02:45:25PM +0800, Christopher Kings-Lynne wrote:
I don't see any very nice solution at the moment. Once we get support
for per-column locales, it might be possible to declare that the shared
catalogs are always in UTF8 encoding and get the necessary
conversions to
we are using postgresql 7.3.2 version.
We are facing a problem in nextval of sequence. The
problem is as follows,
If the server
shuts down abrupotly because of power failuar or any othercause then the
sequences tend to skip few numbers.After restarting theserver the
nextval of sequence
Martijn van Oosterhout wrote:
This may be the only solution. Converting everything to UTF-8 has
issues because some encodings are not roundtrip-safe (Enc - UTF8 - Enc
gives you a different string than you started with). There's probably
no encoding round-trip safe with every other encoding.
On Feb 28, 2006, at 1:38 AM, Tom Lane wrote:
I could not find anything in the Frontend/Backend protocol docs
about
character encoding in the StartupMessage. Assuming it is legal for a
database or user name to have unicode characters, how is this
handled
when nothing yet has been said
Are you caching sequences?On 2/28/06, Suvarna [EMAIL PROTECTED] wrote:
we are using postgresql 7.3.2 version.
We are facing a problem in nextval of sequence. The
problem is as follows,
If the server
shuts down abrupotly because of power failuar or any othercause then the
sequences tend
Hannu Krosing [EMAIL PROTECTED] writes:
There is no fundamental reason, why vacuum needs to run in a transaction
itselt.
I'll just take one point: you cannot hold locks unless you have a
transaction, therefore you cannot even look up the catalog info about
the table you wish to vacuum; let
Hannu Krosing [EMAIL PROTECTED] writes:
Or do you man that an index entry pointing to a non-existing tuple is
corruption ? It would be realtively easy to teach index access method
to just ignore (or even delete) the dangling index entries.
No, I mean that an index entry pointing at a WRONG
I have added a configure option --with-openldap to enable the code.
Does that make sense to you?
Should I try to polish and test the code and submit it as a patch
I would still much prefer to see remote config fetching done in a more
general way, using say libcurl (which handles ldap just
Albe Laurenz [EMAIL PROTECTED] writes:
I am now in the process of writing a patch against CVS HEAD that
changes fe-connect.c as follows:
- If there is a 'service' option or PGSERVICE is set, AND the
environment
PGLDAPSERVERS is set to a comma separated list of LDAP server URIs,
LDAP
Just a wouldn't it be nice if sort of feature request. I'm not sure
how practical it is.
Someone in our organization wrote a data fix query, which has sort of
odd logic, but it does what they need. The problem is that it ran for
14 hours in a test against a copy of the data. I looked at it and
Martijn van Oosterhout kleptog@svana.org writes:
However, my personal preference is to treat the name of the database as
a bunch of bits ie, don't consider it encoded at all.
That's essentially what we are doing as far as the StartupMessage is
concerned. Doesn't really solve the problem of
Uh, why is it a good idea to overload the service option like that?
ISTM it'd be less confusing to use a separate option. Further I
suggest
that pg_service ought to be handled first, ie, it makes sense to me to
be able to put both the LDAP name and the LDAP server address(es) into
a
Suvarna [EMAIL PROTECTED] writes:
We are facing a problem in nextval of sequence. The problem is as =
follows,
If the server shuts down abrupotly because of power failuar or any other
cause then the sequences tend to skip few numbers.
This is not a bug, it is the designed behavior. It's not
Ühel kenal päeval, T, 2006-02-28 kell 10:26, kirjutas Tom Lane:
Hannu Krosing [EMAIL PROTECTED] writes:
There is no fundamental reason, why vacuum needs to run in a transaction
itselt.
I'll just take one point: you cannot hold locks unless you have a
transaction, therefore you cannot even
Ühel kenal päeval, T, 2006-02-28 kell 10:16, kirjutas Alvaro Herrera:
Hannu Krosing wrote:
In the big table with hotspots case, I doubt that the win from
btbulkdelete will outweight having to scan 10 index pages to get to
the 30 or 50 that can be bulkdeleted.
Remember that WAL
On Tue, Feb 28, 2006 at 01:18:14AM -0500, Greg Stark wrote:
But I think the thought process went the other direction. If you have the bit
intended for index scans indicating that the tuple is not in doubt ie, it's
visible to every transaction, then that also implies the tuple doesn't need to
On Tue, Feb 28, 2006 at 12:05:17PM -0300, Alvaro Herrera wrote:
Martijn van Oosterhout wrote:
This may be the only solution. Converting everything to UTF-8 has
issues because some encodings are not roundtrip-safe (Enc - UTF8 - Enc
gives you a different string than you started with).
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, T, 2006-02-28 kell 10:26, kirjutas Tom Lane:
The current bgwriter is incapable of looking at catalog contents as
such --- it operates only at the level of physical data blocks.
Would'nt it still be possible to drop a table from
Martijn van Oosterhout kleptog@svana.org writes:
This may be the only solution. Converting everything to UTF-8 has
issues because some encodings are not roundtrip-safe
Is this still true?
I beleive so. If use the ICU Converter Explorer [1] to examine some of
the encodings we support, they
On Tue, Feb 28, 2006 at 01:22:35PM +, Simon Riggs wrote:
Paul, you mention serializable transactions, but your root issue seems
to be that VACUUM clears up less rows when pg_dump is running, yes? Have
you tried using an on-line hot backup with archive_command set (PITR)?
That doesn't
Martijn van Oosterhout kleptog@svana.org writes:
This may be the only solution. Converting everything to UTF-8 has
issues because some encodings are not roundtrip-safe
Is this still true?
I beleive so. If use the ICU Converter Explorer [1] to
examine some of
the encodings we
On Tue, Feb 28, 2006 at 01:32:19AM -0500, Tom Lane wrote:
To do that requires not just that you have access to a backend's oldest
snapshot, but that you have access to *all* its active snapshots;
because such a transient tuple might be visible in some newer snap even
though it's too new for
Andrew Dunstan [EMAIL PROTECTED] writes:
I would still much prefer to see remote config fetching done in a more
general way, using say libcurl (which handles ldap just fine if openldap
is available). Then we could fetch the config from a variety of sources,
not just ldap.
What other cases
On Tue, Feb 28, 2006 at 09:44:08AM -0600, Kevin Grittner wrote:
It struck me that it would be outstanding if the planner could
recognize this sort of situation, and build a temporary index based on
the snapshot of the data visible to the transaction. It seems to me
that the obvious downside
On Tue, Feb 28, 2006 at 11:19:02AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
This may be the only solution. Converting everything to UTF-8 has
issues because some encodings are not roundtrip-safe
Is this still true?
I beleive so. If use the ICU Converter
Kevin Grittner [EMAIL PROTECTED] writes:
It struck me that it would be outstanding if the planner could
recognize this sort of situation, and build a temporary index based on
the snapshot of the data visible to the transaction.
I don't think that's an appropriate solution at all. What it
Jim C. Nasby wrote:
On Tue, Feb 28, 2006 at 01:18:14AM -0500, Greg Stark wrote:
But I think the thought process went the other direction. If you have the
bit
intended for index scans indicating that the tuple is not in doubt ie,
it's
visible to every transaction, then that also
Jim C. Nasby [EMAIL PROTECTED] writes:
FWIW, Sybase supported something similar a long time ago. It had the
ability to build a temporary 'clustered table' (think index organized
table) when there was enough benefit to do so. This is actually
much easier to make happen inside a transaction for
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Mark
Woodward) belched out:
Mark Woodward wrote:
Like I have repeated a number of times, sometimes, there is more than
one
database cluster on a machine. The proposed pg_clusters.conf, could look
like this:
pg_clusters.conf
Bruce Momjian pgman@candle.pha.pa.us writes:
One idea Simon and I had was to reuse heap rows where all indexed values
in the old row and the new row were the same, meaning the heap value
could be replaced without changing the indexes at all. We thought this
would be very useful for
Mark Woodward [EMAIL PROTECTED] writes:
If one can specify a different port than the default on the command line,
why wouldn't a file designed to describe the server process include it. My
intention is to include all the options available via environment or
command lon in the file.
I think
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
One idea Simon and I had was to reuse heap rows where all indexed values
in the old row and the new row were the same, meaning the heap value
could be replaced without changing the indexes at all. We thought this
would be very
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
MVCC goes out the window, eh? Not to mention transaction rollback ability?
If the old row is not visible to any transactions, why would it not work?
The old row is ALWAYS visible to somebody, until you commit (if you ever
do). You
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
MVCC goes out the window, eh? Not to mention transaction rollback ability?
If the old row is not visible to any transactions, why would it not work?
The old row is ALWAYS visible to somebody, until you commit
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I would still much prefer to see remote config fetching done in a more
general way, using say libcurl (which handles ldap just fine if openldap
is available). Then we could fetch the config from a variety of sources,
not just
On Tue, 28 Feb 2006, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
MVCC goes out the window, eh? Not to mention transaction rollback ability?
If the old row is not visible to any transactions, why would it not work?
The old row is
Heikki Linnakangas wrote:
On Tue, 28 Feb 2006, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
MVCC goes out the window, eh? Not to mention transaction rollback
ability?
If the old row is not visible to any transactions, why
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
The old row is ALWAYS visible to somebody, until you commit (if you ever
do). You can't simply overwrite existing data.
Huh, I am not suggesting overwriting tuples you created, but tuples
created by earlier transactions and now
On Tue, Feb 28, 2006 at 11:05 am, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
The issue at hand really has nothing to do with temp indexes, it's
with
the constrained way that the planner deals with EXISTS subplans.
Yet when the index exists, the query is optimized well.
On Tue, Feb 28, 2006 at 11:36 am, in message
[EMAIL PROTECTED], Kevin Grittner
Also, EXISTS works in situations where
you need to compare on multiple columns, so it is useful in many
situations where EXISTS or MIN/MAX techniques just don't work.
Sorry. That should have read:
EXISTS works in
Bruce Momjian pgman@candle.pha.pa.us writes:
I should be clearer. Suppose you have a table with a single index on
the primary key. You are updating the row over and over again (a
typical case). You create the first row, commit, then it is updated
(two copies), commit, then you update it
Heikki Linnakangas [EMAIL PROTECTED] writes:
Index tuples have commit info hint bits in them, don't they?
Oooh, I forgot that one, but that's definitely strike 5.
And there's a strike 6: I'm pretty sure this idea breaks unique-index
checking. Somebody else trying to insert a tuple with a
Bruce Momjian pgman@candle.pha.pa.us writes:
Heikki Linnakangas wrote:
Index tuples have commit info hint bits in them, don't they? You would
still have to update those.
Right, but consider that we would have to use the index to find the
matching reusable heap to begin with, so we could
Greg Stark [EMAIL PROTECTED] writes:
I originally thought you meant if you are repeatedly updating the same record
within the same transaction. In that case sure you could reuse the space but
a) only if it's big enough for the new record and b) how often do you really
do that?
Also, it's not
Greg Stark wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I should be clearer. Suppose you have a table with a single index on
the primary key. You are updating the row over and over again (a
typical case). You create the first row, commit, then it is updated
(two copies),
Kevin Grittner [EMAIL PROTECTED] writes:
EXISTS works in situations where
you need to compare on multiple columns, so it is useful in many
situations where IN or MIN/MAX techniques just don't work.
IN works fine on multiple columns:
(foo, bar, baz) IN (SELECT x, y, z FROM ...)
On Tue, Feb 28, 2006 at 12:06 pm, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
IN works fine on multiple columns:
(foo, bar, baz) IN (SELECT x, y, z FROM ...)
Thanks for pointing that out. I recognize it as valid ANSI/ISO syntax,
using a row value constructor list.
Simon Riggs wrote:
On Thu, 2006-02-23 at 11:54 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
A patch prototype to make zero_damaged_pages work as advertised is
enclosed, though the current behaviour may well be preferred, in which
case a doc patch is more appropriate.
On Feb 28, 2006, at 11:19 AM, Tom Lane wrote:
In any case I don't think there's a huge problem if we say that
database
and user names had better be chosen from the round-trip-safe subset.
What about the pg_hba.conf file? Is there a provision to specify the
encoding or some other way to
Bruce Momjian pgman@candle.pha.pa.us writes:
Greg Stark wrote:
If you commit each update then your tuple might well be visible to other
transactions, how would you check that?
You check the xmin/xmax using standard visibility rules.
Would that really find anything? Even putting aside
Bruce Momjian pgman@candle.pha.pa.us writes:
On Thu, 2006-02-23 at 11:54 -0500, Tom Lane wrote:
Hmm it'd probably be a good idea to force zero_damaged_pages OFF in
the autovac subprocess. That parameter is only intended for interactive
use --- as you say, autovac would be a rather nasty
Jim C. Nasby wrote:
On Sat, Feb 18, 2006 at 02:49:08PM -0500, Tom Lane wrote:
Perhaps we should make a concerted effort to split the libpq docs into a
section for programmers vs one for users, the latter part covering
the libpq behavior that is interesting to users of a libpq-based app.
John DeSoi [EMAIL PROTECTED] writes:
On Feb 28, 2006, at 11:19 AM, Tom Lane wrote:
What about the pg_hba.conf file? Is there a provision to specify the
encoding or some other way to deal with non-ascii characters?
pg_hba.conf is also processed without any locale considerations,
ie,
On Tue, Feb 28, 2006 at 11:36:28AM -0600, Kevin Grittner wrote:
digression
I'm all for that. So far, we've been going after the low-hanging fruit
in our use of PostgreSQL. When we get to the main applications, we're
going to be dealing with a lot more in the way of EXISTS clauses. The
On Tue, Feb 28, 2006 at 11:05 am, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
The limiting factor is that EXISTS subplans
aren't flattened ... and once that's fixed, I doubt the example
would
need any new kind of join support.
I rewrote the query to use IN predicates
cvs tip configure is giving a warning:
checking for flags to link embedded Perl...
/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/CORE -lperl -lresolv -lnsl
-ldl -lm -lcrypt -lutil -lpthread -lc
gawk: warning:
Tom Lane wrote:
cvs tip configure is giving a warning:
checking for flags to link embedded Perl...
/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/CORE -lperl -lresolv -lnsl
-ldl -lm -lcrypt -lutil
Ühel kenal päeval, E, 2006-02-27 kell 19:20, kirjutas Peter Eisentraut:
Something came to my mind today, I'm not sure if it's feasible but I
would like to know opinions on it.
We've seen database applications that PostgreSQL simply could not manage
because one would have to vacuum
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, I reread the manual page:
As each input record is read, gawk splits the record into
fields, using the value of the FS variable as the field
separator. If FS is a single character, fields are sepa-
rated by
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, I reread the manual page:
As each input record is read, gawk splits the record into
fields, using the value of the FS variable as the field
separator. If FS is a single character, fields are
Mark Woodward wrote:
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Mark
Woodward) belched out:
I'm not keen on the Windows .ini file style sectioning; that makes it
look like a mix between a shell script and something else. It should
be one or the other. It probably should be
Hannu Krosing wrote:
Due to current implementation of vacuum,
you have to abandon continuous vacuuming during vacuum of bigtable, but
i have written and submitted to patches list a patch which allows
vacuums not to block each other out, this is stalled due to Tom's
unesyness about its
Kevin Grittner wrote:
I rewrote the query to use IN predicates rather than EXISTS predicates,
and the cost estimates look like this:
EXISTS, no index: 1.6 billion
EXISTS, with index: 0.023 billion
IN, no index: 13.7 billion
IN, with index: 10.6 billion
At least for the two EXISTS cases,
On Tue, Feb 28, 2006 at 11:58:44AM -0500, Bruce Momjian wrote:
Jim C. Nasby wrote:
On Tue, Feb 28, 2006 at 01:18:14AM -0500, Greg Stark wrote:
But I think the thought process went the other direction. If you have the
bit
intended for index scans indicating that the tuple is not in
On 2006-02-28, Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
OK, I reread the manual page:
As each input record is read, gawk splits the record into
fields, using the value of the FS variable as the field
separator. If FS is a
On Feb 16, 2006, at 21:37 , Dhanaraj wrote:
hi
currently i looking at the postgres src code. I saw the scanner and
parser implemetations at two different places (src/backend/parser/
and /src/bakend/bootstrp). Can anybody tell me the purpose of
having two phases?? or will this help to
Michael Glaesemann [EMAIL PROTECTED] writes:
On Feb 16, 2006, at 21:37 , Dhanaraj wrote:
currently i looking at the postgres src code. I saw the scanner and
parser implemetations at two different places (src/backend/parser/
and /src/bakend/bootstrp). Can anybody tell me the purpose of
Mark Woodward wrote:
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Mark
Woodward) belched out:
I'm not keen on the Windows .ini file style sectioning; that makes it
look like a mix between a shell script and something else. It should
be one or the other. It probably should be
Mark Woodward wrote:
Mark Woodward wrote:
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Mark
Woodward) belched out:
I'm not keen on the Windows .ini file style sectioning; that makes it
look like a mix between a shell script and something else. It should
be one or the other.
I will clean it up before applying.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Because of global tables, I don't think we make any distinction between
xids of the same database and those of a different database, so the
current behavior seems correct.
---
Satoshi Nagayasu wrote:
Hi all,
When I was
Mark Kirkwood wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4.1 /vol03/pg74 5432
Clearly
Andrew Dunstan wrote:
Mark Kirkwood wrote:
Do you need name, value pairs? I was thinking that something like:
# Postgres Cluster Registration
#
# PG_HOME PGDATA PORT
/usr/local/pg7.4.1 /vol01/pggeo 5435
/usr/local/pg7.4.1 /vol01/pgicdmdb 5434
/usr/local/pg7.4.1 /vol03/pg74
On Tue, 28 Feb 2006 01:04:00 -0500, Tom Lane wrote
Jim C. Nasby jnasby ( at ) pervasive ( dot ) com writes:
On Mon, Feb 27, 2006 at 03:05:41PM -0500, Tom Lane wrote:
Moreover, you haven't pointed to any strong reason to adopt this
methodology. It'd only be a win when vacuuming pretty small
Several of the new uninstall scripts give errors, particularly those
that drop types and their support objects. To see an example:
createdb foo
psql -d foo -f ltree.sql
psql -d foo -f uninstall_ltree.sql
A lot of the errors are due to DROP OPERATOR CLASS lines missing
the required USING clause;
88 matches
Mail list logo
