"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Correct me if I'm wrong, but the FSM is only populated by vacuum, so there
> is no FSM information for any given table / database until it's vacuumed, in
> a long running production enviornment this may not be that important, but it
> could result
--On Wednesday, February 26, 2003 17:33:23 -0500 "James H. Cloos Jr."
<[EMAIL PROTECTED]> wrote:
I'm trying to compile a co of REL_7_3_2 for my laptop (initially a
suse 7.3 install) and it fails w/ this from bison:
make -C preproc all
make[1]: Entering directory
`.../pgsql-server-7.3.2/src/inte
> PS: Another idea I'm toying with is to dump out the FSM contents at
> postmaster shutdown and reload them at restart, so that the FSM doesn't
> have to start from ground zero on every restart cycle. But that's
> independent of the management algorithm...
Correct me if I'm wrong, but the FSM is
I'm trying to compile a co of REL_7_3_2 for my laptop (initially a
suse 7.3 install) and it fails w/ this from bison:
make -C preproc all
make[1]: Entering directory `.../pgsql-server-7.3.2/src/interfaces/ecpg/preproc'
bison -y -d preproc.y
preproc.y:5560: fatal error: maximum table size (32767)
Josh Berkus <[EMAIL PROTECTED]> writes:
> I thought this bug was fixed in 7.2.4:
> DBD::PgPP::st execute failed: ERROR: Parent tuple was not found
> (a second VACUUM FULL ANALYZE succeeded)
IIRC, for 7.2.* we only attempted to fix the variants that resulted in
hard (repeatable) errors. You've go
PgPeople:
I thought this bug was fixed in 7.2.4:
DBD::PgPP::st execute failed: ERROR: Parent tuple was not found
Process Failed: ERROR: Parent tuple was not found
from step VACUUM FULL ANALYZE
version
---
I've been thinking about improving the algorithm that the free space map
(FSM) uses to decide what to store when it's not got enough shared
memory to keep track of everything. The present design uses a dynamically
adjusted threshold for each relation, throwing away pages whose free
space amount is
On Wed, 2003-02-26 at 06:00, Michael Meskes wrote:
> And of course I don't like the idea of linking in the GPLed
> GNU MP library on default as this would create licensing problems.
Actually, GNU MP is released under the LGPL.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C
I am trying to emulate a pessimistic locking system you would find in an
old school database file system, for example cobol. Generally, when a
cobol program tries to read a record that is locked by somebody else,
the read fails and either a message is displayed by the user or a error
handling proc
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> Why would there be any speed advantage?
> Is it not faster to add it when all the data is there, rather than
> evaluating it as each row is inserted, like indexes?
I don't see why. There are good algorithmic reasons why bulk-loading
an ind
Dave Cramer <[EMAIL PROTECTED]> writes:
> what cvs version are you working with?
CVS tip in either HEAD or REL7_3_STABLE branches works for me.
There are some known issues with autocommit getting turned off
as part of a multi-statement command that's sent to tbe backend
in a single query string.
On Wed, Feb 26, 2003 at 09:44:14AM +, Darko Prenosil wrote:
>
> I got the sources yesterday. Thank you !
Let me know whether everything works for you. There's also a mailing
list on pqxx.tk if you need it.
Jeroen
---(end of broadcast)---
TIP
On Tue, Feb 25, 2003 at 03:58:51PM +, Lee Kindness wrote:
> Okay guys, i've been a bit tight of time recently to move forward on
> this, but I plan to do a small amount of work on the patches to clean
> them up so they can be merged into the sources.
Thanks a lot for your work Lee.
Michael
--
Sorry for the noise, my instance of postgres was broken.
Dave
On Wed, 2003-02-26 at 02:19, Dave Cramer wrote:
> what cvs version are you working with?
>
> Dave
> On Wed, 2003-02-26 at 01:11, Tom Lane wrote:
> > Dave Cramer <[EMAIL PROTECTED]> writes:
> > > Can someone point me to the documentatio
Michael Meskes kirjutas K, 26.02.2003 kell 13:00:
> Did anyone ever think about creating a library that is able to handle
> our numeric datatype? I'm currently thinking about adding this datatype
> among others to the ones know to ecpg so no one is forced to convert
> them or work on the strings. O
Did anyone ever think about creating a library that is able to handle
our numeric datatype? I'm currently thinking about adding this datatype
among others to the ones know to ecpg so no one is forced to convert
them or work on the strings. On the other hand I'm not sure if anyone's
interested in th
On Tuesday 25 February 2003 18:57, Jeroen T. Vermeulen wrote:
> On Tue, Feb 25, 2003 at 07:34:12PM +, Darko Prenosil wrote:
> > Unfortunately it is application written in QT library that should work on
> > Windows too, but I'll take a look, I'm sure I can learn something from it
> > !
>
> Well,
17 matches
Mail list logo
