Compiled fine. Still a few warnings (using Fedora Core 6 / AMD64).

The new PG_MAGIC_MODULE requirement threw me for a loop. I expect it
will catch others off guard as well.

One of my complicated queries that I threw at it seems to run about
10% - 20% faster now, which is pretty sweet.

The multiline wrap text editor in psql works really well, except it
seems to screw up if I resize the terminal. If I restore the terminal
to its original size, and refresh, it fixes itself.

I'm using it on one of my productions system now, and nothing has
failed yet. :-)

I'm pretty happy.

Good job people.

Cheers,
mark

--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
\ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

Search Discussions

  • Mark at Nov 5, 2006 at 6:38 am

    On Sun, Nov 05, 2006 at 01:15:51AM -0500, mark@mark.mielke.cc wrote:
    One of my complicated queries that I threw at it seems to run about
    10% - 20% faster now, which is pretty sweet.
    I take this back. I forgot to 'analyze'. After 'analyze', the times
    returned to the slower 8.1 times. :-(

    I will have to investigate. The generated plan is more complex after
    'analyze'...

    Cheers,
    mark

    --
    mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
    . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
    \/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
    \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
    One ring to rule them all, one ring to find them, one ring to bring them all
    and in the darkness bind them...

    http://mark.mielke.cc/
  • Simon Riggs at Nov 5, 2006 at 9:11 am

    On Sun, 2006-11-05 at 01:15 -0500, mark@mark.mielke.cc wrote:

    The new PG_MAGIC_MODULE requirement threw me for a loop. I expect it
    will catch others off guard as well.
    Did you find the documentation adequate? Could you locate what you
    needed to know quickly and accurately? Do you think the change was
    adequately explained?

    If that hit you then we're gonna get a few more people trip the same
    way. Do you have any suggestions as to how to avoid that experience for
    others?

    --
    Simon Riggs
    EnterpriseDB http://www.enterprisedb.com
  • Mark at Nov 5, 2006 at 3:45 pm

    On Sun, Nov 05, 2006 at 09:11:07AM +0000, Simon Riggs wrote:
    On Sun, 2006-11-05 at 01:15 -0500, mark@mark.mielke.cc wrote:
    The new PG_MAGIC_MODULE requirement threw me for a loop. I expect it
    will catch others off guard as well.
    Did you find the documentation adequate? Could you locate what you
    needed to know quickly and accurately? Do you think the change was
    adequately explained?
    The documentation was good - once I checked developer.postgresql.org
    for the latest copy.
    If that hit you then we're gonna get a few more people trip the same
    way. Do you have any suggestions as to how to avoid that experience for
    others?
    I believe the release notes are inadequate. I've read them three times
    before and it never stood out for me.

    Currently it is referenced under:

    E.1.3.16. Source Code Changes

    - Add PG_MODULE_MAGIC header blocks to all shared object files
    (Martijn van Ousterhout)

    The magic block prevents version mismatches between loadable object
    files and servers.


    I believe I read this all three times as a "internal PostgreSQL change
    for developers only". The PG_MODULE_MAGIC has a wider impact that what
    is listed above.

    I suspect this should be listed under "Migration to 8.2" or "Server
    Changes" as "loadable modules are now required to include PG_MODULE_MAGIC
    to protect the server from accidentally loading an incompatible module -
    all loadable module authors must implement the change described in the
    documentation to allow their loadable modules to work properly in 8.2".

    Cheers,
    mark

    --
    mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
    . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
    \/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
    \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
    One ring to rule them all, one ring to find them, one ring to bring them all
    and in the darkness bind them...

    http://mark.mielke.cc/
  • Tom Lane at Nov 11, 2006 at 12:34 am

    mark@mark.mielke.cc writes:
    On Sun, Nov 05, 2006 at 09:11:07AM +0000, Simon Riggs wrote:
    If that hit you then we're gonna get a few more people trip the same
    way. Do you have any suggestions as to how to avoid that experience for
    others?
    I believe the release notes are inadequate. I've read them three times
    before and it never stood out for me.
    I put a note about this into "Migration to 8.2".

    regards, tom lane
  • Neil Conway at Nov 5, 2006 at 4:01 pm

    On Sun, 2006-11-05 at 01:15 -0500, mark@mark.mielke.cc wrote:
    Compiled fine. Still a few warnings (using Fedora Core 6 / AMD64).
    Presumably those are just the standard warnings we can't easiy
    eliminate. If not, can you post them please?

    -Neil
  • Mark at Nov 5, 2006 at 4:30 pm

    On Sun, Nov 05, 2006 at 11:01:40AM -0500, Neil Conway wrote:
    On Sun, 2006-11-05 at 01:15 -0500, mark@mark.mielke.cc wrote:
    Compiled fine. Still a few warnings (using Fedora Core 6 / AMD64).
    Presumably those are just the standard warnings we can't easiy
    eliminate. If not, can you post them please?
    They all appear harmless. For the uninitialized warnings, the compiler
    is not able to prove that tm2timestamp, numericvar_to_int8, or
    cost_bitmap_tree_node always stores to the final argument and does not
    fetch from the final argument. An '= 0' would get rid of each of the
    warnings, and might simplify some code (that does conditional
    assignment to 0), although perhaps the goal is to improve performance
    and avoid an assignment to '= 0' if not necessary.

    I suspect initialization would have no measurable performance impact,
    and would improve the maintainability of the code. One more warning
    that people don't become trained to ignore. If tm2timestamp ever
    did not assign to the final argument, the value would be zero, and
    not random data from the stack.

    For the label warning, I think it might be generated by bison/yacc,
    and no REJECT rule is used?

    I don't know about the nbtinsert.c warnings. It looks like part of a
    structure is initialized, and then the structure is used. A little odd.

    I've included them all below. Pretty few for an open source project. :-)

    Cheers,
    mark


    gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
    claration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../../src/
    include -D_GNU_SOURCE -c -o nbtinsert.o nbtinsert.c
    nbtinsert.c: In function ‘_bt_insertonpg’:
    nbtinsert.c:1065: warning: ‘state.best_delta’ may be used uninitialized in this
    function
    nbtinsert.c:1065: warning: ‘state.newitemonleft’ may be used uninitialized in th
    is function
    nbtinsert.c:1065: warning: ‘state.firstright’ may be used uninitialized in this
    function

    gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
    claration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../../src/
    include -D_GNU_SOURCE -c -o costsize.o costsize.c
    costsize.c: In function ‘cost_bitmap_or_node’:
    costsize.c:707: warning: ‘subselec’ may be used uninitialized in this function
    costsize.c:706: warning: ‘subCost’ may be used uninitialized in this function
    costsize.c: In function ‘cost_bitmap_and_node’:
    costsize.c:663: warning: ‘subselec’ may be used uninitialized in this function
    costsize.c:662: warning: ‘subCost’ may be used uninitialized in this function
    costsize.c: In function ‘cost_bitmap_heap_scan’:
    costsize.c:514: warning: ‘indexSelectivity’ may be used uninitialized in this fu
    nction
    costsize.c:513: warning: ‘indexTotalCost’ may be used uninitialized in this func
    tion


    gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
    claration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../../src/
    include -D_GNU_SOURCE -c -o numeric.o numeric.c
    numeric.c: In function ‘numericvar_to_int4’:
    numeric.c:1777: warning: ‘val’ may be used uninitialized in this function
    numeric.c: In function ‘numeric_int2’:
    numeric.c:1867: warning: ‘val’ may be used uninitialized in this function
    numeric.c: In function ‘numeric_int8’:
    numeric.c:1820: warning: ‘result’ may be used uninitialized in this function



    gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
    claration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../../src/
    include -D_GNU_SOURCE -c -o timestamp.o timestamp.c
    timestamp.c: In function ‘timestamptz_zone’:
    timestamp.c:4388: warning: ‘result’ may be used uninitialized in this function
    timestamp.c: In function ‘timestamptz_timestamp’:
    timestamp.c:4356: warning: ‘result’ may be used uninitialized in this function
    timestamp.c: In function ‘timestamp2timestamptz’:
    timestamp.c:4323: warning: ‘result’ may be used uninitialized in this function
    timestamp.c: In function ‘timestamp_zone’:
    timestamp.c:4215: warning: ‘result’ may be used uninitialized in this function
    timestamp.c: In function ‘timestamptz_trunc’:
    timestamp.c:3254: warning: ‘result’ may be used uninitialized in this function
    timestamp.c: In function ‘SetEpochTimestamp’:
    timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function
    timestamp.c: In function ‘timestamptz_part’:
    timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function
    timestamp.c: In function ‘timestamp_part’:
    timestamp.c:3799: warning: ‘timestamptz’ may be used uninitialized in this funct
    ion
    timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function
    timestamp.c: In function ‘timestamp_in’:
    timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function
    timestamp.c: In function ‘timestamptz_in’:
    timestamp.c:1424: warning: ‘dt’ may be used uninitialized in this function

    gcc -O3 -march=athlon64 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wde
    claration-after-statement -Wendif-labels -fno-strict-aliasing -Wno-error -pthrea
    d -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -I../include -I../../.
    ./../src/interfaces/ecpg/include -I. -DMAJOR_VERSION=4 -DMINOR_VERSION=2 -DPATCH
    LEVEL=1 -I../../../../src/include -D_GNU_SOURCE -c -o preproc.o preproc.c
    In file included from preproc.y:6776:
    pgc.c: In function ‘yylex’:
    pgc.c:1570: warning: label ‘find_rule’ defined but not used

    --
    mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
    . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
    \/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
    \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
    One ring to rule them all, one ring to find them, one ring to bring them all
    and in the darkness bind them...

    http://mark.mielke.cc/
  • Tom Lane at Nov 11, 2006 at 1:17 am

    mark@mark.mielke.cc writes:
    On Sun, Nov 05, 2006 at 11:01:40AM -0500, Neil Conway wrote:
    Presumably those are just the standard warnings we can't easiy
    eliminate. If not, can you post them please?
    They all appear harmless.
    The reason those "uninitialized variable" warnings got away from us is
    that gcc doesn't emit them at -O2 or below, so most of us never saw 'em
    before. I've cleaned them up.

    The "find_rule" gripe is really a flex bug :-( ... not easy to avoid.

    regards, tom lane
  • Mark at Nov 11, 2006 at 1:54 am

    On Fri, Nov 10, 2006 at 08:17:09PM -0500, Tom Lane wrote:
    mark@mark.mielke.cc writes:
    On Sun, Nov 05, 2006 at 11:01:40AM -0500, Neil Conway wrote:
    Presumably those are just the standard warnings we can't easiy
    eliminate. If not, can you post them please?
    They all appear harmless.
    The reason those "uninitialized variable" warnings got away from us is
    that gcc doesn't emit them at -O2 or below, so most of us never saw 'em
    before. I've cleaned them up.
    Cool. Thanks. I like my compiles warnings free. :-)
    The "find_rule" gripe is really a flex bug :-( ... not easy to avoid.
    *nod*

    Cheers,
    mark

    --
    mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
    . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
    \/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
    \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
    One ring to rule them all, one ring to find them, one ring to bring them all
    and in the darkness bind them...

    http://mark.mielke.cc/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 5, '06 at 6:15a
activeNov 11, '06 at 1:54a
posts9
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase