Oliver Elphick <[EMAIL PROTECTED]> writes:
> - strerror_r(errnum, strerrbuf, buflen);
> + char buf[256];
> + StrNCpy(strerrbuf, strerror_r(errnum, buf, 256), buflen);
> return strerrbuf;
Easier and safer would be
> - strerror_r(errnum, strerrbuf, buflen);
> -
On Tue, 2004-06-01 at 01:33, Tom Lane wrote:
> First you might want to check which flavor of strerror_r() your platform
> has --- does it return int or char* ?
I made the following change to the strerror_r call, which makes it work
correctly with threading enabled:
--- src/port/thread.c 23 Ap
On Tue, 2004-06-01 at 01:33, Tom Lane wrote:
> First you might want to check which flavor of strerror_r() your platform
> has --- does it return int or char* ? The Linux man page for
> strerror_r() says
>From the definition in /usr/include/string.h, glibc 2.3.2 still has the
version that returns
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> The code we have appears to assume that the result will always be placed
>> in the user-supplied buffer, which is apparently NOT what the glibc
>> version does.
> What does "may, but need not, use the user-supplied buffer" supposed to
> mean in practica
Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
> >> I can't duplicate that here. It looks to me like the probable
> >> explanation is a broken or incompatible version of strerror_r() on your
> >> machine. Does the failure go away if y
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
>> I can't duplicate that here. It looks to me like the probable
>> explanation is a broken or incompatible version of strerror_r() on your
>> machine. Does the failure go away if you build without thread-sa
On Mon, 2004-05-31 at 19:55, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > 1. There are regression failures on timestamptz and horology which seem
> > to have come about either on input or output of timestamps with
> > fractional seconds.
>
> I believe I've fixed this.
All reg
Oliver Elphick <[EMAIL PROTECTED]> writes:
> 1. There are regression failures on timestamptz and horology which seem
> to have come about either on input or output of timestamps with
> fractional seconds.
I believe I've fixed this.
> 2. If the postmaster is not running, there is garbage in psql
Oliver Elphick <[EMAIL PROTECTED]> writes:
> 1. There are regression failures on timestamptz and horology which seem
> to have come about either on input or output of timestamps with
> fractional seconds.
Hmm ... I'm seeing slightly different misbehaviors in the
integer-datetimes and float-dateti
CVS tip built on Debian unstable, i386, Linux 2.6.5 SMP.
gcc 3.3.3
./configure --with-openssl --with-pam --with-krb5 --with-gnu-ld
--with-python --with-perl --with-tcl --with-pgport=5342
--enable-thread-safety --enable-nls --enable-integer-datetimes
--enable-debug --enable-cassert --enable-depen
On Mon, 1 Oct 2001, Bruce Momjian wrote:
> > > > I would propose that the reference machine be one that one of the
> > > > "committers" owns, and be one whose owner is willing to *always* go
> > > > through the effort to resolve regression test changes and differences.
> > > Er ... wasn't that *y
>> ERROR: operator class "timestamp_ops" does not accept data type
>> timestamp with time zone
> Oh, ye olde change-of-opclass-name problem. I've stuck a hack into
> gram.y as we've done in the past, but I'm starting to think that we
> need a better answer going forward. Maybe pg_dump could be
On Monday 01 October 2001 05:07 pm, Bruce Momjian wrote:
> I think we are all just scrambing to get beta ready while the server
> reconfigures itself. :-) I don't see any fundamental changes being
> proposed. We are trying to plug leaks and are stepping on toes, or at
> least it looks that way
> > > I would propose that the reference machine be one that one of the
> > > "committers" owns, and be one whose owner is willing to *always* go
> > > through the effort to resolve regression test changes and differences.
> > Er ... wasn't that *you*?
>
> Yes. At the moment my toes are bright re
> > I would propose that the reference machine be one that one of the
> > "committers" owns, and be one whose owner is willing to *always* go
> > through the effort to resolve regression test changes and differences.
> Er ... wasn't that *you*?
Yes. At the moment my toes are bright red and sore f
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I would propose that the reference machine be one that one of the
> "committers" owns, and be one whose owner is willing to *always* go
> through the effort to resolve regression test changes and differences.
Er ... wasn't that *you*?
> > - First one is that the regression fails on "geometry" on what appears to be
> > a difference in the 13th decimal place of the output value. See the attached
> > regression diff.
> Looks like it was not you that changed, but Thomas' reference machine.
> What platform are you on, anyway?
fwiw,
> > - First one is that the regression fails on "geometry" on what appears
to be
> > a difference in the 13th decimal place of the output value. See the
attached
> > regression diff.
>
> Looks like it was not you that changed, but Thomas' reference machine.
> What platform are you on, anyway?
>
No
"Joe Conway" <[EMAIL PROTECTED]> writes:
> I just grabbed cvs tip this afternoon and ran into two issues:
> - First one is that the regression fails on "geometry" on what appears to be
> a difference in the 13th decimal place of the output value. See the attached
> regression diff.
Looks like it
I just grabbed cvs tip this afternoon and ran into two issues:
- First one is that the regression fails on "geometry" on what appears to be
a difference in the 13th decimal place of the output value. See the attached
regression diff.
- Second was on reloading my data, I got the following error me
20 matches
Mail list logo
