Re: [HACKERS] pl/perl extension fails on Windows

[Sandeep Thakkar]

Hi

On Thu, Aug 10, 2017 at 9:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Ashutosh Sharma <ashu.coe...@gmail.com> writes:
> > On Thu, Aug 10, 2017 at 8:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> Yeah ... however, if that's there, then there's something wrong with
> >> Ashutosh's explanation, because that means we *are* building with
> >> _USE_32BIT_TIME_T in 32-bit builds.  It's just getting there in a
> >> roundabout way.  (Or, alternatively, this code is somehow not doing
> >> anything at all.)
>
> > I am extremely sorry if i have communicated the things wrongly, what i
> > meant was we are always considering _USE_32BIT_TIME_T flag to build
> > plperl module on Windows 32-bit platform but unfortunately that is not
> > being considered/defined in perl code in case we use VC++ compiler
> > version greater than 8.0. and that's the reason for the binary
> > mismatch error on 32 bit platform.
>
> Got it.  So in short, it seems like the attached patch ought to fix it
> for MSVC builds.  (We'd also need to teach PGAC_CHECK_PERL_EMBED_CCFLAGS
> to let _USE_32BIT_TIME_T through on Windows, but let's confirm the theory
> first.)
>
> We built the sources with this patch and were able to create the plperl
extension on Windows 32bit and 64bit.


> regards, tom lane
>
>


-- 
Sandeep Thakkar
EDB

Re: [HACKERS] pl/perl extension fails on Windows

[Sandeep Thakkar]

Hi

An update from beta3 build: We are no longer seeing this issue (handshake
failure) on Windows 64bit, but on Windows 32bit it still persists.

On Mon, Jul 31, 2017 at 10:15 PM, Christoph Berg <m...@debian.org> wrote:

> Re: Tom Lane 2017-07-31 <30582.1501508...@sss.pgh.pa.us>
> > Christoph Berg <m...@debian.org> writes:
> > >>> The only interesting line in log/postmaster.log is a
> log_line_prefix-less
> > >>> Util.c: loadable library and perl binaries are mismatched (got
> handshake key 0xd500080, needed 0xd600080)
> >
> > Can we see the Perl-related output from configure, particularly the new
> > lines about CFLAGS?
>
> $ ./configure --with-perl
>
> checking whether to build Perl modules... yes
>
> checking for perl... /usr/bin/perl
> configure: using perl 5.26.0
> checking for Perl archlibexp... /usr/lib/x86_64-kfreebsd-gnu/perl/5.26
> checking for Perl privlibexp... /usr/share/perl/5.26
> checking for Perl useshrplib... true
> checking for CFLAGS recommended by Perl... -D_REENTRANT -D_GNU_SOURCE
> -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
> checking for CFLAGS to compile embedded Perl... -DDEBIAN
> checking for flags to link embedded Perl...   -fstack-protector-strong
> -L/usr/local/lib  -L/usr/lib/x86_64-kfreebsd-gnu/perl/5.26/CORE -lperl
> -ldl -lm -lpthread -lc -lcrypt
>
> checking for perl.h... yes
> checking for libperl... yes
>
> Christoph
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>



-- 
Sandeep Thakkar
EDB

Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS

[Sandeep Thakkar]

On Thu, Jul 13, 2017 at 8:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Sandeep Thakkar <sandeep.thak...@enterprisedb.com> writes:
> > On Thu, Jul 13, 2017 at 12:44 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> and this is evidently because the libraries themselves don't know where
> >> they live:
> >> $ otool -D /usr/local/icu-57.1/lib/libicui18n.57.dylib
> >> /usr/local/icu-57.1/lib/libicui18n.57.dylib:
> >> libicui18n.57.dylib
>
> > Right. I got that and I fixed the names and loader_paths for ICU libs and
> > postgres and that is why initdb in my case got going and didn't complain
> > about library not found.
>
> Uh, so what did you do *exactly*?
>
> I changed the id and the loader_paths for ICU libs and also changed the
install name of ICU libs on postgres binary
$ otool -L postgres  | grep icu
@loader_path/../lib/libicuuc.57.dylib (compatibility version 57.0.0,
current version 57.1.0)
@loader_path/../lib/libicui18n.57.dylib (compatibility version 57.0.0,
current version 57.1.0)


> >> I can make it work by setting DYLD_LIBRARY_PATH:
> >> $ DYLD_LIBRARY_PATH=/usr/local/icu-57.1/lib initdb
> >> ... goes through normally ...
>
> > You mean you are able to initialize cluster after this? Or you just
> > executed initdb and found that it doesn't complain about ICU lib
> location?
>
> initdb completed successfully.  I didn't try running any tests beyond
> that; I'm not sure that we have any regression tests that will exercise
> ICU locales.
>
> OK. I'll check at my end then.


> > As mentioned above instead of using DYLD_LIBRARY_PATH, I fixed the
> > loader_paths and am able to execute initdb and postgres binaries:
> > But, initdb -D data fails with error code "U_FILE_ACCESS_ERROR".
>
> Yeah, but notice that only two of the three interesting ICU libraries
> are actually linked into the postgres executable so far as otool and
> the dynamic linker are concerned.  I suspect that the other one,
> libicudata, is dynamically loaded by the ICU code --- and in your
> configuration it fails to find that library.  The error message is
> not definitive that that's what's happening, but it's suggestive.
> If that's the right interpretation, it means that setting
> DYLD_LIBRARY_PATH allows that third library to be found, but whatever
> you did doesn't.
>
> Yeah, I observed that otool -L lists only two of three ICU libs. But not
sure why it doesn't load the third one in my case. Here is the otool -D and
otool -L output on ICU libs:
$ otool -D ../lib/libicuuc.dylib
../lib/libicuuc.dylib:
libicuuc.57.dylib

$ otool -L ../lib/libicuuc.dylib
../lib/libicuuc.dylib:
libicuuc.57.dylib (compatibility version 57.0.0, current version 57.1.0)
@loader_path/../lib/libicudata.57.dylib (compatibility version 57.0.0,
current version 57.1.0)

$ otool -D ../lib/libicui18n.dylib
../lib/libicui18n.dylib:
libicui18n.57.dylib

