how many changes about backend mode from 7.2.2 to 8.4.0?

hi, all
NOTE: fedora 17 x86_64, 7.2.2 can not be compiled in the env, I choose
8.4.0 because I think old version is easier to understand than newer
version!

I want to study pg's external sort (in tuplesort.c )through 8.4.0's source
code, and use ddd to do it, according to usingddd-postgres
<http://www-inst.eecs.berkeley.edu/~cs186/fa04/usingddd.pdf> 's description:

In the backend mode, you don’t create a separate postmaster process and
don’t use psql at all. Instead, you start up postgres from the
command line and directly interact with it.

and after starting postgres in ddd, a backend interactive interface works
as doc's Figure 5, and I found version 7.2.2's source postgres'c has
backend interactive interface, but my version is 8.4.0, which seemly has
not backend interactive interface, so I want to ask

(1) whether I must use another method to debug relative external sort code
(in tuplesort.c ), as some post said that I can execute "psql, select select
pg_backend_pid(), and gdb pid" , any advice will be appreciated!

BEST REGARDS
Dillon Peng

On Fri, Jul 11, 2014 at 10:50 AM, 土卜皿 <pengcz(dot)nwpu(at)gmail(dot)com> wrote:
> NOTE: fedora 17 x86_64, 7.2.2 can not be compiled in the env, I choose 8.4.0
> because I think old version is easier to understand than newer version!
Are you aware that Postgres 7.2 has been released in 2002? It is EOL
(end-of-life) since 2005 by looking at the release notes.

> I want to study pg's external sort (in tuplesort.c )through 8.4.0's source
> code, and use ddd to do it, according to usingddd-postgres 's description:
If you are planning to do some development in the future with or for
Postgres, you would get a better insight by looking at more recent
code. Here are some guidelines for example to use git, which is really
helpful as a base infrastructure when studying the code:
https://wiki.postgresql.org/wiki/Working_with_GIT

Hope this helps.
Regards,
--
Michael

hi,
thanks a lot!

2014-07-11 10:10 GMT+08:00 Michael Paquier <michael(dot)paquier(at)gmail(dot)com>:

> On Fri, Jul 11, 2014 at 10:50 AM, 土卜皿 <pengcz(dot)nwpu(at)gmail(dot)com> wrote:
> > NOTE: fedora 17 x86_64, 7.2.2 can not be compiled in the env, I choose
> 8.4.0
> > because I think old version is easier to understand than newer version!
> Are you aware that Postgres 7.2 has been released in 2002? It is EOL
> (end-of-life) since 2005 by looking at the release notes.
>
I know the released time.

>
> > I want to study pg's external sort (in tuplesort.c )through 8.4.0's
> source
> > code, and use ddd to do it, according to usingddd-postgres 's
> description:
> If you are planning to do some development in the future with or for
> Postgres, you would get a better insight by looking at more recent
> code. Here are some guidelines for example to use git, which is really
> helpful as a base infrastructure when studying the code:
> https://wiki.postgresql.org/wiki/Working_with_GIT
>
> seemly the wiki you said has no information about debug

I am sorry, maybe I should make my question clearer, I only want to know,
in 8.4.0 or newer version,
whether I can debug posgres in the bare backend mode (in usingddd-postgres
<http://www-inst.eecs.berkeley.edu/~cs186/fa04/usingddd.pdf>, he said that "
There are two ways to debug postgres (a) in the interactive mode and (b) in
the bare backend mode"
), if yes, what should I do? thanks in advance!

BEST REGARDS
Dillon

=?UTF-8?B?5Zyf5Y2c55q/?= <pengcz(dot)nwpu(at)gmail(dot)com> writes:
> I am sorry, maybe I should make my question clearer, I only want to know,
> in 8.4.0 or newer version,
> whether I can debug posgres in the bare backend mode (in usingddd-postgres
> <http://www-inst.eecs.berkeley.edu/~cs186/fa04/usingddd.pdf>, he said that "
> There are two ways to debug postgres (a) in the interactive mode and (b) in
> the bare backend mode"

Yeah, that still works as well or poorly as it ever did, though the
startup process is a bit different: you need to say "postgres --single"
to launch a standalone backend.

But really, nobody does it that way anymore. There is no advantage to it,
unless maybe you're trying to debug a startup-time crash. The standalone
backend interface is very unpleasant to use compared to psql: no readline
command editing, no nice formatting of output, no tab completion or help,
etc etc. For debugging of normal query operation it's far better to fire
up a psql session and then gdb the connected backend process.

There's more info here:
https://wiki.postgresql.org/wiki/Developer_FAQ#gdb

and if gdb isn't giving you useful symbolic information, see
the setup tips here:
https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

regards, tom lane

hi, tom
thank you very much! this is what I wanted!

Dillon

2014-07-11 10:59 GMT+08:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> =?UTF-8?B?5Zyf5Y2c55q/?= <pengcz(dot)nwpu(at)gmail(dot)com> writes:
> > I am sorry, maybe I should make my question clearer, I only want to know,
> > in 8.4.0 or newer version,
> > whether I can debug posgres in the bare backend mode (in
> usingddd-postgres
> > <http://www-inst.eecs.berkeley.edu/~cs186/fa04/usingddd.pdf>, he said
> that "
> > There are two ways to debug postgres (a) in the interactive mode and (b)
> in
> > the bare backend mode"
>
> Yeah, that still works as well or poorly as it ever did, though the
> startup process is a bit different: you need to say "postgres --single"
> to launch a standalone backend.
>
> But really, nobody does it that way anymore. There is no advantage to it,
> unless maybe you're trying to debug a startup-time crash. The standalone
> backend interface is very unpleasant to use compared to psql: no readline
> command editing, no nice formatting of output, no tab completion or help,
> etc etc. For debugging of normal query operation it's far better to fire
> up a psql session and then gdb the connected backend process.
>
> There's more info here:
> https://wiki.postgresql.org/wiki/Developer_FAQ#gdb
>
> and if gdb isn't giving you useful symbolic information, see
> the setup tips here:
>
> https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD
>
> regards, tom lane
>