On Tue, 19 Dec 2000, Bruce Momjian wrote:
> > PS. -hackers: What happen with PL/Python? Before 1/2 of year I ask if
> > anyone works on this and answer was: "yes, but 'he' is waiting for new
> > fmgr design". Tom's fmgr is done... IMHO it's big worse - The Python
> > has very good
Is this bad, or are there expected to be known problems like this for
OBSD?
7.1beta1 had roughly the same errors..
- BEGIN ---
bpalmer@mizer:~/PG7.1/postgresql-snapshot>uname -a
OpenBSD mizer 2.8 GENERIC#399 i386
bpalmer@mizer:~/PG7.1/postgresql-snapshot>
Hi,
Is it correct behaviour that unnamed table-level check constraints get the
names '$1', '$2', '$3', etc. in Postgres 7.0.3???
Eg, using table constraints:
test=# create table test (temp char(1) NOT NULL, CHECK (temp IN ('M',
'F')));
CREATE
test=# select rcname fr
I have had the time to test today's (12/19) snapshot on my
Linux/Alpha and the good news is that only two regression tests are
failing. The bad news is that these regression tests do not fail on
Linux/Intel. :( [1]
Specifically, the oid and misc regression tests failed. Here are
t
Thanks. Applied.
> On Sunday 17 December 2000 15:07, Bruce Momjian wrote:
> > We need additions to alter_table.sgml for the new OWNER option mention
> > in the features list.
>
> Here it is.
>
> --
> Mark Hollomon
[ Attachment, skipping... ]
--
Bruce Momjian| ht
> furthermore, are there any plans to offer a better libpq interface to INSERT?
> the things i'm doing now to quote the text, and the extra copy i'm maintaining,
> are painful. arbitrary-sized "text" attributes are a huge boon -- we would
> never have considered using postgres for MAPS RSS (or RB
I added (Alpha) next to the mention of 64-bit CPUs on the Function
Manager section at the top.
> On Sat, 16 Dec 2000, Bruce Momjian wrote:
>
> > Here is the list of features in 7.1.
>
> One thing that I think ought to be added is that with 7.1,
> PostgreSQL will compile out of the box (i.
We have an FAQ item on this now under OID's.
[ Charset ISO-8859-1 unsupported, converting... ]
> > > Reading the documentation, I see that OIDs are unique through
> the
> > > whole database.
> > > But since OIDs are int4, does that limit the number of rows I
> can
> > > have in a
> PS. -hackers: What happen with PL/Python? Before 1/2 of year I ask if
> anyone works on this and answer was: "yes, but 'he' is waiting for new
> fmgr design". Tom's fmgr is done... IMHO it's big worse - The Python
> has very good design for integration to other programs.
Good que
> > Reading the documentation, I see that OIDs are unique through
the
> > whole database.
> > But since OIDs are int4, does that limit the number of rows I
can
> > have in a database to 2^32 = 4 billion ?
>
> Yep.
>
> Thanks for the answer - although that concerns me a bit.
> Maybe
> > > AFAIR, none of the index access methods except btree
> > > handle NULLs at all --- they just ignore NULL values
> > > and don't store them in the index.
...
>
> and what does this error means ?
>
> create table rtree_test ( r box );
> copy rtree_test from stdin;
> \N
> total 10,0
> > > The point is, that the heap page is only modified in
> > > places that were previously empty (except header).
> > > All previous row data stays exactly in the same place.
> > > Thus if a page is only partly written
> > > (any order of page segments) only a new row is affected.
> >
> > Excep
Tom Lane writes:
> SELECT * FROM (A NATURAL JOIN B) Jproduces ID, CA, CB
>
> SELECT J.* FROM (A NATURAL JOIN B) J produces ID, CA, CB
>
> SELECT A.* FROM (A NATURAL JOIN B) J produces ID, CA
>
> SELECT B.* FROM (A NATURAL JOIN B) J produces ID, CB
ISTM that
On Sunday 17 December 2000 15:07, Bruce Momjian wrote:
> We need additions to alter_table.sgml for the new OWNER option mention
> in the features list.
Here it is.
--
Mark Hollomon
*** alter_table.sgml.orig Tue Dec 19 17:32:47 2000
--- alter_table.sgmlTue Dec 19 17:39:27 2000
***
On Tue, 19 Dec 2000, Christopher Masto wrote:
> Date: Tue, 19 Dec 2000 13:33:58 -0500
> From: Christopher Masto <[EMAIL PROTECTED]>
> To: Tom Lane <[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]>
> Cc: Oleg Bartunov <[EMAIL PROTECTED]>,
> PostgreSQL-development <[EMAIL PROTECTED]>
> Sub
On Tue, Dec 19, 2000 at 03:03:43PM +, Thomas Lockhart wrote:
> o WAL fsync() log commits and cleanup (aggregate throughput is great,
> but every once in a while someone waits while the paperwork gets done.
> Waiting may be due to processor resource competition)
>
> o Underlying file system bo
my cgi program is
test.cgi:###require
"./connectdb.pl";&connectdatabase();$query="select count(*) from
messages";$sth=$dbh->prepare($query);$sth->execute();$count=$sth->fetchrow_array();print
"Content-type: text/html\n\n";print
<<"TAG"; The count is
$count. TAGexit
0;#
On Sun, Dec 17, 2000 at 11:30:23PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think
> > there are some papers at Berkeley or a web site that goes into it in
> > detail.
>
> I imagine there's some GiST stuff at the Berkeley papers repository
> http://s2k-ftp.CS.Berkel
> Uhm... I always thought that sharing the same socket between
> processes is wrong.
Well, I've never thought about it before this problem, but it definitely
appears to me like something not to do. Sharing remote object doesn't sound
right :-(
> My multi-process daemon works like apache with a p
Thomas Lockhart wrote:
>
> > Perhaps we can create a substantial test database? (Millions of records,
> > many tables, and a number of relations.) So when we see a problem, we
> > can all see it right away. I like "real world" data, because it is often
> > more organic than randomized test data,
On Tue, 19 Dec 2000, Hannu Krosing wrote:
> Date: Tue, 19 Dec 2000 02:04:02 +0200
> From: Hannu Krosing <[EMAIL PROTECTED]>
> To: Tom Lane <[EMAIL PROTECTED]>
> Cc: Oleg Bartunov <[EMAIL PROTECTED]>,
> Bruce Momjian <[EMAIL PROTECTED]>,
> PostgreSQL-development <[EMAIL PROTECTED]>
> Subje
[I was having trouble with the direct address so i'm only sending to
the list]
> select * from table where col = function() ;
> (2) "function()" returns a number of values that are independent of the
> query. Postgres should be able to optimize this to be: "select * from
> table where col in (v
> What do you guys use?
The regression database, which you can augment with some "insert into x
select * from x;" commands. It would also be useful to have a "database
generation" script, but of course this would be cooked data.
> Perhaps we can create a substantial test database? (Millions of r
Given this basic SQL statement:
select * from table where col = function() ;
There are three basic types of SQL behaviors that should be able to be
performed.
(1) "function()" returns a single value. Postgres should be able to
understand how to optimize this to be: "select * from table where c
I am doing some testing and development on Postgres.
Is there, by chance, a good source of data which can be used as a test
database? I have been using a music database, but it is proprietary, and
makes me uncomfortable to post public tests.
What do you guys use?
Perhaps we can create a substan
Sébastien Bonnet wrote:
>
> Hi all, and mainly postresql developpers,
>
> I've been reading old posts about the libpq interface related to multi-process
> application. The main problem being that after a fork, each process has a DB
> connexion, actually the same. If one closes it, the other one
HI all,
I've encountered a database freeze and found it's due
to the reset of connection after abort.
The following is a part of postmaster log.
A new backend(pid=395) started immedaitely after
a backend(pid=394) abort. OTOH postmaster tries
to kill all backends to cleanup shared memory.
However
Hi all,
In InitPostgres()(postinit.c) I see the following code.
RelationCacheInitialize();/* pre-allocated reldescs created here
*/
InitializeTransactionSystem(); /* pg_log,etc init/crash recovery
here */
init_irels() is at the end of RelationCacheInitialize() and
accesses sy
Hi all, and mainly postresql developpers,
I've been reading old posts about the libpq interface related to multi-process
application. The main problem being that after a fork, each process has a DB
connexion, actually the same. If one closes it, the other one remains in a
unknown or not stable st
Paul,
1) Have you ran vacuum analyze after all these inserts to update database
statistics? :) Without vacuum, pgsql will opt to table scan even when
there's an index.
2) I'm not sure if you are executing pgcat 70k times or executing inner
loop in pgcat 70k times. Postgres connection establishme
> anybody know what i could be doing wrong? (i'm also wondering why SELECT
> takes ~250ms whereas INSERT takes ~70ms... seems counterintuitive, unless
> TOAST is doing a LOT better than i think.)
I would think that this is entirely due to planning the query. An INSERT
has no decisions to make, w
Hello all,
I would like to thank Tom, Ian and the other pgsql wizards for their prompt
response. This must surely be open source at it's best :)
I've worked around the situation by running a small script that continually
monitors postgres and takes appropriate action if postgres shuts down. I'm
> > The only source of serious problems is thus a bogus write of a page
> > segment (100 bytes ok 412 bytes chunk actually written to disk),
> > but this case is imho sufficiently guarded or at least detected
> > by disk hardware.
>
> With full page logging after checkpoint we would be safe fro
33 matches
Mail list logo