$ otool -L ../lib/libicui18n.dylib
../lib/libicui18n.dylib:
libicui18n.57.dylib (compatibility version 57.0.0, current version 57.1.0)
@loader_path/../lib/libicuuc.57.dylib (compatibility version 57.0.0,
current version 57.1.0)
@loader_path/../lib/libicudata.57.dylib (compatibility version 57.0.0,
current version 57.1.0)

$ otool -D ../lib/libicudata.dylib
../lib/libicudata.dylib:
libicudata.57.dylib

$ otool -L ../lib/libicudata.dylib
../lib/libicudata.dylib:
libicudata.57.dylib (compatibility version 57.0.0, current version 57.1.0)


> I still think that this represents under-engineering by the ICU crew
> and not anything we're doing wrong.
>
> BTW, when I skimmed the "readme.html" docs in the ICU sources this
> morning, I noted that there were multiple ways you could configure
> it to find the ICU data.  I did not read in detail, figuring that
> their default configuration would be sane, but maybe that was an
> overly charitable assumption.
>
> Sure, thanks for checking this out. It seems the issue is with ICU and
something I did which is why the libicudata.dylib is not able to load. I'll
dig deeper. Thanks for your help.


> regards, tom lane
>



-- 
Sandeep Thakkar
EDB

Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS

[Sandeep Thakkar]

On Thu, Jul 13, 2017 at 12:44 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Sandeep Thakkar <sandeep.thak...@enterprisedb.com> writes:
> > On Wed, Jul 12, 2017 at 8:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >> Ugh.  Please provide details about the hand-built ICU --- what version,
> >> what configure options did you use for it, etc.
>
> > I tried with ICU 53.1 and 57.1 and the results is same.
> > There was no configure options other than --prefix.
>
> Well, when I try that on macOS, I get an ICU installation that's basically
> nonfunctional, apparently because they forgot to specify -install_name
> while linking the dylibs.  The symptom looks a bit different:
>
> $ initdb
> dyld: Library not loaded: libicui18n.57.dylib
>   Referenced from: /Users/tgl/testversion/bin/postgres
>   Reason: image not found
>
> but it's clear from otool that the dynamic linker doesn't know where
> to find the ICU libraries:
>
> $ otool -L ~/testversion/bin/postgres
> /Users/tgl/testversion/bin/postgres:
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1238.60.2)
> libicui18n.57.dylib (compatibility version 57.0.0, current version
> 57.1.0)
> libicuuc.57.dylib (compatibility version 57.0.0, current version
> 57.1.0)
>
> and this is evidently because the libraries themselves don't know where
> they live:
>
> $ otool -D /usr/local/icu-57.1/lib/libicui18n.57.dylib
> /usr/local/icu-57.1/lib/libicui18n.57.dylib:
> libicui18n.57.dylib
>
> Right. I got that and I fixed the names and loader_paths for ICU libs and
postgres and that is why initdb in my case got going and didn't complain
about library not found.


> Compare to what you get for a properly built dylib:
>
> $ otool -D /usr/local/ssl-1.1.0e/lib/libssl.1.1.dylib
> /usr/local/ssl-1.1.0e/lib/libssl.1.1.dylib:
> /usr/local/ssl-1.1.0e/lib/libssl.1.1.dylib
>
> I can make it work by setting DYLD_LIBRARY_PATH:
>
> $ DYLD_LIBRARY_PATH=/usr/local/icu-57.1/lib initdb
> ... goes through normally ...
>
> You mean you are able to initialize cluster after this? Or you just
executed initdb and found that it doesn't complain about ICU lib location?
As mentioned above instead of using DYLD_LIBRARY_PATH, I fixed the
loader_paths and am able to execute initdb and postgres binaries:
$ ./initdb -V
initdb (PostgreSQL) 10beta2

$ ./postgres -V
postgres (PostgreSQL) 10beta2

But, initdb -D data fails with error code "U_FILE_ACCESS_ERROR".


> but that hardly qualifies as a production-grade solution.
>
> I've not dug into the ICU sources to see what it would take to get the
> correct link option applied.  But the short answer seems to be that ICU
> is not up to speed for installation in non-default locations on macOS.
>
> For the record's sake, I configured icu4c-57_1-src.tgz like this:
>
> $ ./runConfigureICU MacOSX --prefix=/usr/local/icu-57.1
>
> and since there's no pkg-config on this machine, I did this to
> configure Postgres:
>
> $ ICU_CFLAGS=" " ICU_LIBS="-licui18n -licuuc -licudata" ./configure [usual
> options] --with-icu --with-includes=/usr/local/icu-57.1/include
> --with-libraries=/usr/local/icu-57.1/lib
>
> It's possible that if I did have pkg-config installed, it would have
> produced some different value for ICU_LIBS, but I rather doubt it.
> I'm not sure that it's possible to fix this on the consumer executable's
> link line anyway.
>
> yes, we use the same flags during configure.


> regards, tom lane
>



-- 
Sandeep Thakkar
EDB

