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

Re: [HACKERS] Question on win32 semaphore simulation

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>, Peter(dot)Brant(at)wicourts(dot)gov
Subject: Re: [HACKERS] Question on win32 semaphore simulation
Date: 2006-05-08 02:39:52
Message-ID: 200605080239.k482dqq26081@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > While we have installed a Win32-specific semaphore implementation for
> > CVS HEAD, what do we want do apply for the back branches, 8.0.X and
> > 8.1.X.  Is this the patch that should be applied?
> 
> Leave 'em alone.  That code has zero field validation, and should
> certainly not get shipped until it's survived a beta-test cycle.

Uh, this is a bug fix, and the patch I am asking about is not the Win32
semaphore reimplementation but a more limited fix.  Here is the problem
report:

	http://archives.postgresql.org/pgsql-bugs/2006-04/msg00101.php

The test request:

	http://archives.postgresql.org/pgsql-bugs/2006-04/msg00251.php

and the successful test run:

	http://archives.postgresql.org/pgsql-bugs/2006-05/msg00002.php

We don't require bug fixes to go through beta testing.

-- 
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

Responses

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-05-08 14:13:45
Subject: Re: [PATCH] Magic block for modules
Previous:From: Tom LaneDate: 2006-05-08 00:21:43
Subject: Re: [PATCH] Magic block for modules

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2006-05-08 02:54:27
Subject: [WIP] The relminxid addition, try 3
Previous:From: Bruce MomjianDate: 2006-05-08 02:20:17
Subject: Re: pgstat: remove delayed destroy / pipe:

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