Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

			regards, tom lane

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group