The problem with pg_dump and renamed primary key attrs can be fixed by
using the indkey attribute of pg_index to lookup attrs in pg_class - this
is what pg_dump does when it dumps indexes. If I am going to make this
change, I would also like to split the PK definition out from the table
Hi,
Does anyone seen this on PostgreSQL 7.0.3?
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Server process (pid 1008) exited with status 6 at Sun Jan 7 04:29:07 2001
Terminating any active server
On Sun, 7 Jan 2001, Philip Warner wrote:
The problem with pg_dump and renamed primary key attrs can be fixed by
using the indkey attribute of pg_index to lookup attrs in pg_class - this
is what pg_dump does when it dumps indexes. If I am going to make this
change, I would also like to split
Dear list,
According to this list's content, the upcoming 7.1 release appears to be
in good progress. This version will bring a *lot* on necessary features
for some database work : unions and subselects in views, and the
long-awaited outer joins. In other words, while 7.0 was a large step in
Emmanuel Charpentier wrote:
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
I am inclined to wait until a Release Candidate, if we have one this go
around, is available before releasing RPM's, but my mind can be
changed :-)
Please do make beta RPMs available.
Peter Eisentraut wrote:
pg_restore has some options that are supposed to allow restoring some or
all indexes/tables/triggers/etc. For example
pg_restore --table
restores all tables and
pg_restore --table=my_table
restores only the named table. The equivalent short option
Oliver Elphick writes:
I don't like that; it will need to be escaped with \ or the shell will
substitute the contents of the current directory for the *.
Why not use `-t all'
Because there might be a table called "all". (Okay, there could be a
table called "*", but really...)
or `-A'?
Denis Perchine [EMAIL PROTECTED] writes:
Does anyone seen this on PostgreSQL 7.0.3?
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Were there any errors before that?
I've been suspicious for awhile that the system might neglect to release
buffer cntx_lock spinlocks if
"Oliver Elphick" [EMAIL PROTECTED] writes:
I'll be doing it soon; but I don't want to release debs until there is
no more chance of an initdb's being needed between betas; that bit me on
7.0.
In that case you may as well say that there will be no beta debs, and
Debian users can forget about
On Sun, 7 Jan 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
On Sun, 7 Jan 2001, Philip Warner wrote:
Is this OK? Or inappropriate for beta?
From Tatsuo's example, it looks critical enough that it should be fixed
before release, and since its a 'support program'
The Hermit Hacker [EMAIL PROTECTED] writes:
Essentially, worst case scenario, we are going from 'broken-broken' ...
No, I don't think so. The current pg_dump code is only broken if
you've renamed a column involved in a foreign-key dependency (if I
understood the thread correctly). But Philip
On Sun, 7 Jan 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Essentially, worst case scenario, we are going from 'broken-broken' ...
No, I don't think so. The current pg_dump code is only broken if
you've renamed a column involved in a foreign-key dependency (if I
A few problems came up with 7.1CVS for i86 OpenBSD. Here is a writeup on
what I learned and how I solved the problems.
- Brandon
b. palmer, [EMAIL PROTECTED]
pgp: www.crimelabs.net/bpalmer.pgp5
Added gmake and gettext. (if you don't have it)
Added bison and replaced /usr/bin/yacc with
Oliver Elphick wrote:
Emmanuel Charpentier wrote:
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
I am inclined to wait until a Release Candidate, if we have one this go
around, is available before releasing RPM's, but my mind can be
changed :-)
Please do make
heap_update() currently ends with
if (newbuf != buffer)
{
LockBuffer(newbuf, BUFFER_LOCK_UNLOCK);
WriteBuffer(newbuf);
}
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
WriteBuffer(buffer);
/* invalidate caches */
RelationInvalidateHeapTuple(relation,
bpalmer writes:
A few problems came up with 7.1CVS for i86 OpenBSD. Here is a writeup on
what I learned and how I solved the problems.
Can you check
http://www.postgresql.org/devel-corner/docs/postgres/kernel-resources.htm#SYSVIPC
to see if the description for FreeBSD is also applicable (at
Can you check
http://www.postgresql.org/devel-corner/docs/postgres/kernel-resources.htm#SYSVIPC
to see if the description for FreeBSD is also applicable (at least in
similar form) to OpenBSD?
Close enough.
I'm currently writing up a section about the process and file limit issue,
which
The KAME files md5.* and sha1.* have the following changelog
entry:
revision 1.2
date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines:
+18 -18
Eliminate some of the more blatant platform-dependencies ... it
builds here now, anyway ...
Marko Kreen [EMAIL PROTECTED] writes:
date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines: +18 -18
Eliminate some of the more blatant platform-dependencies ... it
builds here now, anyway ...
Which basically changes u_int*_t - uint*_t, so now it does not
compile neither under Debian
Create Table fred(f1 int);
Alter Table fred add constraint primary key(f1);
Has support for the above statement (add constraint PK) been added in 7.1?
If so, then what other alter table add constraints have been added? CHECK?
NOT NULL?
Thanks,
Chris
It seems ALL and ANY (SOME) have problems with the parser.
test=# select * from t1 where i all(0,1);
ERROR: parser: parse error at or near "0"
test=# select * from t1 where i = any (0,1);
ERROR: parser: parse error at or near "0"
test=# select version();
On Sun, Jan 07, 2001 at 08:09:07PM -0500, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines: +18 -18
Eliminate some of the more blatant platform-dependencies ... it
builds here now, anyway ...
Which basically changes
Tatsuo Ishii [EMAIL PROTECTED] writes:
It seems ALL and ANY (SOME) have problems with the parser.
I see no problem here. Those are only defined for sub-selects.
SQL92 8.7 says:
quantified comparison predicate ::=
row value constructor comp op quantifier table subquery
On Monday 08 January 2001 00:08, Tom Lane wrote:
Denis Perchine [EMAIL PROTECTED] writes:
Does anyone seen this on PostgreSQL 7.0.3?
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Were there any errors before that?
No... Just clean log (I redirect log from
On Mon, Jan 08, 2001 at 04:06:09AM +0200, Marko Kreen wrote:
On Sun, Jan 07, 2001 at 08:09:07PM -0500, Tom Lane wrote:
Marko Kreen [EMAIL PROTECTED] writes:
Which basically changes u_int*_t - uint*_t, so now it does not
compile neither under Debian 2.2 nor under NetBSD 1.5 which
is
You are right. However, SQL92 spec allows:
select * from t1 where i all values(0,1);
which is not allowed in PostgreSQL...
--
Tatsuo Ishii
Tatsuo Ishii [EMAIL PROTECTED] writes:
It seems ALL and ANY (SOME) have problems with the parser.
I see no problem here. Those are only defined for
26 matches
Mail list logo
