Kris Jurka wrote:
> Bruce Momjian wrote:
> > Great, changes attached and applied. I removed the solaris_i386 and
> > solaris_x86_64.s files and made just one solaris_x86.s. I updated the
> > build system to use the new file, updated the macros, and added some
> > documentation on the approach. T
Bruce Momjian wrote:
Great, changes attached and applied. I removed the solaris_i386 and
solaris_x86_64.s files and made just one solaris_x86.s. I updated the
build system to use the new file, updated the macros, and added some
documentation on the approach. Thanks.
Would you test current CVS
Tom Lane wrote:
> Bruce Momjian writes:
>
> > ! extern volatile slock_t pg_atomic_cas(volatile slock_t *lock, slock_t
> > with,
> > !
> > slock_t cmp);
>
> Surely it is not useful to mark the result of a function as volatile
Bruce Momjian writes:
> The problem is that the call to thread.c::pqGetpwuid() happens in a
> #ifndef WIN32 block, so the function is not seen by Win32, so we don't
> get a compile error.
> I am thinking your patch is a good idea because it will give us a
> non-Win32 platform that has the _check_
Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking your patch is a good idea because it will give us a
> > non-Win32 platform that has the _check_ behavior. We do have to bump
> > the major for ecpg libs for this, but not libpq.
>
> No, because if 8.2 ships with a libpq.so.4 that doesn't
Bruce Momjian writes:
> I am thinking your patch is a good idea because it will give us a
> non-Win32 platform that has the _check_ behavior. We do have to bump
> the major for ecpg libs for this, but not libpq.
No, because if 8.2 ships with a libpq.so.4 that doesn't expose
pqGetpwuid, it will
We have two approaches for dealing with pgport leakage. For libraries,
we remove libpgport from the link line and recompile our own object
files:
# Need to recompile any libpgport object files
LIBS := $(filter-out -lpgport, $(LIBS))
OBJS= execute.o typename.o descriptor.
Bruce Momjian writes:
> Great, changes attached and applied. I removed the solaris_i386 and
> solaris_x86_64.s files and made just one solaris_x86.s. I updated the
> build system to use the new file, updated the macros, and added some
> documentation on the approach. Thanks.
BTW, on the replac
Bruce Momjian writes:
> ! extern volatile slock_t pg_atomic_cas(volatile slock_t *lock, slock_t with,
> !
> slock_t cmp);
Surely it is not useful to mark the result of a function as volatile.
regard
Great, changes attached and applied. I removed the solaris_i386 and
solaris_x86_64.s files and made just one solaris_x86.s. I updated the
build system to use the new file, updated the macros, and added some
documentation on the approach. Thanks.
Would you test current CVS to make sure it still
Atsushi Ogawa <[EMAIL PROTECTED]> writes:
> The OpernameGetCandidates called from oper. The function of oper is
> search for a binary operator. It does the following processing:
> (1)Create candidates of operator that matches operator name and
> operator kind by OpernameGetCandidates.
> (2)Find an
Hannu Krosing wrote:
> ?hel kenal p?eval, N, 2006-04-27 kell 10:17, kirjutas Bruce Momjian:
> > Sorry, I have to revert this patch because it is causing crashes in the
> > plpython regression tests. Would you please run those tests, fix the
> > bug, and resubmit. Thanks.
>
> Where exactly does i
Zeugswetter Andreas DCP SD wrote:
>
> > > 4. Find the option for disabling strict alias and get configure to
> add
> > > that.
> >
> > You'll still lose performance, but the option is "-qalias=noansi".
>
> My old xlc does not show that option, it is unfortunately version
> specific.
> The curren
Ühel kenal päeval, N, 2006-04-27 kell 10:17, kirjutas Bruce Momjian:
> Sorry, I have to revert this patch because it is causing crashes in the
> plpython regression tests. Would you please run those tests, fix the
> bug, and resubmit. Thanks.
Where exactly does it crash ?
Please tell us the ver
Patch reverted, and authors asked to retest and resubmit. Thanks for
the report.
---
Kris Jurka wrote:
> Bruce Momjian wrote:
> > Log Message:
> > ---
> > plpython improvements:
> >
>
> These don't seem to work:
>
Sorry, I have to revert this patch because it is causing crashes in the
plpython regression tests. Would you please run those tests, fix the
bug, and resubmit. Thanks.
---
pgman wrote:
>
> Patch applied. Thanks.
>
> ---
I am now wondering if fe-secure.c, the front-end code, should also check
for "root.crl". The attached patch implents it. Is it a good idea?
Also, if you look in interfaces/libpq/fe-secure.c at some NOT_USED
macros you can see there are a few things we don't implement. Can that
be improved?
--
Here is a gprof result of the pgbench.
% cumulative self selftotal
time seconds secondscalls s/call s/call name
4.77 4.04 4.04140000.000.00 OpernameGetCandidates
4.70 8.02 3.98 20070080.000.00
HeapTupleSatisfiesSnapshot
> > > Magnus Hagander wrote:
> > >> Per some earlier discussion, here is an attempt at
> implementing a
> > >> "delayed write" of the pgstats file, to decrease the
> write activity
> > >> on that file.
> >
> > This was not ready to be applied, was it? "An attempt"
> doesn't sound
> > to me
19 matches
Mail list logo
