I have PostgreSQL 6.4.2 installed since before and it was pretty easy to
compile it except for a few minor things. But but today I planned to
upgrade to version 6.5.1. So I made a pg_dumpall and backed up the rest and
deleted my /usr/local/pgsql to install the new version there.

The compilation and all worked great, it recognised the system as BSDi 4
which is correct and no errors. After this I logged in as postgres user and
wrote "initdb", worked great, BUT when I wrote "postmaster -i" I got a big
problem which I have never got ever before and I don't know why. Here is
the error message from postmaster ->

IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
size=1063936, permission=600
FATAL 1:  ShmemCreate: cannot create region

To me it sounds like it is using some kind of wrong argument with shmget,
but I don't know how to fix this. I hope someone can help me.

This is what I get when I write ipcs ->
Message Queues:
T           ID          KEY        MODE    OWNER    GROUP

Shared Memory:
T           ID          KEY        MODE    OWNER    GROUP
m       196608      5432210 --rwa------ postgres     user
m       196609      5432201 --rw------- postgres     user
m       983042      5432207 --rw------- postgres     user
m      1376259      5432010 --rwa------ postgres postgres
m       131076      5432001 --rw------- postgres     user
m       786437      5432007 --rw------- postgres postgres

Semaphores:
T           ID          KEY        MODE    OWNER    GROUP

If it's anything I need to do with IPC or PostgreSQL, please let me know
what and how, or maybe this is a bug ?  I hope not, I love this database
engine and really wanna start using 6.5.1 asap.

Sincerely
Roberth Andersson

Roberth Andersson, Server Administrator @ Jump-Gate & Webworqs
Phone:	011-46-550-17864
Cellphone:	011-46-70-6422024
EMail:	roberth@jump-gate.com / roberth@webworqs.com


Sat, 31 Jul 1999 05:53:30 +0200
Roberth Andersson <roberth@jump-gate.com>
IPC Memory problem with Postmaster on BSDi 4.x
> IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
> size=1063936, permission=600
> FATAL 1:  ShmemCreate: cannot create region
> 
> To me it sounds like it is using some kind of wrong argument with shmget,
> but I don't know how to fix this. I hope someone can help me.
> 
> This is what I get when I write ipcs ->
> Message Queues:
> T           ID          KEY        MODE    OWNER    GROUP
> 
> Shared Memory:
> T           ID          KEY        MODE    OWNER    GROUP
> m       196608      5432210 --rwa------ postgres     user
> m       196609      5432201 --rw------- postgres     user
> m       983042      5432207 --rw------- postgres     user
> m      1376259      5432010 --rwa------ postgres postgres
> m       131076      5432001 --rw------- postgres     user
> m       786437      5432007 --rw------- postgres postgres
> 
> Semaphores:
> T           ID          KEY        MODE    OWNER    GROUP
> 
> If it's anything I need to do with IPC or PostgreSQL, please let me know
> what and how, or maybe this is a bug ?  I hope not, I love this database
> engine and really wanna start using 6.5.1 asap.

I am running BSDI here.  Try using pgsql/bin/ipcclean to remove the
current shared memory stuff.  Seems the old version did not clean up its
shared memory.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 31 Jul 1999 00:11:19 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x
Roberth Andersson <roberth@jump-gate.com> writes:
> BUT when I wrote "postmaster -i" I got a big
> problem which I have never got ever before and I don't know why. Here is
> the error message from postmaster ->

> IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
> size=1063936, permission=600
> FATAL 1:  ShmemCreate: cannot create region

