Tom Lane wrote:
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.
I have IPv6 enabled
Well, we have jdbc at jdbc.postgresql.org.
---
Shahbaz Chaudhary wrote:
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
Bruce Momjian wrote:
Patrick Macdonald wrote:
Yeah, it's a different method of producing a similar outcome. However, many
companies do not want to be concerned with the management (and space)
of archived logs. Incremental backup allows them the option of performing
a full backup and
Well, I wrote pgmonitor on gborg.postgresql.org, which is like top for
PostgreSQL, but is in TCL. It uses ps internally.
---
Shahbaz Chaudhary wrote:
Sorry, I don't think I made myself clear. I don't want to query the DB
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
So, my idea is to add a message at the end of initdb that states people
should run the pgtune script before running a production server.
Do people read what initdb has to say?
IIRC, the RPM install scripts hide initdb's output from
On Thu, 2003-02-13 at 13:32, Christopher Browne 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 infrequently several gigabytes or more, is pretty
system-depenendent.
Ah, but this
On Thu, 2003-02-13 at 12:00, Vince Vielhaber wrote:
Which means if the the vendor installed Postgresql (say, the
Red Hat Database) you'd expect config files to be in /etc.
If the postgresql is compiled from source by local admin,
you might look somewhere in /usr/local.
Then why not
On 13 Feb 2003, Oliver Elphick wrote:
On Thu, 2003-02-13 at 12:00, Vince Vielhaber wrote:
Which means if the the vendor installed Postgresql (say, the
Red Hat Database) you'd expect config files to be in /etc.
If the postgresql is compiled from source by local admin,
you might look
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 build for distributions are
making an ill advised change. Simply because the distribution makes the
decision to add
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 build for distributions are
making an ill advised change. Simply because the distribution makes the
I was speaking of the 4.4 BSD. FreeBSD has the merged VM, and I think
NetBSD only recently did that. BSD/OS does do the locking by default
and it maps into the kernel address space. I believe FreeBSD has a
sysctl to control locking of SysV memory.
One advantage of having it all at the same VM
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 build for distributions are
making an ill advised
On Thu, 2003-02-13 at 18:45, Bruce Momjian wrote:
Now, on to this configuration discussion. Seems moving the config file
out of $PGDATA requies either:
1) we specifiy both the config directory and the data directory on
postmaster start
2) we specify the
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 build for distributions are
making an ill
mlw wrote:
It doesn't have anything to do with not-invented-here, which is a
common refrain by people who don't like our decisions, like Why don't
you use mmap()? Oh, it's because I thought of it and you didn't. Does
anyone seriously believe that is the motiviation of anyone in this
Tom Lane wrote:
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
Bruce Momjian wrote:
Someone at Red Hat is working on point-in-time recovery, also known as
incremental backups.
PITR and incremental backup are different beasts. PITR deals with a backup
+ logs. Incremental backup deals with a full backup + X smaller/incremental
backups.
So... it doesn't
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 CVS head.
I assume he meant he will repost his 7.3.2-based
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:
hbafile= '/etc/postgres/pg_hba.conf'
identfile='/etc/postgres/pg_ident.conf'
Patrick Macdonald wrote:
Bruce Momjian wrote:
Someone at Red Hat is working on point-in-time recovery, also known as
incremental backups.
PITR and incremental backup are different beasts. PITR deals with a backup
+ logs. Incremental backup deals with a full backup + X
Bruce Momjian said:
This brings up one item it would be nice to address at the same time.
It would be nice if VACUUM FULL would be able to compress the actual
index file and return unused space to the operating system. REINDEX
does this, but I was thinking of something a little
On Wed, 12 Feb 2003, Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
You cannot change SHMMAX on the fly on FreeBSD.
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
On Wed, 12 Feb 2003, J. M. Brenner wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
Okay, here's one: most Unix systems store all of the configuration
files in a well known directory: /etc. These days it's a hierarchy of
directories with /etc as the root of the hierarchy.
The sad thing is that my readline wrapper for libedit doesn't wrap
replace_history_entry, so I could use readline up until now, the tests
for readline succeed as the functions tested for exist, but
command.o: In function `do_edit':
/usr/src/local/pgsql/src/bin/psql/command.c:1652: undefined
-Original Message-
From: Christopher Browne [mailto:[EMAIL PROTECTED]]
Sent: 13 February 2003 13:33
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] location of the configuration files
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
On Wed, 12 Feb 2003,
mlw [EMAIL PROTECTED] writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instances
running on a single machine. This is not unrelated.
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instances
running
Patrick Welche [EMAIL PROTECTED] writes:
The sad thing is that my readline wrapper for libedit doesn't wrap
replace_history_entry,
Well, is that a bug in your wrapper? Or must we add a configure test
for the presence of replace_history_entry()?
regards, tom lane
On Thursday 13 February 2003 10:03, Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple
Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instances
running
Tom Lane wrote:
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
Bruce Momjian wrote:
Well, in a sense, it trades passing one parameter, PGDATA, for another.
I see your point that we should specify configuration first, and let
everything pass from there. However, it does add extra configuration
parameters, and because you still need to specify/create
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:
hbafile= '/etc/postgres/pg_hba.conf'
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:
hbafile= '/etc/postgres/pg_hba.conf'
On Thu, 2003-02-13 at 19:30, Robert Treat wrote:
If we're going to do this, I think we need to account for all of the
files in the directory including PG_VERSION, postmaster.opts,
Not PG_VERSION; that is intimately associated with the data itself and
ought to stay in the data directory.
--
Bruce Momjian wrote:
Patrick Macdonald wrote:
Bruce Momjian wrote:
Someone at Red Hat is working on point-in-time recovery, also known as
incremental backups.
PITR and incremental backup are different beasts. PITR deals with a backup
+ logs. Incremental backup deals with a
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.
--
Peter Eisentraut [EMAIL PROTECTED]
mlw writes:
AFAIK it wasn't actually done. It was more of a, we should do something
different argument. At one point it was talked about rewriting the
configuration system to allow include and other things.
The core of the problem was, and continues to be, this: If you move
postgresql.conf
Peter Eisentraut wrote:
mlw writes:
AFAIK it wasn't actually done. It was more of a, "we should do something
different" argument. At one point it was talked about rewriting the
configuration system to allow "include" and other things.
The core of the problem was, and
Pardon my ignorance, but there's no way to auto-tune? Ship it with a thread
that gathers statistics and periodically re-tunes the database parameters.
Of course, be able to turn it off. People that actually take the time to run
tune manually will turn it off as to not have the overhead or
Lamar Owen wrote:
This isn't the same environment, Bruce, that you got into back when it was
still Postgres95. We are in the big leagues OS-wise, and we need to act like
it. Assuming that we are a 'userspace' program (which is a misnomer anyway,
as _anything_ non-kernel is 'userspace') is
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Speculation time: do you have the IPv6 code compiled in? I don't.
I have IPv6 enabled in the binary, but not the kernel.
Sure enough, the IPV6 patch had broken error handling in the non-IPV6
path.
I've done a little bit of cleanup, but
Michael Brusser wrote:
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
On Thursday 13 February 2003 20:09, Bruce Momjian wrote:
Lamar Owen wrote:
This isn't the same environment, Bruce, that you got into back when it
was still Postgres95.
So you are saying this isn't my grandma's database anymore. :-)
I actually thought of saying it that way, too. :-)
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Speculation time: do you have the IPv6 code compiled in? I don't.
I have IPv6 enabled in the binary, but not the kernel.
Sure enough, the IPV6 patch had broken error handling in the non-IPV6
path.
I've done a
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I've done a little bit of cleanup, but that code is still a mess...
someone should rewrite these routines.
Yes, I looked at it and struggled to get both IPv4 and IPv6 cleanly
working. Any ideas on how to improve it?
The major problem
Lamar Owen wrote:
First, a few conclusions:
We can't use /var/run because we need the postmaster to create
those, and it isn't root.
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.
Tom Lane kirjutas R, 14.02.2003 kell 01:13:
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?
From
Bruce Momjian said:
I imagined they could run pgtune anytime after install to update those
performance parameters. It gives them a one-stop location to at least
do minimal tuning, and as their load changes, they can run it again.
True, but to make reasonably good choice, they will need
101 - 149 of 149 matches
Mail list logo