Re: [HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS

[Sandeep Thakkar]

On Wed, Jul 12, 2017 at 8:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Sandeep Thakkar <sandeep.thak...@enterprisedb.com> writes:
> > On MacOS, I configured PG10 beta2 sources with '--with-icu" option along
> > with ICU_LIBS and ICU_CFLAGS env variables to define the location of the
> > ICU libs that I built. Once the staging is ready, I executed initdb but
> it
> > fails with the following error:
> > [53618] FATAL:  could not open collator for locale "und":
> > U_FILE_ACCESS_ERROR*
> > *2017-07-12 11:18:21.187 BST [53618] STATEMENT:  SELECT
> > pg_import_system_collations('pg_catalog');*
>
> Ugh.  Please provide details about the hand-built ICU --- what version,
> what configure options did you use for it, etc.
>
> I tried with ICU 53.1 and 57.1 and the results is same.
There was no configure options other than --prefix. In environment,
CXXFLAGS was set to "-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
-mmacosx-version-min=10.7 -arch i386 -arch x86_64"


regards, tom lane
>



-- 
Sandeep Thakkar
EDB

[HACKERS] pl/perl extension fails on Windows

[Sandeep Thakkar]

Hi,

I compiled PG 10 beta1/beta2 with "--with-perl" option on Windows and the
extension crashes the database.
--
postgres=# create extension plperl;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
postgres=#

It doesn't produce crashdump (in $DATA/crashdumps) but the log contains the
following error:

*src/pl/plperl/Util.c: loadable library and perl binaries are mismatched
(got handshake key 0A900080, needed 0AC80080)*
--

This is seen with Perl 5.24 but not with 5.20, 5.16. What I found is that
the handshake function is added in Perl 5.21.x and probably that is why we
don't see this issue in earlier versions.

The Perl that is used during compilation and on the target machine is same.
So probably plperl is not able to load the perl library. It works fine on
Linux and MacOS.

-- 
Sandeep Thakkar
EDB

[HACKERS] PostgreSQL10 beta2 with ICU - initdb fails on MacOS

[Sandeep Thakkar]

Hi

On MacOS, I configured PG10 beta2 sources with '--with-icu" option along
with ICU_LIBS and ICU_CFLAGS env variables to define the location of the
ICU libs that I built. Once the staging is ready, I executed initdb but it
fails with the following error:
--
$./initdb -D /tmp/data
The files belonging to this database system will be owned by user
"buildfarm".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory /tmp/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
*performing post-bootstrap initialization ... 2017-07-12 11:18:21.187 BST
[53618] FATAL:  could not open collator for locale "und":
U_FILE_ACCESS_ERROR*
*2017-07-12 11:18:21.187 BST [53618] STATEMENT:  SELECT
pg_import_system_collations('pg_catalog');*
child process exited with exit code 1
initdb: removing data directory "/tmp/data"
--

Has anyone came across this? This error is not seen on Linux and Windows
though.

-- 
Sandeep Thakkar
EDB

Re: [HACKERS] Patch - Tcl 8.6 version support for PostgreSQL

[Sandeep Thakkar]

On Tue, Apr 25, 2017 at 1:59 AM, Dave Page <dp...@pgadmin.org> wrote:

>
>
> On Mon, Apr 24, 2017 at 9:26 PM, Andres Freund <and...@anarazel.de> wrote:
>
>> On 2017-04-24 16:18:30 -0400, Robert Haas wrote:
>> > On Sat, Apr 22, 2017 at 1:58 PM, Sandeep Thakkar <
>> > sandeep.thak...@enterprisedb.com> wrote:
>> >
>> > > Tcl8.6 is already supported in PostgreSQL.
>> > >
>> >
>> > What commit added support for it?
>>
>> I don't think the main build mechanism requires explicit support of new
>> versions. configure just checks for some prerequisites.
>>
>
> Right - and they were adjusted here: https://git.postgresql.o
> rg/gitweb/?p=postgresql.git;a=commit;h=eaba54c20c5ab2cb6aaff
> a57fd4990dfe2c7
>
> Right and it was back-patched till 9.2. But, it missed the changes
required for Windows build. So, can anyone please review those two patches
i.e Mkvcbuild_Tcl86_94-92.patch and Mkvcbuild_Tcl86_95-master.patch and
commit? With this patch, we could build the server with Tcl8.6 on Windows.
Thanks!



> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>



-- 
Sandeep Thakkar
EDB

Re: [HACKERS] Patch - Tcl 8.6 version support for PostgreSQL

[Sandeep Thakkar]

Tcl8.6 is already supported in PostgreSQL. It was just missing the required
changes for Windows build system. Can someone please review and commit the
attached patches?

- Mkvcbuild_Tcl86_94-92.patch (This applies to 9.4, 9.3 and 9.2)
- Mkvcbuild_Tcl86_95-master.patch (This applies to 9.5, 9.6 and master)

Thanks.

On Thu, Apr 20, 2017 at 2:02 PM, Paresh More <paresh.m...@enterprisedb.com>
wrote:

> Hello Team
>
> This is regarding Tcl version (8.6) support in PostgreSQL.
>
> Currently in PostgreSQL server file  (src/tools/msvc/Mkvcbuild.pm) it
> supports only till Tcl version 8.5
>
> Attach patch contains adding Tcl 8.6 support.
>
>
> Please Note - In Tcl8.6, the library name now contains an extra 't" in
> it.
> Tcl 8.6 - tcl86t.lib
> Tcl 8.5 - tcl85.lib
>
> Can you please review the patch and commit for PostgreSQL.
>
>
> --
>
> Thanks & Regards
>
> *Paresh More*
>
> [image: NEW-EDB-logo-4c]
>
> Pune, India.
>



-- 
Sandeep Thakkar
EDB


Mkvcbuild_Tcl86_94-92.patch
Description: Binary data


Mkvcbuild_Tcl86_95-master.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Include ppc64le build type for back branches

[Sandeep Thakkar]

Hi

We have registered two new buildfarm animals for RHEL 7 on PPC64 and
PPC64LE (Little Endian). The configure for 9.3, 9.2 and 9.1 failed on
ppc64le with the error "error: cannot guess build type; you must specify
one". This is because config.guess for these branches don't expect the arch
to be ppc64le (case statement). When I passed the build type as
"powerpc64le-unknown-linux-gnu" to the configure script, the build is
successful.

So, config.guess should be changed to include the build type for ppc64le
like it is in 9.4+ branches.

-- 
Sandeep Thakkar

Re: [HACKERS] Include ppc64le build type for back branches

[Sandeep Thakkar]

Hi Tom

With --build=powerpc64le-unknown-linux-gnu in the config_opts section
of build-farm.conf,
the build and the regression were successful.

Well, by the time the decision is made on this, I have enabled only 9.4+
runs on ppc64le. The results from this buildfarm member 'clam' are now
being reported.

On Wed, Dec 9, 2015 at 12:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:

> Robert Haas <robertmh...@gmail.com> writes:
> > I don't really want to get into an argument about this, but is the
> > reason we haven't updated config.guess and config.sub in the past that
> > it presents an actual stability risk, or just that nobody's asked
> > before?  Because the first one is a good reason not to do it now, but
> > the second one isn't.
>
> Well, I see at least one case in the git history where we explicitly
> declined to update config.guess/config.sub:
>
> Author: Tom Lane <t...@sss.pgh.pa.us>
> Branch: master Release: REL9_3_BR [5c7603c31] 2013-06-04 15:42:02 -0400
> Branch: REL9_2_STABLE Release: REL9_2_5 [612ecf311] 2013-06-04 15:42:21
> -0400
>
> Add ARM64 (aarch64) support to s_lock.h.
>
> Use the same gcc atomic functions as we do on newer ARM chips.
> (Basically this is a copy and paste of the __arm__ code block,
> but omitting the SWPB option since that definitely won't work.)
>
> Back-patch to 9.2.  The patch would work further back, but we'd also
> need to update config.guess/config.sub in older branches to make them
> build out-of-the-box, and there hasn't been demand for it.
>
> Mark Salter
>
>
> More generally, I think "does updating config.guess, in itself, pose
> a stability risk" is a false statement of the issue.  The real issue is
> do we want to start supporting a new platform in 9.1-9.3; that is, IMO
> if we accept this request then we are buying into doing *whatever is
> needed* to support ppc64le on those branches.  Maybe that will stop with
> config.guess/config.sub, or maybe it won't.
>
> Setting this precedent will also make it quite hard to reject future
> requests to back-patch support for other new platforms.
>
> I'm not planning to go to war about this issue either.  But I do think
> there's a slippery-slope hazard here, and we should be prepared for
> the logical consequences of accepting such a request.  Or if we're
> going to have a policy allowing this request but not every such request,
> somebody had better enunciate what that policy is.
>
> regards, tom lane
>
> (BTW, so far as direct stability hazards go, I would guess that the
> key question is how much version skew can be tolerated between autoconf
> and config.guess/config.sub. I have no idea about that; Peter E. might.
> But I do note that pre-9.4 branches use an older autoconf version.)
>



-- 
Sandeep Thakkar

Re: [HACKERS] anole - test case sha2 fails on all branches

[Sandeep Thakkar]

Hi Noah

The build at commit 36e5247 also failed. With new buildfarm client 4.15, we
used additional configure options like --with-gssapi -with-libxml
--with-libxml --with-ldap --with-libxslt . The build at commit 36e5247 and
last commit is successful without these options. I'll check which of these
libs is causing an issue and if updating it resolves it.

Thanks.

On Fri, Apr 24, 2015 at 7:55 AM, Noah Misch n...@leadboat.com wrote:

 On Thu, Apr 23, 2015 at 10:54:45AM -0400, Tom Lane wrote:
  I wrote:
   Given that anole is the only one reporting this, I'm not sure that we
   should immediately blame Postgres itself.  I have a vague recollection
   that we've seen this symptom before and traced it to a bug in some
   supporting library.  Is anole using any particularly out-of-date
 versions
   of openssl, kerberos, etc?
 
  A bit of digging in the archives suggests that my hindbrain remembered
 this:
  http://www.postgresql.org/message-id/flat/4f5a8404.8020...@dunslane.net
 
  The specifics probably don't apply to anole, but the conclusion that
  inconsistent openssl header and library files triggered the bug might.

 A library problem is plausible.  anole builds without OpenSSL, and I have
 no
 guess for which remaining library could be at fault.  I could not reproduce
 this in an HP-UX IA-64 build configured as follows (no HP compiler
 available):
   ./configure --enable-debug --enable-cassert --enable-depend
 --without-readline --without-zlib CC='gcc -pthread -mlp64'

 Sandeep, I suggest trying a build at commit 36e5247, the last REL9_4_STABLE
 commit known good on anole.  If that build fails, you'll know there's an
 environmental problem, like a broken dependency library.  If that build
 succeeds, please use git bisect to find which commit broke things, and
 report the commit hash here.

 Thanks,
 nm




-- 
Sandeep Thakkar

[HACKERS] anole - test case sha2 fails on all branches

[Sandeep Thakkar]

Hi,

The test case sha2 in contrib pgcrypto module is failing with a diff on
anole because the results file contains the additional lines as:
--

+ WARNING:  detected write past chunk end in ExprContext 6021cbb0

--

Ex:
The log for REL9_2_STABLE can be seen at
http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=anoledt=2015-04-23%2009%3A00%3A25stg=contrib-install-check-C


-- 
Sandeep Thakkar

Re: [HACKERS] Compiling extensions on Windows

[Sandeep Thakkar]

Sure. I'll make the changes so that the next available Windows installers
include lbintl.h in $Installdir/include. How about the changes with respect
to NLS?


On Mon, Jan 6, 2014 at 2:44 PM, Dave Page dp...@pgadmin.org wrote:

 On Mon, Jan 6, 2014 at 3:32 AM, Craig Ringer cr...@2ndquadrant.com
 wrote:
  Hi all
 
  Out of personal interest (in pain and suffering) I was recently looking
  into how to compile extensions out-of-tree on Windows using Visual
  Studio (i.e. no PGXS).
 
  It looks like the conventional answer to this is Do a source build of
  PG, compile your ext in-tree in contrib/, and hope the result is binary
  compatible with release PostgreSQL builds for Windows. Certainly that's
  how I've been doing it to date.
 
  How about everyone else here? Does anyone actually build and distribute
  extensions out of tree at all?
 
  I'm interested in making the Windows installer distributions a bit more
  extension dev friendly. In particular, I'd really like to see EDB's
  Windows installers include the libintl.h for the included libintl, since
  its omission, combined with Pg being built with ENABLE_NLS, tends to
  break things horribly. Users can always undefine ENABLE_NLS, but it's an
  unnecessary roadblock.

 Sandeep, can you work on fixing this please?

 Thanks.

  Are there any objections from -hackers to including 3rd party headers
  for libs we expose in our public headers in the binary distribution?
 
  Other than bundling 3rd party headers, any ideas/suggestions for how we
  might make ext building saner on Windows?
 
  --
   Craig Ringer   http://www.2ndQuadrant.com/
   PostgreSQL Development, 24x7 Support, Training  Services
 
 
  --
  Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
  To make changes to your subscription:
  http://www.postgresql.org/mailpref/pgsql-hackers



 --
 Dave Page
 Blog: http://pgsnake.blogspot.com
 Twitter: @pgsnake

 EnterpriseDB UK: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company




-- 
Sandeep Thakkar

Re: [HACKERS] Compiling extensions on Windows

[Sandeep Thakkar]

Okay.

BTW, I just checked that Windows 32bit installer ships the libintl.h. Did
you try if it works for you? Or it requires more headers? Somehow, Windows
64bit installer installer missed it. I'll fix the build script.


On Mon, Jan 6, 2014 at 4:55 PM, Craig Ringer cr...@2ndquadrant.com wrote:

 If libintl.h and any headers it in turn includes are bundled, there is no
 longer an issue with NLS.

 That was just a workaround for building exts when Pg's headers tried to
 refer to nonexistent headers when NLS was enabled.
 On 6 Jan 2014 18:57, Sandeep Thakkar sandeep.thak...@enterprisedb.com
 wrote:

 Sure. I'll make the changes so that the next available Windows installers
 include lbintl.h in $Installdir/include. How about the changes with respect
 to NLS?


 On Mon, Jan 6, 2014 at 2:44 PM, Dave Page dp...@pgadmin.org wrote:

 On Mon, Jan 6, 2014 at 3:32 AM, Craig Ringer cr...@2ndquadrant.com
 wrote:
  Hi all
 
  Out of personal interest (in pain and suffering) I was recently looking
  into how to compile extensions out-of-tree on Windows using Visual
  Studio (i.e. no PGXS).
 
  It looks like the conventional answer to this is Do a source build of
  PG, compile your ext in-tree in contrib/, and hope the result is binary
  compatible with release PostgreSQL builds for Windows. Certainly that's
  how I've been doing it to date.
 
  How about everyone else here? Does anyone actually build and distribute
  extensions out of tree at all?
 
  I'm interested in making the Windows installer distributions a bit more
  extension dev friendly. In particular, I'd really like to see EDB's
  Windows installers include the libintl.h for the included libintl, since
  its omission, combined with Pg being built with ENABLE_NLS, tends to
  break things horribly. Users can always undefine ENABLE_NLS, but it's an
  unnecessary roadblock.

 Sandeep, can you work on fixing this please?

 Thanks.

  Are there any objections from -hackers to including 3rd party headers
  for libs we expose in our public headers in the binary distribution?
 
  Other than bundling 3rd party headers, any ideas/suggestions for how we
  might make ext building saner on Windows?
 
  --
   Craig Ringer   http://www.2ndQuadrant.com/
   PostgreSQL Development, 24x7 Support, Training  Services
 
 
  --
  Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
  To make changes to your subscription:
  http://www.postgresql.org/mailpref/pgsql-hackers



 --
 Dave Page
 Blog: http://pgsnake.blogspot.com
 Twitter: @pgsnake

 EnterpriseDB UK: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company




 --
 Sandeep Thakkar




-- 
Sandeep Thakkar

Re: [HACKERS] PostgreSQL Service on Windows does not start. ~ is not a valid Win32 application

[Sandeep Thakkar]

Services are started with the system privileges. If somebody is able to
place that .exe in the specified directory, then it will be executed on
service start. So, yes, I too agree with Asif that it is an important issue
and should be fixed in the code at the earliest.


On Thu, Oct 31, 2013 at 11:14 AM, Asif Naeem anaeem...@gmail.com wrote:

 On Thu, Oct 31, 2013 at 10:17 AM, Amit Kapila amit.kapil...@gmail.comwrote:

 On Tue, Oct 29, 2013 at 12:46 PM, Naoya Anzai
 anzai-na...@mxu.nes.nec.co.jp wrote:
  Hi Sandeep
 
  I think, you should change the subject line  to Unquoted service path
 containing space is vulnerable and can be exploited on Windows to get the
 attention..  :)
  Thank you for advice!
  I'll try to post to pgsql-bugs again.

 I could also reproduce this issue. The situation is very rare such
 that an exe with name same as first part of directory should exist
 in installation path.


 I believe it is a security risk with bigger impact as it is related to
 Windows environment and as installers rely on it.


 I suggest you can post your patch in next commit fest.


 Yes. Are not vulnerabilities/security risk's taken care of more urgent
 bases ?


 With Regards,
 Amit Kapila.
 EnterpriseDB: http://www.enterprisedb.com





-- 
Sandeep Thakkar


Phone: +91.20.30589505

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

Re: [HACKERS] PostgreSQL Service on Windows does not start. ~ is not a valid Win32 application

[Sandeep Thakkar]

Hi Naoya

I think, you should change the subject line  to Unquoted service path
containing space is vulnerable and can be exploited on Windows to get the
attention..  :)