The kernel error message ("Invalid argument", here) is often very
unhelpful when dealing with shared memory and semaphore operations :-(
I will bet that the real problem is that your kernel is configured
not to allow shared mem regions bigger than 1 megabyte --- but could
it say "Request too big", or some such?  Nooo...

Postgres 6.5 defaults to wanting a shmem region just over a meg, whereas
6.4 was just under IIRC, so this problem will bite anyone who has the
fairly common kernel parameter setting SHMEMMAX = 1meg.

If that's the problem, you can either reconfigure your kernel with a
larger SHMEMMAX setting, or start Postgres with smaller-than-default
limits on number of buffers and backends.  I'd try -N 16 for starters.

Another possibility is that you are running into a kernel limit on the
total amount of shared memory, not the size of this individual chunk.
You say:

> This is what I get when I write ipcs ->
> Message Queues:
> T           ID          KEY        MODE    OWNER    GROUP

> Shared Memory:
> T           ID          KEY        MODE    OWNER    GROUP
> m       196608      5432210 --rwa------ postgres     user
> m       196609      5432201 --rw------- postgres     user
> m       983042      5432207 --rw------- postgres     user
> m      1376259      5432010 --rwa------ postgres postgres
> m       131076      5432001 --rw------- postgres     user
> m       786437      5432007 --rw------- postgres postgres

> Semaphores:
> T           ID          KEY        MODE    OWNER    GROUP

If you do not have a postmaster running then those postgres-owned shared
memory segments should not be there; they must be left over from some
old run where the postmaster crashed without releasing 'em :-(.  They
could be causing the kernel to decide it's given out too much shared
memory.  Use ipcclean to get rid of them.

			regards, tom lane

Sat, 31 Jul 1999 11:55:45 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x 
At 00:11 1999-07-31 -0400, you wrote:
>> IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
>> size=1063936, permission=600
>> FATAL 1:  ShmemCreate: cannot create region
>> 
>> To me it sounds like it is using some kind of wrong argument with shmget,
>> but I don't know how to fix this. I hope someone can help me.
>> 
>> This is what I get when I write ipcs ->
>> Message Queues:
>> T           ID          KEY        MODE    OWNER    GROUP
>> 
>> Shared Memory:
>> T           ID          KEY        MODE    OWNER    GROUP
>> m       196608      5432210 --rwa------ postgres     user
>> m       196609      5432201 --rw------- postgres     user
>> m       983042      5432207 --rw------- postgres     user
>> m      1376259      5432010 --rwa------ postgres postgres
>> m       131076      5432001 --rw------- postgres     user
>> m       786437      5432007 --rw------- postgres postgres
>> 
>> Semaphores:
>> T           ID          KEY        MODE    OWNER    GROUP
>> 
>> If it's anything I need to do with IPC or PostgreSQL, please let me know
>> what and how, or maybe this is a bug ?  I hope not, I love this database
>> engine and really wanna start using 6.5.1 asap.
>
>I am running BSDI here.  Try using pgsql/bin/ipcclean to remove the
>current shared memory stuff.  Seems the old version did not clean up its
>shared memory.

Thanks Bruce

I tried to do that and it worked just fine the first time, and after that I
wrote "ipcs" to get a statistical if it really was cleaned or not, but I
got this ->

Message Queues:
T           ID          KEY        MODE    OWNER    GROUP

Shared Memory:
T           ID          KEY        MODE    OWNER    GROUP
m      1376259            0 --rwa------ postgres postgres
m       131076            0 --rw------- postgres     user
m       786437            0 --rw------- postgres postgres

Semaphores:
T           ID          KEY        MODE    OWNER    GROUP

Now I tried to use "ipcclean" once again, and I am always getting these
errors ->

ipcrm: shmid(1376259): : Invalid argument
ipcrm: shmid(131076): : Invalid argument
ipcrm: shmid(786437): : Invalid argument

I have no idea why, except maybe this could be something that is left over
since old and now the system doesn't know how to remove this Postgres stuff.

If anyone have any clue about what I can do, please let me know, I would
appreciate it a lot.

Sincerely

Roberth Andersson, Server Administrator @ Jump-Gate & Webworqs
Phone:	011-46-550-17864
Cellphone:	011-46-70-6422024
EMail:	roberth@jump-gate.com / roberth@webworqs.com


Sat, 31 Jul 1999 18:22:20 +0200
Roberth Andersson <roberth@jump-gate.com>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x
> >I am running BSDI here.  Try using pgsql/bin/ipcclean to remove the
> >current shared memory stuff.  Seems the old version did not clean up its
> >shared memory.
> 
> Thanks Bruce
> 
> I tried to do that and it worked just fine the first time, and after that I
> wrote "ipcs" to get a statistical if it really was cleaned or not, but I
> got this ->
> 
> Message Queues:
> T           ID          KEY        MODE    OWNER    GROUP
> 
> Shared Memory:
> T           ID          KEY        MODE    OWNER    GROUP
> m      1376259            0 --rwa------ postgres postgres
> m       131076            0 --rw------- postgres     user
> m       786437            0 --rw------- postgres postgres
> 
> Semaphores:
> T           ID          KEY        MODE    OWNER    GROUP
> 
> Now I tried to use "ipcclean" once again, and I am always getting these
> errors ->
> 
> ipcrm: shmid(1376259): : Invalid argument
> ipcrm: shmid(131076): : Invalid argument
> ipcrm: shmid(786437): : Invalid argument
> 
> I have no idea why, except maybe this could be something that is left over
> since old and now the system doesn't know how to remove this Postgres stuff.
> 
> If anyone have any clue about what I can do, please let me know, I would
> appreciate it a lot.

Go to /tmp, and do a ls -la.  There will be some file in there that are
left over that should be deleted.  But now that I look, they aren't in
/tmp anymore in 4.0.  Use ipcs and ipcrm to manually delete them.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 31 Jul 1999 12:53:47 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x


On Sat, 31 Jul 1999, Tom Lane wrote:

> Roberth Andersson <roberth@jump-gate.com> writes:
> > IpcMemoryCreate: shmget failed (Invalid argument) key=5432001,
> > size=1063936, permission=600
> > FATAL 1:  ShmemCreate: cannot create region
> 
> The kernel error message ("Invalid argument", here) is often very
> unhelpful when dealing with shared memory and semaphore operations :-(

FWIW, I'm just installing v6.5.1 on Solaris 2.5 -- and lo!  I had the
same problem, and sure enough, SHMEMMAX is 1meg, and -N 16 worked like a
charm!  So Tom, looks like you're right.  As always.

Since this was my first time compiling/installing pgsql, I've noticed a
couple of oopses (maybe mine) in the installation instructions...  Who do
I talk to to update them?  (Example: Instead of being able simply to type
"initdb" to get started, I had to specify a user with "initdb -u
postgres".  That kind of stuff.)

Michael


Sun, 1 Aug 1999 13:58:08 -0500 (EST)
"J. Michael Roberts" <mirobert@cs.indiana.edu>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x 
> Since this was my first time compiling/installing pgsql, I've noticed a
> couple of oopses (maybe mine) in the installation instructions...  Who do
> I talk to to update them?  (Example: Instead of being able simply to type
> "initdb" to get started, I had to specify a user with "initdb -u
> postgres".  That kind of stuff.)

Send it to hackers or focs.  Either is good.  The -u may be because of
your pg_hba.conf file.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 1 Aug 1999 16:14:42 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x
> > Since this was my first time compiling/installing pgsql, I've noticed a
> > couple of oopses (maybe mine) in the installation instructions...  Who do
> > I talk to to update them?
> Send it to hackers or focs.  Either is good.  The -u may be because of
> your pg_hba.conf file.

If you have trouble finding the "focs" list, try "docs" instead ;)

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Sun, 01 Aug 1999 21:05:26 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x
> > > Since this was my first time compiling/installing pgsql, I've noticed a
> > > couple of oopses (maybe mine) in the installation instructions...  Who do
> > > I talk to to update them?
> > Send it to hackers or focs.  Either is good.  The -u may be because of
> > your pg_hba.conf file.
> 
> If you have trouble finding the "focs" list, try "docs" instead ;)
> 

Shhh, don't tell everyone else about the focs list.  :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 1 Aug 1999 17:42:27 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x
You people are harsh.

BTW, I didn't modify the pg_hba.conf file at all since I want to allow
only local use, so ... um ... since I really haven't digested the usage of
the whole host configuration thing, I haven't the faintest clue whether
that would be the problem.

However, either way, I'd like to understand what happened and make sure
that the next hapless newbie doesn't spend as much time on it as I did.
Which, granted, wasn't that much time.

Here are a couple of surprises, then, that I encountered during this.

- initdb complained that it couldn't find a user.  I gave it -u postgres.
- I needed to install flex (no surprise) -- the instructions are quite
  explicit, but, well, wrong: flex depends on bison.  So you have to get
  and compile bison first.  Also, the GNU FTP server has "redisorganized"
  their file structure, so the very detailed FTP instructions for getting
  flex are also outdated.
- Being only halfway a sysadmin, I was a little worried about making a
  postgres "superuser".  I just made a postgres user and didn't worry
  about the super part, and it seems to work.  Am I missing a point?
- The aforementioned shared memory problem was distressing.  Thank God
  somebody else had just encountered it.  Is there any better way to
  trap for that?  Should the default number of backends be made something
  less than 32 so that the "common setting" of 1 meg will be safe?  Am I
  being too wimpy?

That's pretty much it.  Seems to be perking along happily now, but I
haven't run the regression tests yet.

On Sun, 1 Aug 1999, Thomas Lockhart wrote:

> > > Since this was my first time compiling/installing pgsql, I've noticed a
> > > couple of oopses (maybe mine) in the installation instructions...  Who do
> > > I talk to to update them?
> > Send it to hackers or focs.  Either is good.  The -u may be because of
> > your pg_hba.conf file.
> 
> If you have trouble finding the "focs" list, try "docs" instead ;)
> 
>                      - Thomas
> 
> -- 
> Thomas Lockhart				lockhart@alumni.caltech.edu
> South Pasadena, California
> 


Sun, 1 Aug 1999 17:21:02 -0500 (EST)
"J. Michael Roberts" <mirobert@cs.indiana.edu>
[HACKERS] Installation procedure.
> You people are harsh.

Ooh, a compliment. We live for those... ;)

