Re: [HACKERS] backend freezeing on win32 fixed (I hope ;-) )

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Horak Daniel <horak(at)mmp(dot)plzen-city(dot)cz>
Cc: "'pgsql-hackers(at)postgreSQL(dot)org'" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] backend freezeing on win32 fixed (I hope ;-) )
Date: 1999-08-16 14:50:40
Message-ID: 898.934815040@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Horak Daniel <horak(at)mmp(dot)plzen-city(dot)cz> writes:
>> I do not like this patch one bit --- I think it is voodoo that doesn't
>> really have anything to do with the true problem. I don't know what
>> the true problem is, mind you, but I don't think this is the way to
>> fix it.

> I know it is not a perfect solution but now it is better than nothing.

> Does this mean that when I have one connection to the server, I end it and
> start a new one, this new one will use the same semaphores? But it seems to
> work.

Yes. The way the code used to work (pre 6.5) was that the first backend
to fire up would grab a block of 16 semaphores, which would be used by
backends 2-16; when you started a 17'th concurrent backend another block
of 16 semaphores would be grabbed; etc. The code you diked out simply
forces preallocation of a bunch of semaphores at postmaster start time,
rather than having it done by selected backends. That's why it doesn't
make any sense to me that removing it would fix anything --- you'll
still have backends dependent on semaphores that were created by other
processes, it's just that they were other backends instead of the
postmaster.

In any case, when one backend quits and another one is started, the new
one will re-use the semaphore no longer used by the defunct backend.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-08-16 14:56:51 Re: [HACKERS] Re: [CORE] Re: tomorrow
Previous Message Vince Vielhaber 1999-08-16 14:36:57 Re: [HACKERS] Re: [CORE] Re: tomorrow