On Thu, Apr 26, 2007 at 10:29:47AM -0700, Mark Wong wrote:
> I applied it to REL8_2_STABLE/pgsql and ran 'run_build.pl --test
> --keepall REL8_2_STABLE'. Looks like it passed everything for me. :)
Thanks for this test. I just committed the changes to CVS.
Michael
--
Michael Meskes
Email: Michae
On Thu, Apr 26, 2007 at 01:35:42PM -0400, Tom Lane wrote:
> AFAICS you do not need to inline create_statement. The risk factor
> is where you call a routine that does something with a va_list, and
> then you want to do something else (other than va_end) with that va_list
> after it returns. The o
Michael Meskes <[EMAIL PROTECTED]> writes:
> Having spend countless hours debugging this stuff I fully agree with
> you. It's not just ECPGget_variable though. I also had to inline
> create_statement.
AFAICS you do not need to inline create_statement. The risk factor
is where you call a routine t
On 4/26/07, Michael Meskes <[EMAIL PROTECTED]> wrote:
On Wed, Apr 25, 2007 at 04:38:30PM -0400, Tom Lane wrote:
> My recommendation is to get rid of the APREF hack, deal only in
> va_list not &va_list, and inline ECPGget_variable into the two
> places it's used to avoid the question of passing va
On Thu, Apr 26, 2007 at 06:28:29AM -0500, Andrew Dunstan wrote:
> If you commit to HEAD it will be automatically tested on the buildfarm.
True. But it might also break a lot of other archs without helping on
those troubled ones. I thought this way would be better.
Michael
--
Michael Meskes
Email
Michael Meskes wrote:
>
> Attached you'll find a patch that should inline both functions and
> remove the APREF stuff. This successfully runs the regression suite on
> my Linux box. Please test it on those archs that needed special
> treatment before I commit.
>
If you commit to HEAD it will be au
ARGH!
This time with patch.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
diff -ruN --exclude CVS /home/po
On Wed, Apr 25, 2007 at 04:38:30PM -0400, Tom Lane wrote:
> My recommendation is to get rid of the APREF hack, deal only in
> va_list not &va_list, and inline ECPGget_variable into the two
> places it's used to avoid the question of passing va_lists around
> after they've been modified. The routin
On Wed, Apr 25, 2007 at 03:17:19PM -0400, Tom Lane wrote:
> Why in the world is that like that? We don't have such a kluge
> anyplace else we use va_list. stringinfo.c for instance has
> never needed any such thing.
I don't remember the exact details but this was added a long time ago
before 8.0
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> But I also see that my amd64/FC6 machine does pass these tests with gcc.
Yeah, but the typedef represented by va_list can and probably does vary
between amd64 and ppc64. I haven't an easy way to check, but I wonder
whether it's not an array type on ppc
Tom Lane wrote:
Hmm, and I don't have to look far to find a smoking gun:
#if defined(__GNUC__) && (defined (__powerpc__) || defined(__amd64__) ||
defined(__x86_64__))
if (create_statement(lineno, compat, force_indicator, con, &stmt,
query, args) == false)
#else
if (create_stat
On 4/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Mark Wong" <[EMAIL PROTECTED]> writes:
> Does this help?
> (gdb) p var->ind_pointer
> $8 = (void *) 0x0
Well, that seems to be the reason why it's failing to indirect through
ind_pointer ... but why is it only failing on your machine and not
ever
"Mark Wong" <[EMAIL PROTECTED]> writes:
> Does this help?
> (gdb) p var->ind_pointer
> $8 = (void *) 0x0
Well, that seems to be the reason why it's failing to indirect through
ind_pointer ... but why is it only failing on your machine and not
everyone else's? I think this indicates something unp
On 4/25/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think you'll need to compile with optimisation turned off and then try
> running the test under debugger control, putting a breakpoint in
> ECPGget_variable() and then stepping through it. I wonder what
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I think you'll need to compile with optimisation turned off and then try
> running the test under debugger control, putting a breakpoint in
> ECPGget_variable() and then stepping through it. I wonder what value of
> var->ind_pointer it is getting?
Yo
Mark Wong wrote:
On 4/25/07, Michael Meskes <[EMAIL PROTECTED]> wrote:
I also saw that wombat is segfaulting in ecpg tests but not only with
CVS HEAD but also trying to test 8.2. Any idea what's going on with this
machine?
I generated a stack trace for REL8_2_STABLE, but I'm not sure how
helpf
On 4/25/07, Michael Meskes <[EMAIL PROTECTED]> wrote:
I also saw that wombat is segfaulting in ecpg tests but not only with
CVS HEAD but also trying to test 8.2. Any idea what's going on with this
machine?
I generated a stack trace for REL8_2_STABLE, but I'm not sure how
helpful it is. Let me
Dave Page wrote:
Andrew Dunstan wrote:
Please don't do that on your buildfarm repo copy (if that's what you
did). You should not touch *anything* inside it. If need to you do this,
make a copy (see later) and alter that.
If you did do this to the buildfarm repo copy, please blow it away so
t
Andrew Dunstan wrote:
> Please don't do that on your buildfarm repo copy (if that's what you
> did). You should not touch *anything* inside it. If need to you do this,
> make a copy (see later) and alter that.
>
> If you did do this to the buildfarm repo copy, please blow it away so
> that buildfa
Dave Page wrote:
Michael Meskes wrote:
On Wed, Apr 25, 2007 at 10:47:57AM +0100, Dave Page wrote:
I'm seeing an ECPG-Check failure on Windows Vista - any ideas what might
be causing this?
Hmm, first glance suggests some permission problems.
Yes, that was my thought as wel
Michael Meskes wrote:
> On Wed, Apr 25, 2007 at 10:47:57AM +0100, Dave Page wrote:
>> I'm seeing an ECPG-Check failure on Windows Vista - any ideas what might
>> be causing this?
>
> Hmm, first glance suggests some permission problems.
Yes, that was my thought as well, however I ran cacls down t
On Wed, Apr 25, 2007 at 10:47:57AM +0100, Dave Page wrote:
> I'm seeing an ECPG-Check failure on Windows Vista - any ideas what might
> be causing this?
Hmm, first glance suggests some permission problems.
I never touched a Vista system so far, so I'm at a loss as far as
details are concerned.
I'm seeing an ECPG-Check failure on Windows Vista - any ideas what might
be causing this?
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=vaquita&dt=2007-04-24%2020:00:05
The only other Vista buildfarm member (baiji, on the same physical box)
is running MSVC builds which don't yet test ECPG fro
23 matches
Mail list logo