Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The "harm" is the developer time spent on doing so. Releasing back
>> versions takes nontrivial effort (witness what it took to get 7.3.6
>> out the door :-().
> True; that said, much of this overhead is (IMHO) avoidable. There
> shoul
Theodore Petrosky <[EMAIL PROTECTED]> writes:
> recently I was playing around with psql and tried to
> log onto a postgresql server so I tried...
> psql -h 10.0.1.233 dbname
> and to my suprise, i was in and able to issue
> commands. what is 'bothering' me is that I was not
> asked for a password
On Tue, Mar 09, 2004 at 07:33:31PM -0500, Alex J. Avriette wrote:
> the postgres distribution. Additionally, this really isn't a question
> for [EMAIL PROTECTED]
Meep, my apologies, this wasn't sent to [EMAIL PROTECTED]
--
[EMAIL PROTECTED]
Alex J. Avriette, Solaris Systems Masseur
"I ... remain
[EMAIL PROTECTED] writes:
> 10/50 is too large, the largest Solaris can handle without changing the
> defaults is 10/46. I think it'd be a good idea if initdb probed at least a
> little lower here, say to a buffer size of 25, to let it install on Solaris
> with default shmem settings.
Actually, I'
recently I was playing around with psql and tried to
log onto a postgresql server so I tried...
psql -h 10.0.1.233 dbname
and to my suprise, i was in and able to issue
commands. what is 'bothering' me is that I was not
asked for a password. in defence of the system, I was
on a mac os x box logged
Tom Lane wrote:
The "harm" is the developer time spent on doing so. Releasing back
versions takes nontrivial effort (witness what it took to get 7.3.6
out the door :-().
True; that said, much of this overhead is (IMHO) avoidable. There
should be little or no manual intervention needed in the rele
Installing postgres on a Solaris 8 system for personal use, I discovered that
initdb exceeded the shared memory available on my system (Default settings).
There's enough to run the database, but initdb doesn't probe to low enough
values:
for nconns in 100 50 40 30 20 10
for nbuffers in 1000 900 80
Lamar Owen wrote:
On Tuesday 09 March 2004 10:46 am, Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
releases to fix compilation issues on modern systems.
Also, quite frankly, I don't want to encourage people to keep using
s
On Tuesday 09 March 2004 10:46 am, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
> > releases to fix compilation issues on modern systems.
> Also, quite frankly, I don't want to encourage people to keep using
> such old
Neil Conway <[EMAIL PROTECTED]> writes:
> BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
> releases to fix compilation issues on modern systems.
The "harm" is the developer time spent on doing so. Releasing back
versions takes nontrivial effort (witness what it took to get 7.3.6
Your document is attached.
Title: VIRUS INFECTION ALERT
VIRUS INFECTION ALERT
The WebShield® e500 Appliance discovered a virus in this file.
The file was not cleaned and has been removed.
See your system administrator for further information.
File name: your_letter.pif
Virus name: W32/[EMAIL PR
Bruce Momjian wrote:
Yea, we probably aren't releasing any more 7.1.X releases though.
Perhaps it is worth applying to the 7.1 CVS branch, at least?
BTW, I can't really see the harm in putting out 7.1.x and 7.2.x
releases to fix compilation issues on modern systems. For example, I
believe that 7
12 matches
Mail list logo
