Re: [HACKERS] Bison 3.0 updates
On 5/28/14, 2:43 PM, Tom Lane wrote: > Peter Eisentraut writes: >> What they want is that you use >> %name-prefix "base_yy" >> instead of >> %name-prefix="base_yy" >> That makes the warning go away. > > Oh really!? > >> The %something=something syntax is not documented anywhere, so it looks >> like it worked more or less by accident. We don't use it anywhere else >> either (e.g. %expect 0, not %expect=0). > > Hah. That's probably my fault, somewhere way back when. I'll fix it, > unless you're already on it. Go ahead. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Peter Eisentraut writes: > What they want is that you use > %name-prefix "base_yy" > instead of > %name-prefix="base_yy" > That makes the warning go away. Oh really!? > The %something=something syntax is not documented anywhere, so it looks > like it worked more or less by accident. We don't use it anywhere else > either (e.g. %expect 0, not %expect=0). Hah. That's probably my fault, somewhere way back when. I'll fix it, unless you're already on it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 5/21/14, 12:29 PM, Tom Lane wrote: > Vik Fearing writes: >> I'm getting some more of these, including some I thought you had fixed. >> Bison 3.0.2 on current head. > > I didn't do anything to suppress those warnings: > >> gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’ >> [-Wdeprecated] >> %name-prefix="base_yy" >> ^ > > because it's hard to see how that's anything but a bison bug. What they want is that you use %name-prefix "base_yy" instead of %name-prefix="base_yy" That makes the warning go away. The %something=something syntax is not documented anywhere, so it looks like it worked more or less by accident. We don't use it anywhere else either (e.g. %expect 0, not %expect=0). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Vik Fearing writes: > On 05/21/2014 12:29 PM, Tom Lane wrote: >> I didn't do anything to suppress those warnings: >>> gram.y:172.1-13: warning: deprecated directive, use â%name-prefixâ >>> [-Wdeprecated] >>> %name-prefix="base_yy" >>> ^ >> because it's hard to see how that's anything but a bison bug. > The wording is a little odd as it seems we're supposed to replace > %name-prefix with... %name-prefix, but the docs say we're supposed to > use api.prefix now instead. Oh, just a bad error message eh? [ Reads docs ... ] AFAICT, they've deprecated this in favor of some other syntax that they introduced in 2.6, which was released in July 2012. That makes it a nonstarter for us. We're not going to break PG altogether for most people in order to hide a warning message on the bleeding edge version. (For comparison, I've got bison 2.3 on my Mac and 2.4.1 on my RHEL6 machine, both of which are pretty up-to-date platforms as such things go. Some of the buildfarm machines are still running 1.875.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 05/21/2014 12:29 PM, Tom Lane wrote: > Vik Fearing writes: >> I'm getting some more of these, including some I thought you had fixed. >> Bison 3.0.2 on current head. > I didn't do anything to suppress those warnings: > >> gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’ >> [-Wdeprecated] >> %name-prefix="base_yy" >> ^ > because it's hard to see how that's anything but a bison bug. The wording is a little odd as it seems we're supposed to replace %name-prefix with... %name-prefix, but the docs say we're supposed to use api.prefix now instead. I'll just take your word for it as I've never done anything with bison before. -- Vik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Vik Fearing writes: > I'm getting some more of these, including some I thought you had fixed. > Bison 3.0.2 on current head. I didn't do anything to suppress those warnings: > gram.y:172.1-13: warning: deprecated directive, use â%name-prefixâ > [-Wdeprecated] > %name-prefix="base_yy" > ^ because it's hard to see how that's anything but a bison bug. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
I'm getting some more of these, including some I thought you had fixed. Bison 3.0.2 on current head. <> Writing postgres.bki Writing schemapg.h Writing postgres.description Writing postgres.shdescription gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’ [-Wdeprecated] %name-prefix="base_yy" ^ Writing fmgroids.h Writing fmgrtab.c bootparse.y:96.1-13: warning: deprecated directive, use ‘%name-prefix’ [-Wdeprecated] %name-prefix="boot_yy" ^ In file included from gram.y:14004:0: scan.c: In function ‘yy_try_NUL_trans’: scan.c:10188:23: warning: unused variable ‘yyg’ [-Wunused-variable] struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* This var may be unused depending upon options. */ ^ repl_gram.y:43.1-13: warning: deprecated directive, use ‘%name-prefix’ [-Wdeprecated] %name-prefix="replication_yy" ^ preproc.y:576.1-13: warning: deprecated directive, use ‘%name-prefix’ [-Wdeprecated] %name-prefix="base_yy" ^ pl_gram.y:113.1-13: warning: deprecated directive, use ‘%name-prefix’ [-Wdeprecated] %name-prefix="plpgsql_yy" ^ cubeparse.y:42.1-13: warning: deprecated directive, use ‘%name-prefix’ [-Wdeprecated] %name-prefix="cube_yy" ^ segparse.y:45.1-13: warning: deprecated directive, use ‘%name-prefix’ [-Wdeprecated] %name-prefix="seg_yy" ^ PostgreSQL, contrib, and documentation installation complete. On 07/29/2013 01:05 AM, Tom Lane wrote: > Buildfarm member anchovy has been failing for the last couple of days, > evidently because its owner just couldn't wait to adopt bison 3.0, > which is all of 3 days old. The failures look like > > cubeparse.y:42.1-13: warning: deprecated directive, use '%name-prefix' > [-Wdeprecated] > %name-prefix="cube_yy" > ^ > > (which looks like 3.0 isn't actually ready for prime time, but at least > it's only a warning) > > cubeparse.c:163:5: error: conflicting types for 'cube_yyparse' > int cube_yyparse (void); > ^ > cubeparse.y:32:5: note: previous declaration of 'cube_yyparse' was here > int cube_yyparse(void *result); > ^ > > A look in the Bison release notes explains this one: they stopped > supporting YYPARSE_PARAM, which contrib/cube and contrib/seg both use. > The recommended replacement is %parse-param, which is certainly a whole > lot cleaner: it lets you specify the datatype of the extra parser > parameter, instead of having it default to "void *". This option also > changes the signature of yyerror(), but that's not a problem. > > At first I thought this was going to make us go through a tool upgrade > exercise, because I couldn't find %parse-param in the documentation for > bison 1.875, which is our oldest supported version. But further > research shows that %parse-param actually was introduced in 1.875, > they just forgot to document it :-(. > > So I propose the attached patch, which I've verified still works with > 1.875. I don't plan to install 3.0 just to test this, but I assume it's > OK there. > > I'm thinking we should apply this to all supported branches, in case > somebody gets the idea to build an older branch with bleeding-edge > tools. Any objections? > > regards, tom lane > > > -- Vik
Re: [HACKERS] bison, flex and ./configure
Hello Heikki, Thanks for sharing. Reagrds On Tuesday, January 28, 2014 3:48 PM, Heikki Linnakangas wrote: On 01/28/2014 04:28 PM, salah jubeh wrote: >> Yes. Bison and flex are not required when building from a source >> tarball, because the tarball includes the generated files. If you're >> building from a git checkout, however, then you need bison and flex. You >> will get an error at make, and IIRC a warning at ./configure > > Thanks for the quick reply. For curiosity reasons why the differentiation > between tar and git. We include the generated files in the tarballs for the convenience of people who just want to download, compile, and install the software. Fewer dependencies is good in that case. It also ensures that an official version, ie. from a tarball, is always built using the same version of bison/flex. Whereas if you do a git checkout, you're probably a developer, and want to modify the sources. It's not unreasonable to expect a developer to have bison and flex installed. Also, including the generated files in the git repository would cause unnecessary diffs when people have different versions of bison/flex installed on their development boxes. We've chosen a different approach with autoconf; the configure file is generated from configure.in, but we include the configure file in the git repository. It does add some extra effort to developers that need to modify configure.in, but OTOH, if you don't modify it, you don't need to have autoconf installed. - Heikki
Re: [HACKERS] bison, flex and ./configure
On 01/28/2014 04:28 PM, salah jubeh wrote: Yes. Bison and flex are not required when building from a source tarball, because the tarball includes the generated files. If you're building from a git checkout, however, then you need bison and flex. You will get an error at make, and IIRC a warning at ./configure Thanks for the quick reply. For curiosity reasons why the differentiation between tar and git. We include the generated files in the tarballs for the convenience of people who just want to download, compile, and install the software. Fewer dependencies is good in that case. It also ensures that an official version, ie. from a tarball, is always built using the same version of bison/flex. Whereas if you do a git checkout, you're probably a developer, and want to modify the sources. It's not unreasonable to expect a developer to have bison and flex installed. Also, including the generated files in the git repository would cause unnecessary diffs when people have different versions of bison/flex installed on their development boxes. We've chosen a different approach with autoconf; the configure file is generated from configure.in, but we include the configure file in the git repository. It does add some extra effort to developers that need to modify configure.in, but OTOH, if you don't modify it, you don't need to have autoconf installed. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] bison, flex and ./configure
>Yes. Bison and flex are not required when building from a source >tarball, because the tarball includes the generated files. If you're >building from a git checkout, however, then you need bison and flex. You >will get an error at make, and IIRC a warning at ./configure Thanks for the quick reply. For curiosity reasons why the differentiation between tar and git. Regards On Tuesday, January 28, 2014 3:18 PM, Heikki Linnakangas wrote: On 01/28/2014 04:14 PM, salah jubeh wrote: > Today, I have noticed that ./configure does not return an error when bison > and flex are missing. Is this intended ? Yes. Bison and flex are not required when building from a source tarball, because the tarball includes the generated files. If you're building from a git checkout, however, then you need bison and flex. You will get an error at make, and IIRC a warning at ./configure. - Heikki
Re: [HACKERS] bison, flex and ./configure
On 01/28/2014 04:14 PM, salah jubeh wrote: Today, I have noticed that ./configure does not return an error when bison and flex are missing. Is this intended ? Yes. Bison and flex are not required when building from a source tarball, because the tarball includes the generated files. If you're building from a git checkout, however, then you need bison and flex. You will get an error at make, and IIRC a warning at ./configure. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] bison, flex and ./configure
Hello, Today, I have noticed that ./configure does not return an error when bison and flex are missing. Is this intended ? OS: Ubuntu 13.04 Regards
Re: [HACKERS] Bison 3.0 updates
Andres Freund writes: > On 2013-07-29 08:02:49 -0400, Tom Lane wrote: >>> It looks like our choices are (1) teach configure to enable >>> -fno-aggressive-loop-optimizations if the compiler recognizes it, >>> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9. >>> >>> I am in favor of fixing the back branches via (1), because it's less >>> work and much less likely to break third-party extensions. > This seems to be the agreed upon course of action, so I've prepared a > patch including a preliminary commit message. I confirmed that it fixes > the issue with gcc 4.8 and 9.1 for me. Committed --- thanks for doing the legwork to check it fixes the problem. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 2013-07-29 08:02:49 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-07-29 07:11:13 -0400, Stephen Frost wrote: > >> * Tom Lane (t...@sss.pgh.pa.us) wrote: > >>> The bottom line was: > >>> It looks like our choices are (1) teach configure to enable > >>> -fno-aggressive-loop-optimizations if the compiler recognizes it, > >>> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9. > >>> > >>> I am in favor of fixing the back branches via (1), because it's less > >>> work and much less likely to break third-party extensions. Some other > >>> people argued for (2), but I've not seen any patch emerge from them, > >>> and you can bet I'm not going to do it. > > >> Yea, just passing -fno-aggressive-loop-optimizations seems like the > >> safest and best option to me also.. > > > I think we need to do both. There very well might be other optimizations > > made based on the unreachability information. > > If we turn off the optimization, that will fix any other cases as well, > no? So why would we risk breaking third-party code by back-porting the > struct declaration changes? This seems to be the agreed upon course of action, so I've prepared a patch including a preliminary commit message. I confirmed that it fixes the issue with gcc 4.8 and 9.1 for me. The patch needs to be applied to 9.1, 9.0 and 8.4. Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services >From 1d9f13fd9245c66de02478875c9f6c3eea3bc978 Mon Sep 17 00:00:00 2001 From: Andres Freund Date: Wed, 21 Aug 2013 13:10:23 +0200 Subject: [PATCH] Amend CFLAGS for gcc 4.8 to prevent optimization problems due to variable length structs gcc 4.8 concludes it can terminate some loops prematurely, causing e.g. initdb to fail in optimized builds, because we embed variable length structs inside catalog structs. If those embedded variable length structs are not the trailing field gcc concludes that they an area of memory has to be of a certain size and uses that information to infer that some loops can only iterate a limited number of times. In reality, the actual struct layout isn't used for any of the elements beyond the first variable length element, it's just there for the benefit genbki.pl. Later fields are only accessed indirectly via heap_getattr() and friends. But the compiler doesn't know that. Commits 8137f2c3 / 8a3f745f, which are only included in 9.2 and onwards, thus hide all variable length fields after the first one via #ifdefs. For the benefit of earlier releases, let configure check for -fno-aggressive-loop-optimizations, which disables this kind of optimization. It was concluded that this way of fixing problems arising from the optimization is less likely to cause problems than backporting the aforementioned commits. Per discussion on the hackers mailinglist. --- configure.in | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.in b/configure.in index cf1afeb..76cd5eb 100644 --- a/configure.in +++ b/configure.in @@ -438,6 +438,9 @@ if test "$GCC" = yes -a "$ICC" = no; then PGAC_PROG_CC_CFLAGS_OPT([-fwrapv]) # Disable FP optimizations that cause various errors on gcc 4.5+ or maybe 4.6+ PGAC_PROG_CC_CFLAGS_OPT([-fexcess-precision=standard]) + # Disable some loop optimizations, causes error due to variable length structs + # needed for < 9.2 and gcc 4.8+ + PGAC_PROG_CC_CFLAGS_OPT([-fno-aggressive-loop-optimizations]) elif test "$ICC" = yes; then # Intel's compiler has a bug/misoptimization in checking for # division by NAN (NaN == 0), -mp1 fixes it, so add it to the CFLAGS. -- 1.8.2.rc2.4.g7799588.dirty -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On Tue, Jul 30, 2013 at 3:56 AM, Noah Misch wrote: > Agreed. Let's stick an "Updates OS packages daily, regularly acquiring > bleeding-edge upstream releases" note on the buildfarm status page FWIW, I added "[updated daily]" to the OS version field. I haven't changed other configuration yet, will wait until there's a consensus. Regards, Marti -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On Mon, Jul 29, 2013 at 11:05:52AM -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On 07/29/2013 10:28 AM, Marti Raudsepp wrote: > >> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages > >> daily. > >> I assumed that's a good thing -- the purpose of build farm is to test > >> PostgreSQL in various different real-life environments? Arch Linux is > >> one such environment that adopts new packages very quickly. If Arch > >> users are unable to build PostgreSQL then surely it's good to be > >> notified by the build farm before real users start reporting problems? > > > The buildfarm is principally designed to detect when some change in the > > Postgres code breaks something. As such, the expectation is that the > > animals will provide a fairly stable platform. A totally moving target > > will present us with false positives, since the failure could be due to > > no action of ours at all. > > I can see both sides of this. It's definitely nice to get early warning > when toolchain changes create new problems for Postgres, but it's not > clear that the buildfarm is the best way to get such notifications. Early notification when a dependency's compatibility break affects PostgreSQL is a Very Good Thing. > The big problem here is that it might take a long time before we have > a suitable fix, and in the meantime that buildfarm member is basically > useless: it can't tell us anything new, and even if it tried, probably > nobody would notice because they'd not realize the failure cause changed. > We've had cases before where a buildfarm member that was failing for > some known reason was unable to detect a later-introduced bug, so this > isn't hypothetical. (And I'm not too thrilled that we've let the > back-branch failures on anchovy persist for months, though I suppose > that's not as bad as a breakage in HEAD.) True, but the solution, if any, is more buildfarm members. anchovy plays the important role of a sentinel for trouble with bleeding-edge dependency packages. Doing that with excellence inevitably makes it less useful for detecting other kinds of problems. > On the other hand, this > doesn't seem like a big enough problem to justify building some > different infrastructure for it, so I'm not seeing a practical way > to do better. Agreed. Let's stick an "Updates OS packages daily, regularly acquiring bleeding-edge upstream releases" note on the buildfarm status page, like we have for the CLOBBER_CACHE_ALWAYS members. That should be enough for folks to realize that a failure in this animal alone is more likely the fault of a new package version than of the latest commit. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
* Andrew Dunstan wrote: I'm toying with the idea of a check_upgrade mode for the buildfarm client where it wouldn't do a git pull, but would report changes if the build result was different from the previous result. You'd run this immediately after pulling new changes into your OS. Other, brighter ideas welcome. Might it be possible for the buildfarm client to query the various tools (compiler, autotools, flex, bison, perl, shell, etc.) for their version numbers and report those too? If the config page said "since the last successful build, these commits have been added, and the compiler is now tomorrow's snapshot of gcc 4.8.4711", diagnosing a failed build could be easier. This could be done either through the usual -V, --version flags or by asking the host's packaging system, although there are probably too many of the latter to support. I would not want to have to implement this, but perhaps the client could also automatically drop back to the last known good commit if it gets a failed build immediately after a tool version change. -- Christian -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On Mon, Jul 29, 2013 at 11:45 AM, Andrew Dunstan wrote: > > On 07/29/2013 02:26 PM, Marti Raudsepp wrote: >>> >>> I'm toying with the idea of a check_upgrade mode for the buildfarm client >>> where it wouldn't do a git pull, but would report changes if the build >>> result was different from the previous result. You'd run this immediately >>> after pulling new changes into your OS. Other, brighter ideas welcome. >> >> What would be the right course of action if check_upgrade fails? Is it >> reasonable to expect buildfarm volunteers to downgrade the system and >> postpone until the problem is resolved? >> >> Or do you think the member should be removed from the farm until the >> build succeeds again? Sounds like worst of both worlds. >> > > > Neither, I don't think you're understanding me at all. The idea is to have > some way of saying "well, the code is the same, but the tools have changed." > i.e. we want to be able to hold one of these variables constant. Could it remove the need for manual intervention, by detecting if the tools have changed first, and then suppressing the git pull and adding the appropriate reporting flag, if they have? Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On Mon, Jul 29, 2013 at 4:05 PM, Tom Lane wrote: > I can see both sides of this. It's definitely nice to get early warning > when toolchain changes create new problems for Postgres, but it's not > clear that the buildfarm is the best way to get such notifications. Perhaps something as simple as choosing a sufficiently oddball or frightening animal name? predator or alien? killerbee? bedbug? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 07/29/2013 02:26 PM, Marti Raudsepp wrote: I'm toying with the idea of a check_upgrade mode for the buildfarm client where it wouldn't do a git pull, but would report changes if the build result was different from the previous result. You'd run this immediately after pulling new changes into your OS. Other, brighter ideas welcome. What would be the right course of action if check_upgrade fails? Is it reasonable to expect buildfarm volunteers to downgrade the system and postpone until the problem is resolved? Or do you think the member should be removed from the farm until the build succeeds again? Sounds like worst of both worlds. Neither, I don't think you're understanding me at all. The idea is to have some way of saying "well, the code is the same, but the tools have changed." i.e. we want to be able to hold one of these variables constant. The buildfarm server knows how the run was invoked, and could distinguish runs done in this mode from other runs. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On Mon, Jul 29, 2013 at 9:15 PM, Andrew Dunstan wrote: > There has to be something between "set in stone and never changes" and > "auto-updates everything every 24 hours" that would suit us. Well sure I could change the update frequency. But again, it seems like delaying the inevitable. > I'm toying with the idea of a check_upgrade mode for the buildfarm client > where it wouldn't do a git pull, but would report changes if the build > result was different from the previous result. You'd run this immediately > after pulling new changes into your OS. Other, brighter ideas welcome. What would be the right course of action if check_upgrade fails? Is it reasonable to expect buildfarm volunteers to downgrade the system and postpone until the problem is resolved? Or do you think the member should be removed from the farm until the build succeeds again? Sounds like worst of both worlds. Regards, Marti -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 07/29/2013 11:05 AM, Tom Lane wrote: Andrew Dunstan writes: On 07/29/2013 10:28 AM, Marti Raudsepp wrote: Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily. I assumed that's a good thing -- the purpose of build farm is to test PostgreSQL in various different real-life environments? Arch Linux is one such environment that adopts new packages very quickly. If Arch users are unable to build PostgreSQL then surely it's good to be notified by the build farm before real users start reporting problems? The buildfarm is principally designed to detect when some change in the Postgres code breaks something. As such, the expectation is that the animals will provide a fairly stable platform. A totally moving target will present us with false positives, since the failure could be due to no action of ours at all. I can see both sides of this. It's definitely nice to get early warning when toolchain changes create new problems for Postgres, but it's not clear that the buildfarm is the best way to get such notifications. The big problem here is that it might take a long time before we have a suitable fix, and in the meantime that buildfarm member is basically useless: it can't tell us anything new, and even if it tried, probably nobody would notice because they'd not realize the failure cause changed. We've had cases before where a buildfarm member that was failing for some known reason was unable to detect a later-introduced bug, so this isn't hypothetical. (And I'm not too thrilled that we've let the back-branch failures on anchovy persist for months, though I suppose that's not as bad as a breakage in HEAD.) Ideally we'd not rotate toolchain updates into the buildfarm until they'd been checked out in some other way. On the other hand, this doesn't seem like a big enough problem to justify building some different infrastructure for it, so I'm not seeing a practical way to do better. There has to be something between "set in stone and never changes" and "auto-updates everything every 24 hours" that would suit us. I'm toying with the idea of a check_upgrade mode for the buildfarm client where it wouldn't do a git pull, but would report changes if the build result was different from the previous result. You'd run this immediately after pulling new changes into your OS. Other, brighter ideas welcome. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On Mon, Jul 29, 2013 at 5:53 PM, Andres Freund wrote: > Both the > gcc 4.8 and the bison 3.0 problems are things the project needs to know > about Perl 5.18 too: http://www.postgresql.org/message-id/2825.1370226...@sss.pgh.pa.us Marti -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Andrew Dunstan writes: > On 07/29/2013 10:28 AM, Marti Raudsepp wrote: >> Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily. >> I assumed that's a good thing -- the purpose of build farm is to test >> PostgreSQL in various different real-life environments? Arch Linux is >> one such environment that adopts new packages very quickly. If Arch >> users are unable to build PostgreSQL then surely it's good to be >> notified by the build farm before real users start reporting problems? > The buildfarm is principally designed to detect when some change in the > Postgres code breaks something. As such, the expectation is that the > animals will provide a fairly stable platform. A totally moving target > will present us with false positives, since the failure could be due to > no action of ours at all. I can see both sides of this. It's definitely nice to get early warning when toolchain changes create new problems for Postgres, but it's not clear that the buildfarm is the best way to get such notifications. The big problem here is that it might take a long time before we have a suitable fix, and in the meantime that buildfarm member is basically useless: it can't tell us anything new, and even if it tried, probably nobody would notice because they'd not realize the failure cause changed. We've had cases before where a buildfarm member that was failing for some known reason was unable to detect a later-introduced bug, so this isn't hypothetical. (And I'm not too thrilled that we've let the back-branch failures on anchovy persist for months, though I suppose that's not as bad as a breakage in HEAD.) Ideally we'd not rotate toolchain updates into the buildfarm until they'd been checked out in some other way. On the other hand, this doesn't seem like a big enough problem to justify building some different infrastructure for it, so I'm not seeing a practical way to do better. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 2013-07-29 10:52:10 -0400, Tom Lane wrote: > Andres Freund writes: > > FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and > > e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me > > (After fixing trivial conflicts in the latter). > > I've already spent more time on this than I wanted to, but just for > the archives' sake: neither of those commits exist in the master > repo. Hrmpf, sorry for that. Posting the hashes *after* cherry-picking them ontop REL9_1_STABLE obviously isn't very helpful. The correct ones are: 8a3f745f160d8334ad978676828d3926ac949f43 8137f2c32322c624e0431fac1621e8e9315202f9 Those definitely are reachable via gitweb. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 2013-07-29 10:46:41 -0400, Andrew Dunstan wrote: > > On 07/29/2013 10:28 AM, Marti Raudsepp wrote: > >Hi, > > > >>On 07/29/2013 01:05 AM, Tom Lane wrote: > >>>Buildfarm member anchovy has been failing for the last couple of days, > >>>evidently because its owner just couldn't wait to adopt bison 3.0, > >>>which is all of 3 days old. > >Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily. > > > >I assumed that's a good thing -- the purpose of build farm is to test > >PostgreSQL in various different real-life environments? Arch Linux is > >one such environment that adopts new packages very quickly. If Arch > >users are unable to build PostgreSQL then surely it's good to be > >notified by the build farm before real users start reporting problems? > > > >I don't mean to sound reluctant, I'm open to suggestions, but please > >help me understand why this is bad. > > > The buildfarm is principally designed to detect when some change in the > Postgres code breaks something. As such, the expectation is that the animals > will provide a fairly stable platform. A totally moving target will present > us with false positives, since the failure could be due to no action of ours > at all. > > A machine that can auto-upgrade anything at any time is really not very fit > for the purpose. What that would be testing is not if a change in Postgres > code has broken something, but if the host packaging system has broken > something. FWIW given the evidence here anchovy seems to do a good job. Both the gcc 4.8 and the bison 3.0 problems are things the project needs to know about and that need to get fixed. And none of the other animals seems to run anything really up2date. Also, afaik Arch has a rolling release model, so there isn't any other specific release that should be tested instead. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Andres Freund writes: > FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and > e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me > (After fixing trivial conflicts in the latter). I've already spent more time on this than I wanted to, but just for the archives' sake: neither of those commits exist in the master repo. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 07/29/2013 10:28 AM, Marti Raudsepp wrote: Hi, On 07/29/2013 01:05 AM, Tom Lane wrote: Buildfarm member anchovy has been failing for the last couple of days, evidently because its owner just couldn't wait to adopt bison 3.0, which is all of 3 days old. Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily. I assumed that's a good thing -- the purpose of build farm is to test PostgreSQL in various different real-life environments? Arch Linux is one such environment that adopts new packages very quickly. If Arch users are unable to build PostgreSQL then surely it's good to be notified by the build farm before real users start reporting problems? I don't mean to sound reluctant, I'm open to suggestions, but please help me understand why this is bad. The buildfarm is principally designed to detect when some change in the Postgres code breaks something. As such, the expectation is that the animals will provide a fairly stable platform. A totally moving target will present us with false positives, since the failure could be due to no action of ours at all. A machine that can auto-upgrade anything at any time is really not very fit for the purpose. What that would be testing is not if a change in Postgres code has broken something, but if the host packaging system has broken something. And if the upgrade involves the OS or the compiler, please use the udate_personality.pl script to update the server. Is it OK to run update_personality.pl automatically every day from crontab? No. It is designed to support a fairly small number of changes. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Hi, > On 07/29/2013 01:05 AM, Tom Lane wrote: >> Buildfarm member anchovy has been failing for the last couple of days, >> evidently because its owner just couldn't wait to adopt bison 3.0, >> which is all of 3 days old. Hmm? Anchovy is upgrading automatically to newest Arch Linux packages daily. I assumed that's a good thing -- the purpose of build farm is to test PostgreSQL in various different real-life environments? Arch Linux is one such environment that adopts new packages very quickly. If Arch users are unable to build PostgreSQL then surely it's good to be notified by the build farm before real users start reporting problems? I don't mean to sound reluctant, I'm open to suggestions, but please help me understand why this is bad. On Mon, Jul 29, 2013 at 4:59 PM, Andrew Dunstan wrote: > Reminder to buildfarm animal owners: if you upgrade software please make > sure your buildfarm members are still working. If I had checked the machine's status manually after upgrading, the best course of action would be to report the incompatibility to PostgreSQL mailing lists. The end result is the same, in that sense, it was "working". Manual upgrades would only delay that reporting, not prevent it? I realize there have been problems with anchovy that are my own fault and I'm sorry about that. I check the buildfarm status every week or two. > And if the upgrade involves > the OS or the compiler, please use the udate_personality.pl script to update > the server. Is it OK to run update_personality.pl automatically every day from crontab? Regards, Marti -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 2013-07-29 08:44:56 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-07-29 08:17:46 -0400, Tom Lane wrote: > >> I'm not excited about breaking code in order to fix optimization bugs > >> that are purely hypothetical (and for which there's no particular reason > >> to believe that the proposed change would fix them anyway). If we were > >> seeing such things in the field it would be a different story. > > > Well, given the problems we're discussing here, it's not all that > > hypothetical. Obviously the compiler *does* have information it believes > > to proof some code to be unreachable. > > The known case here has nothing to do with unreachability IMO; it has > to do with concluding that a loop can be unrolled into exactly one > execution. If I understand the optimization correctly what it does is building a flow control model of a loop and concluding which its iterations can be reached assuming standard conforming code. In this case, since it knows (from looking at the underlying data structures) that the upper bound of the iteration has to be 1 it decides to stop there. If oidvector had values[2] it would make two iterations. > But in any case, there is no point in arguing about what > hypothetical versions of gcc might do in hypothetical cases. We have > experimental evidence that -fno-aggressive-loop-optimizations fixes the > observed problem with gcc 4.8.0. Well, it seems to me like we don't have particularly good experience with fixing compiler optimization issues by disabling some specific optimization. They tend to crop up again under the umbrella of another feature a compiler version or two later. FWIW cherry-picking bf66bfb4cd726b6ddab3fe2718648f65a7106149 and e58f3181fdaacc91d4cc1bd98a4a8ad7d286544c fixes the issue for me (After fixing trivial conflicts in the latter). 32 files changed, 98 insertions(+), 50 deletions(-) > So we can apply a one-line patch that > fixes the observed problem and seems 100% safe, or we can apply a very > large patch that might possibly fix problems that we don't know exist, > and might also break third-party code. Given the available evidence > the choice seems pretty clear to me. If you want to provide concrete > proof that there are additional optimization hazards then that would > change the tradeoff. No, don't really want to spend more time on this. We'll see whether it crops up again or not. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 07/29/2013 01:05 AM, Tom Lane wrote: Buildfarm member anchovy has been failing for the last couple of days, evidently because its owner just couldn't wait to adopt bison 3.0, which is all of 3 days old. The failures look like Reminder to buildfarm animal owners: if you upgrade software please make sure your buildfarm members are still working. And if the upgrade involves the OS or the compiler, please use the udate_personality.pl script to update the server. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Andres Freund writes: > On 2013-07-29 08:17:46 -0400, Tom Lane wrote: >> I'm not excited about breaking code in order to fix optimization bugs >> that are purely hypothetical (and for which there's no particular reason >> to believe that the proposed change would fix them anyway). If we were >> seeing such things in the field it would be a different story. > Well, given the problems we're discussing here, it's not all that > hypothetical. Obviously the compiler *does* have information it believes > to proof some code to be unreachable. The known case here has nothing to do with unreachability IMO; it has to do with concluding that a loop can be unrolled into exactly one execution. But in any case, there is no point in arguing about what hypothetical versions of gcc might do in hypothetical cases. We have experimental evidence that -fno-aggressive-loop-optimizations fixes the observed problem with gcc 4.8.0. So we can apply a one-line patch that fixes the observed problem and seems 100% safe, or we can apply a very large patch that might possibly fix problems that we don't know exist, and might also break third-party code. Given the available evidence the choice seems pretty clear to me. If you want to provide concrete proof that there are additional optimization hazards then that would change the tradeoff. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 2013-07-29 08:17:46 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-07-29 08:02:49 -0400, Tom Lane wrote: > >> If we turn off the optimization, that will fix any other cases as well, > >> no? So why would we risk breaking third-party code by back-porting the > >> struct declaration changes? > > > The -fno-agressive-loop thingie afaics only controls the optimization > > with regard to loopey constructs, not in general. I *think* there are > > independent hazards with general unreachability detection. Not sure > > whether they trigger at -O2 or only at -O3 though. > > I'm not excited about breaking code in order to fix optimization bugs > that are purely hypothetical (and for which there's no particular reason > to believe that the proposed change would fix them anyway). If we were > seeing such things in the field it would be a different story. Well, given the problems we're discussing here, it's not all that hypothetical. Obviously the compiler *does* have information it believes to proof some code to be unreachable. And we know that information comes from the way the catalog structs are declared. I don't really fancy finding more and more optimizations we didn't think about and disabling them one by one after annoying debugging sessions. Also, just about all code that would get broken by that change would be code that's already pretty much broken. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Andres Freund writes: > On 2013-07-29 08:02:49 -0400, Tom Lane wrote: >> If we turn off the optimization, that will fix any other cases as well, >> no? So why would we risk breaking third-party code by back-porting the >> struct declaration changes? > The -fno-agressive-loop thingie afaics only controls the optimization > with regard to loopey constructs, not in general. I *think* there are > independent hazards with general unreachability detection. Not sure > whether they trigger at -O2 or only at -O3 though. I'm not excited about breaking code in order to fix optimization bugs that are purely hypothetical (and for which there's no particular reason to believe that the proposed change would fix them anyway). If we were seeing such things in the field it would be a different story. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 2013-07-29 08:02:49 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2013-07-29 07:11:13 -0400, Stephen Frost wrote: > >> * Tom Lane (t...@sss.pgh.pa.us) wrote: > >>> The bottom line was: > >>> It looks like our choices are (1) teach configure to enable > >>> -fno-aggressive-loop-optimizations if the compiler recognizes it, > >>> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9. > >>> > >>> I am in favor of fixing the back branches via (1), because it's less > >>> work and much less likely to break third-party extensions. Some other > >>> people argued for (2), but I've not seen any patch emerge from them, > >>> and you can bet I'm not going to do it. > > >> Yea, just passing -fno-aggressive-loop-optimizations seems like the > >> safest and best option to me also.. > > > I think we need to do both. There very well might be other optimizations > > made based on the unreachability information. > > If we turn off the optimization, that will fix any other cases as well, > no? So why would we risk breaking third-party code by back-porting the > struct declaration changes? The -fno-agressive-loop thingie afaics only controls the optimization with regard to loopey constructs, not in general. I *think* there are independent hazards with general unreachability detection. Not sure whether they trigger at -O2 or only at -O3 though. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Andres Freund writes: > On 2013-07-29 07:11:13 -0400, Stephen Frost wrote: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> The bottom line was: >>> It looks like our choices are (1) teach configure to enable >>> -fno-aggressive-loop-optimizations if the compiler recognizes it, >>> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9. >>> >>> I am in favor of fixing the back branches via (1), because it's less >>> work and much less likely to break third-party extensions. Some other >>> people argued for (2), but I've not seen any patch emerge from them, >>> and you can bet I'm not going to do it. >> Yea, just passing -fno-aggressive-loop-optimizations seems like the >> safest and best option to me also.. > I think we need to do both. There very well might be other optimizations > made based on the unreachability information. If we turn off the optimization, that will fix any other cases as well, no? So why would we risk breaking third-party code by back-porting the struct declaration changes? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
On 2013-07-29 07:11:13 -0400, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > However, I comment on this mainly because anchovy has had issues with > > > 9.1 and older for some time, which looks like an issue with GCC 4.8.0. > > > Did you happen to resolve or identify what is happening there..? > > > > Yeah, we know about that: > > http://www.postgresql.org/message-id/14242.1365200...@sss.pgh.pa.us > > Ah, right, read the thread but didn't attach it to anchovy. > > > The bottom line was: > > >> It looks like our choices are (1) teach configure to enable > > >> -fno-aggressive-loop-optimizations if the compiler recognizes it, > > >> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9. > > > > I am in favor of fixing the back branches via (1), because it's less > > work and much less likely to break third-party extensions. Some other > > people argued for (2), but I've not seen any patch emerge from them, > > and you can bet I'm not going to do it. > > Yea, just passing -fno-aggressive-loop-optimizations seems like the > safest and best option to me also.. I think we need to do both. There very well might be other optimizations made based on the unreachability information. Like concluding some conditional block isn't reachable. (1) would be back branches only, right? If others aggree I'll happily (ok, that's a blatant lie), provide patches if that actually helps $committer. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > However, I comment on this mainly because anchovy has had issues with > > 9.1 and older for some time, which looks like an issue with GCC 4.8.0. > > Did you happen to resolve or identify what is happening there..? > > Yeah, we know about that: > http://www.postgresql.org/message-id/14242.1365200...@sss.pgh.pa.us Ah, right, read the thread but didn't attach it to anchovy. > The bottom line was: > >> It looks like our choices are (1) teach configure to enable > >> -fno-aggressive-loop-optimizations if the compiler recognizes it, > >> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9. > > I am in favor of fixing the back branches via (1), because it's less > work and much less likely to break third-party extensions. Some other > people argued for (2), but I've not seen any patch emerge from them, > and you can bet I'm not going to do it. Yea, just passing -fno-aggressive-loop-optimizations seems like the safest and best option to me also.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Bison 3.0 updates
Stephen Frost writes: > However, I comment on this mainly because anchovy has had issues with > 9.1 and older for some time, which looks like an issue with GCC 4.8.0. > Did you happen to resolve or identify what is happening there..? Yeah, we know about that: http://www.postgresql.org/message-id/14242.1365200...@sss.pgh.pa.us The bottom line was: >> It looks like our choices are (1) teach configure to enable >> -fno-aggressive-loop-optimizations if the compiler recognizes it, >> or (2) back-port commit 8137f2c32322c624e0431fac1621e8e9315202f9. I am in favor of fixing the back branches via (1), because it's less work and much less likely to break third-party extensions. Some other people argued for (2), but I've not seen any patch emerge from them, and you can bet I'm not going to do it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison 3.0 updates
Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Buildfarm member anchovy has been failing for the last couple of days, [...] > I'm thinking we should apply this to all supported branches, in case > somebody gets the idea to build an older branch with bleeding-edge > tools. Any objections? Certainly looks cleaner to me, and if it works for older bison then it seems reasonable to back-patch it. However, I comment on this mainly because anchovy has had issues with 9.1 and older for some time, which looks like an issue with GCC 4.8.0. Did you happen to resolve or identify what is happening there..? Thanks! Stephen signature.asc Description: Digital signature
[HACKERS] Bison 3.0 updates
Buildfarm member anchovy has been failing for the last couple of days,
evidently because its owner just couldn't wait to adopt bison 3.0,
which is all of 3 days old. The failures look like
cubeparse.y:42.1-13: warning: deprecated directive, use '%name-prefix'
[-Wdeprecated]
%name-prefix="cube_yy"
^
(which looks like 3.0 isn't actually ready for prime time, but at least
it's only a warning)
cubeparse.c:163:5: error: conflicting types for 'cube_yyparse'
int cube_yyparse (void);
^
cubeparse.y:32:5: note: previous declaration of 'cube_yyparse' was here
int cube_yyparse(void *result);
^
A look in the Bison release notes explains this one: they stopped
supporting YYPARSE_PARAM, which contrib/cube and contrib/seg both use.
The recommended replacement is %parse-param, which is certainly a whole
lot cleaner: it lets you specify the datatype of the extra parser
parameter, instead of having it default to "void *". This option also
changes the signature of yyerror(), but that's not a problem.
At first I thought this was going to make us go through a tool upgrade
exercise, because I couldn't find %parse-param in the documentation for
bison 1.875, which is our oldest supported version. But further
research shows that %parse-param actually was introduced in 1.875,
they just forgot to document it :-(.
So I propose the attached patch, which I've verified still works with
1.875. I don't plan to install 3.0 just to test this, but I assume it's
OK there.
I'm thinking we should apply this to all supported branches, in case
somebody gets the idea to build an older branch with bleeding-edge
tools. Any objections?
regards, tom lane
diff --git a/contrib/cube/cube.c b/contrib/cube/cube.c
index ce8eaa870fc760b7c7b4607e0844c38ffd5e56bb..dab0e6e7586e306ecfabb6537789a91f95d656e8 100644
*** a/contrib/cube/cube.c
--- b/contrib/cube/cube.c
*** PG_MODULE_MAGIC;
*** 26,33
#define ARRPTR(x) ( (double *) ARR_DATA_PTR(x) )
#define ARRNELEMS(x) ArrayGetNItems( ARR_NDIM(x), ARR_DIMS(x))
! extern int cube_yyparse();
! extern void cube_yyerror(const char *message);
extern void cube_scanner_init(const char *str);
extern void cube_scanner_finish(void);
--- 26,33
#define ARRPTR(x) ( (double *) ARR_DATA_PTR(x) )
#define ARRNELEMS(x) ArrayGetNItems( ARR_NDIM(x), ARR_DIMS(x))
! extern int cube_yyparse(NDBOX **result);
! extern void cube_yyerror(NDBOX **result, const char *message);
extern void cube_scanner_init(const char *str);
extern void cube_scanner_finish(void);
*** Datum
*** 156,167
cube_in(PG_FUNCTION_ARGS)
{
char *str = PG_GETARG_CSTRING(0);
! void *result;
cube_scanner_init(str);
if (cube_yyparse(&result) != 0)
! cube_yyerror("bogus input");
cube_scanner_finish();
--- 156,167
cube_in(PG_FUNCTION_ARGS)
{
char *str = PG_GETARG_CSTRING(0);
! NDBOX *result;
cube_scanner_init(str);
if (cube_yyparse(&result) != 0)
! cube_yyerror(&result, "bogus input");
cube_scanner_finish();
diff --git a/contrib/cube/cubeparse.y b/contrib/cube/cubeparse.y
index 21fe5378773da012bd223f4437f02d248da6b6c6..d7205b824cb5c0f21c913b5746552898d8590327 100644
*** a/contrib/cube/cubeparse.y
--- b/contrib/cube/cubeparse.y
***
*** 1,10
%{
/* NdBox = [(lowerleft),(upperright)] */
/* [(xLL(1)...xLL(N)),(xUR(1)...xUR(n))] */
- /* contrib/cube/cubeparse.y */
-
- #define YYPARSE_PARAM result /* need this to pass a pointer (void *) to yyparse */
#define YYSTYPE char *
#define YYDEBUG 1
--- 1,9
%{
+ /* contrib/cube/cubeparse.y */
+
/* NdBox = [(lowerleft),(upperright)] */
/* [(xLL(1)...xLL(N)),(xUR(1)...xUR(n))] */
#define YYSTYPE char *
#define YYDEBUG 1
*** extern int cube_yylex(void);
*** 28,35
static char *scanbuf;
static int scanbuflen;
! void cube_yyerror(const char *message);
! int cube_yyparse(void *result);
static int delim_count(char *s, char delim);
static NDBOX * write_box(unsigned int dim, char *str1, char *str2);
--- 27,34
static char *scanbuf;
static int scanbuflen;
! extern int cube_yyparse(NDBOX **result);
! extern void cube_yyerror(NDBOX **result, const char *message);
static int delim_count(char *s, char delim);
static NDBOX * write_box(unsigned int dim, char *str1, char *str2);
*** static NDBOX * write_point_as_box(char *
*** 38,43
--- 37,43
%}
/* BISON Declarations */
+ %parse-param {NDBOX **result}
%expect 0
%name-prefix="cube_yy"
*** box: O_BRACKET paren_list COMMA paren_li
*** 70,76
YYABORT;
}
! *((void **)result) = write_box( dim, $2, $4 );
}
--- 70,76
YYABORT;
}
! *result = write_box( dim, $2, $4 );
}
*** box: O_BRACKET paren_list COMMA paren_li
*** 97,103
YYABORT;
}
! *((void **)result) = write_box( dim, $1, $3
Re: [HACKERS] bison location reporting for potentially-empty list productions
I wrote:
> To produce a really useful cursor for this type of situation I think
> we would have to do something like this:
> #define YYLLOC_DEFAULT(Current, Rhs, N) \
> do { \
> int i;
> (Current) = -1; \
> for (i = 1; i <= (N); i++)
> {
> (Current) = (Rhs)[i]; \
> if ((Current) >= 0)
> break;
> }
> } while (0)
> This is pretty ugly and seems likely to create a visible hit on the
> parser's speed (which is already not that good). I'm not sure it's
> worth it for something that seems to be a corner case --- anyway
> we've not hit it before in six years since the location tracking
> support was added.
After another look at the Bison manual I realized that there's a way to
fix this without making YYLLOC_DEFAULT slower, because that macro only
sets the *default* location for the current nonterminal; the rule action
is allowed to override its location value. So I propose the attached
patch against HEAD. This is a little bit ugly because we have to
remember to put some extra code in productions that have this issue ...
but track record so far suggests that there will be very few of them.
Anyone have an objection, or a better idea?
regards, tom lane
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 7feadeac1693e7ff46f44ef3ad9ea2fa86bf46a8..e4ff76e66e0990d91790ccc54615c26dd64a143e 100644
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
***
*** 67,82
#include "utils/xml.h"
! /* Location tracking support --- simpler than bison's default */
#define YYLLOC_DEFAULT(Current, Rhs, N) \
do { \
! if (N) \
(Current) = (Rhs)[1]; \
else \
! (Current) = (Rhs)[0]; \
} while (0)
/*
* Bison doesn't allocate anything that needs to live across parser calls,
* so we can easily have it use palloc instead of malloc. This prevents
* memory leaks if we error out during parsing. Note this only works with
--- 67,100
#include "utils/xml.h"
! /*
! * Location tracking support --- simpler than bison's default, since we only
! * want to track the start position not the end position of each nonterminal.
! */
#define YYLLOC_DEFAULT(Current, Rhs, N) \
do { \
! if ((N) > 0) \
(Current) = (Rhs)[1]; \
else \
! (Current) = (-1); \
} while (0)
/*
+ * The above macro assigns -1 (unknown) as the parse location of any
+ * nonterminal that was reduced from an empty rule. This is problematic
+ * for nonterminals defined like
+ * OptFooList: / * EMPTY * / { ... } | OptFooList Foo { ... } ;
+ * because we'll set -1 as the location during the first reduction and then
+ * copy it during each subsequent reduction, leaving us with -1 for the
+ * location even when the list is not empty. To fix that, do this in the
+ * action for the nonempty rule(s):
+ * if (@$ < 0) @$ = @2;
+ * (Although we have many nonterminals that follow this pattern, we only
+ * bother with fixing @$ like this when the nonterminal's parse location
+ * is actually referenced in some rule.)
+ */
+
+ /*
* Bison doesn't allocate anything that needs to live across parser calls,
* so we can easily have it use palloc instead of malloc. This prevents
* memory leaks if we error out during parsing. Note this only works with
*** OptSchemaName:
*** 1223,1230
;
OptSchemaEltList:
! OptSchemaEltList schema_stmt { $$ = lappend($1, $2); }
! | /* EMPTY */ { $$ = NIL; }
;
/*
--- 1241,1254
;
OptSchemaEltList:
! OptSchemaEltList schema_stmt
! {
! if (@$ < 0) /* see comments for YYLLOC_DEFAULT */
! @$ = @2;
! $$ = lappend($1, $2);
! }
! | /* EMPTY */
! { $$ = NIL; }
;
/*
diff --git a/src/test/regress/expected/namespace.out b/src/test/regress/expected/namespace.out
index 5fcd46daf42705147f53599d657e52d8fe7b5b1f..9187c8126a3ffa32e365400816b262daf3b6f2d5 100644
*** a/src/test/regress/expected/namespace.out
--- b/src/test/regress/expected/namespace.out
*** CREATE SCHEMA IF NOT EXISTS test_schema_
*** 47,54
b int UNIQUE
);
ERROR: CREATE SCHEMA IF NOT EXISTS cannot include schema elements
! LINE 1: CREATE SCHEMA IF NOT EXISTS test_schema_1
! ^
DROP SCHEMA test_schema_1 CASCADE;
NOTICE: drop cascades to 2 other objects
DETAIL: drop cascades to table test_schema_1.abc
--- 47,54
b int UNIQUE
);
ERROR: CREATE SCHEMA IF NOT EXISTS cannot include schema elements
! LINE 2:CREATE TABLE abc (
!^
DROP SCHEMA test_schema_1 CASCADE;
NOTICE: drop cascades to 2 other objects
DETAIL: drop cascades to table test_schema_1.abc
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] bison location reporting for potentially-empty list productions
In the just-committed patch for CREATE SCHEMA IF NOT EXISTS, there is
an error thrown by the grammar when IF NOT EXISTS is specified together
with any schema-element clauses. I thought it would make more sense for
the error cursor to point at the schema-element clauses, rather than at
the IF NOT EXISTS as submitted. So the code looks like, eg,
| CREATE SCHEMA IF_P NOT EXISTS ColId OptSchemaEltList
...
if ($7 != NIL)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("CREATE SCHEMA IF NOT EXISTS cannot
include schema elements"),
parser_errposition(@7)));
However, it turns out this actually results in a cursor pointing at the
previous word:
CREATE SCHEMA IF NOT EXISTS test_schema_1 -- fail, disallowed
CREATE TABLE abc (
a serial,
b int UNIQUE
);
ERROR: CREATE SCHEMA IF NOT EXISTS cannot include schema elements
LINE 1: CREATE SCHEMA IF NOT EXISTS test_schema_1
^
After some study I think what is happening is that there's a deficiency
in the location-tracking macro in gram.y:
/* Location tracking support --- simpler than bison's default */
#define YYLLOC_DEFAULT(Current, Rhs, N) \
do { \
if (N) \
(Current) = (Rhs)[1]; \
else \
(Current) = (Rhs)[0]; \
} while (0)
OptSchemaEltList looks like this:
OptSchemaEltList:
OptSchemaEltList schema_stmt{ $$ = lappend($1, $2); }
| /* EMPTY */ { $$ = NIL; }
;
When the macro is evaluated for the initial empty production for
OptSchemaEltList, the "else" case causes it to index off the beginning
of the array and pick up the location for the preceding token. Then,
each succeeding reduction of the first part of the production copies
that bogus value from the first RHS member item. So this same problem
applies not only to OptSchemaEltList but to any case where we've formed
a zero-or-more-element-list production in this style. So far as I can
tell, there are no other cases in the current grammar where we make use
of the position of a list nonterminal for error-reporting purposes,
which is why we'd not noticed this before. But it seems likely to come
up again.
It seems clear to me now that the macro ought at least to be changed to
#define YYLLOC_DEFAULT(Current, Rhs, N) \
do { \
if (N) \
(Current) = (Rhs)[1]; \
else \
(Current) = -1; \
} while (0)
so that the parse location attributed to an empty production is -1
(ie, unknown) rather than the current quite bogus behavior of marking
it as the preceding token's location. (For one thing, what if there
*isn't* a preceding token? That's not possible I think in the current
grammar, but if it were possible this code would be indexing off the
beginning of the locations array.)
But that change wouldn't really fix the issue for CREATE SCHEMA ---
the -1 would be propagated up to all instances of OptSchemaEltList
even after we'd reduced the first production a few times, so that
we'd end up printing no error cursor for this case.
To produce a really useful cursor for this type of situation I think
we would have to do something like this:
#define YYLLOC_DEFAULT(Current, Rhs, N) \
do { \
int i;
(Current) = -1; \
for (i = 1; i <= (N); i++)
{
(Current) = (Rhs)[i]; \
if ((Current) >= 0)
break;
}
} while (0)
This is pretty ugly and seems likely to create a visible hit on the
parser's speed (which is already not that good). I'm not sure it's
worth it for something that seems to be a corner case --- anyway
we've not hit it before in six years since the location tracking
support was added.
At this point I'm inclined to change the macro to the second case
(with the -1) and accept a less good error cursor position for the
CREATE SCHEMA error.
Has anybody got a better idea?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison crashes postgresql
The thing is I was in a project to develop a Fuzzy Database Management System. We have to bring fuzzy logic to postgresql, there was a team developing a software in java and the other developing in the postgresql core. But I always think these were wrong, so I'm trying to develop a library to do that, but I guess I'm moving forward, the bug was solved and I have a google code project: http://code.google.com/p/fuzzyquery/. Now I hope to give more features and have a fully functional library. 2009/9/1 Hans-Juergen Schoenig -- PostgreSQL : > Andrew Dunstan wrote: >> >> >> Werner Echezuria wrote: >>> >>> Hi, I have a code in which I translate some code from sqlf to sql, but >>> when it comes to yy_parse the server crashes, I have no idea why, >>> because it works fine in other situations. >>> >> >> I don't understand why you're doing what you're doing this way. Wouldn't >> it be better to patch the main postgres parser and make your functionality >> first class rather than having it run via an SQL string and a function that >> calls a secondary parser? >> >> cheers >> >> andrew >> > > yes, this is the thing i had in mind as well. > what is your ultimate goal? > > many thanks, > > hans > > > -- > Cybertec Schoenig & Schoenig GmbH > Reyergasse 9 / 2 > A-2700 Wiener Neustadt > Web: www.postgresql-support.de > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison crashes postgresql
Andrew Dunstan wrote: Werner Echezuria wrote: Hi, I have a code in which I translate some code from sqlf to sql, but when it comes to yy_parse the server crashes, I have no idea why, because it works fine in other situations. I don't understand why you're doing what you're doing this way. Wouldn't it be better to patch the main postgres parser and make your functionality first class rather than having it run via an SQL string and a function that calls a secondary parser? cheers andrew yes, this is the thing i had in mind as well. what is your ultimate goal? many thanks, hans -- Cybertec Schoenig & Schoenig GmbH Reyergasse 9 / 2 A-2700 Wiener Neustadt Web: www.postgresql-support.de -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Bison crashes postgresql
Werner Echezuria wrote: Hi, I have a code in which I translate some code from sqlf to sql, but when it comes to yy_parse the server crashes, I have no idea why, because it works fine in other situations. I don't understand why you're doing what you're doing this way. Wouldn't it be better to patch the main postgres parser and make your functionality first class rather than having it run via an SQL string and a function that calls a secondary parser? cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Bison crashes postgresql
Hi, I have a code in which I translate some code from sqlf to sql, but
when it comes to yy_parse the server crashes, I have no idea why,
because it works fine in other situations.
This is the code (the problem is in parse_sqlf, when I call sqlf_yyparse):
#include "postgres.h"
#include "gram.h"
#include "utils/builtins.h"
#include "funcapi.h"
#include "executor/spi.h"
#include "access/heapam.h"
#include "fmgr.h"
#include "miscadmin.h"
extern Datum sqlf(PG_FUNCTION_ARGS);
char *parse_sqlf();
PG_MODULE_MAGIC;
PG_FUNCTION_INFO_V1(sqlf);
Datum
sqlf(PG_FUNCTION_ARGS)
{
char*query = text_to_cstring(PG_GETARG_TEXT_PP(0));
char*sql;
ReturnSetInfo *rsinfo = (ReturnSetInfo *) fcinfo->resultinfo;
Tuplestorestate *tupstore;
TupleDesc tupdesc;
int call_cntr;
int max_calls;
AttInMetadata *attinmeta;
SPITupleTable *spi_tuptable;
TupleDesc spi_tupdesc;
boolfirstpass;
char*lastrowid;
int i;
int num_categories;
MemoryContext per_query_ctx;
MemoryContext oldcontext;
int ret;
int proc;
sql=(char *)palloc(strlen(query)*sizeof(char *));
sql=parse_sqlf(query);
/* check to see if caller supports us returning a tuplestore */
if (rsinfo == NULL || !IsA(rsinfo, ReturnSetInfo))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("set-valued function called in context
that cannot accept a set")));
if (!(rsinfo->allowedModes & SFRM_Materialize))
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("materialize mode required, but it is not " \
"allowed in this context")));
per_query_ctx = rsinfo->econtext->ecxt_per_query_memory;
/* Connect to SPI manager */
if ((ret = SPI_connect()) < 0)
/* internal error */
elog(ERROR, "SPI_connect returned %d", ret);
/* Retrieve the desired rows */
ret = SPI_execute(sql, true, 0);
proc = SPI_processed;
/* If no qualifying tuples, fall out early */
if (ret != SPI_OK_SELECT || proc <= 0)
{
SPI_finish();
rsinfo->isDone = ExprEndResult;
PG_RETURN_NULL();
}
spi_tuptable = SPI_tuptable;
spi_tupdesc = spi_tuptable->tupdesc;
/* get a tuple descriptor for our result type */
switch (get_call_result_type(fcinfo, NULL, &tupdesc))
{
case TYPEFUNC_COMPOSITE:
/* success */
break;
case TYPEFUNC_RECORD:
/* failed to determine actual type of RECORD */
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("function returning record called
in context "
"that cannot accept type record")));
break;
default:
/* result type isn't composite */
elog(ERROR, "return type must be a row type");
break;
}
/*
* switch to long-lived memory context
*/
oldcontext = MemoryContextSwitchTo(per_query_ctx);
/* make sure we have a persistent copy of the result tupdesc */
tupdesc = CreateTupleDescCopy(tupdesc);
/* initialize our tuplestore in long-lived context */
tupstore =
tuplestore_begin_heap(rsinfo->allowedModes &
SFRM_Materialize_Random,
false, work_mem);
MemoryContextSwitchTo(oldcontext);
/*
* Generate attribute metadata needed later to produce tuples from raw C
* strings
*/
attinmeta = TupleDescGetAttInMetadata(tupdesc);
/* total number of tuples to be examined */
max_calls = proc;
/* the return tuple always must have 1 rowid + num_categories columns */
num_categories = tupdesc->natts;
firstpass = true;
lastrowid = NULL;
for (call_cntr = 0; call_cntr < max_calls; call_cntr++)
{
char**values;
HeapTuple spi_tuple;
HeapTuple tuple;
/* allocate and zero space */
values = (char **) palloc0((1 + num_categories) * sizeof(char *));
/* get the next sql result tuple */
spi_tuple = spi_tuptable->vals[call_cntr];
/*
* now loop through the sql results and assign each value in sequence
* to the next category
*/
for (i = 0; i < num_categories; i++)
{
/* see if we've gone too far already */
if (call_cntr >= max_calls)
break;
values[i] = SPI_getvalue(spi_tuple, spi_tupdesc, i+1);
Re: [HACKERS] Bison 2.1 on win32
Hi. I was operating in a tentative way by 2.3. Still, it is not sufficient. However, it moves. I will think that I am glad, if it can adjust with Magnus. http://winpg.jp/~saito/MinGW/bison-2.3_win32_src.tgz Regards, Hiroshi Saito - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> To: "Magnus Hagander" <[EMAIL PROTECTED]> Cc: "PGSQL Hackers" Sent: Sunday, March 18, 2007 2:06 AM Subject: Re: [HACKERS] Bison 2.1 on win32 Magnus Hagander <[EMAIL PROTECTED]> writes: Do you happen to have a 2.2 around so you can see what happens there? Or does someone else have that? So I know which version to test against... 2.2 and 2.3 seem to use _MSC_VER in the same way. I had occasion to test both last fall, and they generate only trivially different outputs from our grammar. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander <[EMAIL PROTECTED]> writes: > Do you happen to have a 2.2 around so you can see what happens there? Or > does someone else have that? So I know which version to test against... 2.2 and 2.3 seem to use _MSC_VER in the same way. I had occasion to test both last fall, and they generate only trivially different outputs from our grammar. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Bison 2.1 on win32
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Actually, looking at the GNU ftp site, there isn't even a version 2.2 >> available. There is a 2.1a which should have the fix (based on file >> dates - they don't use branches or tags in their cvs repository). > > Huh? At > http://ftp.gnu.org/gnu/bison/ > I see 2.0, 2.1, 2.2, 2.3, and no 2.1a. Gah. I clicked the wrong link that was titled "test releases" ;-) I just found a second ftp link when the first one didn't work. Should've read more carefully. Ok. So it looks like 2.2 should be fine as well, as soon as they put out a new win32 ver... (FYI, the code seems to come from data/c.m4) /Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander <[EMAIL PROTECTED]> writes: > Actually, looking at the GNU ftp site, there isn't even a version 2.2 > available. There is a 2.1a which should have the fix (based on file > dates - they don't use branches or tags in their cvs repository). Huh? At http://ftp.gnu.org/gnu/bison/ I see 2.0, 2.1, 2.2, 2.3, and no 2.1a. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander wrote: > I just tried building with Bison 2.1 on msvc, and it broke. For one > thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is > obviously incorrect :-) Actually, looking at the GNU ftp site, there isn't even a version 2.2 available. There is a 2.1a which should have the fix (based on file dates - they don't use branches or tags in their cvs repository). But I'll go ahead and just say it's fixed in 2.3, and patch accordingly. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bison 2.1 on win32
Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> The attached patch seems to fix the build issue. Does it seem >> acceptable/the right thing to do? > > No, it seems pretty bletcherous. That's kind of what I thought :-) >> Another option would be to just reject both 2.0 and 2.1 as broken to >> build pg with, I guess... > > In bison 2.3 (which is shipping with Fedora Core 6), all the uses of > __STDC__ seem to also test _MSC_VER: > > #if (defined __STDC__ || defined __C99__FUNC__ \ > || defined __cplusplus || defined _MSC_VER) > > If this fixes the problem, then I'd vote for just stating you need > bison >= 2.3 (or 2.2?) to build on MSVC. It certainly looks like it would fix it. However, the gnuwin32 project doesn't have 2.3, not even 2.2. But let's add a check and say we need it, and then we can fix it again once they do release that version if it's broken still... Do you happen to have a 2.2 around so you can see what happens there? Or does someone else have that? So I know which version to test against... //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander <[EMAIL PROTECTED]> writes: > The attached patch seems to fix the build issue. Does it seem > acceptable/the right thing to do? No, it seems pretty bletcherous. > Another option would be to just reject both 2.0 and 2.1 as broken to > build pg with, I guess... In bison 2.3 (which is shipping with Fedora Core 6), all the uses of __STDC__ seem to also test _MSC_VER: #if (defined __STDC__ || defined __C99__FUNC__ \ || defined __cplusplus || defined _MSC_VER) If this fixes the problem, then I'd vote for just stating you need bison >= 2.3 (or 2.2?) to build on MSVC. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Bison 2.1 on win32
Magnus Hagander wrote: I just tried building with Bison 2.1 on msvc, and it broke. For one thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is obviously incorrect :-) But the generated C file also does not compile causing the error on http://msdn2.microsoft.com/en-us/library/93az0868.aspx, because msvc doesn't define __STDC__, which causes Bison to generate code it can't compile. Defining __STDC__ globally breaks several other places, since it affects a lot of include files that aren't necessarily others. The attached patch seems to fix the build issue. Does it seem acceptable/the right thing to do? Another option would be to just reject both 2.0 and 2.1 as broken to build pg with, I guess... I rolled back to 1.875 to get MSVC builds working. In the longer term, though, falling behind upstream is probably not a good idea. Should this be reported to the bison people? For now I could live with either of your solutions. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Bison 2.1 on win32
I just tried building with Bison 2.1 on msvc, and it broke. For one thing, the .BAT file rejects 2.1 as broken instead of 2.0, which is obviously incorrect :-) But the generated C file also does not compile causing the error on http://msdn2.microsoft.com/en-us/library/93az0868.aspx, because msvc doesn't define __STDC__, which causes Bison to generate code it can't compile. Defining __STDC__ globally breaks several other places, since it affects a lot of include files that aren't necessarily others. The attached patch seems to fix the build issue. Does it seem acceptable/the right thing to do? Another option would be to just reject both 2.0 and 2.1 as broken to build pg with, I guess... //Magnus Index: src/backend/parser/gram.y === RCS file: /projects/cvsroot/pgsql/src/backend/parser/gram.y,v retrieving revision 2.581 diff -c -r2.581 gram.y *** src/backend/parser/gram.y 13 Mar 2007 00:33:41 - 2.581 --- src/backend/parser/gram.y 17 Mar 2007 13:14:40 - *** *** 62,67 --- 62,71 #include "utils/numeric.h" #include "utils/xml.h" + /* MSVC does not define __STDC__, but Bison 2.1 generates broken code without it */ + #ifdef WIN32_ONLY_COMPILER + #define __STDC__ 1 + #endif /* Location tracking support --- simpler than bison's default */ #define YYLLOC_DEFAULT(Current, Rhs, N) \ Index: src/backend/bootstrap/bootparse.y === RCS file: /projects/cvsroot/pgsql/src/backend/bootstrap/bootparse.y,v retrieving revision 1.88 diff -c -r1.88 bootparse.y *** src/backend/bootstrap/bootparse.y 13 Mar 2007 00:33:39 - 1.88 --- src/backend/bootstrap/bootparse.y 17 Mar 2007 13:14:56 - *** *** 51,56 --- 51,61 #include "tcop/dest.h" #include "utils/rel.h" + /* MSVC does not define __STDC__, but Bison 2.1 generates broken code without it */ + #ifdef WIN32_ONLY_COMPILER + #define __STDC__ 1 + #endif + #define atooid(x) ((Oid) strtoul((x), NULL, 10)) Index: src/pl/plpgsql/src/gram.y === RCS file: /projects/cvsroot/pgsql/src/pl/plpgsql/src/gram.y,v retrieving revision 1.99 diff -c -r1.99 gram.y *** src/pl/plpgsql/src/gram.y 19 Feb 2007 03:18:51 - 1.99 --- src/pl/plpgsql/src/gram.y 17 Mar 2007 13:15:11 - *** *** 18,23 --- 18,27 #include "parser/parser.h" + /* MSVC does not define __STDC__, but Bison 2.1 generates broken code without it */ + #ifdef WIN32_ONLY_COMPILER + #define __STDC__ 1 + #endif static PLpgSQL_expr *read_sql_construct(int until, int until2, ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Bison Version
Due to the bug in bison 2.1, I always use version 1.875: http://www.mail-archive.com/bug-bison@gnu.org/msg00718.html ""Christopher Kings-Lynne"" <[EMAIL PROTECTED]> > What version of Bison is currently required to compile HEAD? 1.75 > doesn't seem to work... > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings > ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Bison Version
Christopher Kings-Lynne wrote: What version of Bison is currently required to compile HEAD? 1.75 doesn't seem to work... Bison >= 1.875 has been required for years. That hasn't changed. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bison Version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > What version of Bison is currently required to compile HEAD? 1.75 > doesn't seem to work... 1.875 Search for Bison here: http://projects.commandprompt.com/public/pgsql/browser/trunk/pgsql/doc/src/sgml/installation.sgml - -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200608110905 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFE3IEivJuQZxSWSsgRAlflAJ9ZqKPKyrav/Ln7vjSgFzBEyorfgACgw0vJ OMR3lJzf5MP1mhzVdlVDZG4= =Oz63 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Bison Version
What version of Bison is currently required to compile HEAD? 1.75 doesn't seem to work... ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] bison version
Yep!
I reverted to 1.875 and it works, I'll be a member of build farm soon for
UnixWare.
On Sun, 11 Jun 2006, Tom Lane wrote:
> Date: Sun, 11 Jun 2006 11:21:20 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: ohp@pyrenet.fr
> Cc: Stefan Kaltenbrunner <[EMAIL PROTECTED]>,
> PostgreSQL-development
> Subject: Re: [HACKERS] bison version
>
> ohp@pyrenet.fr writes:
> > Here's my make.log FWIW...
> > ...
> > gram.y:7074.27-7077.33: warning: useless rule: b_expr: b_expr IS OF '('
> > type_list ')'
> > gram.y:7078.27-7081.33: warning: useless rule: b_expr: b_expr IS NOT OF '('
> > type_list ')'
> > gmake[3]: *** [parse.h] Segmentation Fault (core dumped)
>
> The fact that bison dumps core after emitting all those bogus
> messages suggests to me that you've got a broken copy of bison.
>
> regards, tom lane
>
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
--
Make your life a dream, make your dream a reality. (St Exupery)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] bison version
ohp@pyrenet.fr writes:
> Here's my make.log FWIW...
> ...
> gram.y:7074.27-7077.33: warning: useless rule: b_expr: b_expr IS OF '('
> type_list ')'
> gram.y:7078.27-7081.33: warning: useless rule: b_expr: b_expr IS NOT OF '('
> type_list ')'
> gmake[3]: *** [parse.h] Segmentation Fault (core dumped)
The fact that bison dumps core after emitting all those bogus
messages suggests to me that you've got a broken copy of bison.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] bison version
Hi Stefan, Here's my make.log FWIW... TIA On Sat, 10 Jun 2006, Stefan Kaltenbrunner wrote: > Date: Sat, 10 Jun 2006 21:10:09 +0200 > From: Stefan Kaltenbrunner <[EMAIL PROTECTED]> > To: ohp@pyrenet.fr > Cc: PostgreSQL-development > Subject: Re: [HACKERS] bison version > > ohp@pyrenet.fr wrote: > > Hi, > > > > I'd like to check 2 things: > > > > What's the bison version required to compile gram.y ? > > Trying to set up a build farm machine, it seems I can't compile with bison > > 2.1 ... > > 2.1 should work fine - there are a number of boxes on the buildfarm > running with that version (like sponge the FC5/ppc I own). > What exact problem do you see on your platform ? > > > > > Also where is the documentation page that gives postgresql limits (number > > of column/table max size of col) > > http://www.postgresql.org/docs/faqs.FAQ.html#item4.4 > > > Stefan > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery)gmake -C doc all gmake[1]: Entering directory `/home4/ohp/pgfarmbuild/HEAD/pgsql.4903/doc' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home4/ohp/pgfarmbuild/HEAD/pgsql.4903/doc' gmake -C src all gmake[1]: Entering directory `/home4/ohp/pgfarmbuild/HEAD/pgsql.4903/src' gmake -C port all gmake[2]: Entering directory `/home4/ohp/pgfarmbuild/HEAD/pgsql.4903/src/port' ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o getopt_long.o getopt_long.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o copydir.o copydir.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o dirmod.o dirmod.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o exec.o exec.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o noblock.o noblock.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled echo "#define PGBINDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/bin\"" >pg_config_paths.h echo "#define PGSHAREDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/share/postgresql\"" >>pg_config_paths.h echo "#define SYSCONFDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/etc/postgresql\"" >>pg_config_paths.h echo "#define INCLUDEDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/include\"" >>pg_config_paths.h echo "#define PKGINCLUDEDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/include/postgresql\"" >>pg_config_paths.h echo "#define INCLUDEDIRSERVER \"/home4/ohp/pgfarmbuild/HEAD/inst/include/postgresql/server\"" >>pg_config_paths.h echo "#define LIBDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/lib\"" >>pg_config_paths.h echo "#define PKGLIBDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/lib/postgresql\"" >>pg_config_paths.h echo "#define LOCALEDIR \"\"" >>pg_config_paths.h echo "#define DOCDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/doc/postgresql\"" >>pg_config_paths.h echo "#define MANDIR \"/home4/ohp/pgfarmbuild/HEAD/inst/man\"" >>pg_config_paths.h ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o path.o path.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled ccache cc -O -Kinline -g -I../../src/port -DFRONTEND -I../../src/include -I/usr/local/include -c -o pipe.o pipe.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled UX:cc: WARNING: debugging and optimization mutually exclus
Re: [HACKERS] bison version
ohp@pyrenet.fr wrote: > Hi, > > I'd like to check 2 things: > > What's the bison version required to compile gram.y ? > Trying to set up a build farm machine, it seems I can't compile with bison > 2.1 ... 1.875 > Also where is the documentation page that gives postgresql limits (number > of column/table max size of col) FAQ. -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] bison version
ohp@pyrenet.fr wrote: > Hi, > > I'd like to check 2 things: > > What's the bison version required to compile gram.y ? > Trying to set up a build farm machine, it seems I can't compile with bison > 2.1 ... 2.1 should work fine - there are a number of boxes on the buildfarm running with that version (like sponge the FC5/ppc I own). What exact problem do you see on your platform ? > > Also where is the documentation page that gives postgresql limits (number > of column/table max size of col) http://www.postgresql.org/docs/faqs.FAQ.html#item4.4 Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] bison version
Hi, I'd like to check 2 things: What's the bison version required to compile gram.y ? Trying to set up a build farm machine, it seems I can't compile with bison 2.1 ... Also where is the documentation page that gives postgresql limits (number of column/table max size of col) Many thanks -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Josh Berkus writes: > Might I suggest changing the wording in the final release, then? The warning > sure looked dangerous; It only looks dangerous to those who don't actually read the full text of the message. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Tom, > > Really? 'cause I got the warning from the Beta4 tarball. > > If you mean the configure warning, sure, but the build won't fail. Might I suggest changing the wording in the final release, then? The warning sure looked dangerous; I aborted the build and went looking for bison 1.875 binaries. We should let people know that the warning is non-fatal so they don't repeat my experience. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Josh Berkus wrote: Peter, I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford to upgrade right now. Does such an animal exist? Help! Install it from source if you cannot find a package. Hmmm ... still getting the "Bison Too Old" warning message. How can I tell where Postgres is looking for Bison? I got the same problem when I upgraded my SuSE 8.1. Try "which bison" to locate it; usually, SuSE will install in /usr/bin, while packages installed from source will install to /usr/local/bin, so the older bison would take precedence. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Josh Berkus <[EMAIL PROTECTED]> writes: >> No, because it only matters to people who build from a CVS pull instead >> of using a tarball. I'd think most of the people in the first category >> have already dealt with the issue... > Really? 'cause I got the warning from the Beta4 tarball. If you mean the configure warning, sure, but the build won't fail. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
TOm, > No, because it only matters to people who build from a CVS pull instead > of using a tarball. I'd think most of the people in the first category > have already dealt with the issue... Really? 'cause I got the warning from the Beta4 tarball. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Josh Berkus <[EMAIL PROTECTED]> writes: > (I predict that we're going to get many more questions about Bison after we > release 7.4, since many major Linux distros don't yet include 1.875) No, because it only matters to people who build from a CVS pull instead of using a tarball. I'd think most of the people in the first category have already dealt with the issue... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
On Fri, 17 Oct 2003 09:43 am, Josh Berkus wrote: > (I predict that we're going to get many more questions about Bison after we > release 7.4, since many major Linux distros don't yet include 1.875) You only need bison if you are building from CVS - tarballs include the bison output files (AFAIK - correct me if I am mistaken anyone). Regards, Philip. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Peter, > If you installed from source into /usr/local/bin and you have an older > version in /usr/bin, you may need to run 'hash -r' or 'rehash' to make the > shell forget about the old installation in the path. Yeah, that was it. Thanks! (I predict that we're going to get many more questions about Bison after we release 7.4, since many major Linux distros don't yet include 1.875) -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Josh Berkus writes: > Hmmm ... still getting the "Bison Too Old" warning message. How can I tell > where Postgres is looking for Bison? checking for bison... bison -y ^ I tells you right there. If you installed from source into /usr/local/bin and you have an older version in /usr/bin, you may need to run 'hash -r' or 'rehash' to make the shell forget about the old installation in the path. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Peter, > > I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford > > to upgrade right now. Does such an animal exist? Help! > > Install it from source if you cannot find a package. Hmmm ... still getting the "Bison Too Old" warning message. How can I tell where Postgres is looking for Bison? -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Peter Eisentraut wrote: Josh Berkus writes: I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford to upgrade right now. Does such an animal exist? Help! Install it from source if you cannot find a package. or build from an SRPM - the dependencies are quite modest, I believe cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bison 1.875 for SuSE Linux 8.1?
Josh Berkus writes: > I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford > to upgrade right now. Does such an animal exist? Help! Install it from source if you cannot find a package. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Bison 1.875 for SuSE Linux 8.1?
Folks, I can't seem to find a Bison 1.875 RPM for a SuSE 8.1 machine I can't afford to upgrade right now. Does such an animal exist? Help! -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Bison 1.875 now required.
For those using Linux, the RPMs at: http://services.csl.co.uk/postgresql/ are probably handy. L. Bruce Momjian writes: > Sorry, I meant bison 1.875 is now required, not 1.85. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Bison 1.875 RPMs
Guys, for your convenience i've put online a source RPM for Bison 1.875 along with binary RPMs for Redhat 7.2, 7.3 and 8.0. Hunting around the net i didn't find any existing Bison >= 1.50 RPMs, so this should be useful for those compiling PostgreSQL (ECPG in particular) from the CVS source: http://services.csl.co.uk/postgresql/bison-1.875-1PGDG.src.rpm http://services.csl.co.uk/postgresql/redhat72/bison-1.875-1PGDG.i386.rpm http://services.csl.co.uk/postgresql/redhat73/bison-1.875-1PGDG.i386.rpm http://services.csl.co.uk/postgresql/redhat80/bison-1.875-1PGDG.i386.rpm The PGDG tag seemed appropriate. >From version 1.50 onward Bison starting installing a 'yacc' script - i've disabled the creation of this in these RPMs so upgrades can be done simply without conflicting with the 'byacc' package (guess this is Bison based too)... Thanks, Lee. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] bison error
bigapple wrote: > hi, > When I check out the pgsql from cvs and I complile it, an error occured . > > dir: pgsql/src/interfaces/ecpg/preproc > bison -y -d preproc.y > erro information: > preproc.y:5559: fatal error: maximum table size (32767) exceeded. > You need at least version 1.5 of bison. Last time I checked, the latest out was 1.75 > However, I used the source from the ftp, find preproc.c in there. gmake will skip >the > step(bison -y -d preproc.y) and succeeded. > > who can tell me why? Source distributions contain preprocessed files so that you can compile PostgreSQL without needing bison installed. I think you only need bison if you get source code from CVS (or want to hack the grammar in the source distribution). HTH, Joe ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] bison error
On Mon, 2002-12-09 at 01:58, bigapple wrote: > When I check out the pgsql from cvs and I complile it, an error occured . > > dir: pgsql/src/interfaces/ecpg/preproc > bison -y -d preproc.y > erro information: > preproc.y:5559: fatal error: maximum table size (32767) exceeded. You need to use Bison 1.50 or greater, due to a limitation in previous versions of Bison. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] bison error
hi, When I check out the pgsql from cvs and I complile it, an error occured . dir: pgsql/src/interfaces/ecpg/preproc bison -y -d preproc.y erro information: preproc.y:5559: fatal error: maximum table size (32767) exceeded. However, I used the source from the ftp, find preproc.c in there. gmake will skip the step(bison -y -d preproc.y) and succeeded. who can tell me why? ¡¡ 2002-12-09 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bison 1.75 installed ...
Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > let me know if there are any problems with it > > > Other than the fact that it's about a factor of 16 slower than bison > 1.28, while not offering any substantial gain in functionality? If I > were a Bison maintainer, I'd hang my head in shame. > > > All PG regression tests pass here with 1.75-built parsers. 16x is the grammer output generation, not the actual parsing of the SQL, right? There are cases where slow output generation can lead to faster parsing, right? Let's hope that happened. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] bison 1.75 installed ...
let me know if there are any problems with it ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Bison 1.50 was released
Oh, that's right. I had forgotten that it wasn't for general PostgreSQL use. Since it's a ecpg deal only, I guess I remove my objection. Greg On Thu, 2002-10-10 at 09:18, Tom Lane wrote: > Greg Copeland <[EMAIL PROTECTED]> writes: > > Can we please hold off until bison 1.50 becomes a defacto? > > We don't have a whole lot of choice, unless you prefer releasing a > broken or crippled ecpg with 7.3. > > In practice this only affects people who pull sources from CVS, anyway. > If you use a tarball then you'll get prebuilt bison output. > > regards, tom lane > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Bison 1.50 was released
Greg Copeland wrote: -- Start of PGP signed section. > Can we please hold off until bison 1.50 becomes a defacto? It will be a > matter of weeks before distros offer this as an upgrade package let > alone months before distros offer this as a standard. Seems like these > changes are ideal for a release after next (7.5/7.6) as enough time will > of gone by for it to be much more commonly found. By not jumping on the > wagon now, it will also allow more time for bugs in the wild to be > caught and fixed before we force it onto the masses. No, we can't wait. A fully function ecpg has exceeded the bison tables sizes, so we need a new version now. Rememeber we ship pre-bison'ed files in the tarball, so only developers will need a new bison. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bison 1.50 was released
Greg Copeland <[EMAIL PROTECTED]> writes: > Can we please hold off until bison 1.50 becomes a defacto? We don't have a whole lot of choice, unless you prefer releasing a broken or crippled ecpg with 7.3. In practice this only affects people who pull sources from CVS, anyway. If you use a tarball then you'll get prebuilt bison output. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Bison 1.50 was released
Can we please hold off until bison 1.50 becomes a defacto? It will be a matter of weeks before distros offer this as an upgrade package let alone months before distros offer this as a standard. Seems like these changes are ideal for a release after next (7.5/7.6) as enough time will of gone by for it to be much more commonly found. By not jumping on the wagon now, it will also allow more time for bugs in the wild to be caught and fixed before we force it onto the masses. Greg On Thu, 2002-10-10 at 02:05, Michael Meskes wrote: > Hi, > > I just learned that bison 1.50 was released on Oct. 5th and it indeed > compiles ecpg just nicely on my machine. Could we please install this on > our main machine and merge the ecpg.big branch back into main? > > Michael > -- > Michael Meskes > [EMAIL PROTECTED] > Go SF 49ers! Go Rhein Fire! > Use Debian GNU/Linux! Use PostgreSQL! > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster signature.asc Description: This is a digitally signed message part
[HACKERS] Bison 1.50 was released
Hi, I just learned that bison 1.50 was released on Oct. 5th and it indeed compiles ecpg just nicely on my machine. Could we please install this on our main machine and merge the ecpg.big branch back into main? Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bison news
Bruce Momjian writes: > This may be a case where we have to do some beta testing on our own. I > will grab the bison beta myself for my machine. I imagine that bison doesn't get a lot of beta testing, since people don't have a whole bunch of production grammars lying around that they want to upgrade at the earliest possible moment. So if we want to test it more, we could propagate it to our beta testers. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bison news
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > OK, now that _a_ bison exists that works, how does this effect our > > release? I don't see preproc.[ch] in CVS. Do we need this new bison > > version on postgresql.org because Marc generates these as part of his > > install script? > > I don't think we want a beta bison on postgres.org. Let's see if we can > hold out for a release... Well, we had better get it on or it will get zero testing, and we _need_ it for the 7.3 release of ecpg, because as I remember, we didn't have any other good backup plans. ;-) This may be a case where we have to do some beta testing on our own. I will grab the bison beta myself for my machine. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bison news
Bruce Momjian <[EMAIL PROTECTED]> writes: > OK, now that _a_ bison exists that works, how does this effect our > release? I don't see preproc.[ch] in CVS. Do we need this new bison > version on postgresql.org because Marc generates these as part of his > install script? I don't think we want a beta bison on postgres.org. Let's see if we can hold out for a release... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] bison news
OK, now that _a_ bison exists that works, how does this effect our release? I don't see preproc.[ch] in CVS. Do we need this new bison version on postgresql.org because Marc generates these as part of his install script? --- Tom Lane wrote: > Michael Meskes <[EMAIL PROTECTED]> writes: > > On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote: > >> BTW, I spent some time looking at the problem, and it seems the issue > >> is not overrun of any bison internal table, but failure to compress the > >> resulting "action table" into 32K entries. This means that the required > > > Ouch! This of course is not so much a problem for ecpg but for the > > backend should we run into the problem there too. > > As of CVS tip a few days ago, the backend's action table was about 27K > entries. So we have some breathing room, but certainly in the > foreseeable future there will be a problem... > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] bison news
Michael Meskes <[EMAIL PROTECTED]> writes: > On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote: >> BTW, I spent some time looking at the problem, and it seems the issue >> is not overrun of any bison internal table, but failure to compress the >> resulting "action table" into 32K entries. This means that the required > Ouch! This of course is not so much a problem for ecpg but for the > backend should we run into the problem there too. As of CVS tip a few days ago, the backend's action table was about 27K entries. So we have some breathing room, but certainly in the foreseeable future there will be a problem... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bison news
On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote: > BTW, I spent some time looking at the problem, and it seems the issue > is not overrun of any bison internal table, but failure to compress the > resulting "action table" into 32K entries. This means that the required Ouch! This of course is not so much a problem for ecpg but for the backend should we run into the problem there too. > ... > Also, it seemed to me that the most leverage on the size of the > compressed action table would be gained by reducing the number of > terminal symbols, more so than the number of rules. Dunno if there > is a lot you can do about that, but it's a thought. Will look at it. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bison news
Michael Meskes <[EMAIL PROTECTED]> writes: > I just got the latest beta and it compiles ecpg grammar correctly! This is good. Any word on when it will go to an official release? BTW, I spent some time looking at the problem, and it seems the issue is not overrun of any bison internal table, but failure to compress the resulting "action table" into 32K entries. This means that the required expansion from short to int is not just a cost paid while you run bison; the actual table in the ecpg executable will double in size. I trust they did not fix the problem in a way that causes *every* generated parser to use an int[] rather than short[] action table ... Also, it seemed to me that the most leverage on the size of the compressed action table would be gained by reducing the number of terminal symbols, more so than the number of rules. Dunno if there is a lot you can do about that, but it's a thought. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] bison news
I just got the latest beta and it compiles ecpg grammar correctly! I had to make one change to my source though as bison no longer accepts a comma inside the token list. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] bison
Hi, I talked to one of the bison guys and he told me where to find a beta version of bison 1.49. And this one translates the grammar without a problem, no more table overflow. So once they will release the new bison we should be able to expand our grammar. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