> - initdb complained that it couldn't find a user.  I gave it -u postgres.

This is the only report of this I can remember (others might remind me
otherwise, but...). The best I can tell you somehow didn't have a USER
environment variable or mucked around with accounts between building
software and trying to initdb. There are several messages from initdb
with similar wording but with different diagnostics so you would need
to send the actual text or look in the initdb source code yourself
(src/bin/initdb/initdb.sh).

> - I needed to install flex (no surprise) -- the instructions are quite
>   explicit, but, well, wrong: flex depends on bison.  So you have to get
>   and compile bison first.  Also, the GNU FTP server has "redisorganized"
>   their file structure, so the very detailed FTP instructions for getting
>   flex are also outdated.

Thanks. Can you give a suggestion for a more helpful phrasing for
this, or a better choice of content?

> - Being only halfway a sysadmin, I was a little worried about making a
>   postgres "superuser".  I just made a postgres user and didn't worry
>   about the super part, and it seems to work.  Am I missing a point?

Only sort of. The "postgres superuser" is a normal user as far as the
OS is concerned, but is a superuser as far as the Postgres
installation is concerned. Ya done good.

> - The aforementioned shared memory problem was distressing.  Thank God
>   somebody else had just encountered it.  Is there any better way to
>   trap for that?  Should the default number of backends be made something
>   less than 32 so that the "common setting" of 1 meg will be safe?  Am I
>   being too wimpy?