BTW, in your case, the file Program should be an exe and not just any
other file to exploit this vulnerability. Right?


On Tue, Oct 29, 2013 at 11:34 AM, Naoya Anzai anzai-na...@mxu.nes.nec.co.jp
 wrote:

 Hi,Sandeep

 Thanks.

 Sorry, There was a mistake in what I said.

 I said
Not only pg_ctl.exe but postgres.exe also have the same
 problem.
 but, to say it correctly,

 postgres.exe does not have the problem.
 Source that contains the problem is only pg_ctl.c.

  So, this is not an installer issue. Is this bug raised to the PostgreSQL
 community? If yes, you should submit the patch there.
 YES, I had submitted there already,But nobody has responded me yet.


 http://postgresql.1045698.n5.nabble.com/PostgreSQL-Service-on-Windows-does-not-start-td5774206.html

 Regards,
 Naoya

  So, this is not an installer issue. Is this bug raised to the PostgreSQL
 community? If yes, you should submit the patch there.
 
 
  On Tue, Oct 29, 2013 at 6:23 AM, Naoya Anzai 
 anzai-na...@mxu.nes.nec.co.jp wrote:
 
 
Hi, Asif
 
Thank you for providing my patch (pg_ctl.c.patch) to Sandeep on my
 behalf.
 
 
 Good finding. I have attached another version of patch
 (pg_ctl.c_windows_vulnerability.patch) attached that has fewer lines of
 code changes, can you please take a look ?. Thanks.
 
 
