This patch no longer applies cleanly. The call is now:
freeaddrinfo_all(hint.ai_family, addrs);
Would you please submit a new patch, or is it no longer required? There
were two fixed in your patch.
Thanks.
--
On Sat, 26 Jul 2003 21:08:46 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> said something like:
>
> I am seeing repeatable success from a CVS of 2003-05-01, and
> repeatable failure from current CVS.
>
> I have only been running nightly paralell regression runs since June
> 27, so it is possible
On Sat, 26 Jul 2003 20:24:56 -0400
Tom Lane <[EMAIL PROTECTED]> said something like:
>
> What time of day did your successive pulls correspond to, anyway?
> (I believe my cvs2cl printout above is showing me EST.)
>
> regards, tom lane
>
>
I'm MST, and I did not specify a
I am seeing repeatable success from a CVS of 2003-05-01, and repeatable
failure from current CVS.
I have only been running nightly paralell regression runs since June 27,
so it is possible that the paralell regression was broken in February,
fixed in May, then broken some time after that.
I will
Tom Lane wrote:
> Robert Creager <[EMAIL PROTECTED]> writes:
> > 2003-02-15 passes 50/50 and 33/33 on second pass (so far)
> > 2003-02-16 fails 6/50
>
> I looked in the CVS logs while waiting for a compile, and the only patch
> I see that goes anywhere near the locking or cache code around that ti
Robert Creager <[EMAIL PROTECTED]> writes:
> 2003-02-15 passes 50/50 and 33/33 on second pass (so far)
> 2003-02-16 fails 6/50
I looked in the CVS logs while waiting for a compile, and the only patch
I see that goes anywhere near the locking or cache code around that time
is this one:
2003-02-17
Robert Creager <[EMAIL PROTECTED]> writes:
> Looks like something was done after the 15'th...
> 2003-02-15 passes 50/50 and 33/33 on second pass (so far)
> 2003-02-16 fails 6/50
As far back as that! Okay, many thanks for the info --- that will help.
I'm buried in error message editing right now
I found it (I think)...
Looks like something was done after the 15'th...
2003-02-15 passes 50/50 and 33/33 on second pass (so far)
2003-02-16 fails 6/50
vacuum failed 1 times
misc failed 3 times
sanity_check failed 3 times
inherit failed 1 times
triggers failed 4 times
2003-02-18
Hi all,
since long time ( in the mean time I did Postgres upgrade four time and
now I'm using 7.3.3 ) I'm having, at least once in a week, a signal 11 on
a backend, and how you can immagine with the subseguent drop of all
connections, finally now I have the core.
The process killed made always the
On Sat, 26 Jul 2003 16:49:27 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> said something like:
> [ cc to hackers]
>
> It certainly looks closer, particularly because the failure is s
> simple domain constraint failure and not a more internal error.
>
> Have you tried moving ahead a few days to
On Sat, 26 Jul 2003 16:40:27 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> said something like:
>
> That is a very good guess. All the errors seem related to the parser.
>
Everyone gets lucky now and then ;-)
I'm now using bison 1.5
2003-01-22 did not fail in 50 tests.
2003-01-26 has not fail
[ cc to hackers]
It certainly looks closer, particularly because the failure is s simple
domain constraint failure and not a more internal error.
Have you tried moving ahead a few days to see if the bug was fixed in
CVS?
---
That is a very good guess. All the errors seem related to the parser.
---
Robert Creager wrote:
-- Start of PGP signed section.
>
> Could the failures have something to do with bison level? 2003-02-01
> would not compile
On Sat, Jul 26, 2003 at 10:59:49AM -0700, Jenny - wrote:
> The following lines are from readme file present in the
> \src\backend\storage\lmgr folder of postgresql
>
> "If we are setting a table level lock
> Both the blockId and tupleId (in an item pointer this is called
> the position) are set t
HI,
To identify the object locked , do we have to use the LockTag field of Lock
struct or can only
lock->tag.relId, lock->tag.dbId, lock->tag.objId.blkno can be used?
thanks
Jenny
_
STOP MORE SPAM with the new MSN 8 and get 2 months
The following lines are from readme file present in the
\src\backend\storage\lmgr folder of postgresql
"If we are setting a table level lock
Both the blockId and tupleId (in an item pointer this is called
the position) are set to invalid, if it is a page level lock the
blockId is valid, while the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think you need a dual cpu machine to see the failures.
>
> I was wondering about that myself, but we shouldn't fixate on that
> assumption without more evidence. There could be some other factor
> explaining why I can't reproduce i
On Sat, 26 Jul 2003 11:22:21 -0400
Tom Lane <[EMAIL PROTECTED]> said something like:
> Robert Creager <[EMAIL PROTECTED]> writes:
> > Just to make sure I've got this right:
>
> > cvs update -D -mm-dd
> > make maintainer-clean
> > ./configure
> > make
> > test
>
> I'd do the "make maintainer
./configure --with-pgport=5433 --prefix=/usr/local/pgsql_cvs
The failure moves around (out of 25 tests):
constraints failed 1 times
cluster failed 1 times
foreign_key failed 1 times
misc failed 6 times
sanity_check failed 3 times
inherit failed 2 times
triggers failed 4 times
Have not tried ins
Excellent idea. Patch attached and applied.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I had a little problem apply this patch because it had an #ifdef for
> > elog() parameter passing. Because ere
Robert Creager <[EMAIL PROTECTED]> writes:
> Just to make sure I've got this right:
> cvs update -D -mm-dd
> make maintainer-clean
> ./configure
> make
> test
I'd do the "make maintainer-clean" before cvs update'ing, but otherwise
probably right. Watch the output the first couple times and m
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think you need a dual cpu machine to see the failures.
>
> I was wondering about that myself, but we shouldn't fixate on that
> assumption without more evidence. There could be some other factor
> explaining why I can't reproduce i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I had a little problem apply this patch because it had an #ifdef for
> elog() parameter passing. Because ereport() is now a macro, you can't
> do #ifdef inside a macro _call_, so I did it this way:
I don't think a non-SSL-enabled build need be pointing
Robert Creager wrote:
-- Start of PGP signed section.
> On Sat, 26 Jul 2003 10:47:12 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> said something like:
>
> >
> > If you would like to do the cvs -d testing yourself instead of me, let
> > me know. It will take me a few hours to get to it anyway.
Yep, I think that is it, though the last one is pgtest or whatever you
are using for testing.
---
Robert Creager wrote:
-- Start of PGP signed section.
> On Sat, 26 Jul 2003 10:47:12 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTE
Robert Creager wrote:
-- Start of PGP signed section.
> On Sat, 26 Jul 2003 10:47:12 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> said something like:
>
> >
> > If you would like to do the cvs -d testing yourself instead of me, let
> > me know. It will take me a few hours to get to it anyway.
On Sat, 26 Jul 2003 10:47:12 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> said something like:
>
> If you would like to do the cvs -d testing yourself instead of me, let
> me know. It will take me a few hours to get to it anyway.
>
Just to make sure I've got this right:
cvs update -D -mm
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think you need a dual cpu machine to see the failures.
I was wondering about that myself, but we shouldn't fixate on that
assumption without more evidence. There could be some other factor
explaining why I can't reproduce it. A couple of questions fo
There was a recent question on pgsql-sql (not visible in the archives
yet, but look for title "Very strange 'now' behaviour" of today's date)
about misbehavior of a 'now' default for a timestamp column. This makes
me wonder whether the following bit of hackery in catalog/heap.c is
really as good a
On Sat, 26 Jul 2003 10:47:12 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> said something like:
>
> If you would like to do the cvs -d testing yourself instead of me, let
> me know. It will take me a few hours to get to it anyway.
>
I will start doing pulling down old versions (once I figure o
If you would like to do the cvs -d testing yourself instead of me, let
me know. It will take me a few hours to get to it anyway.
---
Robert Creager wrote:
-- Start of PGP signed section.
>
> On Sat, 26 Jul 2003 01:00:46 -0
I am going to use cvs -d to pull an older CVS and see if that fails, so
we can track down the date it started failing.
---
Robert Creager wrote:
-- Start of PGP signed section.
>
> On Sat, 26 Jul 2003 01:00:46 -0400
> Tom L
On Sat, 26 Jul 2003 01:00:46 -0400
Tom Lane <[EMAIL PROTECTED]> said something like:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I run it every night and it fails 25% of the time.
>
> When did you start seeing the problem?
>
> I just wasted an hour running eighty-some iterations of "make ch
Let me get the patch queue applied, then use CVS to backtrack and find
the date it started failing. I think you need a dual cpu machine to see
the failures.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
I had a little problem apply this patch because it had an #ifdef for
elog() parameter passing. Because ereport() is now a macro, you can't
do #ifdef inside a macro _call_, so I did it this way:
#ifdef USE_SSL
#define EREPORT_SSL_STATUS (port->ssl ? "on" : "off")
#else
#define EREPORT_SSL_STATU
35 matches
Mail list logo
