On Tuesday, June 24, 2014 13:37 CEST, "Sebastian Reitenbach"
wrote:
> On Tuesday, June 24, 2014 03:12 CEST, Robert Haas
> wrote:
>
> > On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark wrote:
> > > On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas
> > > wro
tell is that
for 5.5 no postgresql packages were built. But that may be that
due to the recent upgrade from gcc 2.95 to 3.3.
I guess that not all dependencies to actually build postgresql
are available for the vax, or may build successfully there. But I need
to verify. Might need a few days, since
> The cluster is created in the state that was dumped, default read
> only flags and all.
>
> Are you saying that you find current behavior acceptable in back
> branches?
>
Here is how this came about.
Installation of PG 8.4 (port 5432) on Windows with default settings.
Creation of a test database
Installation of PG 9.3 on Windows (port 5433) with default settings
Starting up pg_upgrade as postgres
--> fails
c:\Windows\Temp>pg_upgrade.exe --old-datadir "C:/Program Files
(x86)/PostgresPlus/8.4SS/data" --new-datadir "C:/Program Files
(x86)/PostgreSQL/9.3/data" --old-bindir "C:/Program Files
(x86)/PostgresPlus/8.4SS/bin" --new-bindir "C:/Program F
iles (x86)/PostgreSQL/9.3/bin"
SQL command failed
CREATE TEMPORARY TABLE info_rels (reloid) AS SELECT c.oid FROM
pg_catalog.pg_cla
ss c JOIN pg_catalog.pg_namespace nON c.relnamespace = n.oid LEFT
OUTER
JOIN pg_catalog.pg_index i ON c.oid = i.indexrelid WHERE relkind IN
('r'
, 'm', 'i', 'S') AND i.indisvalid IS DISTINCT FROM false AND i.indisready IS
D
ISTINCT FROM false AND ((n.nspname !~ '^pg_temp_' AND n.nspname !~
'^pg_to
ast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema',
'binary_upgrade', 'pg_toast') AND
c.oid >= 16384) OR (n.nspname = 'pg_catalog' AND relname IN
('pg_largeob
ject', 'pg_largeobject_loid_pn_index') ));
ERROR: transaction is read-only
Regards,
Sebastian
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Changing enable_nestloop works great -- I'll use it for now. Thanks all
On 12/30/05, Michael Fuhr <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 30, 2005 at 11:02:20AM -0700, Michael Fuhr wrote:
> > On Fri, Dec 30, 2005 at 03:15:03AM -0500, Sebastian wrote:
> > > Any idea
Any ideas for a temporary work around?
On 12/29/05, Sebastian <[EMAIL PROTECTED]> wrote:
> > How many columns in the table?
>
> There are 4 columns in the table
>
> On 12/29/05, Michael Fuhr <[EMAIL PROTECTED]> wrote:
> > On Thu, Dec 29, 2005 at 12:12:52P
> How many columns in the table?
There are 4 columns in the table
On 12/29/05, Michael Fuhr <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 29, 2005 at 12:12:52PM -0800, Sebastian wrote:
> > I've waited 10 minutes before cancelling. On pg8 it runs in less than a
> > secon
I've waited 10 minutes before cancelling. On pg8 it runs in less than a second
: test=> EXPLAIN SELECT * FROM information_schema.element_types;
: ERROR: record type has not been registered
I can reproduce this...
- sebastian
On 12/29/05, Michael Fuhr <[EMAIL PROTECTED]> wrote:
BY ordinal_position
-- replaces 'codes' and 'countries' with a schema and table that exist
One fellow on IRC using FreeBSD 4.11 and pg8.1.1 can reproduce the problem.
Any suggestions?
Thanks in advance,
sebastian
---(end of broadcast)---
TIP 6: explain analyze is your friend
