From: Tom Lane <tgl@sss.pgh.pa.us>
To: mahendrakar s <mahendrakarforpg@gmail.com>
cc: pgsql-novice <pgsql-novice@lists.postgresql.org>
Subject: Re: debugging libpq backend code
In-reply-to: 
 <CABkiuWrTvNTega8aCb3Dak0wbTTySb_SQ=xTvdwwoO2Gu0qXyg@mail.gmail.com>
References: 
 <CABkiuWrTvNTega8aCb3Dak0wbTTySb_SQ=xTvdwwoO2Gu0qXyg@mail.gmail.com>
Comments: In-reply-to mahendrakar s <mahendrakarforpg@gmail.com>
	message dated "Sat, 05 Nov 2022 23:40:38 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2732737.1667677179.1@sss.pgh.pa.us>
Date: Sat, 05 Nov 2022 15:39:39 -0400
Message-ID: <2732738.1667677179@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2732738.1667677179%40sss.pgh.pa.us>
Precedence: bulk

mahendrakar s <mahendrakarforpg@gmail.com> writes:
> I'm trying to debug libpq backend code (files: auth.c, auth-sasl.c in
> directory src/backend/libpq).
> I followed: Developer FAQ - PostgreSQL wiki and attached postgres
> process ( because connection is still in progress and I don't see
> backend process yet when I try to connect through psql). I could set
> the break-points but these are not hit while it must. I think I should
> not be attaching postmaster parent process instead attach the backend
> process but how?

The traditional answer is to set pre_auth_delay high enough to give
yourself time to identify the new backend process (via "ps") and
attach to it in gdb.

You might also be able to attach to the postmaster in gdb and
persuade it to follow the fork(), but I'm not very sure about
the details of making that work while not complicating your
life with a bunch of other postmaster children.

			regards, tom lane