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
definitio
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 pr
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 s
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
*per
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 be
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 sho
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'
Emmanuel Charpentier writes:
> 1) Updatable views.
You can make rules updateable by attaching appropriate rules to them.
The transparent implementation of updateable views would essentially do
that. It's a planned feature but I don't know of anyone who has made it
his priority.
> 2) External d
On Sunday 07 January 2001 21:31, Emmanuel Charpentier wrote:
> These advances will allow me to use PostgreSQL for some work I had to do
> until now with (gasp !) MS-Access (which has poor performance but good
> competence). And get rid of the damn MS-Windows envoronment for good !
Excuse me, but
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' issue, not a 'core
> server' issue, rami
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
"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 ab
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 p
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 Phil
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
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 /usr
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 :-)
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, &oldtup)
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
The way that heap_update() and heap_delete() are currently coded, they
hold the buffer context lock on the buffer containing the old tuple
while they invoke heap_tuple_toast_attrs(). This strikes me as at least
inefficient and at worst a source of deadlock. Is it possible to avoid
holding the bu
> 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,
> whi
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
> 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();
versi
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 c
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:
::=
::= |
::= ALL
::= SOME | ANY
and that is the o
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 whi
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 def
30 matches
Mail list logo
