At 15:15 7/01/01 +0900, Tatsuo Ishii wrote:
>> As for the latest CVS source, it looks still we have problems
>> regarding alter table rename column and pg_dump as Grant has
>> mentioned. Results of pg_dump is attached.
>
>Sorry, an attachmet was missing.
>
I can reproduce this in 7.0.2 as well;
> As for the latest CVS source, it looks still we have problems
> regarding alter table rename column and pg_dump as Grant has
> mentioned. Results of pg_dump is attached.
Sorry, an attachmet was missing.
aaa.gz
As for the latest CVS source, it looks still we have problems
regarding alter table rename column and pg_dump as Grant has
mentioned. Results of pg_dump is attached.
test=# create table a ( aa serial primary key );
NOTICE: CREATE TABLE will create implicit sequence 'a_aa_seq' for SERIAL column
On Sun, 7 Jan 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > On Sat, 6 Jan 2001, Tom Lane wrote:
> >> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> can a couple ppl check it over and make sure that nothing was overlooked
> before I announce it?
> >>
> >> Loo
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> On Sat, 6 Jan 2001, Tom Lane wrote:
>> The Hermit Hacker <[EMAIL PROTECTED]> writes:
can a couple ppl check it over and make sure that nothing was overlooked
before I announce it?
>>
>> Looks great, other than that it's missing the fixes I
regression=# begin;
BEGIN
regression=# insert into rtest_t1 values(1,2);
INSERT 287918 1
regression=# select * from tenk1, tenk1 t2;
-- press ^C here
Cancel request sent
ERROR: Query was cancelled.
ERROR: Query was cancelled.
FATAL 2: elog: error during error recovery, giving up!
pqReadData() -
On Sat, 6 Jan 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > can a couple ppl check it over and make sure that nothing was overlooked
> > before I announce it?
>
> Looks great, other than that it's missing the fixes I checked in since
> then ;-)
Critical enough to ditc
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> can a couple ppl check it over and make sure that nothing was overlooked
> before I announce it?
Looks great, other than that it's missing the fixes I checked in since
then ;-)
regards, tom lane
can a couple ppl check it over and make sure that nothing was overlooked
before I announce it?
Peter, I got your mk-release changes in for the docs ... the build itself
looked great, but I figure a couple of confirmations before announcing it
will at least prevent any obvious bug reports ...
M
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Apparently these resultmap entries were needed at some point.
I think you read the message backwards --- we were adding the entries,
not removing them. (The patch was reversed as given, which is a common
mistake.) As patched, the entries for OpenBS
bpalmer writes:
> > Those all look like trivial platform dependencies. Please read
> > http://www.postgresql.org/devel-corner/docs/postgres/regress.htm
> > http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.htm
> > and submit resultmap patches as required for your platform.
>
bpalmer <[EMAIL PROTECTED]> writes:
> [ resultmap patches for OpenBSD ]
Applied, thanks!
> Sweet. Thanks, looks like the problem is solved. Should me make note of
> the changes what were needed for OBSD somewhere?
If there's anything that users need to know beyond the standard build
instruct
OK, stringToNode changes committed. I think we're ready to go for
beta2...
regards, tom lane
At 22:05 6/01/01 +0100, Peter Eisentraut wrote:
>
>restores only the named table. The equivalent short option is -t but it
>does not allow restoring all tables, since it requires an argument. I
>suggest that an argument of '*' also means to restore all tables.
Sounds fine.
>Also, if you just
> Those all look like trivial platform dependencies. Please read
> http://www.postgresql.org/devel-corner/docs/postgres/regress.htm
> http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.htm
> and submit resultmap patches as required for your platform.
Sweet. Thanks, looks lik
On Sat, 6 Jan 2001, Tom Lane wrote:
> The stringToNode routines (backend/nodes/read.c and readfuncs.c) depend
> on a static variable that is the next-input pointer for lsptok().
>
> Guess what happens if stringToNode is invoked recursively. (Hint:
> it's not good.)
>
> It's apparently not easy f
The stringToNode routines (backend/nodes/read.c and readfuncs.c) depend
on a static variable that is the next-input pointer for lsptok().
Guess what happens if stringToNode is invoked recursively. (Hint:
it's not good.)
It's apparently not easy for this to happen, but I have a reproducible
test
bpalmer <[EMAIL PROTECTED]> writes:
> There are still, however, 4 tests that fail.
Those all look like trivial platform dependencies. Please read
http://www.postgresql.org/devel-corner/docs/postgres/regress.htm
http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.htm
and submi
> In the postmaster: the fork() to launch a backend is failing. There
> should be a more detailed message in the postmaster's stderr log,
> but almost certainly it's a resource-exhaustion issue. Does your
> kernel enforce a per-userid limit on the number of processes, for
> example?
Looks like
bpalmer <[EMAIL PROTECTED]> writes:
> ! psql: Backend startup failed
> Any ideas where to look for this one?
In the postmaster: the fork() to launch a backend is failing. There
should be a more detailed message in the postmaster's stderr log,
but almost certainly it's a resource-exhaustion issu
When I run 'make check' on the CVS version (today and for the last
serveral days), I have been getting interesting failures. Some of the
tests fail, but the interesting part is that not the same tests always
fail. Example:
bpalmer@mizer:~/APPS/pgsql>diff 1 2
1c1
< boolean ..
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 is -t but it
does not allow restoring all ta
>> psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such file
>or directory
> Not sure why you are getting such a message, but it strikes me that you
> may have a corrupted set of sources, ie, some out-of-date files. Have
> you tried doing a fresh cvs checkout and build
Hi all!
How I can to split tables over many disks without using RAID (by using
symlinks? ) ?
Can I use raw devices for store PostgreSQL data ?
Thanks.
Sergey.
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. Seems to me that there's a
> fai
Anyone can help with that one?
Warning: PostgresSQL query failed: ERROR: cannot find attribute 10 of
relation pg_am in [..]
Warning: 0 is not a PostgresSQL result index in
Thanks in advice
ineck
psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such file or
directory
and it's true..
% ls /usr/local/pgsql/data/global
1260126112621264126917127 17130
pg_control
source from Jan 3 15:59 GMT
configure --enable-lo
Please ignore last 2 messages re
psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such file or
directory
- I had another old postmaster running...
Cheers,
Patrick
Posting again as even though I receive mail from hackers I am apparently
not a member (registered correctly as [EMAIL PROTECTED] - from will say
[EMAIL PROTECTED] - setting reply-to to [EMAIL PROTECTED] used to get
around it..)
psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_dat
backend/commands/command.c has a routine is_view() that tests for
view-ness by scanning pg_rewrite (all of it) to see if the given
relation has any ON SELECT rules.
This is only used to disallow AlterTableAddConstraint and
LockTableCommand on views. While I don't care much about the
performance
(approximately in the order in the HISTORY file)
WAL -- update documentation of fsync option (runtime.sgml)
TOAST -- The introductory paragraph in lobj.sgml needs some updating
regarding the remaining merits of the large object system.
Overhaul pg_dump (Philip Warner) -- backup.sgml could use s
On Fri, 5 Jan 2001, Lamar Owen wrote:
> Ok, consider my mind changed. :-). My only concerns were, due to some
> feedback I have gotten, is that people would treat the RPM release as
> _productions_ rather than beta -- but maybe I'm just being paranoid.
Just because you're paranoid doesn't mean
32 matches
Mail list logo