I think your patch is not sufficient to fix.
Not only pg_ctl.exe but postgres.exe also have the same
 problem.
Even if your patch is attached,
A Path of postgres.exe passed to CreateRestrictedProcess is not
 enclosed in quotation.(See pgwin32_ServiceMain at pg_ctl.c)
 
So, processing enclosed in quotation should do in both conditions.
 
 
Regards,
Naoya
 
---
Naoya Anzai
Engineering Department
NEC Soft, Ltd.
E-Mail: anzai-na...@mxu.nes.nec.co.jp
---
 
 
 Hi Sandeep,

 PFA Naoya's patch (pg_ctl.c.patch).

 Hi Naoya,

 Good finding. I have attached another version of patch
 (pg_ctl.c_windows_vulnerability.patch) attached that has fewer lines of
 code changes, can you please take a look ?. Thanks.

 Best Regards,
 Asif Naeem


 On Mon, Oct 28, 2013 at 4:46 PM, Sandeep Thakkar 
 sandeep.thak...@enterprisedb.com wrote:


   Hi Dave

   We register the service using pg_ctl. When I manually
 executed the following on the command prompt, I saw that the service path
 of the registered service did not have the pg_ctl.exe path in quotes. May
 be it should be handled in the pg_ctl code.

   c:\Users\Sandeep Thakkar\Documentsc:\Program
 Files\PostgreSQL\9.3\bin\pg_ctl.e
   xe register -N pg-9.3 -U NT AUTHORITY\NetworkService
 -D c:\Program Files\P
   ostgreSQL\9.3\data -w

   Naoya,  I could not find your patch here. Can you please
 share it again?



   On Mon, Oct 28, 2013 at 2:53 PM, Dave Page 
 dp...@pgadmin.org wrote:


   Sandeep, can you look at this please? Thanks.

   On Mon, Oct 28, 2013 at 8:18 AM, Asif Naeem 
 anaeem...@gmail.com wrote:
