Beginner question: Hacking environment?

Adrian von Bidder <avbidder@fortytwo.ch> wrote:

Is there a short howto on how to start / debug postgres from
within the unpacked/compiled tar? Are there scripts that set up
linker paths and Postgres' environment?

You should probably start by reading the developer FAQ page:

http://wiki.postgresql.org/wiki/Developer_FAQ

If you still have questions, be sure to mention your OS.

-Kevin

Hi,

On Tuesday 08 March 2011 15.39:56 Kevin Grittner wrote:

http://wiki.postgresql.org/wiki/Developer_FAQ

thanks

If you still have questions, be sure to mention your OS.

Sorry, forgot. Linux.

The "Basic system testing" item is where I'm kinda stuck. You advise to
"perform run time testing via psql." Which is a bit short, since obviously
psql can't be directly started since there is no installation...

Aagain, my question: are there wrappers/helpers to do this easily from the
source/compile tree? Like: set up PATH, LD_LIBRARY_PATH, PG_WHATEVER, call
initdb, ...

Or do you advise to just "make install" and test from there?

thanks
-- vbi

--
[...] if you have to do the occasional model for Japanese collectors,
which are covered in reticulated ostrich testicle leather, then by all
means continue to do so.
-- Michael Reichmann
http://www.luminous-landscape.com/essays/leica-open-letter.shtml

On Tue, Mar 8, 2011 at 9:17 AM, Adrian von Bidder <avbidder@fortytwo.ch> wrote:

Hi,

On Tuesday 08 March 2011 15.39:56 Kevin Grittner wrote:

http://wiki.postgresql.org/wiki/Developer_FAQ

thanks

If you still have questions, be sure to mention your OS.

Sorry, forgot.  Linux.

The "Basic system testing" item is where I'm kinda stuck. You advise to
"perform run time testing via psql." Which is a bit short, since obviously
psql can't be directly started since there is no installation...

Aagain, my question: are there wrappers/helpers to do this easily from the
source/compile tree? Like: set up PATH, LD_LIBRARY_PATH, PG_WHATEVER, call
initdb, ...

sure, linux distos provide packages that do all that stuff. if you are
rolling your own from scratch, you have to do some of that
yourself...create the user, set the path, etc. This is all documented
here: http://www.postgresql.org/docs/9.0/interactive/install-post.html.
If you are hacking postgres this will become second nature to you
very quickly.

merlin

Adrian von Bidder <avbidder@fortytwo.ch> wrote:

Or do you advise to just "make install" and test from there?

Pretty much. For development you will want to specify a few options
in the ./configure step. At a minimum I recommend:

--prefix=
--enable-debug
--enable-cassert
--enable-depend

See this page for other options:

http://www.postgresql.org/docs/9.0/interactive/install-procedure.html

Of course, there are those who prefer to use eclipse or some other
IDE. For setting up eclipse, see this page:

http://wiki.postgresql.org/wiki/Working_with_Eclipse

I see that page is a bit out of date (we've converted from CVS to
git), but perhaps you can extrapolate.

-Kevin

On tis, 2011-03-08 at 16:17 +0100, Adrian von Bidder wrote:

Aagain, my question: are there wrappers/helpers to do this easily from
the source/compile tree? Like: set up PATH, LD_LIBRARY_PATH,
PG_WHATEVER, call initdb, ...

Many developers have their own wrapper scripts, mainly to handle dealing
with multiple versions or branches. But just to build and test one
version you don't need to set any environment variables.

Hi,

On Tuesday 08 March 2011 16.58:58 Kevin Grittner wrote:

Adrian von Bidder <avbidder@fortytwo.ch> wrote:

Or do you advise to just "make install" and test from there?

Pretty much.

Thanks for all your answers. I was just a bit confused because when I write
stuff for myself I usually set up stuff to run directly in the build
environment, so I was expecting something like that to be available. But
make install into ~/pg will do fine as well. (I want to avoid having my
trashed version version be available systemwide...)

cheers
-- vbi

--
I've never been DPL (AFAICT)
-- Pierre Habouzit on debian-vote, 2007-07-31

Adrian von Bidder <avbidder@fortytwo.ch> writes:

Thanks for all your answers. I was just a bit confused because when I write
stuff for myself I usually set up stuff to run directly in the build
environment, so I was expecting something like that to be available. But
make install into ~/pg will do fine as well. (I want to avoid having my
trashed version version be available systemwide...)

No, nobody installs test versions into "real" locations. What you want
is to set an install spot with configure --prefix. For instance, I
usually do
configure --prefix=/home/tgl/testversion --enable-debug --enable-cassert
Be sure to add $PREFIX/bin to your PATH so that you can call the
test-installation programs conveniently.

It's also often a good idea to specify a non-default port number using
--with-pgport so that you can run your test postmaster concurrently with
a regular one.

Lastly, setting PGDATA in your environment to a suitable test database
location will save typing and avoid mistakes.