This is the first release where the shared memory size was actually
being calculated correctly. The numbers used pretty much match the
theoretical (but incorrectly calculated) maximum limits in previous
releases, but the calculated number is bigger and a few OSes seem to
cough. Your OS is being wimpy imho, but the workaround is pretty easy.

Do you have a specific suggestion for a change here in the docs?
Probably no need to change the build procedure, but perhaps a warning
about possible startup problems?

Have fun with the new toy...

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Mon, 02 Aug 1999 03:32:49 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Installation procedure.
"J. Michael Roberts" <mirobert@cs.indiana.edu> writes:
> Since this was my first time compiling/installing pgsql, I've noticed a
> couple of oopses (maybe mine) in the installation instructions...  Who do
> I talk to to update them?  (Example: Instead of being able simply to type
> "initdb" to get started, I had to specify a user with "initdb -u
> postgres".  That kind of stuff.)

FWIW, I think I know the cause of that one --- initdb, and also the
regression tests (and maybe other places?) look at the USER environment
variable by default to get the name of the postgres user.  If you are
on a platform that doesn't ordinarily set USER, you lose.  I've been
burnt by that myself.

I am not sure whether we ought to make the code look at LOGNAME as
a fallback if USER isn't set, or just document that you ought to set
USER.  The first sounds good, but I wonder what the odds are of
picking up the wrong username.  On my platform, for example, su'ing
to the postgres account does *not* change LOGNAME, which would mean
initdb would pick the wrong thing.  Maybe what we need is just a
better error message ("USER environment variable is not set, please
set it or provide -u switch" ...)

			regards, tom lane

Sun, 01 Aug 1999 23:50:58 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x 
> > You people are harsh.
> Ooh, a compliment. We live for those... ;)

Heh.

> > - initdb complained that it couldn't find a user.  I gave it -u postgres.
> 
> This is the only report of this I can remember (others might remind me
> otherwise, but...). The best I can tell you somehow didn't have a USER
> environment variable or mucked around with accounts between building
> software and trying to initdb.

Aha.  Come to think of it, I'm sure that I was actually root su'd to
postgres.  That was probably the problem.  I hadn't even thought of that.

> > - I needed to install flex (no surprise) -- the instructions are quite
> >   explicit, but, well, wrong: flex depends on bison.
> Thanks. Can you give a suggestion for a more helpful phrasing for
> this, or a better choice of content?

Will do.  Um, "soon."  Actually, I was very heartened by the explicit
detail.

> > - Being only halfway a sysadmin, I was a little worried about making a
> >   postgres "superuser".  I just made a postgres user and didn't worry
> >   about the super part, and it seems to work.  Am I missing a point?
> 
> Only sort of. The "postgres superuser" is a normal user as far as the
> OS is concerned, but is a superuser as far as the Postgres
> installation is concerned. Ya done good.

IMHO that should probably be more explicit in INSTALL.  I'll update it.

> Your OS is being wimpy imho, but the workaround is pretty easy.
> 
> Do you have a specific suggestion for a change here in the docs?
> Probably no need to change the build procedure, but perhaps a warning
> about possible startup problems?

Yeah, that would be a good idea.  Again, sounds like it's up to me to
revise INSTALL a bit.

> Have fun with the new toy...

Toy, schmoy.  This is going to back up several web sites.  After the
recent glowing description on this mailing list of v6.5.1, I decided to
take the plunge and junk Illustra (the total lack of support and
documentation and tuning and licensing freedom and so on have finally
taken their toll on my confidence...)  Wish me luck.


Sun, 1 Aug 1999 22:53:22 -0500 (EST)
"J. Michael Roberts" <mirobert@cs.indiana.edu>
Re: [HACKERS] Installation procedure.
> If you are
> on a platform that doesn't ordinarily set USER, you lose.  I've been
> burnt by that myself.
> 
> I am not sure whether we ought to make the code look at LOGNAME as
> a fallback if USER isn't set, or just document that you ought to set
> USER.

My take would be at least to change the installation documentation,
and improve the error message (you can never improve error message *too*
much).  Getting clever about what username to use seems more dangerous
than helpful, and besides, it's simple enough simply to say "initdb needs
to figure out your user somehow" and leave it at that.  How often do you
run initdb anyway?

  The first sounds good, but I wonder what the odds are of
> picking up the wrong username.  On my platform, for example, su'ing
> to the postgres account does *not* change LOGNAME, which would mean
> initdb would pick the wrong thing.  Maybe what we need is just a
> better error message ("USER environment variable is not set, please
> set it or provide -u switch" ...)


Sun, 1 Aug 1999 23:12:22 -0500 (EST)
"J. Michael Roberts" <mirobert@cs.indiana.edu>
Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x 
Great stuff, Michael.  I think by the time most of us got to the point
of contributing much to Postgres, we'd forgotten the little glitches
we hit on the first try.  Cleaning up these issues is definitely
worthwhile, and I am glad to see you willing to help out.

Thomas already gave good responses about the technical issues,
but I have one point to add:

>> - The aforementioned shared memory problem was distressing.  Thank God
>> somebody else had just encountered it.  Is there any better way to
>> trap for that?  Should the default number of backends be made something
>> less than 32 so that the "common setting" of 1 meg will be safe?  Am I
>> being too wimpy?

> This is the first release where the shared memory size was actually
> being calculated correctly. The numbers used pretty much match the
> theoretical (but incorrectly calculated) maximum limits in previous
> releases, but the calculated number is bigger and a few OSes seem to
> cough. Your OS is being wimpy imho, but the workaround is pretty easy.

Actually, when we set the default MAXBACKENDS to 32 for 6.5, it was
done specifically to ensure that the default shared mem block size would
stay under a meg.  (The equivalent setting in 6.4 was 64 backends.)
But I guess various data structures changed a little bit after that
time, and we ended up on the wrong side of the breakpoint without
thinking about it.

Should we cut the default MAXBACKENDS some more, or just try to
document the issue better?

			regards, tom lane

Mon, 02 Aug 1999 00:46:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Installation procedure. 
> Actually, when we set the default MAXBACKENDS to 32 for 6.5, it was
> done specifically to ensure that the default shared mem block size would
> stay under a meg.  (The equivalent setting in 6.4 was 64 backends.)
> But I guess various data structures changed a little bit after that
> time, and we ended up on the wrong side of the breakpoint without
> thinking about it.

Oops.  :-)

> Should we cut the default MAXBACKENDS some more, or just try to
> document the issue better?

I've added a paragraph to the system requirements in INSTALL which
explains the situation.  Now to figure out how to get the changes to you
guys....  Is the procedure simply to diff it and email it to somebody, or
what?  Just because I've been lurking on this list for nearly a year now
doesn't mean I know what I'm doing.

As to whether MAXBACKENDS should be changed -- I have no idea what impact
that would actually have.  What *is* a backend, precisely?  In Illustra,
anyway, each active query starts a new process while it's working -- is
that a backend?  I've never seen more than about 5 on my own server (not
that I hang around monitoring all the time) so 16 seems capacious.




