On August 29, 2002 03:37 pm, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > One thing I do see though is that there is a completion issue.
>
> Well, (a) the shell type can't be used for anything till you turn it
> into a real type, and (b) the completion issue already exists,
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> One thing I do see though is that there is a completion issue.
Well, (a) the shell type can't be used for anything till you turn it
into a real type, and (b) the completion issue already exists, and has
for a long time; you've always been able to c
On August 29, 2002 09:45 am, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > YES! Well, sort of. I didn't have any other operators but while I
> > thought that both were the same (after all, I contributed it) someone
> > must have fixed the one in CVS before adding it. The
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> YES! Well, sort of. I didn't have any other operators but while I thought
> that both were the same (after all, I contributed it) someone must have fixed
> the one in CVS before adding it. The one I was working with had the
> operators working
On August 28, 2002 11:07 pm, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > Hmm. I did give it a harder look and look what jumped out. Both
> > chkpass_out and chkpass_rout return PG_RETURN_CSTRING but chkpass_out
> > builds a standard c string while chkpass_rout builds a v
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> Hmm. I did give it a harder look and look what jumped out. Both
> chkpass_out and chkpass_rout return PG_RETURN_CSTRING but chkpass_out
> builds a standard c string while chkpass_rout builds a variable text
> structure. That can't be right.
It's
On August 28, 2002 09:23 am, Tom Lane wrote:
> The behavior looks a lot like a memory clobber, so perhaps the key
> variable is some difference in malloc's allocation strategy, causing
> two items to be adjacent in NetBSD where they are not on the other
> platforms we've tried.
Here's some other
On August 28, 2002 02:07 pm, D'Arcy J.M. Cain wrote:
> I had also tried changing palloc.h and mcxt.c to turn MemoryContextAlloc()
> into a macro that called a modified version of the real one to try to
> narrow down where it was being called from but that wouldn't even run. Is
> there another fil
On August 28, 2002 12:48 pm, D'Arcy J.M. Cain wrote:
> On August 28, 2002 09:23 am, Tom Lane wrote:
> > The behavior looks a lot like a memory clobber, so perhaps the key
> > variable is some difference in malloc's allocation strategy, causing
> > two items to be adjacent in NetBSD where they are
On August 28, 2002 09:23 am, Tom Lane wrote:
> The behavior looks a lot like a memory clobber, so perhaps the key
> variable is some difference in malloc's allocation strategy, causing
> two items to be adjacent in NetBSD where they are not on the other
> platforms we've tried.
Hmm. I might try
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
>> Could you try CVS tip on one of the boxes where you see the failure?
>> That'd help to narrow down the issue.
> Same issue. It must be a NetBSD issue but I can't think what.
The behavior looks a lot like a memory clobber, so perhaps the key
vari
On August 27, 2002 06:20 pm, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > How about that --enable-multibyte?
>
> --enable-multibyte is default (indeed only) option on CVS tip,
> so that's not it. Ditto locale.
>
> Could you try CVS tip on one of the boxes where you see the
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> How about that --enable-multibyte?
--enable-multibyte is default (indeed only) option on CVS tip,
so that's not it. Ditto locale.
Could you try CVS tip on one of the boxes where you see the failure?
That'd help to narrow down the issue.
On August 27, 2002 03:39 pm, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > NetBSD issue? It does it on all the NetBSD systems I tried it on.
>
> Hm. The first thing I thought was "portability problem" --- I had been
> testing on HPUX. But I just tried it on a Linux Intel
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On August 27, 2002 09:13 am, Tom Lane wrote:
>> Zero failures in a dozen iterations here. Anyone else see it?
> NetBSD issue? It does it on all the NetBSD systems I tried it on.
Hm. The first thing I thought was "portability problem" --- I had
On August 27, 2002 09:13 am, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > On August 27, 2002 02:01 am, Tom Lane wrote:
> >> FWIW, I couldn't see any problem in CVS tip. Could you provide an exact
> >> sequence-to-reproduce?
> >
> > Surely. Create a database (chkpass_test)
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> On August 27, 2002 02:01 am, Tom Lane wrote:
>> FWIW, I couldn't see any problem in CVS tip. Could you provide an exact
>> sequence-to-reproduce?
> Surely. Create a database (chkpass_test) and, after loading the chkpass
> type, follow this bounc
On August 27, 2002 02:01 am, Tom Lane wrote:
> "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> > I have been getting the subject message ever since upgrading to 7.2.1. I
> > tried 7.2.2 with the same thing. It seems to be related to my chkpass
> > type (see contrib) as it only happens on tables
"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> I have been getting the subject message ever since upgrading to 7.2.1. I
> tried 7.2.2 with the same thing. It seems to be related to my chkpass type
> (see contrib) as it only happens on tables with that type.
FWIW, I couldn't see any problem
I have been getting the subject message ever since upgrading to 7.2.1. I
tried 7.2.2 with the same thing. It seems to be related to my chkpass type
(see contrib) as it only happens on tables with that type. I tried it on a
new database with a very simple table and still see it. After compil
20 matches
Mail list logo
