Обсуждение: 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 '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.nwpu@gmail.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.paquier@gmail.com>:
On Fri, Jul 11, 2014 at 10:50 AM, 土卜皿 <pengcz.nwpu@gmail.com> wrote:Are you aware that Postgres 7.2 has been released in 2002? It is EOL
> 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!
(end-of-life) since 2005 by looking at the release notes.
I know the released time.
If you are planning to do some development in the future with or for
> 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:
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, 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
土卜皿 <pengcz.nwpu@gmail.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@sss.pgh.pa.us>:
土卜皿 <pengcz.nwpu@gmail.com> writes:> <http://www-inst.eecs.berkeley.edu/~cs186/fa04/usingddd.pdf>, he said that "
> 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> There are two ways to debug postgres (a) in the interactive mode and (b) inYeah, that still works as well or poorly as it ever did, though the
> the bare backend mode"
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