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;
On Tue, 28 Feb 2006 01:04:00 -0500, Tom Lane wrote
"Jim C. Nasby" 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 numbers
of tuples, which is not the d
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
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 oth
That's not a bug it's normal behaviour.
Suvarna 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 other
cause then the sequences tend to skip few numbers.
Aft
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 wa
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.
---
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
> 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 pro
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 purpo
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 p
On 2006-02-28, Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian 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
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
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, th
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 it
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 b
Tom Lane wrote:
> Bruce Momjian 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-
> >
Bruce Momjian 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 that character. If F
Ü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 cont
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 -l
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: e
>>> 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 predic
On Tue, Feb 28, 2006 at 11:36:28AM -0600, Kevin Grittner wrote:
>
> 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
> product we
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, effec
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-base
Bruce Momjian 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 loose cannon
Bruce Momjian 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 your own trans
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 de
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 ap
>>> 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 construc
Greg Stark wrote:
>
> Bruce Momjian 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 yo
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
"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 ...)
Bruce Momjian 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 clear the hint bit.
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 dup
Bruce Momjian 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 again. That first c
>>> 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
Bruce Momjian 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 invisible to every
Heikki Linnakangas wrote:
> On Tue, 28 Feb 2006, Bruce Momjian wrote:
>
> > Tom Lane wrote:
> >> Bruce Momjian 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
On Tue, 28 Feb 2006, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian 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
>>> 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 optimiz
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 lda
Tom Lane wrote:
> Bruce Momjian 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 eve
Bruce Momjian 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 can't simply overw
Tom Lane wrote:
> Bruce Momjian 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 fre
"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 t
Bruce Momjian 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 frequently-updated rows. It
> 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_
"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 transact
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
"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 i
On Tue, Feb 28, 2006 at 11:19:02AM -0500, Tom Lane wrote:
> Martijn van Oosterhout 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 Ex
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 downsid
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 c
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
> Martijn van Oosterhout 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 su
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 su
Martijn van Oosterhout 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 have "Con
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 fr
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 wit
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 t
Ü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 th
Ü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 ca
"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
> 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
> pg
Martijn van Oosterhout 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 post-startup acce
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 an
"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,
>
>>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
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 WRO
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 a
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
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 about
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 encodi
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 the server the
nextval of sequence does
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
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.con
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
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, 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 o
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.
--
Alva
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 na
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
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 pg_services.con
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 fi
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
Ü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 d
Ü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 prett
Ü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 func
89 matches
Mail list logo
