Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
On Tuesday, June 24, 2014 03:12 CEST, Robert Haas robertmh...@gmail.com wrote: On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark st...@mit.edu wrote: On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas robertmh...@gmail.com wrote: However, we don't know of anyone who has tried to do this in a very long time, and are therefore considering removing the remaining support for the VAX platform. Has anyone tried to build PostgreSQL for VAX lately? Actually I tried a while ago but got stuck configuring the network on simh so I could get all the tools. I can try again if there's interest but we don't necessarily need to keep a port just because there's a simulator for it. That's really up to you. I'm not particularly interested in generating interest in maintaining this port if there wouldn't otherwise be any; I'm trying to figure out whether there is existing interest in it. For all I know, whateverBSD is shipping PostgreSQL binaries for VAX and every other platform they support in each new release and people are using them to get real work done. Then again, for all I know, it doesn't even compile on that platform, and if you did manage to get it to compile it wouldn't fit on the disk, and if you managed to fit it on the disk it wouldn't work because key system calls aren't supported. If someone is still interested in this, I'm hoping they'll help us figure out whether it's anywhere close to working, and maybe even contribute a buildfarm critter. If no one cares, then let's just rip it out and be done with it. I'm building the vax packages for openbsd. What I can 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 I'm currently on vacation, with sparse Internet connectivity. ;) Sebastian -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
On Tuesday, June 24, 2014 13:37 CEST, Sebastian Reitenbach sebas...@l00-bugdead-prods.de wrote: On Tuesday, June 24, 2014 03:12 CEST, Robert Haas robertmh...@gmail.com wrote: On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark st...@mit.edu wrote: On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas robertmh...@gmail.com wrote: However, we don't know of anyone who has tried to do this in a very long time, and are therefore considering removing the remaining support for the VAX platform. Has anyone tried to build PostgreSQL for VAX lately? Actually I tried a while ago but got stuck configuring the network on simh so I could get all the tools. I can try again if there's interest but we don't necessarily need to keep a port just because there's a simulator for it. That's really up to you. I'm not particularly interested in generating interest in maintaining this port if there wouldn't otherwise be any; I'm trying to figure out whether there is existing interest in it. For all I know, whateverBSD is shipping PostgreSQL binaries for VAX and every other platform they support in each new release and people are using them to get real work done. Then again, for all I know, it doesn't even compile on that platform, and if you did manage to get it to compile it wouldn't fit on the disk, and if you managed to fit it on the disk it wouldn't work because key system calls aren't supported. If someone is still interested in this, I'm hoping they'll help us figure out whether it's anywhere close to working, and maybe even contribute a buildfarm critter. If no one cares, then let's just rip it out and be done with it. I'm building the vax packages for openbsd. What I can 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 I'm currently on vacation, with sparse Internet connectivity. ;) OK, that was easy: $ cd /usr/ports/databases/postgresql $ make install === postgresql-client-9.3.4p0 requires shared libraries . OpenBSD VAX is static only, so no postgresql on OpenBSD VAX before shared libraries will ever be made working on it. cheers, Sebastian Sebastian -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency
to database template1 as user kgrittn.
SET
SET
SET
SET
SET
SET
SET
COMMENT
CREATE EXTENSION
COMMENT
REVOKE
REVOKE
GRANT
GRANT
You are now connected to database test as user kgrittn.
SET
SET
SET
SET
SET
SET
SET
CREATE SCHEMA
ALTER SCHEMA
CREATE EXTENSION
COMMENT
SET
SET
SET
CREATE TABLE
ALTER TABLE
CREATE VIEW
ALTER TABLE
SET
SELECT 0
ALTER TABLE
SET
CREATE VIEW
ALTER TABLE
SELECT 0
ALTER TABLE
CREATE VIEW
ALTER TABLE
SELECT 0
ALTER TABLE
SELECT 0
ALTER TABLE
SELECT 0
ALTER TABLE
SELECT 0
ALTER TABLE
ALTER TABLE
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
SET
REFRESH MATERIALIZED VIEW
SET
REFRESH MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
REVOKE
REVOKE
GRANT
GRANT
SET
SET
SET
ERROR: role kgrittn already exists
ALTER ROLE
ALTER DATABASE
REVOKE
REVOKE
GRANT
GRANT
CREATE DATABASE
ALTER DATABASE
You are now connected to database postgres as user kgrittn.
SET
SET
SET
SET
SET
SET
SET
COMMENT
CREATE EXTENSION
COMMENT
REVOKE
REVOKE
GRANT
GRANT
You are now connected to database template1 as user kgrittn.
SET
SET
SET
SET
SET
SET
SET
COMMENT
CREATE EXTENSION
COMMENT
REVOKE
REVOKE
GRANT
GRANT
You are now connected to database test as user kgrittn.
SET
SET
SET
SET
SET
SET
SET
CREATE SCHEMA
ALTER SCHEMA
CREATE EXTENSION
COMMENT
SET
SET
SET
CREATE TABLE
ALTER TABLE
CREATE VIEW
ALTER TABLE
SET
SELECT 0
ALTER TABLE
SET
CREATE VIEW
ALTER TABLE
SELECT 0
ALTER TABLE
CREATE VIEW
ALTER TABLE
SELECT 0
ALTER TABLE
SELECT 0
ALTER TABLE
SELECT 0
ALTER TABLE
SELECT 0
ALTER TABLE
ALTER TABLE
CREATE INDEX
CREATE INDEX
CREATE INDEX
CREATE INDEX
SET
REFRESH MATERIALIZED VIEW
SET
REFRESH MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
REFRESH MATERIALIZED VIEW
REVOKE
REVOKE
GRANT
GRANT
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\Temppg_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
Re: [HACKERS] broken 'SHOW TABLE'-like query works in 8, not 8.1.1
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:52PM -0800, Sebastian wrote: I've waited 10 minutes before cancelling. On pg8 it runs in less than a second How many columns in the table? In 8.1.1 I'm seeing a nearly exponential increase in time with each extra column, at least up to about five columns; with more columns the time continues to increase although not as sharply. I don't see such an increase in 8.0.5. Querying the views individually doesn't take long; I wonder if the planner is doing something wrong with the join operation. -- Michael Fuhr ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] broken 'SHOW TABLE'-like query works in 8, not 8.1.1
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 ideas for a temporary work around? You could try querying the system catalogs directly instead of using the information_schema views; You could also set enable_nestloop to off for your original query. Now that EXPLAIN is fixed it looks like 8.1.1 is choosing a nested loop where a hash join is actually much faster. -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] broken 'SHOW TABLE'-like query works in 8, not 8.1.1
Hi,
I have a query that previously worked fine using pg8 on Fedora. Since
then we've moved to a FreeBSD 6 server running pg8.1.1 and the query
doesn't seem to ever finish.
I have VACUUM ANALYZEd the database. Here is the query:
SELECT column_name, table_schema, table_name, c.data_type,
et.data_type as array_type,
col_description('codes.countries'::regclass,ordinal_position),
c.character_maximum_length
FROM information_schema.columns c
LEFT JOIN information_schema.element_types et
ON et.object_schema = table_schema
AND et.object_name = table_name
AND et.array_type_identifier = c.dtd_identifier
WHERE table_schema='codes' and table_name='countries'
ORDER 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
Re: [HACKERS] broken 'SHOW TABLE'-like query works in 8, not 8.1.1
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: On Thu, Dec 29, 2005 at 11:14:59AM -0800, Sebastian wrote: I have a query that previously worked fine using pg8 on Fedora. Since then we've moved to a FreeBSD 6 server running pg8.1.1 and the query doesn't seem to ever finish. How long did you wait? In one of my tests the query took over three times as long to finish in 8.1.1 as it did in 8.0.5, but it did finish. However, EXPLAIN fails in 8.1.1: test= EXPLAIN SELECT ... ERROR: record type has not been registered Something about the information_schema.element_types view seems to be the problem: test= EXPLAIN SELECT * FROM information_schema.element_types; ERROR: record type has not been registered -- Michael Fuhr ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] broken 'SHOW TABLE'-like query works in 8, not 8.1.1
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 second How many columns in the table? In 8.1.1 I'm seeing a nearly exponential increase in time with each extra column, at least up to about five columns; with more columns the time continues to increase although not as sharply. I don't see such an increase in 8.0.5. Querying the views individually doesn't take long; I wonder if the planner is doing something wrong with the join operation. -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