Sun, 1 Aug 1999 23:56:08 -0500 (EST)
"J. Michael Roberts" <mirobert@cs.indiana.edu>
Re: [HACKERS] Installation procedure. 
"J. Michael Roberts" <mirobert@cs.indiana.edu> writes:
> Now to figure out how to get the changes to you
> guys....  Is the procedure simply to diff it and email it to somebody, or
> what?

Standard operating procedure is to make a patch-compatible diff
(I think -c format is preferred) and post it to the pgsql-patches
mailing list.  If you have a real good idea which core member is
probably going to apply the patch you could send it just to that
person, but it's more courteous to put it on the public mailing list.

> As to whether MAXBACKENDS should be changed -- I have no idea what impact
> that would actually have.  What *is* a backend, precisely?  In Illustra,
> anyway, each active query starts a new process while it's working -- is
> that a backend?

No.  There's one backend process per client connection; it lives till
the client disconnects, and handles all queries that come through that
connection.  So MAXBACKENDS really means "how many simultaneous
clients am I expecting"?

			regards, tom lane

Mon, 02 Aug 1999 01:09:43 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Installation procedure. 
On Mon, 2 Aug 1999, Tom Lane wrote:

> Great stuff, Michael.  I think by the time most of us got to the point
> of contributing much to Postgres, we'd forgotten the little glitches
> we hit on the first try.  Cleaning up these issues is definitely
> worthwhile, and I am glad to see you willing to help out.
> 
> Thomas already gave good responses about the technical issues,
> but I have one point to add:
> 
> >> - The aforementioned shared memory problem was distressing.  Thank God
> >> somebody else had just encountered it.  Is there any better way to
> >> trap for that?  Should the default number of backends be made something
> >> less than 32 so that the "common setting" of 1 meg will be safe?  Am I
> >> being too wimpy?
> 
> > This is the first release where the shared memory size was actually
> > being calculated correctly. The numbers used pretty much match the
> > theoretical (but incorrectly calculated) maximum limits in previous
> > releases, but the calculated number is bigger and a few OSes seem to
> > cough. Your OS is being wimpy imho, but the workaround is pretty easy.
> 
> Actually, when we set the default MAXBACKENDS to 32 for 6.5, it was
> done specifically to ensure that the default shared mem block size would
> stay under a meg.  (The equivalent setting in 6.4 was 64 backends.)
> But I guess various data structures changed a little bit after that
> time, and we ended up on the wrong side of the breakpoint without
> thinking about it.
> 
> Should we cut the default MAXBACKENDS some more, or just try to
> document the issue better?

