Re: initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)

> On Fri, Jun 24, 2016 at 1:28 PM, Craig Ringer
<craig(at)2ndquadrant(dot)com> wrote:

> > I'd like more details from those whose installs are crashing. What exact
> > vcvars env did you run under, with which exact cl.exe version?

This is a Windows server 2012 R2 Standard.
Devenv: Microsoft Visual Studio 2013 Community Version 12.0.31101.0.

Env:

%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\vcvarsall.bat"" x86_amd64

'where cl.exe'

C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\bin\x86_amd64\cl.exe
C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\bin\cl.exe

I have been able to reproduce it on Windows 7 Professional (Service Pack 1
) also with Microsoft Visual Studio 2013 Community Version 12.0.40629.0.

Env:
%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\vcvarsall.bat"" x86_amd64

'Where cl.exe'
C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\bin\x86_amd64\cl.exe
C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\bin\cl.exe

I started with bisect activity between beta2 (bad) and beta1(good) given
that beta1 works fine. Crash occurs at following commit.

commit 100340e2dcd05d6505082a8fe343fb2ef2fa5b2a
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sat Jun 18 15:22:34 2016 -0400

Restore foreign-key-aware estimation of join relation sizes.

This patch provides a new implementation of the logic added by commit
137805f89 and later removed by 77ba61080. It differs from the original
primarily in expending much less effort per joinrel in large queries,
which it accomplishes by doing most of the matching work once per query
not
once per joinrel. Hopefully, it's also less buggy and better commented.
The never-documented enable_fkey_estimates GUC remains gone.

There remains work to be done to make the selectivity estimates account
for nulls in FK referencing columns; but that was true of the original
patch as well. We may be able to address this point later in beta.
In the meantime, any error should be in the direction of overestimating
rather than underestimating joinrel sizes, which seems like the
direction
we want to err in.

Tomas Vondra and Tom Lane
Discussion: <31041(dot)1465069446(at)sss(dot)pgh(dot)pa(dot)us>

This appears consistent with the crash in planner suggested by crash dump
Craig shared.

Tom any ideas on what could be going wrong here ?

Given that it fails on 'setup_description', I tried bypassing that by
commenting it out, it again crashes on 'setup_privileges' and
'setup_schema'.

debug_query_string for setup_privileges:

*INSERT INTO pg_init_privs (objoid, classoid, objsubid, initprivs,
privtype) SELECT oid, (SELECT oid FROM pg_class WHERE
relname = 'pg_class'), 0, relacl, 'i' FROM
pg_class WHERE relacl IS NOT NULL AND relkind IN ('r',
'v', 'm', 'S');INSERT INTO pg_init_privs (objoid, classoid, objsubid,
initprivs, privtype) SELECT pg_class.oid, (SELECT oid FROM
pg_class WHERE relname = 'pg_class'), pg_attribute.attnum,
pg_attribute.attacl, 'i' FROM pg_class JOIN
pg_attribute ON (pg_class.oid = pg_attribute.attrelid) WHERE
pg_attribute.attacl IS NOT NULL AND pg_class.relkind IN ('r', 'v',
'm', 'S');INSERT INTO pg_init_privs (objoid, classoid, objsubid,
initprivs, privtype) SELECT oid, (SELECT oid FROM pg_class
WHERE relname = 'pg_proc'), 0, proacl, 'i' FROM
pg_proc WHERE proacl IS NOT NULL;INSERT INTO pg_init_privs
(objoid, classoid, objsubid, initprivs, privtype) SELECT oid,
(SELECT oid FROM pg_class WHERE relname = 'pg_type'), 0,
typacl, 'i' FROM pg_type WHERE typacl IS NOT
NULL;INSERT INTO pg_init_privs (objoid, classoid, objsubid, initprivs,
privtype) SELECT oid, (SELECT oid FROM pg_class WHERE
relname = 'pg_language'), 0, lanacl, 'i' FROM
pg_language WHERE lanacl IS NOT NULL;INSERT INTO pg_init_privs
(objoid, classoid, objsubid, initprivs, privtype) SELECT oid,
(SELECT oid FROM pg_class WHERE relname = 'pg_largeobject_metadata'),
0, lomacl, 'i' FROM pg_largeobject_metadata
WHERE lomacl IS NOT NULL;INSERT INTO pg_init_privs (objoid,
classoid, objsubid, initprivs, privtype) SELECT oid,
(SELECT oid FROM pg_class WHERE relname = 'pg_namespace'), 0,
nspacl, 'i' FROM pg_namespace WHERE nspacl IS
NOT NULL;INSERT INTO pg_init_privs (objoid, classoid, objsubid,
initprivs, privtype) SELECT oid, (SELECT oid FROM pg_class
WHERE relname = 'pg_database'), 0, datacl, 'i' FROM
pg_database WHERE datacl IS NOT NULL;INSERT INTO
pg_init_privs (objoid, classoid, objsubid, initprivs, privtype) SELECT
oid, (SELECT oid FROM pg_class WHERE relname =
'pg_tablespace'), 0, spcacl, 'i' FROM
pg_tablespace WHERE spcacl IS NOT NULL;INSERT INTO pg_init_privs
(objoid, classoid, objsubid, initprivs, privtype) SELECT oid,
(SELECT oid FROM pg_class WHERE relname = 'pg_foreign_data_wrapper'),
0, fdwacl, 'i' FROM pg_foreign_data_wrapper
WHERE fdwacl IS NOT NULL;INSERT INTO pg_init_privs (objoid,
classoid, objsubid, initprivs, privtype) SELECT oid,
(SELECT oid FROM pg_class WHERE relname = 'pg_foreign_server'), 0,
srvacl, 'i' FROM pg_foreign_server WHERE
srvacl IS NOT NULL;/**
* * SQL Information Schema*
* * as defined in ISO/IEC 9075-11:2011*
* **
* * Copyright (c) 2003-2016, PostgreSQL Global Development Group*
* **
* * src/backend/catalog/information_schema.sql*
* **
* * Note: this file is read in single-user -j mode, which means that the*
* * command terminator is semicolon-newline-newline; whenever the backend*
* * sees that, it stops and executes what it's got. If you write a lot of*
* * statements without empty lines between, they'll all get quoted to you*
* * in any error message about one of them, so don't do that. Also, you*
* * cannot write a semicolon immediately followed by an empty line in a*
* * string literal (including a function body!) or a multiline comment.*
* */*