It is related to windows unquoted service path
 vulnerability in the the
installer that creates service path without
 quotes that make service.exe to
look for undesirable path for executable.
   
postgresql-9.3 service path :
 C:/Users/asif/Desktop/Program
files/9.3/bin/pg_ctl.exe runservice -N
 postgresql-9.3 -D
C:/Users/asif/Desktop/Program files/9.3/data -w
   
service.exe
   
C:\Users\asif\Desktop\Program NAME NOT FOUND
C:\Users\asif\Desktop\Program.exe NAME NOT
 FOUND
C:\Users\asif\Desktop\Program
 files\9.3\bin\pg_ctl.exe ACCESS DENIED
C:\Users\asif\Desktop\Program
 files\9.3\bin\pg_ctl.exe ACCESS DENIED
C:\Users\asif\Desktop\Program
 files\9.3\bin\pg_ctl.exe runservice NAME
NOT FOUND
C:\Users\asif\Desktop\Program
 files\9.3\bin\pg_ctl.exe runservice.exe
NAME NOT FOUND
C:\Users\asif\Desktop\Program
 files\9.3\bin\pg_ctl.exe runservice -N
NAME NOT FOUND
C:\Users\asif\Desktop\Program
 files\9.3\bin\pg_ctl.exe runservice -N.exe
NAME NOT FOUND
C

Re: [HACKERS] PostgreSQL Service on Windows does not start. ~ is not a valid Win32 application

[Sandeep Thakkar]

Hi Dave

We register the service using pg_ctl. When I manually executed the
following on the command prompt, I saw that the service path of the
registered service did not have the pg_ctl.exe path in quotes. May be it
should be handled in the pg_ctl code.

*c:\Users\Sandeep Thakkar\Documents*c:\Program
Files\PostgreSQL\9.3\bin\pg_ctl.e
xe register -N pg-9.3 -U NT AUTHORITY\NetworkService -D c:\Program
Files\P
ostgreSQL\9.3\data -w

Naoya,  I could not find your patch here. Can you please share it again?



On Mon, Oct 28, 2013 at 2:53 PM, Dave Page dp...@pgadmin.org wrote:

 Sandeep, can you look at this please? Thanks.

 On Mon, Oct 28, 2013 at 8:18 AM, Asif Naeem anaeem...@gmail.com wrote:
  It is related to windows unquoted service path vulnerability in the the
  installer that creates service path without quotes that make service.exe
 to
  look for undesirable path for executable.
 
  postgresql-9.3 service path : C:/Users/asif/Desktop/Program
  files/9.3/bin/pg_ctl.exe runservice -N postgresql-9.3 -D
  C:/Users/asif/Desktop/Program files/9.3/data -w
 
  service.exe
 
  C:\Users\asif\Desktop\Program NAME NOT FOUND
  C:\Users\asif\Desktop\Program.exe NAME NOT FOUND
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe ACCESS DENIED
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe ACCESS DENIED
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice
 NAME
  NOT FOUND
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice.exe
  NAME NOT FOUND
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  NAME NOT FOUND
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N.exe
  NAME NOT FOUND
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3 NAME INVALID
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3.exe NAME INVALID
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3 -D NAME INVALID
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3 -D.exe NAME INVALID
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3 -D C:\Users\asif\Desktop\Program NAME INVALID
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3 -D C:\Users\asif\Desktop\Program.exe NAME INVALID
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3 -D C:\Users\asif\Desktop\Program files\9.3\data
 NAME
  INVALID
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3 -D C:\Users\asif\Desktop\Program files\9.3\data.exe
  NAME INVALID
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3 -D C:\Users\asif\Desktop\Program files\9.3\data -w
  NAME INVALID
  C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe runservice -N
  postgresql-9.3 -D C:\Users\asif\Desktop\Program files\9.3\data
 -w.exe
  NAME INVALID
 
 
  Fix :
 
  postgresql-9.3 service path : C:/Users/asif/Desktop/Program
  files/9.3/bin/pg_ctl.exe runservice -N postgresql-9.3 -D
  C:/Users/asif/Desktop/Program files/9.3/data -w
 
  It would be good if this is reported on pg installer forum or security
  forum. Thanks.
 
  Regards,
  Asif Naeem
 
  On Mon, Oct 28, 2013 at 12:06 PM, Naoya Anzai
  anzai-na...@mxu.nes.nec.co.jp wrote:
 
  Hi, Asif.
 
  Thank you for response.
 
 
 C:\Users\asif\Desktop\Program files\9.3bin\pg_ctl -D
   C:\Users\asif\Desktop\Program files\9.3\data1 -l logfile start
 server starting
 
  This failure does not occur by the command line.
  PostgreSQL needs to start by Windows Service.
 
  Additionally,In this case,
  A file Program needs to be exist at C:\Users\asif\Desktop\, and
  postgres.exe needs to be exist at C:\Users\asif\Desktop\Program
  files\9.3\bin.
  
  C:\Users\asif\Desktop\Program files\9.3\bindir
  ...
  4,435,456   postgres.exe
 80,896   pg_ctl.exe
  ...
 
  C:\Users\asif\Desktoppdir
  ...
  0  Program
  DIR  Program files
  ...
  
 
  Regards,
  Naoya
 
   Hi Naoya,
  
   I am not able to reproduce the problem. Do you mean pg windows service
   installed by installer is not working or bin\pg_ctl binary is not
 accepting
   spaces in the patch ?. Following worked for me i.e.
  
  
 C:\Users\asif\Desktop\Program files\9.3bin\pg_ctl -D
   C:\Users\asif\Desktop\Program files\9.3\data1 -l logfile start
 server starting
  
  
   Can you please share the exact steps ?. Thanks.
  
  
   Regards,
   Muhammad Asif Naeem
  
  
  
   On Mon, Oct 28, 2013 at 10:26 AM, Naoya Anzai
   anzai-na...@mxu.nes.nec.co.jp wrote:
  
  
 Hi All,
  
 I have found a case that PostgreSQL Service does not start.
 When it happens, the following error appears.
  
  is not a valid Win32 application
  
 This failure occurs when the following

