> > For #2, yes, the semaphores will go away when the last
> process holding
> > a HANDLE to it goes away. For #1, the code seems to handle
> that right?
> >
>
> I intentionally use *unnamed* semaphores to avoid these
> problems -- even if the semaphores didn't go away (as Magus
> pointed out
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> Note I am not saying there's anything wrong with the code you posted;
> based on discussion to date it seems to be solid. What I am taking
> issue with is the attitude you seem to have that it's not our problem
> if we leak resources. It is our problem.
>
""Magnus Hagander"" <[EMAIL PROTECTED]> wrote
>
> Just a point - they will get automatically cleaned up even if the
> process doesn't exit *gracefully*, as long as it exits. Only if it's
> hung and won't actually exit will the handles not get cleaned up.
> This goes for both named and unnamed ones
> > I intentionally use *unnamed* semaphores to avoid these problems --
> > even if the semaphores didn't go away (as Magus pointed out, if all
> > processes can exit gracefully, this won't happen), we won't worry
> > about them -- Creating semahpores will still succeed
> because there is
> >
Comment added and patch applied. Thanks.
---
Jeremy Drake wrote:
> If configure sees that the compiler specified by $CC looks like gcc
> (defines __GNUC__), then it puts some extra command line options into the
> CFLAGS (m
Tom Lane wrote:
> BERTHOULE Emmanuel <[EMAIL PROTECTED]> writes:
> > with this patch, you can now restore default value with SIGHUP when
> > commenting an variable in postgresql.conf
>
> This seems pretty poorly thought out, in particular making PGC_S_SIGHUP
> >= PGC_S_OVERRIDE seems to me likely
Albe Laurenz wrote:
> > This patch for libpq allows you to enter an LDAP URL in
> pg_service.conf.
> > The URL will be queried and the resulting string(s) parsed for
> > keyword = value connection options.
> >
> > The idea is to have connection information stored centrally on an LDAP
> > server ra
Should also warn anyone who tries this that the regression tests for
float4 and float8 fail under normal optimization flags. I managed to
track it down, and apparently some floating point optimizations (seemingly
relating to SSE) cause comparisons involving NaN to give non-standard
results. This
On Fri, 2006-04-21 at 19:56 -0400, Bruce Momjian wrote:
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.
This patch shou
This seems like a compiler bug so I am hoping it will be fixed, or is
already fixed in a later release. In fact, I know some users are using
the Intel compiler, and we are not hearing reports of regression
failures, so I am hoping the release with this bug is not widely used.
---
Bruce Momjian writes:
> This seems like a compiler bug so I am hoping it will be fixed, or is
> already fixed in a later release.
Yeah. NaN == 0 is just silly ...
regards, tom lane
---(end of broadcast)---
TIP 1: if postin
On Fri, 21 Apr 2006, Tom Lane wrote:
> Bruce Momjian writes:
> > This seems like a compiler bug so I am hoping it will be fixed, or is
> > already fixed in a later release.
>
> Yeah. NaN == 0 is just silly ...
>From what I can tell from the instruction set docs and test programs, the
actual bug
Where are we on this patch?
---
Simon Riggs wrote:
> On Tue, 2006-03-21 at 17:47 -0500, Tom Lane wrote:
>
> > I'm fairly unconvinced about Simon's underlying premise --- that we
> > can't make good use of work_mem in sortin
13 matches
Mail list logo
