Обсуждение: IPC Memory problem with Postmaster on BSDi 4.x
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
> 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, Pennsylvania19026
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
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
> >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, Pennsylvania19026
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
> 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, Pennsylvania19026
> > 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
> > > 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, Pennsylvania19026
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, sothe 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 userand 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 anybetter way to trap for that? Should the default number of backends be made something less than 32 so that the "commonsetting" 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 >
> 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
"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
> > 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.
> 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" ...)
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
> 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.
"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
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
> 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
"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
> 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
> "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, Pennsylvania19026
> "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.
"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