Re: [HACKERS] PostgreSQL Service on Windows does not start. ~ is not a valid Win32 application

[Sandeep Thakkar]

So, this is not an installer issue. Is this bug raised to the PostgreSQL
community? If yes, you should submit the patch there.


On Tue, Oct 29, 2013 at 6:23 AM, Naoya Anzai
anzai-na...@mxu.nes.nec.co.jpwrote:

 Hi, Asif

 Thank you for providing my patch (pg_ctl.c.patch) to Sandeep on my behalf.

  Good finding. I have attached another version of patch
 (pg_ctl.c_windows_vulnerability.patch) attached that has fewer lines of
 code changes, can you please take a look ?. Thanks.

 I think your patch is not sufficient to fix.
 Not only pg_ctl.exe but postgres.exe also have the same problem.
 Even if your patch is attached,
 A Path of postgres.exe passed to CreateRestrictedProcess is not enclosed
 in quotation.(See pgwin32_ServiceMain at pg_ctl.c)

 So, processing enclosed in quotation should do in both conditions.

 Regards,
 Naoya

 ---
 Naoya Anzai
 Engineering Department
 NEC Soft, Ltd.
 E-Mail: anzai-na...@mxu.nes.nec.co.jp
 ---


  Hi Sandeep,
 
  PFA Naoya's patch (pg_ctl.c.patch).
 
  Hi Naoya,
 
  Good finding. I have attached another version of patch
 (pg_ctl.c_windows_vulnerability.patch) attached that has fewer lines of
 code changes, can you please take a look ?. Thanks.
 
  Best Regards,
  Asif Naeem
 
 
  On Mon, Oct 28, 2013 at 4:46 PM, Sandeep Thakkar 
 sandeep.thak...@enterprisedb.com wrote:
 
 
Hi Dave
 
We register the service using pg_ctl. When I manually executed the
 following on the command prompt, I saw that the service path of the
 registered service did not have the pg_ctl.exe path in quotes. May be it
 should be handled in the pg_ctl code.
 
c:\Users\Sandeep Thakkar\Documentsc:\Program
 Files\PostgreSQL\9.3\bin\pg_ctl.e
xe register -N pg-9.3 -U NT AUTHORITY\NetworkService -D
 c:\Program Files\P
ostgreSQL\9.3\data -w
 
Naoya,  I could not find your patch here. Can you please share it
 again?
 
 
 
On Mon, Oct 28, 2013 at 2:53 PM, Dave Page dp...@pgadmin.org
 wrote:
 
 
Sandeep, can you look at this please? Thanks.
 
On Mon, Oct 28, 2013 at 8:18 AM, Asif Naeem 
 anaeem...@gmail.com wrote:
 It is related to windows unquoted service path
 vulnerability in the the
 installer that creates service path without quotes that
 make service.exe to
 look for undesirable path for executable.

 postgresql-9.3 service path :
 C:/Users/asif/Desktop/Program
 files/9.3/bin/pg_ctl.exe runservice -N postgresql-9.3
 -D
 C:/Users/asif/Desktop/Program files/9.3/data -w

 service.exe

 C:\Users\asif\Desktop\Program NAME NOT FOUND
 C:\Users\asif\Desktop\Program.exe NAME NOT FOUND
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 ACCESS DENIED
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 ACCESS DENIED
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice NAME
 NOT FOUND
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice.exe
 NAME NOT FOUND
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 NAME NOT FOUND
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N.exe
 NAME NOT FOUND
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 postgresql-9.3 NAME INVALID
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 postgresql-9.3.exe NAME INVALID
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 postgresql-9.3 -D NAME INVALID
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 postgresql-9.3 -D.exe NAME INVALID
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 postgresql-9.3 -D C:\Users\asif\Desktop\Program NAME
 INVALID
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 postgresql-9.3 -D C:\Users\asif\Desktop\Program.exe
 NAME INVALID
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 postgresql-9.3 -D C:\Users\asif\Desktop\Program
 files\9.3\data NAME
 INVALID
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 postgresql-9.3 -D C:\Users\asif\Desktop\Program
 files\9.3\data.exe
 NAME INVALID
 C:\Users\asif\Desktop\Program files\9.3\bin\pg_ctl.exe
 runservice -N
 postgresql-9.3 -D C:\Users\asif\Desktop\Program
 files\9.3\data -w
 NAME INVALID
 C

Re: [HACKERS] Bug: Windows installer modifies ACLs on the whole volume

[Sandeep Thakkar]

Alex, how much of your D:\ is occupied or what is the total size of the
files and folders in D:\ ?

Can you just try the following command manually to see if it returns quick?

icacls  D:\ /grant UserName:RX

