Re: [HACKERS] MAX Query length - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] MAX Query length
Date
Msg-id 6339.932050703@sss.pgh.pa.us
Whole thread Raw
In response to RE: [HACKERS] MAX Query length  ("Ansley, Michael" <Michael.Ansley@intec.co.za>)
Responses Interesting index/LIKE/join slowness problems
List pgsql-hackers
"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
> Once I have recompiled with a new block size, how do I update the databases
> that I already have.  If I understand right, once the block size has been
> updated, my current dbs will not work.  Do I just pg_dump before make
> install and then recreate the dbs and load the dumps afterwards?

Right, the real sequence when you are changing disk layout details ispg_dumpall with old pg_dump and backend.stop
postmasterrm-rf installationmake installinitdbstart postmasterpsql <pgdumpscript.
 

You may want to do your development work in a "playpen" installation
instead of risking breaking your "production" installation with these
sorts of shenanigans.  I do that all the time here; for one thing I
don't have to bother saving and restoring any data when I blow away
a playpen installation.

The easiest kind of playpen setup is a separate server machine, but if
you only have one machine available then you do something like this to
build a playpen:
configure --with-pgport=5440 --prefix=/users/postgres/testversion

(Adjust playpen's port and install location to taste; make more than one
if you want...)  BTW, if you are messing with the backend then your
playpen should also be built with --enable-cassert.

As I commented a moment ago, it's probably not really necessary for you
to change BLCKSZ for your testing, but the above tips are worth
repeating every so often for the benefit of new hackers.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] MAX Query length
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Counting bool flags in a complex query