Re: Question about debugging bootstrapping and catalog entries

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question about debugging bootstrapping and catalog entries
Date: 2006-12-21 06:12:09
Message-ID: 14308.1166681529@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com> writes:
> On 12/18/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> There is already an option to sleep early in backend startup for the
>> normal case. Not sure if it works for bootstrap, autovacuum, etc,
>> but I could see making it do so.

> You are probably referring to the command-line switch -W to posrgres, that
> translates to 'PostAuthDelay' GUC variable; I think that kicks in a bit too
> late!

No, I was thinking of PreAuthDelay. There might be cases where even
that is too late in the procedure --- probably not on Unix, but on
Windows there's a lot that happens before BackendInitialize. But
offhand I don't know how we'd have a configurable delay much earlier
... custom insertions of hardwired delays into the source code are
probably the only good approach if you find that, say, guc.c
initialization fails in individual backends under Windows.

Back at the ranch, though, the question was whether it'd be worth
honoring PreAuthDelay in the other startup code paths such as
BootstrapMain.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-12-21 06:33:40 Re: ERROR: tuple concurrently updated
Previous Message Tom Lane 2006-12-21 05:59:22 Re: Stats Collector Oddity