On Fri, Jan 11, 2013 at 9:28 AM, Craig Ringer cr...@2ndquadrant.com wrote:

 On 01/09/2013 05:10 PM, emergency.sho...@gmail.com wrote:
  One click installer postgresql-9.2.2-1-windows-x64.exe from
  http://www.postgresql.org/download/windows/.
 
  Start the installer from D:\downloads, choose C:\Program
  Files\PostgreSQL\9.2 as binary directory, and
  D:\db\postgresql\9.2\data as the data directory.
 
  The installer runs for  1 hour (actually it had not finished yet).
  While doing so, it starts ICACLS child processes that modify ACLs of
  every directory (and file?) on the D:\ volume:
 
  icacls  D:\ /grant UserName:(NP)(RX)
  ...
  icacls  D:\ /grant NT AUTHORITY\NetworkService:(NP)(RX)
  ...
 I see periodic reports of this issue, but I don't think it's ever been
 conclusively solved. I seem to recall discussion suggesting the cause
 had been found a while ago, but you're on the latest release so this
 isn't just an old in-installer-version issue.

 It'd be helpful to have a full list of installed software, service
 packs, etc, along with the exact Windows version.

 I've CC'd Sandeep at EnterpriseDB, who IIRC is looking after the
 installer at the moment.

 --
  Craig Ringer   http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training  Services




-- 
Sandeep Thakkar
Senior Software Engineer
EnterpriseDB Corporation
The Enterprise Postgres Company
Phone: +91.20.30589523

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.

Re: [HACKERS] Bug: Windows installer modifies ACLs on the whole volume

[Sandeep Thakkar]

I remember last time we fixed a bug in initcluster.vbs. There was a typo
which caused icacls to run on system drive. Let me nail down this issue
completely. I'm on it.

On Fri, Jan 11, 2013 at 9:28 AM, Craig Ringer cr...@2ndquadrant.com wrote:

 On 01/09/2013 05:10 PM, emergency.sho...@gmail.com wrote:
  One click installer postgresql-9.2.2-1-windows-x64.exe from
  http://www.postgresql.org/download/windows/.
 
  Start the installer from D:\downloads, choose C:\Program
  Files\PostgreSQL\9.2 as binary directory, and
  D:\db\postgresql\9.2\data as the data directory.
 
  The installer runs for  1 hour (actually it had not finished yet).
  While doing so, it starts ICACLS child processes that modify ACLs of
  every directory (and file?) on the D:\ volume:
 
  icacls  D:\ /grant UserName:(NP)(RX)
  ...
  icacls  D:\ /grant NT AUTHORITY\NetworkService:(NP)(RX)
  ...
 I see periodic reports of this issue, but I don't think it's ever been
 conclusively solved. I seem to recall discussion suggesting the cause
 had been found a while ago, but you're on the latest release so this
 isn't just an old in-installer-version issue.

 It'd be helpful to have a full list of installed software, service
 packs, etc, along with the exact Windows version.

 I've CC'd Sandeep at EnterpriseDB, who IIRC is looking after the
 installer at the moment.

 --
  Craig Ringer   http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training  Services




-- 
Sandeep Thakkar
Senior Software Engineer
EnterpriseDB Corporation
The Enterprise Postgres Company
Phone: +91.20.30589523

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.

Re: [HACKERS] Bug: Windows installer modifies ACLs on the whole volume

[Sandeep Thakkar]

Alex, please send across the install-postgresql.log. It must be present in
your system TEMP.

On Fri, Jan 11, 2013 at 12:02 PM, Sandeep Thakkar 
sandeep.thak...@enterprisedb.com wrote:

 I remember last time we fixed a bug in initcluster.vbs. There was a typo
 which caused icacls to run on system drive. Let me nail down this issue
 completely. I'm on it.

 On Fri, Jan 11, 2013 at 9:28 AM, Craig Ringer cr...@2ndquadrant.comwrote:

 On 01/09/2013 05:10 PM, emergency.sho...@gmail.com wrote:
  One click installer postgresql-9.2.2-1-windows-x64.exe from
  http://www.postgresql.org/download/windows/.
 
  Start the installer from D:\downloads, choose C:\Program
  Files\PostgreSQL\9.2 as binary directory, and
  D:\db\postgresql\9.2\data as the data directory.
 
  The installer runs for  1 hour (actually it had not finished yet).
  While doing so, it starts ICACLS child processes that modify ACLs of
  every directory (and file?) on the D:\ volume:
 
  icacls  D:\ /grant UserName:(NP)(RX)
  ...
  icacls  D:\ /grant NT AUTHORITY\NetworkService:(NP)(RX)
  ...
 I see periodic reports of this issue, but I don't think it's ever been
 conclusively solved. I seem to recall discussion suggesting the cause
 had been found a while ago, but you're on the latest release so this
 isn't just an old in-installer-version issue.

 It'd be helpful to have a full list of installed software, service
 packs, etc, along with the exact Windows version.

 I've CC'd Sandeep at EnterpriseDB, who IIRC is looking after the
 installer at the moment.

 --
  Craig Ringer   http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training  Services




 --
 Sandeep Thakkar
 Senior Software Engineer
 EnterpriseDB Corporation
 The Enterprise Postgres Company
 Phone: +91.20.30589523

 Website: www.enterprisedb.com
 EnterpriseDB Blog: http://blogs.enterprisedb.com/
 Follow us on Twitter: http://www.twitter.com/enterprisedb

 This e-mail message (and any attachment) is intended for the use of the
 individual or entity to whom it is addressed. This message contains
 information from EnterpriseDB Corporation that may be privileged,
 confidential, or exempt from disclosure under applicable law. If you are
 not the intended recipient or authorized to receive this for the intended
 recipient, any use, dissemination, distribution, retention, archiving, or
 copying of this communication is strictly prohibited. If you have received
 this e-mail in error, please notify the sender immediately by reply e-mail
 and delete this message.




-- 
Sandeep Thakkar
Senior Software Engineer
EnterpriseDB Corporation
The Enterprise Postgres Company
Phone: +91.20.30589523

Website: www.enterprisedb.com
EnterpriseDB Blog: http://blogs.enterprisedb.com/
Follow us on Twitter: http://www.twitter.com/enterprisedb

This e-mail message (and any attachment) is intended for the use of the
individual or entity to whom it is addressed. This message contains
information from EnterpriseDB Corporation that may be privileged,
confidential, or exempt from disclosure under applicable law. If you are
not the intended recipient or authorized to receive this for the intended
recipient, any use, dissemination, distribution, retention, archiving, or
copying of this communication is strictly prohibited. If you have received
this e-mail in error, please notify the sender immediately by reply e-mail
and delete this message.