The appended patch makes the msvc setting integer_datetimes propagate to
ecpg_config.h as well.
Joachim
Index: src/tools/msvc/Solution.pm
===
RCS file: /projects/cvsroot/pgsql/src/tools/msvc/Solution.pm,v
retrieving revision 1.25
For some reason the cluster test fails on my machine due to a different
order of the result rows when I run installcheck instead of check. Is
there a problem adding an ORDER BY to it?
Joachim
Index: src/test/regress/sql/cluster.sql
Joachim Wieland [EMAIL PROTECTED] writes:
For some reason the cluster test fails on my machine due to a different
order of the result rows when I run installcheck instead of check. Is
there a problem adding an ORDER BY to it?
We should find out why that's happening rather than just throwing an
On Fri, May 25, 2007 at 10:33:41AM -0400, Tom Lane wrote:
We should find out why that's happening rather than just throwing an
ORDER BY at it. Considering the number of buildfarm machines that
aren't showing any such problem, there must be something odd about
yours. What's the platform?
Joachim Wieland wrote:
On Fri, May 25, 2007 at 10:33:41AM -0400, Tom Lane wrote:
We should find out why that's happening rather than just throwing an
ORDER BY at it. Considering the number of buildfarm machines that
aren't showing any such problem, there must be something odd about
Joachim Wieland [EMAIL PROTECTED] writes:
EXPLAIN SELECT conname FROM pg_constraint WHERE conrelid =
'clstr_tst'::regclass;
QUERY PLAN
---
Index Scan
Joachim Wieland [EMAIL PROTECTED] writes:
As said before, it only happens with make installcheck, not make check.
Curious. I'm not sure if the buildfarm tries to isolate the
installation against its locale environment --- can you check the locale
used by the install case?
Tom Lane [EMAIL PROTECTED] writes:
This is in the regression database after a completed regression run, so
it's possible that it's a bit different state from what's seen at the
instant the cluster test was running, but it sure looks like the
expected results are what you get from a seqscan.
I wrote:
Attached is a proposed replacement patch that keeps essentially all the
advisor logic outside the core backend, and uses the method I suggested of
modifying the result of get_relation_info() rather than installing phony
system-catalog entries.
I've applied this with one further
Gregory Stark [EMAIL PROTECTED] writes:
Perhaps this comes down to 64 vs 32 bit datum and aligments and therefore
different size tables which because the planner does the lseek to measure the
table size shows up as different estimates for sequential scan costs?
But we've got plenty of both in
Here's a new version, all known issues are now fixed. I'm now happy with
this patch.
Next, I'll start looking at the latest version of Jeff's synchronized
scans patch.
Bruce Momjian wrote:
Great. Based on this, do you have a patch that is ready to apply.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Here's a new version, all known issues are now fixed. I'm now happy with
this patch.
Next, I'll start looking at the latest version of Jeff's synchronized
scans patch.
I'm a bit confused --- weren't you intending to review these in parallel
On Fri, May 25, 2007 at 12:09:43PM -0400, Tom Lane wrote:
This is in the regression database after a completed regression run, so
it's possible that it's a bit different state from what's seen at the
instant the cluster test was running, but it sure looks like the
expected results are what you
13 matches
Mail list logo
