Zitat von Michael Fuhr [EMAIL PROTECTED]:
This is exactly what I did fix with the work mentioned in the hackers
thread. It should work nicely with CVS HEAD. Could you please try
this?
Try what? I don't see a patch, link, or suggested fix in the
thread -- just your original message and the
Le 29 déc. 04, à 23:38, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
Le 29 d=E9c. 04, =E0 18:05, Tom Lane a =E9crit :
Backtracing the core dump from that crash would do fine.
Here you go
(gdb) bt
#0 0x010a in ?? ()
#1 0x046e9cce in queryin (buf=3DCannot access
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
Hmm. I was hoping to spot some obviously machine-dependent code nearby
to the crash point, but I don't see anything wrong in that area.
You might try rebuilding tsearch with -O0 (if it wasn't already) in
hopes that the backtrace becomes
On Wed, 29 Dec 2004 19:57:15 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
I don't see too much of a difference between #1 (an on-disk structure
buffered in shared memory) and #2 (a shared memory structure spilling
to disk).
If you stand back that far, maybe
Pursuant to Theodore Petrosky's recent trouble report, I thought I would
see what happens if you try to build Postgres in a directory whose path
contains spaces, or if the install prefix contains spaces.
It doesn't work, not even close.
It looks to me like there are a couple of hundred places in
Manfred Koizar [EMAIL PROTECTED] writes:
So the question is whether starting by making nbtree more flexible isn't
the lower hanging fruit...
Certainly not; indexes depend on locks, not vice versa. You'd not be
able to do that without introducing an infinite recursion into the
system design.
Le 30 déc. 04, à 16:05, Tom Lane a écrit :
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
Hmm. I was hoping to spot some obviously machine-dependent code
nearby
to the crash point, but I don't see anything wrong in that area.
You might try rebuilding tsearch with -O0 (if it wasn't
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
Ugh. That suggests it could be a compiler bug. Are you using the
latest available compiler version for your platform?
The problem is that when compiled with -O2, the pushval_morph func
address is 0x0 (in query.c).
It goes away with the
On Thu, 30 Dec 2004 13:36:53 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Certainly not; indexes depend on locks, not vice versa. You'd not be
able to do that without introducing an infinite recursion into the
system design.
Wouldn't you have to face the same sort of problems if you spill part of
On Mon, 2004-12-27 at 22:21, Bruce Momjian wrote:
Should we consider at least adjusting the meaning of bgwriter_percent?
Yes. As things stand, this is the only change that seems safe.
Here's a very short patch that implements this change within BufferSync
in bufmgr.c
- No algorithm changes
-
Simon Riggs wrote:
On Mon, 2004-12-27 at 22:21, Bruce Momjian wrote:
Should we consider at least adjusting the meaning of bgwriter_percent?
Yes. As things stand, this is the only change that seems safe.
Here's a very short patch that implements this change within BufferSync
in bufmgr.c
Baring any cries of *STOP* ... I'm going to try and get it packaged first
thing in the morning ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of
'k, I'm upgraded for 1.79 and RC3 ...
On Tue, 21 Dec 2004, Peter Eisentraut wrote:
Marc G. Fournier wrote:
'k, I'm about to screw up rc2 for this too ... FreeBSD ports is
'stuck' at 1.78 ...
Well, file a bug to get it updated?
just went to
http://sourceforge.net/projects/docbook, and there are two
NUMERIC data type is hardcoded to use '.' as the decimal point.
FLOATs are in fact hardcoded the same way (they use strtod() and sprintf()
while pgsql's LC_NUMERIC is always C).
The only data type that localizes decimal point is MONEY.
it makes many problems when the decimal point is not '.'
Manfred Koizar [EMAIL PROTECTED] writes:
On Thu, 30 Dec 2004 13:36:53 -0500, Tom Lane [EMAIL PROTECTED] wrote:
Certainly not; indexes depend on locks, not vice versa. You'd not be
able to do that without introducing an infinite recursion into the
system design.
Wouldn't you have to face the
Yay
I assume that any changes will be in CVS at that point?
I have a bunch of patches and some new files for the OS/2 port that I plan
on submitting as a diff to the 8.0 GA when that
comes about. Is that the appropriate time?
BTW - I did get all the NLS stuff working as well.
Lorne
In
16 matches
Mail list logo