*/**
* * Note: Generally, the definitions in this file should be ordered*
* * according to the clause numbers in the SQL standard, which is also the*
* * alphabetical order. In some cases it is convenient or necessary to*
* * define one information schema view by using another one; in that case,*
* * put the referencing view at the very end and leave a note where it*
* * should have been put.*
* */*

*/**
* * 5.1*
* * INFORMATION_SCHEMA schema*
* */*

*CREATE SCHEMA information_schema;*
*GRANT USAGE ON SCHEMA information_schema TO PUBLIC;*
*SET search_path TO information_schema;*

debug_query_string for setup_schema:

*INSERT INTO sql_implementation_info VALUES ('10003', 'CATALOG NAME', NULL,
'Y', NULL);*
*INSERT INTO sql_implementation_info VALUES ('10004', 'COLLATING SEQUENCE',
NULL, (SELECT default_collate_name FROM character_sets), NULL);*
*INSERT INTO sql_implementation_info VALUES ('23', 'CURSOR COMMIT
BEHAVIOR', 1, NULL, 'close cursors and retain prepared statements');*
*INSERT INTO sql_implementation_info VALUES ('2', 'DATA SOURCE NAME',
NULL, '', NULL);*
*INSERT INTO sql_implementation_info VALUES ('17', 'DBMS NAME', NULL,
(select trim(trailing ' ' from substring(version() from '^[^0-9]*'))),
NULL);*
*INSERT INTO sql_implementation_info VALUES ('18', 'DBMS VERSION', NULL,
'???', NULL); -- filled by initdb*
*INSERT INTO sql_implementation_info VALUES ('26', 'DEFAULT TRANSACTION
ISOLATION', 2, NULL, 'READ COMMITTED; user-settable');*
*INSERT INTO sql_implementation_info VALUES ('28', 'IDENTIFIER CASE', 3,
NULL, 'stored in mixed case - case sensitive');*
*INSERT INTO sql_implementation_info VALUES ('85', 'NULL COLLATION', 0,
NULL, 'nulls higher than non-nulls');*
*INSERT INTO sql_implementation_info VALUES ('13', 'SERVER NAME', NULL,
'', NULL);*
*INSERT INTO sql_implementation_info VALUES ('94', 'SPECIAL CHARACTERS',
NULL, '', 'all non-ASCII characters allowed');*
*INSERT INTO sql_implementation_info VALUES ('46', 'TRANSACTION
CAPABLE', 2, NULL, 'both DML and DDL');*

And if I comment these out i.e. setup_description, setup_privileges and
'setup_schema' it seem to progress well without any errors/crashes.

Regards,
Haroon

--
Haroon http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services