As Peter mentioned, most of us have scripts to set up a preferred
working environment of this sort. I think I've published mine at least
once ... check the archives.

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> wrote:

As Peter mentioned, most of us have scripts to set up a preferred
working environment of this sort. I think I've published mine at
least once

That reminds me -- Greg Smith put something together which might
make it easier to get started:

https://github.com/gregs1104/peg/

-Kevin

On 03/08/2011 01:04 PM, Kevin Grittner wrote:

Tom Lane<tgl@sss.pgh.pa.us> wrote:

As Peter mentioned, most of us have scripts to set up a preferred
working environment of this sort. I think I've published mine at
least once

That reminds me -- Greg Smith put something together which might
make it easier to get started:

https://github.com/gregs1104/peg/

FWIW, the buildfarm software
<https://github.com/PGBuildFarm/client-code&gt; has a couple of developer
modes. They are particularly useful for testing patches, as the script
runs through a complete build and test cycle with one command.

cheers

andrew

Heyho again!

Now this kind of stuff is what I was after :-)

On Tuesday 08 March 2011 19.04:53 Kevin Grittner wrote:

That reminds me -- Greg Smith put something together which might
make it easier to get started:

https://github.com/gregs1104/peg/

Since you don't allow anonymous editing of the wiki, nor have an obvious
"create account", I leave it to you to add this:

+++
How can I easily test my modified postgres version?

You'll want to install PostgreSQL into a local directory (in your home
directory, for instance) to avoid conflicting with a system wide
installation. Use the --prefix=... option to specify an installation
location; --with-pgport to specify a non-standard default port may also be
helpful. To run this instance, you will need to make sure that the correct
binaries are used; depending on your operating system, environment variables
like PATH and LD_LIBRARY_PATH (on most Linux/Unix-like systems) need to be
set. Setting PGDATA will also be useful.

To avoid having to set this environment up manually, you may want to use
Greg Smith's [href="https://github.com/gregs1104/peg peg] scripts, or the
[https://github.com/PGBuildFarm/client-code scripts] that are used on the
buildfarm.
+++

... and you'll never have to answer to this "stupid" question again ... :-)

thanks & happy hacking
-- vbi

P.S.: those who remember me from many months back may guess that I'm trying
to implement IMMUTABLE columns. But I'll come back when I actually have to
show something, so far I've only managed to break 121 of 124 tests of "make
check". At least initdb miraculously works again.

--
this email is protected by a digital signature: http://fortytwo.ch/gpg

Hi,

On Tuesday 08 March 2011 21:12:53 Adrian von Bidder wrote:

Since you don't allow anonymous editing of the wiki, nor have an obvious
"create account", I leave it to you to add this:

Its linked on the mainpage: http://www.postgresql.org/community/signup

Andres

[adding webmaster to cc]

On Tuesday 08 March 2011 21.20:20 Andres Freund wrote:

"create account", ...

Its linked on the mainpage: http://www.postgresql.org/community/signup

Hmm. Could it be that this web form doesn't have a mail queue and thus
doesn't retry to send the mail when the first attempt was denied by
greylisting? And now it says "user already exists"...

(At least: I hven't seen a retry for 4h, first mail was rejected at 08:42
+0100)

cheers
-- vbi

--
featured product: Debian GNU/Linux - http://debian.org

On Wed, Mar 9, 2011 at 13:00, Adrian von Bidder <avbidder@fortytwo.ch> wrote:

[adding webmaster to cc]

On Tuesday 08 March 2011 21.20:20 Andres Freund wrote:

"create account", ...

Its linked on the mainpage: http://www.postgresql.org/community/signup

Hmm.  Could it be that this web form doesn't have a mail queue and thus
doesn't retry to send the mail when the first attempt was denied by
greylisting?  And now it says "user already exists"...

It definitely does have this.

I see a graylisted email that's in the queue... I'll give it a kick,
but normally you jsut have to wait...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On Wednesday 09 March 2011 13.05:55 Magnus Hagander wrote:

I see a graylisted email that's in the queue... I'll give it a kick,
but normally you jsut have to wait...

Thanks, it arrived.

I'm used to wait when I enable greylisting. >4h delay is rare, though.

greets
-- vbi

--
I liken ISPs to sausage factories. You know what goes in, and you think
that what comes out is tasty, but by Apollo's unwashed speedos you DON'T
want to know what goes on in between.
-- Sid Dabster

Excerpts from Adrian von Bidder's message of mié mar 09 09:13:04 -0300 2011:

On Wednesday 09 March 2011 13.05:55 Magnus Hagander wrote:

I see a graylisted email that's in the queue... I'll give it a kick,
but normally you jsut have to wait...

Thanks, it arrived.

I'm used to wait when I enable greylisting. >4h delay is rare, though.

Yeah, I think these servers wait for an excessive period if the initial
delivery fails.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support