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 <[EM
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
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 '.' (f
'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
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 broa
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 buf
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
-
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 o
=?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
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 alre
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.
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
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 tha
=?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 backtr
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
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 messag
16 matches
Mail list logo
