[HACKERS] performance difference between pgsql and SQL
Hi, I am using postgreSQL 7.3.4 I have a single table in the databasse. mytable(id, tag, parent, label) all in int8. hash index is built for id and btree index for all attributes. now, I have over 9 million tuples in the table. The problem is when I access the database through psql interface, where I issued the following query: select tag from mytable where id = 1; it took 51880 milliseconds to execute. the "explain" command showed it used seq scan. I turned enable_seqscan and enable_nestloop off, and it still used seqscan. however, if I call it through a pgsql function, it only took aobut 0.17 milliseconds. create function test_tag(int8) returns int8 as' declare begin return tag from mytable where id = $1; end; ' language 'plpgsql'; This looks like a bug to me. -- Bill Shui ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] performance difference between pgsql and SQL
On Sat, 11 Oct 2003, Bill Shui wrote: > Hi, > > I am using postgreSQL 7.3.4 > > I have a single table in the databasse. > > mytable(id, tag, parent, label) > all in int8. > > hash index is built for id and btree index for all attributes. > Hash indexes are generally a bad idea in 7.3. > select tag from mytable where id = 1; Try: select tag from mytable where id = 1::int8; This is a known flaw of the typing system which the community has been discussing/attempting to fix for some time. Gavin ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 2-phase commit
On Fri, Oct 10, 2003 at 09:37:53PM -0700, Dann Corbit wrote: > Why not apply the effort to something already done and compatibly > licensed? > > This: > http://dog.intalio.com/ots.html > > Appears to be a Berkeley style licensed: > http://dog.intalio.com/license.html > > Transaction monitor. I'd say this is complementary, not an alternative to 2PC implementation issues. The transaction monitor lives on the other side of the problem. 2PC is needed in the database _so that_ the transaction monitor can do its job. That said, having a 3-tier model is probably a good idea if distributed transaction management is what we want. :-) Jeroen ---(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] compile warning
- Original Message - From: "Manfred Spraul" <[EMAIL PROTECTED]> > > The kernel is still compiled with -fno-strict-aliasing - I'm not sure if > there are outstanding problems, or if it's just a safety precaution. > We should probably do likewise, at least until this is cleaned up, if that's what we want to do, again probably from an overabundance of caution. cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pg_ctl reload - is it safe?
On Fri, Oct 10, 2003 at 23:07:59 -0400, Michael Brusser <[EMAIL PROTECTED]> wrote: > Env: Postgres 7.3.4 on Unix > > I have a script to create a new database user and update pg_hba.conf. Do you run multiple databases with not all users having access to all databases? If any valid use will have access to a particular database, then you can use 'any' for the username in the pg_hba.conf file and not have to worry about updating it. ---(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] compile warning
I have a fix for this which I will post to patches - essentially you cast the pointers to (void *) and the compiler doesn't complain. It would be a pity to turn off strict aliasing altogether, as it is known to improve performance in some cases. Tested on Cygwin/GCC 3.3.1 cheers andrew - Original Message - From: "Andrew Dunstan" <[EMAIL PROTECTED]> To: "PostgreSQL Hackers Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, October 11, 2003 8:58 AM Subject: Re: [HACKERS] compile warning > > - Original Message - > From: "Manfred Spraul" <[EMAIL PROTECTED]> > > > > The kernel is still compiled with -fno-strict-aliasing - I'm not sure if > > there are outstanding problems, or if it's just a safety precaution. > > > > We should probably do likewise, at least until this is cleaned up, if that's > what we want to do, again probably from an overabundance of caution. > > cheers > > andrew > > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] compile warning
Andrew Dunstan wrote: > > I have a fix for this which I will post to patches - essentially you cast > the pointers to (void *) and the compiler doesn't complain. It would be a > pity to turn off strict aliasing altogether, as it is known to improve > performance in some cases. > > Tested on Cygwin/GCC 3.3.1 I am not sure about the patch. I know it fixes it, but is the compiler actually reporting a valid concern, or is it broken? Is it complaining about passing a struct pointer of one type to another? Don't we do that all over the place? I hate to add a patch just to fix a buggy version of a compiler. If we do apply this patch, I think we should cast to (void *), then to the valid type, and add a comment in each instance about its purpose. -- 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
[HACKERS] OpenORB Re: 2-phase commit
> From: "Dann Corbit" <[EMAIL PROTECTED]> > Subject: Re: 2-phase commit > Date: Fri, 10 Oct 2003 21:37:53 -0700 > Why not apply the effort to something already done and compatibly > licensed? I'm not sure, what is your point here exactly? To use OpenORB as as a transaction monitor, you'd still need XA protocol support (which means 2-phase commit) in each of the PostgreSQL databases being overseen by that transaction monitor, no? Or are you saying that OpenORB includes XA support for both the master and the slave (I am probably using the wrong terminology here), the code be linked in or otherwise used as-is for PostgreSQL? Either way, have you actually used OpenORB with a RDBMS, or heard feedback from anyone else who personally has? > This: > http://dog.intalio.com/ots.html > > Appears to be a Berkeley style licensed: > http://dog.intalio.com/license.html > > Transaction monitor. > > "Overview > The OpenORB Transaction Service is a very scalable transaction monitor > which also provides several extensions like XA management, a management > interface to control all transaction processes and a high reliable > recovery system. > Here is a sourceforge version of the same thing > http://openorb.sourceforge.net/ -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] compile warning
- Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> To: "Andrew Dunstan" <[EMAIL PROTECTED]> Cc: "PostgreSQL Hackers Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, October 11, 2003 11:26 AM Subject: Re: [HACKERS] compile warning > Andrew Dunstan wrote: > > > > I have a fix for this which I will post to patches - essentially you cast > > the pointers to (void *) and the compiler doesn't complain. It would be a > > pity to turn off strict aliasing altogether, as it is known to improve > > performance in some cases. > > > > Tested on Cygwin/GCC 3.3.1 > > I am not sure about the patch. I know it fixes it, but is the compiler > actually reporting a valid concern, or is it broken? Is it complaining > about passing a struct pointer of one type to another? Don't we do that > all over the place? > > I hate to add a patch just to fix a buggy version of a compiler. If we > do apply this patch, I think we should cast to (void *), then to the > valid type, and add a comment in each instance about its purpose. > This is not a compiler bug. The compiler is behaving perfectly correctly. See http://www.gnu.org/software/gcc/bugs.html#nonbugs_c. See also http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html for more info. Actually, the fact that we get so few warnings on this is a monument to how clean our code is, although the warnings are not guaranteed to catch every instance of illegal type-punning. If you look through the code you will see that we are casting to void * all over the place. (I count 772 instances of the string "void *" in the code). AFAIK this patch will inhibit the compiler from making type alias assumptions which could result in nasty reordering of operations, but I could be wrong. The other problem could be pointer misalignment, but if so we would surely have seen it from straight casts by now - I'd be more worried about operation reordering than misalignment, but maybe this would need to be tested on a platform with heavier alignment restrictions than any machine I have (a SPARC, say?). If you don't want to do this we could turn off strict-aliasing. You might take a performance hit, though - see http://www.freetype.org/pipermail/devel/2003-June/009452.html for info on what the FreeType people found. There are more fundamental ways of addressing this, but they are far more intrusive to the code, and presumably we don't want that at this stage in the cycle. Incidentally, I understand that other compilers than gcc are starting to implment this part of the standard, so even if we turn it off for gcc we'll have to deal with it eventually. cheers andrew cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] compile warning
Agreed. Patch applied. I was confused because the original posted URL mentioned unions, which was a different alignment issue from just structure pointer compatibility. --- Andrew Dunstan wrote: > > - Original Message - > From: "Bruce Momjian" <[EMAIL PROTECTED]> > To: "Andrew Dunstan" <[EMAIL PROTECTED]> > Cc: "PostgreSQL Hackers Mailing List" <[EMAIL PROTECTED]> > Sent: Saturday, October 11, 2003 11:26 AM > Subject: Re: [HACKERS] compile warning > > > > Andrew Dunstan wrote: > > > > > > I have a fix for this which I will post to patches - essentially you > cast > > > the pointers to (void *) and the compiler doesn't complain. It would be > a > > > pity to turn off strict aliasing altogether, as it is known to improve > > > performance in some cases. > > > > > > Tested on Cygwin/GCC 3.3.1 > > > > I am not sure about the patch. I know it fixes it, but is the compiler > > actually reporting a valid concern, or is it broken? Is it complaining > > about passing a struct pointer of one type to another? Don't we do that > > all over the place? > > > > I hate to add a patch just to fix a buggy version of a compiler. If we > > do apply this patch, I think we should cast to (void *), then to the > > valid type, and add a comment in each instance about its purpose. > > > > This is not a compiler bug. The compiler is behaving perfectly correctly. > See http://www.gnu.org/software/gcc/bugs.html#nonbugs_c. > > See also http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html for > more info. > > Actually, the fact that we get so few warnings on this is a monument to how > clean our code is, although the warnings are not guaranteed to catch every > instance of illegal type-punning. > > If you look through the code you will see that we are casting to void * all > over the place. (I count 772 instances of the string "void *" in the code). > > AFAIK this patch will inhibit the compiler from making type alias > assumptions which could result in nasty reordering of operations, but I > could be wrong. The other problem could be pointer misalignment, but if so > we would surely have seen it from straight casts by now - I'd be more > worried about operation reordering than misalignment, but maybe this would > need to be tested on a platform with heavier alignment restrictions than any > machine I have (a SPARC, say?). > > If you don't want to do this we could turn off strict-aliasing. You might > take a performance hit, though - see > http://www.freetype.org/pipermail/devel/2003-June/009452.html for info on > what the FreeType people found. > > There are more fundamental ways of addressing this, but they are far more > intrusive to the code, and presumably we don't want that at this stage in > the cycle. Incidentally, I understand that other compilers than gcc are > starting to implment this part of the standard, so even if we turn it off > for gcc we'll have to deal with it eventually. > > cheers > > andrew > > cheers > > andrew > > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend > -- 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 8: explain analyze is your friend
Re: [HACKERS] compile warning
On Sat, Oct 11, 2003 at 12:31:35PM -0400, Bruce Momjian wrote: > > Agreed. Patch applied. I was confused because the original posted URL > mentioned unions, which was a different alignment issue from just > structure pointer compatibility. In the article Andrew mentioned, it is said that the unions thingie is a GCC extension for solving the problem, thus unportable. -- Alvaro Herrera () "If it wasn't for my companion, I believe I'd be having the time of my life" (John Dunbar) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] compile warning
On Sat, Oct 11, 2003 at 12:17:42PM -0400, Andrew Dunstan wrote: > If you don't want to do this we could turn off strict-aliasing. You might > take a performance hit, though - see > http://www.freetype.org/pipermail/devel/2003-June/009452.html for info on > what the FreeType people found. See the followup. That was actually a mistake in the metodology that turned -O2 off. The real performance decrease is said to be 1-2%, not the 100% that the original articly says. -- Alvaro Herrera () "En las profundidades de nuestro inconsciente hay una obsesiva necesidad de un universo lógico y coherente. Pero el universo real se halla siempre un paso más allá de la lógica" (Irulan) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] compile warning
It has just been pointed out to me that the Freetype guy misconfigured his test settings, so the performance gain was not great. See http://www.freetype.org/pipermail/devel/2003-June/009453.html the other points are valid, though. I think we should be proud of the fact we can do this :-) - other projects have just given up on it and use -fno-strict-aliasing. cheers andrew - Original Message - From: "Andrew Dunstan" <[EMAIL PROTECTED]> To: "PostgreSQL Hackers Mailing List" <[EMAIL PROTECTED]> Sent: Saturday, October 11, 2003 12:17 PM Subject: Re: [HACKERS] compile warning > > - Original Message - > From: "Bruce Momjian" <[EMAIL PROTECTED]> > To: "Andrew Dunstan" <[EMAIL PROTECTED]> > Cc: "PostgreSQL Hackers Mailing List" <[EMAIL PROTECTED]> > Sent: Saturday, October 11, 2003 11:26 AM > Subject: Re: [HACKERS] compile warning > > > > Andrew Dunstan wrote: > > > > > > I have a fix for this which I will post to patches - essentially you > cast > > > the pointers to (void *) and the compiler doesn't complain. It would be > a > > > pity to turn off strict aliasing altogether, as it is known to improve > > > performance in some cases. > > > > > > Tested on Cygwin/GCC 3.3.1 > > > > I am not sure about the patch. I know it fixes it, but is the compiler > > actually reporting a valid concern, or is it broken? Is it complaining > > about passing a struct pointer of one type to another? Don't we do that > > all over the place? > > > > I hate to add a patch just to fix a buggy version of a compiler. If we > > do apply this patch, I think we should cast to (void *), then to the > > valid type, and add a comment in each instance about its purpose. > > > > This is not a compiler bug. The compiler is behaving perfectly correctly. > See http://www.gnu.org/software/gcc/bugs.html#nonbugs_c. > > See also http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html for > more info. > > Actually, the fact that we get so few warnings on this is a monument to how > clean our code is, although the warnings are not guaranteed to catch every > instance of illegal type-punning. > > If you look through the code you will see that we are casting to void * all > over the place. (I count 772 instances of the string "void *" in the code). > > AFAIK this patch will inhibit the compiler from making type alias > assumptions which could result in nasty reordering of operations, but I > could be wrong. The other problem could be pointer misalignment, but if so > we would surely have seen it from straight casts by now - I'd be more > worried about operation reordering than misalignment, but maybe this would > need to be tested on a platform with heavier alignment restrictions than any > machine I have (a SPARC, say?). > > If you don't want to do this we could turn off strict-aliasing. You might > take a performance hit, though - see > http://www.freetype.org/pipermail/devel/2003-June/009452.html for info on > what the FreeType people found. > > There are more fundamental ways of addressing this, but they are far more > intrusive to the code, and presumably we don't want that at this stage in > the cycle. Incidentally, I understand that other compilers than gcc are > starting to implment this part of the standard, so even if we turn it off > for gcc we'll have to deal with it eventually. > > cheers > > andrew > > cheers > > andrew > > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend ---(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] pg_resetxlog fixed
[EMAIL PROTECTED] writes: > Changed a couple of lines and traslated them in a better way. Installed, and the other one as well. Please send it to pgsql-patches next time. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Hacking PostgreSQL to work in Mac OS X 10.3 (Panther 7B85)
All, After toying with a few builds of the up coming OS X 10.3 (Panther) release, I've written a doc on how to get postgresql to build using Panther build 7B85 and Xcode build 7B85 (which are rumored to be the gold master and the builds that will be shipping later this month). Two things needed to be hacked to get postgresql to build from darwinports, and I'm assuming the same fixes would apply to a build from a .tar.gz. Essentially, a header file installed by Apple's Xcode devel tools needs to be edited, and the template for darwin needs a line removed. This fix is also known to work with OS X 10.3 build 7B85 and Xcode 7B68. Whilst I'm not in a position to analyse the root cause of why these hacks are needed, this doc is simply a quick and dirty guide to hacking it together. Scenario Fresh install of OS X 10.3 7B85 Fresh install of Xcode 7B85 howrare:~ jwilson$ sudo port install postgresql btodb Compiler Error Error: Target com.apple.build returned: shell command "cd "/Library/DarwinPorts/dports/databases/postgresql/work/postgresql -7.3.2" && CPPFLAGS=-I/opt/local/include CFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib gnumake all" returned error 2 Command output: gnumake[2]: Nothing to be done for `all'. gnumake -C backend all gnumake -C ../../src/port all gnumake[3]: Nothing to be done for `all'. prereqdir=`cd parser/ >/dev/null && pwd` && \ cd ../../src/include/parser/ && rm -f parse.h && \ ln -s "$prereqdir/parse.h" . gnumake -C utils fmgroids.h CPP='gcc -traditional-cpp -E' AWK='awk' /bin/sh Gen_fmgrtab.sh ../../../src/include/catalog/pg_proc.h cd ../../src/include/utils/ && rm -f fmgroids.h && \ ln -s ../../../src/backend/utils/fmgroids.h . gnumake -C access all gnumake -C common SUBSYS.o gcc -traditional-cpp -I/opt/local/include -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -I/opt/local/include -c -o heaptuple.o heaptuple.c gcc -traditional-cpp -I/opt/local/include -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -I/opt/local/include -c -o indextuple.o indextuple.c gcc -traditional-cpp -I/opt/local/include -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -I/opt/local/include -c -o indexvalid.o indexvalid.c gcc -traditional-cpp -I/opt/local/include -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -I/opt/local/include -c -o printtup.o printtup.c In file included from /usr/include/machine/param.h:30, from /usr/include/sys/socket.h:67, from ../../../../src/include/libpq/pqcomm.h:28, from ../../../../src/include/libpq/libpq-be.h:24, from ../../../../src/include/libpq/libpq.h:21, from printtup.c:20: /usr/include/ppc/param.h:98: macro "btodb" requires 2 arguments, but only 1 given /usr/include/ppc/param.h:100: macro "dbtob" requires 2 arguments, but only 1 given gnumake[4]: *** [printtup.o] Error 1gnumake[3]: *** [common-recursive] Error 2 gnumake[2]: *** [access-recursive] Error 2 gnumake[1]: *** [all] Error 2 gnumake: *** [all] Error 2 Workaround -- howrare:~ jwilson$ sudo cp /usr/include/ppc/param.h /usr/include/ppc/param.h_pgfix howrare:~ jwilson$ sudo vim /usr/include/ppc/param.h * Go to line 90 (Type '90gg') Note this section: /* bytes to pages */ #define btoc(x) (((unsigned)(x)+(PGOFSET))>>PGSHIFT) #ifdef __APPLE__ #define btodb(bytes, devBlockSize) \ ((unsigned)(bytes) / devBlockSize) #define dbtob(db, devBlockSize)\ ((unsigned)(db) * devBlockSize) #else #define btodb(bytes)/* calculates (bytes / DEV_BSIZE) */ \ ((unsigned)(bytes) >> DEV_BSHIFT) #define dbtob(db) /* calculates (db * DEV_BSIZE) */ \ ((unsigned)(db) << DEV_BSHIFT) #endif It seems that __APPLE__ is defined somehow (perhaps it should be) when postgres is compiling. Hence, the btodb macros are expecting two args and getting only one. The quick and dirty fix is to remove the ifdef __APPLE__ portion of the code and leave it such that the only macros defined are the single arg ones. Hence, delete these lines: #ifdef __APPLE__ #define btodb(bytes, devBlockSize) \ ((unsigned)(bytes) / devBlockSize) #define dbtob(db, devBlockSize)\ ((unsigned)(db) * devBlockSize) #else And then delete the "#endif" line at the end of that section of code (Just above the comment block for the next section which starts with "Map a ``block device block``" As such, after deleting the lines the code section at line 90 and beyond should look like this: /* bytes to pages */ #define btoc(x) (((unsigned)(x)+(PGOFSET))>>PGSHIFT) #define btodb(bytes)/* calculates (bytes / DEV_BSIZE) */ \ ((unsigned)(bytes) >> DEV_BSHIFT) #define dbtob(db) /* calc
Re: [HACKERS] Hacking PostgreSQL to work in Mac OS X 10.3 (Panther 7B85)
James, we've spent some time lately with Mac OS X related changes to the code base. Please try this again with a fresh CVS copy of PostgreSQL and let us know if there are any further changes you think we'd need to work properly with Panther. Thanks, mk On 11.10.2003, at 04:32, James Wilson wrote: After toying with a few builds of the up coming OS X 10.3 (Panther) release, I've written a doc on how to get postgresql to build using Panther build 7B85 and Xcode build 7B85 (which are rumored to be the gold master and the builds that will be shipping later this month). ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PERFORM] Sun performance - Major discovery!
On 8.10.2003, at 21:31, Bruce Momjian wrote: Well, this is really embarassing. I can't imagine why we would not set at least -O on all platforms. Looking at the template files, I see these have no optimization set: darwin Regarding Darwin optimizations, Apple has introduced a "-fast" flag in their GCC 3.3 version that they recommend when compiling code for their new G5 systems. Because of this, I foresee a lot of people defining CFLAGS="-fast" on their systems. This is problematic for PostgreSQL, however, since the -fast flag is the equivalent of: -O3 -falign-loops-max-skip=15 -falign-jumps-max-skip=15 -falign-loops=16 -falign-jumps=16 -falign-functions=16 -malign-natural -ffast-math -fstrict-aliasing -frelax-aliasing -fgcse-mem-alias -funroll-loops -floop-transpose -floop-to-memset -finline-floor -mcpu=G5 -mpowerpc64 -mpowerpc-gpopt -mtune=G5 -fsched-interblock -fload-after-store --param max-gcse-passes=3 -fno-gcse-sm -fgcse-loop-depth -funit-at-a-time -fcallgraph-inlining -fdisable-typechecking-for-spec At least the --fast-math part causes problems, seeing that PostgreSQL actually checks for the __FAST_MATH__ macro to make sure that it isn't turned on. There might be other problems with Apple's flags, but I think that the __FAST_MATH__ check should be altered. As you know, setting --fast-math in GCC is the equivalent of setting -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, -ffinite-math-only and -fno-signaling-nans. What really should be done, I think, is adding the opposites of these flags (-fmath-errno, -fno-unsafe-math-optimizations, -ftrapping_math, -fno-finite-math-only and -fsignaling-nans) to the command line if __FAST_MATH__ is detected. This would allow people to use CFLAGS="-fast" on their G5s, beat some Xeon speed records, and not worry about esoteric IEEE math standards. What do you guys think? GCC sets __FAST_MATH__ even if you counter a -ffast-math with the negating flags above. This means that it is not currently possible to use the -fast flag when compiling PostgreSQL at all. Instead, you have to go through all the flags Apple is setting and only pass on those that don't break pg. mk ---(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] [PATCHES] fix for strict-alias warnings
[ Moved to hackers.]
Andrew Dunstan wrote:
> struct foobar {
> int tag;
> union {
> struct foo foo;
> struct bar bar;
> } v;
> };
>
OK, this is very clear. Thanks.
> > The proc.c cases were using MemSet, which was checking if the
> > int* as aligned for int* access. In fact, we could change MemSet to
> > always take a void *, and do the int* casting when we access it after
> > testing for alignment.
> >
>
> Since MemSet is generic, that is probably a good idea.
Done.
> > The big question in my mind is whether there there is other struct *
> > passing that could be masked right now by void* casting, and if so, do
> > they have different first elements? This determined whether we do
> > -fstrict-aliasing for gcc, or fix just these few cases.
>
> Just analysing this is a non-trivial piece of work, I think.
I understand the desire to deal with this later, but we never seem to
focus on compiler issues except during beta.
I think I know why we are hitting the warning in tablecmds.c and not in
trigger.c. Trigger.c has:
ExecCallTriggerFunc(TriggerData *trigdata,
FmgrInfo *finfo,
MemoryContext per_tuple_context)
{
...
fcinfo.flinfo = finfo;
fcinfo.context = (Node *) trigdata;
This does not generate a warning, while this does in tablecmds.c:
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
FunctionCallInfoData fcinfo;
TriggerData trigdata;
/*
* Make a call to the trigger function
*
* No parameters are passed, but we do set a context
*/
MemSet(&fcinfo, 0, sizeof(fcinfo));
/*
* We assume RI_FKey_check_ins won't look at flinfo...
*/
trigdata.type = T_TriggerData;
trigdata.tg_event = TRIGGER_EVENT_INSERT | TRIGGER_EVENT_ROW;
trigdata.tg_relation = rel;
trigdata.tg_trigtuple = tuple;
trigdata.tg_newtuple = NULL;
trigdata.tg_trigger = &trig;
fcinfo.context = (Node *) &trigdata;
RI_FKey_check_ins(&fcinfo);
}
trigger.c doesn't generate the warning because it is a TriggerData*,
while tablecmds.c has an acual structure. trigger.c doesn't know if the
passed pointer was allocated via malloc(), and therefore properly
aligned for any data type, or if it was allocated on the stack, so it
does not complain.
In tablecmds.c, they create it as local loop structure that is passed to
RI_FKey_check_ins(). What we should be doing in this code is allocating
a proper Node structure using makeNode(TriggerData), and using that in
the loop. (We should allocate it outside the loop.)
I see the same problem in execQual.c. sysv_shmem probably needs the
void*, and psql/command.c should have parse_char defines as unsigned
char **, rather than char **.
Comments?
--
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] [PATCHES] fix for strict-alias warnings
Bruce Momjian wrote:
I understand the desire to deal with this later, but we never seem to
focus on compiler issues except during beta.
I think I know why we are hitting the warning in tablecmds.c and not in
trigger.c. Trigger.c has:
ExecCallTriggerFunc(TriggerData *trigdata,
FmgrInfo *finfo,
MemoryContext per_tuple_context)
{
...
fcinfo.flinfo = finfo;
fcinfo.context = (Node *) trigdata;
This does not generate a warning, while this does in tablecmds.c:
while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
FunctionCallInfoData fcinfo;
TriggerData trigdata;
/*
* Make a call to the trigger function
*
* No parameters are passed, but we do set a context
*/
MemSet(&fcinfo, 0, sizeof(fcinfo));
/*
* We assume RI_FKey_check_ins won't look at flinfo...
*/
trigdata.type = T_TriggerData;
trigdata.tg_event = TRIGGER_EVENT_INSERT | TRIGGER_EVENT_ROW;
trigdata.tg_relation = rel;
trigdata.tg_trigtuple = tuple;
trigdata.tg_newtuple = NULL;
trigdata.tg_trigger = &trig;
fcinfo.context = (Node *) &trigdata;
RI_FKey_check_ins(&fcinfo);
}
trigger.c doesn't generate the warning because it is a TriggerData*,
while tablecmds.c has an acual structure. trigger.c doesn't know if the
passed pointer was allocated via malloc(), and therefore properly
aligned for any data type, or if it was allocated on the stack, so it
does not complain.
I could be wrong, but I don't think it has to do with malloc or whether
or not it is on the stack or in dynamic memory, but rather to do with
the fact that you have manipulated it using one personality and then
cast it to another.
In tablecmds.c, they create it as local loop structure that is passed to
RI_FKey_check_ins(). What we should be doing in this code is allocating
a proper Node structure using makeNode(TriggerData), and using that in
the loop. (We should allocate it outside the loop.)
I see the same problem in execQual.c. sysv_shmem probably needs the
void*, and psql/command.c should have parse_char defines as unsigned
char **, rather than char **.
signedness is not supposed to affect strict aliasing, but the compiler
could be confused.
(disclaimer) I am not a language lawyer, and this is one of those rare
times we need one :-) Don't take my word for it on this stuff.
cheers
andrew
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[HACKERS] VARHDRSZ
Hi guys, For formatting types pre-7.1, how do I know what the value of VARHDRSZ is? (Given that it's a PHP script, say.) I need to be able to subtract that from the typmod to get the field length. Is it possible? Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