My opinion...cut it back to 16 and document.  Reason: those new won't hit
the problem, and those that have started to use it in "more production
environments" will have started to look into performance tuning, and most
likely have at least scan'd thruogh the postmaster man page (and will have
seen the -B option)...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Mon, 2 Aug 1999 02:21:42 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Installation procedure. 
> IMHO that should probably be more explicit in INSTALL.  I'll update it.

Oops. Sorry I took a break for dinner (I see another e-mail or two
referencing INSTALL too).

The changes need to happen in doc/src/sgml/install.sgml, which is the
source code from which INSTALL is derived. If you look at that file I
think you will see how it corresponds to the output file.

If you can make changes and preserve the sgml markup, great. If not,
just send patches with text inserted in the right places and I'll
finish up the markup.

If your changes to INSTALL are pretty isolated, then I can also accept
patches on that file. But ones on the sgml source would be easier.

> Toy, schmoy.  This is going to back up several web sites.  After the
> recent glowing description on this mailing list of v6.5.1, I decided to
> take the plunge and junk Illustra (the total lack of support and
> documentation and tuning and licensing freedom and so on have finally
> taken their toll on my confidence...)  Wish me luck.

We'll be interested in hearing how it goes. afaik Illustra was
"Postgres done right", based on Postgres as of a few years ago with
some sections rewritten. In the meantime, PostgreSQL has had
substantial improvements, and I wonder if we've caught up to or passed
where Illustra froze.

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Mon, 02 Aug 1999 05:38:43 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] Installation procedure.
"J. Michael Roberts" <mirobert@cs.indiana.edu> writes:
> - I needed to install flex (no surprise) -- the instructions are quite
>   explicit, but, well, wrong: flex depends on bison.  So you have to get
>   and compile bison first.

