On Sat, 27 Dec 2003, A E wrote:
Hi,
I was wondering if a solution was ever found to the error: wrong record type
supplied in RETURN NEXT when executing a function that returns the Record datatype?
I have seen a couple of previous post from Tom Lane and others, but no real
resolution.
*growl* - it sounds like the business...and I was all set to code it,
however after delving into Pg's aggregation structure a bit, it suffers
a fatal flaw :
There appears to be no way to avoid visiting every row when defining an
aggregate (even if you do nothing on each one) -- which defeats
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Longer term, a robust mechanism for DB level locks would probably be
preferable, I guess, so I'm not sure if my idea is worth doing in the
mean time. Presumably it hasn't caused much of a problem up to now,
since most people are not
Andrew Dunstan [EMAIL PROTECTED] writes:
How about (even quicker and dirtier) putting a limited loop (say 5
iterations?) with a small delay in it around the check for whether or
not we are the only connection? Createdb is hardly a time critical
operation, and taking a few seconds extra in
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
How about (even quicker and dirtier) putting a limited loop (say 5
iterations?) with a small delay in it around the check for whether or
not we are the only connection? Createdb is hardly a time critical
operation, and taking a few
Dear all ,
I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .
Also I would like to learn how professional users of PostgreSQL work
with rounding of monetary terms .
If you would like to know whats IEEE 754 read this
Sai Hertz And Control Systems wrote:
Dear all ,
I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .
Also I would like to learn how professional users of PostgreSQL work
with rounding of monetary terms .
If you would like to know
Dear all:
This may not be the right list to refer to the rpm,
but I am confident that someone on this list will be
able to point me in the right direction.
I am trying to make sure when this rpm is installed,
it installs to /opt/postgresql-7.2.4/ in stead of
/usr/bin, /usr/man etcetera (this is
Manfred Spraul [EMAIL PROTECTED] writes:
Mark ran a DBT-2 testrun with the attached statistics patch applied: It
collects stats about all lightweight locks and dumps them during
shutdown. The hottest locks are
Lock Acquire%contention sleep calls
8(WALInsertLock)
Sai Hertz And Control Systems wrote:
Dear all ,
I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .
Also I would like to learn how professional users of PostgreSQL work
with rounding of monetary terms .
For all monetary values the
On Dec 29, 2003, at 11:28 AM, Sai Hertz And Control Systems wrote:
I would like to share my concerns about the IEEE 754 specification and
floating point handling by PostgreSQL .
What specifically are your concerns regarding floating point handling
and PostgreSQL? I'm not in a position to address
Bruce Momjian [EMAIL PROTECTED] writes:
Manfred Spraul wrote:
I remember there were patches that tried other algorithms instead of the
simple LRU for the buffer manager. Has anyone tried to change the
locking of the buffer manager?
CVS HEAD already has an Adaptive Replacement Cache (ARC)
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Manfred Spraul wrote:
I remember there were patches that tried other algorithms instead of the
simple LRU for the buffer manager. Has anyone tried to change the
locking of the buffer manager?
CVS HEAD already has an
Jan Wieck [EMAIL PROTECTED] writes:
That's irrelevant to the problem, though. Unless the ARC code uses data
structures that are more amenable to localized locking than the old
global buffer freelist. (Jan?)
the strategy itself does no locking at all. Like the old LRU code it
simply
14 matches
Mail list logo
