Mike Wilson writes:
> Just for my interest I also created a new PG 842 db (initdb) and put
> some sample data it it and successfully did a pg_upgrade from 842 ->
> 920b2. Whatever the issue is it seems to be related to my actual
> database as a sample db conversion works.
Yeah, I was suspecting
Excerpts from Dave Page's message of mar jun 05 14:38:54 -0400 2012:
>
> On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera
> wrote:
> >> I have been installing PostgreSQL 9.1.3.2, and I've noted that 'creating
> >> database cluster' is too long. I have been waiting for a half of hour, and
> >> it h
Just for my interest I also created a new PG 842 db (initdb) and put some
sample data it it and successfully did a pg_upgrade from 842 -> 920b2.
Whatever the issue is it seems to be related to my actual database as a sample
db conversion works. Again, 842-914 conversion works for my db though
On tor, 2012-07-12 at 15:25 +, ch...@chrullrich.net wrote:
> The PostgreSQL configure script indiscriminately enables the --as-needed
> option to the linker if the linker supports it, which GNU ld 2.17.50 in
> FreeBSD 9 does. It does not, however, use it in its own library checks. The
> configu
core stack:
root@db4 / $ pstack ~postgres/core
core '/opt/postgres/core' of 19868: pg_upgrade --verbose --link
--old-datadir=/opt/postgres/db/root/old --
fd7ffeda1148 memcpy () + 6b8
0040b8b6 transfer_single_new_db () + fa
0040b6ea transfer_all_new_dbs () + 116
daniele.varra...@gmail.com writes:
> CREATE TABLE foo
> (
> id serial primary key,
> f1 integer NOT NULL
> );
> CREATE INDEX foo_idx1 ON foo (f1);
> CREATE INDEX foo_idx2 ON foo (f1) WHERE id > 10;
> COMMENT ON INDEX foo_idx2 IS 'whatever';
> create table foo2 (like foo including all);
I'v
On Mon, Jul 16, 2012 at 12:47:37PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > As a side question for the list, should we fix this differently in 9.2 to
> > avoid forcing an initdb for the next beta?
>
> I'm confused, why would an initdb be involved?
pg_constraint.connoinherit is presently o
Noah Misch writes:
> As a side question for the list, should we fix this differently in 9.2 to
> avoid forcing an initdb for the next beta?
I'm confused, why would an initdb be involved?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
T
On Mon, Jul 16, 2012 at 04:49:46PM +0530, Amit Kapila wrote:
> Code Changes
>
> I will make changes in following functions to ensure that connoinherit
> should be appropriately set(pass the value as true).
> a. index_constraint_create()
> b. ATAddForeignKeyConstraint()
> c. Cre
On 14 July 2012 05:56, Craig Ringer wrote:
> On 07/14/2012 12:18 AM, Petros Tsialiamanis wrote:
>>
>> Thank you very much for your reply.
>
> Thanks for coming back and re-testing with a modern PostgreSQL.
>
> PostgreSQL 9.1 isn't compatible with databases from 8.3, so you can't
> actually run Pg
The following bug has been logged on the website:
Bug reference: 6739
Logged by: Stuart Axon
Email address: stua...@yahoo.com
PostgreSQL version: 9.1.0
Operating system: Linux
Description:
If you go to Database>{db}>Schemas>public>Tables
You can only select one table
On 07/16/2012 07:54 PM, Petros Tsialiamanis wrote:
Sorry for the misunderstanding. When I said that I reproduced the
error in 9.1 version, I mean that I created the PGDATA with 9.1
postgresql server as 'local system' user and after that I tried to
start the postgresql server as 'pss-svc' user a
From: Noah Misch [mailto:n...@leadboat.com]
Sent: Monday, July 16, 2012 2:54 AM
> One can construct similar bugs around dropping foreign key and exclusion
> constraints. Though it may be irrelevant for command semantics,
additionally
> using connoinherit = 't' for contype = 't' (CONSTRAINT_TRIGG
From: Noah Misch [mailto:n...@leadboat.com]
Sent: Monday, July 16, 2012 2:54 AM
> > From: pgsql-bugs-ow...@postgresql.org
[mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of
miroslav.s...@fordfrog.com
> > Sent: Saturday, June 30, 2012 4:28 PM
> Care to prepare a patch with a test case addition
14 matches
Mail list logo