BTW, does anyone understand *why* our lexer files require flex and not
just garden-variety lex?  Would it be worth trying to make them more
portable?

Or perhaps we should ship pre-lexed derived files, as we do for the
larger grammar files?

Having to install bison & flex is probably the most annoying Postgres
prerequisite for people on non-Linux platforms, so I think it would
be nice to clean this up.  I hadn't realized that you're essentially
forced to install both...

			regards, tom lane

Mon, 02 Aug 1999 10:22:45 -0400
Tom Lane <tgl@sss.pgh.pa.us>
flex (was Re: [HACKERS] Installation procedure.)
> BTW, does anyone understand *why* our lexer files require flex and not
> just garden-variety lex?  Would it be worth trying to make them more
> portable?

Some of the oldest and cruftiest AT&T lexers do not support the
concept of an exclusive start state, which we use extensively (it's my
fault; makes for *much* cleaner specifications).

Unfortunately, Sun adopted some SysV packages when they made the
switch from BSD, and got a bad lexer in the bargain. afaik, most other
systems ship a more capable package.

> Or perhaps we should ship pre-lexed derived files, as we do for the
> larger grammar files?

Yes, that would probably be a good idea...

                    - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Mon, 02 Aug 1999 14:46:52 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: flex (was Re: [HACKERS] Installation procedure.)
> "J. Michael Roberts" <mirobert@cs.indiana.edu> writes:
> > - I needed to install flex (no surprise) -- the instructions are quite
> >   explicit, but, well, wrong: flex depends on bison.  So you have to get
> >   and compile bison first.
> 
> BTW, does anyone understand *why* our lexer files require flex and not
> just garden-variety lex?  Would it be worth trying to make them more
> portable?

Can we do that?  Is flex actually required too?

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 2 Aug 1999 11:07:05 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: flex (was Re: [HACKERS] Installation procedure.)

> "J. Michael Roberts" <mirobert@cs.indiana.edu> writes:
> > - I needed to install flex (no surprise) -- the instructions are quite
> >   explicit, but, well, wrong: flex depends on bison.  So you have to get
> >   and compile bison first.
> 
> BTW, does anyone understand *why* our lexer files require flex and not
> just garden-variety lex?  Would it be worth trying to make them more
> portable?
> 
> Or perhaps we should ship pre-lexed derived files, as we do for the
> larger grammar files?
> 
> Having to install bison & flex is probably the most annoying Postgres
> prerequisite for people on non-Linux platforms, so I think it would
> be nice to clean this up.  I hadn't realized that you're essentially
> forced to install both...

You undoubtedly already had both installed...

For the record, if configure doesn't find flex, it assumes lex.  The
problem is if you don't even have lex.

However, the pre-lexed derived files are a good idea.  If somebody then
really wants to mess with those, they can go get flex.  That means that
the standard distribution *wouldn't* require flex.  For me, it was a good
excuse to get the lead out and finally install flex and bison (OK, it took
me only about fifteen minutes, but you know how those to-do lists get).
But if my only goal were just to get Postgres running, that would be a
rather unnecessary step.


Mon, 2 Aug 1999 10:47:58 -0500 (EST)
"J. Michael Roberts" <mirobert@cs.indiana.edu>
Re: flex (was Re: [HACKERS] Installation procedure.)
"J. Michael Roberts" <mirobert@cs.indiana.edu> writes:
> For the record, if configure doesn't find flex, it assumes lex.  The
> problem is if you don't even have lex.

Or if you have lex but it doesn't work on Postgres' .l files, as indeed
is true for the vendor lex on HPUX, and probably some other systems.

> However, the pre-lexed derived files are a good idea.

Yah.  This has been discussed before, but no one has got round to it...

			regards, tom lane

Mon, 02 Aug 1999 12:55:54 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: flex (was Re: [HACKERS] Installation procedure.) 