Tom,
Sound excellent. Index growth has been something that always bothered me (not
the disk space usage, but the slow searches).
I believe it's best to have pages marked dead at the time the last key
contained in the page is deleted (you didn't discuss how efficient this is),
because this
Justin Clift said:
snip
In theory, if we find recyclable page(s) at the physical end of the index,
we could truncate the file (ie, give the space back to the filesystem)
instead of reporting these pages to FSM. I am not sure if this is worth
doing --- in most cases it's likely that
Christopher Kings-Lynne wrote:
Hrm. I just saw that the PHP ADODB guy just published a bunch of database
benchmarks. It's fairly evident to me that benchmarking PostgreSQL on
Win32 isn't really fair:
http://php.weblogs.com/oracle_mysql_performance
*sigh*
Not fair, perhaps.
But if you
On Wed, 12 Feb 2003, [ISO-8859-1] Hans-J$B|(Brgen Sch$Bv(Bnig wrote:
(B
(B Be careful with sort_mem - this might lead to VERY unexpected results. I
(B did some testing on my good old Athlon 500 with a brand new IBM 120 Gigs
(B HDD. Reducing the sort_mem gave me significantly faster results
Our students are (unfortunately) on solaris x86 (unfortunate because I
have to do another round of testing before I deploy pgsql code for
them to hack).
Sadly, set_ps_display does not seem to have any effect in solaris
x86. At least ps only reports multiple postmaster processes and
arguments.
Well, to the extent that you're serious, you understand that
a lot of people feel that /usr/local should be reserved for
stuff that's installed by the local sysadmin, and your
vendor/distro isn't supposed to be messing with it.
Which means if the the vendor installed Postgresql (say,
On Wed, 12 Feb 2003, Peter Bierman wrote:
What do you gain by having the postmaster config and the database
data live in different locations?
You can then standardize a location for the configuration files.
Everybody has room in /etc for another 10K of data. Where you have
room for something
tom lane initially wrote:
Restructuring the tree during page deletion
---
We will delete only completely-empty pages. If we were to
merge nearly-empty pages by moving data items from one page
to an adjacent one, this would imply changing the
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
On Wed, 12 Feb 2003, Peter Bierman wrote:
What do you gain by having the postmaster config and the database
data live in different locations?
You can then standardize a location for the configuration files.
Everybody has
On Wed, 2003-02-12 at 16:02, Ulf Rehmann wrote:
Hi!
Is there any way to adjust dumps from postgresql 7.3 for use by
version 7.2 and vice versa ?
Or is there a way to transport a full database via csv or in any other
kind to 7.2 and vice versa ?
We are running a couple of
Christopher Browne wrote:
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
On Wed, 12 Feb 2003, Peter Bierman wrote:
What do you gain by having the postmaster config and the database
data live in different locations?
You can
On Thu, 13 Feb 2003, Christopher Browne wrote:
1. It assumes that there is a location for the configuration files
for /the single database instance./
No; it assumes that there's a location for the default instance. If
you have more than one, you could have one default and one elsewhere,
On Thursday 13 February 2003 08:32, Christopher Browne wrote:
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
Everybody has room in /etc for another 10K of data. Where you have
room for something that might potentially be a half terrabyte of
data, and is not
Daniel Kalchev [EMAIL PROTECTED] writes:
... Thus we should 'free' the index
pages with one VACUUM run, instead of two.
Bear in mind that the only thing that deletes index entries is ... VACUUM.
Thus what we're really discussing is whether VACUUM should delete an
index page at the same time it
On Thu, 13 Feb 2003, Curt Sampson wrote:
On Thu, 13 Feb 2003, Christopher Browne wrote:
1. It assumes that there is a location for the configuration files
for /the single database instance./
No; it assumes that there's a location for the default instance. If
you have more than
Sailesh Krishnamurthy [EMAIL PROTECTED] writes:
Sadly, set_ps_display does not seem to have any effect in solaris
x86. At least ps only reports multiple postmaster processes and
arguments.
IIRC, you have to use the other version of ps to see the process
status on Solaris. I forget where it
Curtis Faith [EMAIL PROTECTED] writes:
ISTM, that a VACUUM that only reclaims empty pages will be helpful in
certain cases but won't help much at all in many other common normal
operation cases which would be helped by partial reorganization.
Got any evidence to back that up? I was relying on
Robert Treat [EMAIL PROTECTED] writes:
On Wed, 2003-02-12 at 16:02, Ulf Rehmann wrote:
Is there any way to adjust dumps from postgresql 7.3 for use by
version 7.2 and vice versa ?
Create a schema only dump with the 7.2 pg_dump.
Create a data only dump (possibly with INSERT output) with the
On Thu, Feb 13, 2003 at 15:03:09 +,
Nigel J. Andrews [EMAIL PROTECTED] wrote:
Is everyone forgetting that wherever the configuration file is stored and
whether or not it needs a command line argument to specify it the database is
not going to start up automatically unless at least part
On Thu, Feb 13, 2003 at 09:23:20 -0500,
mlw [EMAIL PROTECTED] wrote:
Personally, however, I think the configuration issue is a no-brainer and
I am amazed that people are balking. EVERY other service on a UNIX box
is configured in this way, why not do it this way in PostgreSQL? The
patch
On Thu, 2003-02-13 at 10:42, Tom Lane wrote:
I think he'll have trouble even with that :-( ... 7.3 pg_dump will try
to use column-name-list syntax in its COPY commands, which the 7.2
server won't like.
If you used an insert-only, data-only dump, that might work...
Cheers,
Neil
--
Neil
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get to a PG box and hunt around for data
directory so as to be able to administer the system. What's really
annoying is when you have to find the data
Robert Treat wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get to a PG box and hunt around for data
directory so as to be able to administer the system. What's really
annoying is
Bruno Wolff III wrote:
On Thu, Feb 13, 2003 at 09:23:20 -0500,
mlw [EMAIL PROTECTED] wrote:
Personally, however, I think the configuration issue is a no-brainer and
I am amazed that people are balking. EVERY other service on a UNIX box
is configured in this way, why not do
On Thu, 13 Feb 2003, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get to a PG box and hunt around for data
directory so as to be able to administer the system.
Stephan Szabo wrote:
On Thu, 13 Feb 2003, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get to a PG box and hunt
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I'm still getting failure, but it gets weirder:
Fixed --- turns out the bug is that timetz_out was scribbling on its
input (thereby changing the table) in the --enable-integer-datetimes
path.
I back-patched the change into 7.3, although I
tom lane wrote:
Got any evidence to back that up? I was relying on
[Johnson89] Johnson, T. and Shasha, D. Utilization of
B-trees with Inserts, Deletes and Modifies ACM Symp. on
PODS, 235-246, 1989.
which provides a ton of math and simulations leading up to
the conclusion that
Curtis Faith [EMAIL PROTECTED] writes:
I don't dispute their conclusions in that context and under the
circumstances they outline of random distribution of deletion and
insertion values for the index keys. [But the random-distribution
assumption doesn't always hold.]
That's a fair point.
In CVS tip, I'm getting only an empty string from psql where it should
print connection-failure messages.
psql 7.3 does this:
$ psql -p
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket
Greg Stark [EMAIL PROTECTED] writes:
Ran into this in cvs tip checked out as of yesterday:
db= SELECT sum(CASE WHEN (upper(substr((select 'en'::varchar),1,1)) not between
'A' and 'Z') THEN 1 ELSE 0 END) AS n FROM tab;
ERROR: transformExpr: does not know how to transform node 309 (internal
On Thu, 13 Feb 2003, mlw wrote:
Stephan Szabo wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get to a PG box and hunt around for data
directory so as to be able to administer the system. What's
On 13 Feb 2003, Martin Coxall wrote:
Well, to the extent that you're serious, you understand that
a lot of people feel that /usr/local should be reserved for
stuff that's installed by the local sysadmin, and your
vendor/distro isn't supposed to be messing with it.
Which means if
I don't see why we can't keep everyone happy and let the users choose the
setup they want. To wit, make the following, probably simple, changes:
1) Have postgresql default to using /etc/postgresql.conf
2) Add a setting in postgresql.conf specifying the data directory
3) Change the meaning of -D
On Wed, 12 Feb 2003, Bruce Momjian wrote:
And part of the reason is because some/most BSD's map the page tables
into physical RAM (kernel space) rather than use some shared page table
mechanism. This is good because it prevents the shared memory from
being swapped out (performance
tom lane wrote:
Curtis Faith [EMAIL PROTECTED] writes:
I don't dispute their conclusions in that context and under the
circumstances they outline of random distribution of deletion and
insertion values for the index keys. [But the random-distribution
assumption doesn't always hold.]
On 13 Feb 2003, Oliver Elphick wrote:
On Thu, 2003-02-13 at 18:45, Bruce Momjian wrote:
Oliver Elphick wrote:
On Thu, 2003-02-13 at 17:52, Vince Vielhaber wrote:
Seems to me that if FHS allows such a mess, it's reason enough to avoid
compliance. Either that or those of you who
On Thu, 13 Feb 2003, mlw wrote:
Christopher Browne wrote:
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
On Wed, 12 Feb 2003, Peter Bierman wrote:
What do you gain by having the postmaster config and the database
data live in different locations?
You can
scott.marlowe wrote:
These are not issues at all. You could put the configuration file
anywhere, just as you can for any UNIX service.
postmaster --config=/home/myhome/mydb.conf
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get
On Thu, 2003-02-13 at 15:08, mlw wrote:
Stephan Szabo wrote:
Re-read my statement and yours about the case you were mentioning. ;)
Sure, putting the files in /etc lets you find them easily. However, if
you're doing things like finding configuration made by someone else and
said
Bradley McLean [EMAIL PROTECTED] writes:
Here's a patch that fixes my issue. I have not extensively developed
tests for it.
Patch applied, thanks!
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the
Hi All,
I was wondering if there is a libq or libqxx type library written in
java. Even if it is done through jni. I would like to do some
experiments, perhaps make a utility that reads server information such
as currently executing query, current locks, amount of disk/ram taken up
by pgsql.
On Thu, Feb 13, 2003 at 05:59:17PM -0500, Robert Treat wrote:
On Thu, 2003-02-13 at 15:08, mlw wrote:
Stephan Szabo wrote:
On Thu, 13 Feb 2003, mlw wrote:
I have absolutely no problem debating and augmenting the feature. None
what so ever, I am more pushing to get momentum to
(B
(BActually, the results are completely expected once you know what's
(Bexactly is going on. I found it weird that my sorts were also slowing
(Bdown with more sort memory until Tom or Bruce or someone pointed out to
(Bme that my stats said my sorts were swapping.
(B
(B
(B
(Bthis way
| Create a schema only dump with the 7.2 pg_dump.
| Create a data only dump (possibly with INSERT output) with the 7.3
| pg_dump. Assuming you haven't done anything too wacky, you should be
| able to drop your 7.2 database, reload the 7.2 schema, then load up the
| 7.3 data. As always, test
Is there any way to adjust dumps from postgresql 7.3 for use by
version 7.2 and vice versa ?
Or is there a way to transport a full database via csv or in any other
kind to 7.2 and vice versa ?
We are running a couple of servers/mirrors at various locations in the
world, handling data
I have Postgres 7.2.1 configured to listen on TCP/IP port.
When the server starts up it still creates the socket file in /tmp.
Removing this file manually does not seem to cause any problem for the
application.
Is there a way to prevent postmaster from creating this file?
Is this really safe to
Wow, there's been a lot of discussion on this issue!
While it won't address some of the issues that have been brought up,
there is one very simple thing we can do that will help sysadmins
quite a lot: eliminate the postmaster's use of $PGDATA, and force the
data directory to be specified on the
Good evening, tonight while running my routine vacuum, the following came up on my
screen:
---8---
NOTICE: Rel xamefiles: Uninitialized page 708135 - fixing
NOTICE: Rel xamefiles: Uninitialized page 708136 - fixing
NOTICE: Rel xamefiles: Uninitialized page 708137 - fixing
NOTICE:
Bruce Momjian wrote:
I don't think separate params for each config file is good. At the
most, I think we will specify the configuration _directory_ for all the
config files, perhaps pgsql/etc, and have pgdata default to ../data, or
honor $PGDATA. That might be the cleanest.
Of course,
Vince Vielhaber wrote:
On Thu, 13 Feb 2003, Lamar Owen wrote:
On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
Actually FHS says the opposite. If the distribution installs PostgreSQL
then the config files belong in /etc/postgresql. If the admin does then
they belong in
I don't think this is based on a useful test for wal_buffers. The
wal_buffers setting only has to be large enough for the maximum amount
of WAL log data that your system emits between commits, because a commit
(from anyone) is going to flush the WAL data to disk (for everyone).
So a
I don't think this is based on a useful test for wal_buffers. The
wal_buffers setting only has to be large enough for the maximum amount
of WAL log data that your system emits between commits, because a commit
(from anyone) is going to flush the WAL data to disk (for everyone).
So a
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Here's a question then - what is the _drawback_ to having 1024
wal_buffers
as opposed to 8?
Waste of RAM? You'd be better off leaving that 8 meg available for use
as general-purpose buffers ...
What I mean is say you have an enterprise
Josh Berkus wrote:
Uh ... do we have a basis for recommending any particular sets of
parameters for these different scenarios? This could be a good idea
in the abstract, but I'm not sure I know enough to fill in the details.
Sure.
Mostly-Read database, few users, good hardware,
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Here's a question then - what is the _drawback_ to having 1024 wal_buffers
as opposed to 8?
Waste of RAM? You'd be better off leaving that 8 meg available for use
as general-purpose buffers ...
regards, tom lane
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I've just spent the last day and a half trying to benchmark our new database
installation to find a good value for wal_buffers. The quick answer - there
isn't, just leave it on the default of 8.
I don't think this is
Kevin Brown [EMAIL PROTECTED] writes:
What happens when the only transaction running emits more WAL log data
than wal_buffers can handle? A flush happens when the WAL buffers
fill up (that's what I'd expect)? Didn't find much in the
documentation about it...
A write, not a flush (ie, we
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
What I mean is say you have an enterprise server doing heaps of transactions
with lots of work. If you have scads of RAM, could you just shove up
wal_buffers really high and assume it will improve performance?
There is no such thing as
Quick question for the group
I'm assuming that the PG_TEMP_FILES_DIR for BufFile temps is
automatically under the PGDATA directory. Is that correct ?
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP 1:
Bruce Momjian wrote:
We could prevent the postmaster from starting unless they run pg_tune or
if they have modified postgresql.conf from the default. Of course,
that's pretty drastic.
If you're going to do that, then you may as well make the defaults
something that will perform reasonably
Tom Lane wrote:
I don't see any great value in a separate postgresql.conf parameter for
each secondary config file; that just means clutter to me, especially
if we add more such files in future. I am also distinctly not in favor
of eliminating the PGDATA environment variable; that reads to me
OK,
Here's a stab at some extra conf files. Feel free to shoot them down.
If we can come up with at least _some_ alternative files that we can put
somewhere for them to see when postgres is installed, then at least people
can see what variables will affect what...
I didn't see the point of a
Kevin Brown [EMAIL PROTECTED] writes:
I agree with your assessment for the most part, except for PGDATA.
There's no good reason I can think of for the postmaster to look at
it.
The other side of that coin is, what's the good reason to remove it?
There's a long way between I don't want my setup
Apache explicitly supports a number of different layouts for files out of
the box (and provides support for you to roll your own very easily). From
the manual:
The second, and more flexible way to configure the install path locations
for Apache is using the config.layout file. Using this method,
On Thursday 13 February 2003 21:13, Bruce Momjian wrote:
Lamar Owen wrote:
It isn't without precedent to have a directory under /var/run. Maybe
/var/run/postgresql. Under this one could have a uniquely named pid
file.
But how do you handle the default then, where you have postmaster.pid
Oliver Elphick [EMAIL PROTECTED] writes:
I'm not entirely sure why SE Linux has a problem, seeing that postgres
needs read-write access to all the files in $PGDATA, but assuming the
need is verified, I could do this by moving the pid file from
$PGDATA/postmaster.pid to
On Thursday 13 February 2003 21:49, Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
need is verified, I could do this by moving the pid file from
$PGDATA/postmaster.pid to /var/run/postgresql/5432.pid and similarly for
other ports. This would also have the benefit of being more
Lamar Owen wrote:
I am now wondering if we even want pg_hba_dir and pg_ident_dir. Seems
we can assume they are in the same directory as postgresql.conf. That
leaves only data_dir as new for postgresql.conf.
Ok, if we're going this far already, tell me exactly why we have three config
Lamar Owen [EMAIL PROTECTED] writes:
Ok, if we're going this far already, tell me exactly why we have three config
files. Why not really Unify things and fulfil the full promise of Grand
Unified Configuration by rolling hba and ident into postgresql.conf. Is
there a compelling reason not
Tatsuo,
Sigh. People always complain pgbench does not reliably producing
repeatable numbers or something then say that's because pgbench's
transaction has too much contention on the branches table. So I added
-N option to pgbench which makes pgbench not to do any UPDATE to
the branches
This patch allows using PostgreSQL with a command line configuration
file parameter instead of the data directory.
If no configuration is specified, postmaster operates as it always has.
The configuration file is specified with the -C parameter, as:
postmaster -C /somepath/somefile.conf
HEY PEOPLE!
How about we take this discussion to the Performance List, where it belongs?
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Laurette Cisneros [EMAIL PROTECTED] writes:
This is the error in the pgsql log:
2003-02-13 16:21:42 [8843] ERROR: Index external_signstops_pkey is not a
btree
This says that one of two fields that should never change, in fixed
positions in the first block of a btree index, didn't have the
On Thu, 2003-02-13 at 23:06, mlw wrote:
Bruce Momjian wrote:
Can non-root write to /var/run?
Shouldn't be able too
But it should be able to write under /var/run/postgresql, which the
distribution will set up with the correct permissions.
--
Oliver Elphick
On Thu, 2003-02-13 at 22:53, Bruce Momjian wrote:
Oliver Elphick wrote:
What your comments strongly suggest to me is that projects like
PostgreSQL and pine, along with everything else, should comply with FHS;
then there will be no confusion because everyone will be following the
smae
On Fri, 2003-02-14 at 02:49, Tom Lane wrote:
Oliver Elphick [EMAIL PROTECTED] writes:
I'm not entirely sure why SE Linux has a problem, seeing that postgres
needs read-write access to all the files in $PGDATA, but assuming the
need is verified, I could do this by moving the pid file from
On Fri, 2003-02-14 at 02:45, [EMAIL PROTECTED] wrote:
3.7.1 Purpose
/etc contains configuration files and directories that are specific to the
current system.
3.7.4 Indicates that
Host-specific configuration files for add-on application software packages
must be installed within the
Peter Eisentraut wrote:
Joe Conway writes:
So I wrote a quick hack to load and initialize the library on postmaster
startup.
On glibc systems you can probably do this using the environment variable
LD_PRELOAD. I guess others have a similar mechanism.
Hmmm. I could try that. But I found
Tom Lane kirjutas N, 13.02.2003 kell 20:10:
Curtis Faith [EMAIL PROTECTED] writes:
I don't dispute their conclusions in that context and under the
circumstances they outline of random distribution of deletion and
insertion values for the index keys. [But the random-distribution
All I see here is an arbitrary break with our past practice. I do
not see any net improvement.
FreeBSD Port Maintainer
Well, given that there's a trend to make PostgreSQL more usable, I can
say with absolute certainty, that an FAQ that I get about once a week
is (and granted only from new
On Thu, 2003-02-13 at 21:21, Vince Vielhaber wrote:
I certainly wasn't trying to provoke anything. It just seems odd to me
that when the distribution installs a package and places it's config files
in /etc and later the admin happens to upgrade by the instructions with
the package, it's
On Thu, 2003-02-13 at 14:28, Bruce Momjian wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 14:06, mlw wrote:
I will be resubmitting my patch for the 7.3.2 tree.
I'm no core developer, but surely this wont be included in the 7.3.x
branch. Any change needs to be made against
On Thu, 2003-02-13 at 14:43, Bruce Momjian wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file
On Thu, 2003-02-13 at 14:51, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
Oliver Elphick wrote:
What your comments strongly suggest to me is that projects like
PostgreSQL and pine, along with everything else, should comply with FHS;
then there will be no confusion because everyone will be following the
smae standards. Messes arise when people ignore standards; we
Robert Treat wrote:
IIRC the postmaster.pid file should be in /var/run according to FHS, I'm
not sure about postmaster.opts though...
Again, if we're going to make a change, let's make sure we think it
through.
Can non-root write to /var/run?
--
Bruce Momjian|
Patrick Macdonald wrote:
But why would someone want incremental backups compared to PITR? The
backup would be mixture of INSERTS, UPDATES, and DELETES, right? Seems
pretty weird. :-)
Yeah, it's a different method of producing a similar outcome. However, many
companies do not want to
To auto-tune, you would need to monitor swap usage and other stuff that
may vary too much based on load from other systems. Only the admin
knows how to answer some of those questions.
---
Jason Hihn wrote:
Pardon my
Bruce Momjian wrote:
Robert Treat wrote:
IIRC the postmaster.pid file should be in /var/run according to FHS, I'm
not sure about postmaster.opts though...
Again, if we're going to make a change, let's make sure we think it
through.
Can non-root write to /var/run?
Wow, I never even thought that was possible. Do other db's support that
feature?
Isn't that basically what the current replication kits for Postgresql do
-- via triggers and log tables?
--
Rod Taylor [EMAIL PROTECTED]
PGP Key: http://www.rbt.ca/rbtpub.asc
signature.asc
Description: This
On 13 Feb 2003, Oliver Elphick wrote:
What your comments strongly suggest to me is that projects like
PostgreSQL and pine, along with everything else, should comply with FHS;
then there will be no confusion because everyone will be following the
smae standards. Messes arise when people
Hannu Krosing [EMAIL PROTECTED] writes:
But if we would allow the scans to find the same keys twice without ill
effects (as was suggested earlier, for using btrees to index arrays),
How is returning the same data twice not an ill effect?
then we could possibly 1) copy the key to the right 2)
Robert Treat wrote:
On Thu, 2003-02-13 at 14:51, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
But if we would allow the scans to find the same keys twice without ill
effects (as was suggested earlier, for using btrees to index arrays),
How is returning the same data twice not an ill effect?
then we could possibly 1) copy
On Thursday 13 February 2003 17:53, Bruce Momjian wrote:
Oliver Elphick wrote:
What your comments strongly suggest to me is that projects like
PostgreSQL and pine, along with everything else, should comply with FHS;
then there will be no confusion because everyone will be following the
On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
Actually FHS says the opposite. If the distribution installs PostgreSQL
then the config files belong in /etc/postgresql. If the admin does then
they belong in /usr/local/etc/postgresql. FHS is out of their tree. If
PostgreSQL or
On Thu, 13 Feb 2003, Lamar Owen wrote:
On Thursday 13 February 2003 18:07, Vince Vielhaber wrote:
Actually FHS says the opposite. If the distribution installs PostgreSQL
then the config files belong in /etc/postgresql. If the admin does then
they belong in /usr/local/etc/postgresql. FHS
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
In CVS tip, I'm getting only an empty string from psql where it should
print connection-failure messages.
[ it works here ]
Speculation time: do you have the IPv6 code compiled in? I don't.
regards, tom lane
On Thursday 13 February 2003 18:41, Vince Vielhaber wrote:
On Thu, 13 Feb 2003, Lamar Owen wrote:
PostgreSQL is as critical as PHP, Apache, or whatever other package is
being backended by PostgreSQL. If the package is provided by the
distributor, consider it part of the OS. If it isn't,
1 - 100 of 149 matches
Mail list logo
