Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)
seWHEREdatacl 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_tablespaceWHEREspcacl IS NOT NULL;INSERT INTO pg_init_privs
(objoid, classoid, objsubid, initprivs, privtype)SELECToid,
(SELECT oid FROM pg_class WHERE relname = 'pg_foreign_data_wrapper'),
0,fdwacl,'i'FROMpg_foreign_data_wrapper
WHEREfdwacl IS NOT NULL;INSERT INTO pg_init_privs (objoid,
classoid, objsubid, initprivs, privtype)SELECToid,
(SELECT oid FROM pg_class WHERE relname = 'pg_foreign_server'),0,
srvacl,'i'FROMpg_foreign_serverWHERE
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
--
Haroonhttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)
On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote: >> I was helping Haroon with this last night. I don't have access to the >> original thread and he's not around so I don't know how much he said. I'll >> repeat our findings here. Craig, I am around now looking into this. I'll update the list as I get more info. - Haroon On 24 June 2016 at 11:27, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, Jun 24, 2016 at 3:22 PM, Craig Ringer <cr...@2ndquadrant.com> > wrote: > > > > > > On 24 June 2016 at 10:28, Michael Paquier <michael.paqu...@gmail.com> > wrote: > >> > >> On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer <cr...@2ndquadrant.com> > >> wrote: > >> > * Launch a VS x86 command prompt > >> > * devenv /debugexe bin\initdb.exe -D test > >> > * Set a breakpoint in initdb.c:3557 and initdb.c:3307 > >> > * Run > >> > * When it traps at get_restricted_token(), manually move the > execution > >> > pointer over the setup of the restricted execution token by dragging & > >> > dropping the yellow instruction pointer arrow. Yes, really. Or, > y'know, > >> > comment it out and rebuild, but I was working with a supplied binary. > >> > * Continue until next breakpoint > >> > * Launch process explorer and find the pid of the postgres child > >> > process > >> > * Debug->attach to process, attach to the child postgres. This > doesn't > >> > detach the parent, VS does multiprocess debugging. > >> > * Continue execution > >> > * vs will trap on the child when it crashes > >> > >> Do you think a crash dump could have been created by creating > >> crashdumps/ in PGDATA as part of initdb before this query is run? > > > > > > > > The answer is "yes" btw. Add "crashdumps" to the static array of > directories > > created by initdb and it works great. > > As simple as attached.. > > > Sigh. It'd be less annoying if I hadn't written most of the original > patch. > > You mean the patch that created the crashdumps/ trick? This has saved > me a couple of months back to analyze a problem TBH. > -- > Michael > -- Haroonhttp://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)
On Sat, Jun 25, 2016 at 6:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> If that is the explanation, I'm suspicious that it's got something to do
> with the interaction of a static inline-able (single-call-site) function
> and taking the address of a formal parameter. We certainly have multiple
> other instances of each thing, but maybe not both at the same place.
> This leads to a couple of suggestions for dodging the problem:
>
> 2. Don't pass the original formal parameter to
> get_foreign_key_join_selectivity, ie do something like
>
> static double
> calc_joinrel_size_estimate(PlannerInfo *root,
>RelOptInfo *outer_rel,
>RelOptInfo *inner_rel,
>double outer_rows,
>double inner_rows,
>SpecialJoinInfo *sjinfo,
> - List *restrictlist)
> + List *orig_restrictlist)
> {
> JoinTypejointype = sjinfo->jointype;
> + List *restrictlist = orig_restrictlist;
> Selectivity fkselec;
> Selectivity jselec;
> Selectivity pselec;
>
>
The problem appears to be related to 'taking the address of a formal
parameter'. NOT passing the original formal parameter to
get_foreign_key_join_selectivity fixes it (dodges the problem) on VS2013.
Resulting binaries seem to work fine as initdb doesn't experience child
process crash anymore. 'vcregress check' does not report any failures also.
Anyways, We have decided to use VS2015 tool chain for 9.6beta2 release.
Thanks everyone for the valuable input and help. Appreciate it!
Regards,
Haroon
--
Haroonhttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)
I have been running bisect, it breaks at this commit: *commit 100340e2dcd05d6505082a8fe343fb2ef2fa5b2a* *Author: Tom Lane <t...@sss.pgh.pa.us <t...@sss.pgh.pa.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.1465069...@sss.pgh.pa.us> -- Haroonhttp://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services On Fri, Jun 24, 2016 at 12:19 PM, Haroon Muhammad <contact.mhar...@gmail.com > wrote: > On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer > <craig(at)2ndquadrant(dot)com> wrote: > > >> I was helping Haroon with this last night. I don't have access to the > >> original thread and he's not around so I don't know how much he said. > I'll > >> repeat our findings here. > > Craig, I am around now looking into this. I'll update the list as I get > more info. > > Apparently my previous message (this same text ) didn't make it through ... > > > -- Haroon > >
Re: [HACKERS] initdb issue on 64-bit Windows - (Was: [pgsql-packagers] PG 9.6beta2 tarballs are ready)
On Fri, Jun 24, 2016 at 11:21 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote: >> I was helping Haroon with this last night. I don't have access to the >> original thread and he's not around so I don't know how much he said. I'll >> repeat our findings here. Craig, I am around now looking into this. I'll update the list as I get more info. Apparently my previous message (this same text ) didn't make it through ... -- Haroon
