Re: [BUGS] 9.2 beta1 libxml2 can't be loaded on Windows
Sachin, please investigate ASAP. Thanks. On Mon, Jun 11, 2012 at 6:30 AM, Edmund Horner wrote: > On 9 June 2012 03:48, Dave Page wrote: >> On Fri, Jun 1, 2012 at 1:39 AM, Edmund Horner wrote: >>> On 1 June 2012 12:36, Edmund Horner wrote: On 1 June 2012 12:14, Edmund Horner wrote: > I tried using an older libxml2.dll. Replace with the one from > ftp://ftp.zlatkovic.com/libxml/oldreleases/libxml2-2.6.9.win32.zip > (and copying zlib1.dll to zlib.dll), and it works. > > ... >> >> Please test 9.2 beta 2 - that's the first build to come from the new >> build machine that'll be used for this release. It's got a new set of >> dependencies which should all work correctly. > > Hi Dave, > > I've tried with the EnterpriseDB.com Windows 32-bit 9.2 beta2 > installer found via his page: > http://www.postgresql.org/download/snapshots/ > > Previously I was testing with the plain binaries zip, but those don't > seem to be available for beta2 yet. > > The problem still occurs. Again, I can work past it by copying in an > old version of libxml2.dll and zlib.dll. > > Edmund. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] JDBC Driver can't read UUID from database
Thanks. Out of curiosity why didn't the driver map the Postgresql UUID to a Java UUID? On 6/6/12 2:12 AM, "Kris Jurka" wrote: > > >On Tue, 5 Jun 2012, Dean Schulze wrote: > >> >> I'm using Hibernate (3.6 and 4.0) with Postgresql 9.1. Our tables have >> UUIDs in them and your driver is trying to convert UUIDs to longs: >> > >This is a hibernate mapping problem, not a JDBC Driver problem. If you >have a plain ResultSet and call getString() on a UUID field, it will >certainly work. Mapping the UUID to BLOB or CLOB is incorrect. I'm not >sure why your attempt to map it to a String didn't work, but you are >not convincing Hibernate to use a plain getString call. > >Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6687: initdb -A ident can almost never be correct
The following bug has been logged on the website: Bug reference: 6687 Logged by: David Fetter Email address: da...@fetter.org PostgreSQL version: 9.1.4 Operating system: All Description: When calling initdb -A, it is assumed--wrongly in the case of ident, that every method is valid for both local and network. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6687: initdb -A ident can almost never be correct
On Mon, Jun 11, 2012 at 5:14 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 6687 > Logged by: David Fetter > Email address: da...@fetter.org > PostgreSQL version: 9.1.4 > Operating system: All > Description: > > When calling initdb -A, it is assumed--wrongly in the case of ident, that > every method is valid for both local and network. Um, what do you mean? If I specify initdb -A, it gives me peer on local and ident on tcp, is that not what you expected? Or maybe I'm misunderstanding the problem completely.. What is happening, and what are you expecting to happen? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6687: initdb -A ident can almost never be correct
On Mon, Jun 11, 2012 at 05:51:06PM +0200, Magnus Hagander wrote: > On Mon, Jun 11, 2012 at 5:14 PM, wrote: > > The following bug has been logged on the website: > > > > Bug reference: 6687 > > Logged by: David Fetter > > Email address: da...@fetter.org > > PostgreSQL version: 9.1.4 > > Operating system: All > > Description: > > > > When calling initdb -A, it is assumed--wrongly in the case of ident, that > > every method is valid for both local and network. > > Um, what do you mean? > > If I specify initdb -A, it gives me peer on local and ident on tcp, is > that not what you expected? > > Or maybe I'm misunderstanding the problem completely.. What is > happening, and what are you expecting to happen? We have a design issue, namely that initdb -A blindly applies the auth method specified to all default accesses. This is the correct behavior for all auth methods except for ident, where it is wrong just about everywhere for network (localhost rather than local) access. I'm tempted to say it's always wrong for network access, only I know someone will pipe up and talk about how they're running identd on some legacy system. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6687: initdb -A ident can almost never be correct
On Mon, Jun 11, 2012 at 6:01 PM, David Fetter wrote: > On Mon, Jun 11, 2012 at 05:51:06PM +0200, Magnus Hagander wrote: >> On Mon, Jun 11, 2012 at 5:14 PM, wrote: >> > The following bug has been logged on the website: >> > >> > Bug reference: 6687 >> > Logged by: David Fetter >> > Email address: da...@fetter.org >> > PostgreSQL version: 9.1.4 >> > Operating system: All >> > Description: >> > >> > When calling initdb -A, it is assumed--wrongly in the case of ident, that >> > every method is valid for both local and network. >> >> Um, what do you mean? >> >> If I specify initdb -A, it gives me peer on local and ident on tcp, is >> that not what you expected? >> >> Or maybe I'm misunderstanding the problem completely.. What is >> happening, and what are you expecting to happen? > > We have a design issue, namely that initdb -A blindly applies the auth > method specified to all default accesses. This is the correct > behavior for all auth methods except for ident, where it is wrong just > about everywhere for network (localhost rather than local) access. Uh, what *would* you expect to happen if you choose "ident"? That something different than what you choose is done? I can get the argument for "peer", which could potentially leave the non-local entries out completely. But I don't see anything wrong with what "ident" does. And even in the case of peer, since the default is not to even *listen* on remote connections, it's not a huge problem... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6687: initdb -A ident can almost never be correct
On Mon, Jun 11, 2012 at 06:04:22PM +0200, Magnus Hagander wrote: > On Mon, Jun 11, 2012 at 6:01 PM, David Fetter wrote: > > On Mon, Jun 11, 2012 at 05:51:06PM +0200, Magnus Hagander wrote: > >> On Mon, Jun 11, 2012 at 5:14 PM, wrote: > >> > The following bug has been logged on the website: > >> > > >> > Bug reference: 6687 > >> > Logged by: David Fetter > >> > Email address: da...@fetter.org > >> > PostgreSQL version: 9.1.4 > >> > Operating system: All > >> > Description: > >> > > >> > When calling initdb -A, it is assumed--wrongly in the case of ident, that > >> > every method is valid for both local and network. > >> > >> Um, what do you mean? > >> > >> If I specify initdb -A, it gives me peer on local and ident on tcp, is > >> that not what you expected? > >> > >> Or maybe I'm misunderstanding the problem completely.. What is > >> happening, and what are you expecting to happen? > > > > We have a design issue, namely that initdb -A blindly applies the auth > > method specified to all default accesses. This is the correct > > behavior for all auth methods except for ident, where it is wrong just > > about everywhere for network (localhost rather than local) access. > > Uh, what *would* you expect to happen if you choose "ident"? That > something different than what you choose is done? I'd expect it to error out because it's trying to apply ident to things which to an excellent approximation can never work, namely localhost (ipv4 and ipv6 versions). That this misbehavior is long-standing doesn't make it correct. This came up in IRC with someone trying to create automated deployment scripts using initdb -A and then connecting to localhost instead of local. You could argue that this is pilot error, but it's a perfectly reasonable thing for someone new to try, but there is nothing to indicate the source of the problems he's seeing. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6687: initdb -A ident can almost never be correct
On Mon, Jun 11, 2012 at 6:14 PM, David Fetter wrote: > On Mon, Jun 11, 2012 at 06:04:22PM +0200, Magnus Hagander wrote: >> On Mon, Jun 11, 2012 at 6:01 PM, David Fetter wrote: >> > On Mon, Jun 11, 2012 at 05:51:06PM +0200, Magnus Hagander wrote: >> >> On Mon, Jun 11, 2012 at 5:14 PM, wrote: >> >> > The following bug has been logged on the website: >> >> > >> >> > Bug reference: 6687 >> >> > Logged by: David Fetter >> >> > Email address: da...@fetter.org >> >> > PostgreSQL version: 9.1.4 >> >> > Operating system: All >> >> > Description: >> >> > >> >> > When calling initdb -A, it is assumed--wrongly in the case of ident, >> >> > that >> >> > every method is valid for both local and network. >> >> >> >> Um, what do you mean? >> >> >> >> If I specify initdb -A, it gives me peer on local and ident on tcp, is >> >> that not what you expected? >> >> >> >> Or maybe I'm misunderstanding the problem completely.. What is >> >> happening, and what are you expecting to happen? >> > >> > We have a design issue, namely that initdb -A blindly applies the auth >> > method specified to all default accesses. This is the correct >> > behavior for all auth methods except for ident, where it is wrong just >> > about everywhere for network (localhost rather than local) access. >> >> Uh, what *would* you expect to happen if you choose "ident"? That >> something different than what you choose is done? > > I'd expect it to error out because it's trying to apply ident to > things which to an excellent approximation can never work, namely > localhost (ipv4 and ipv6 versions). That this misbehavior is > long-standing doesn't make it correct. I've certainly seen deployments over localhost that use that. In fact, that's one of the few cases where ident can be considered "fully secure", given that the channel is actually trusted... So erroring out is clearly not the right thing. That's not saying that the interface can't be improved, but erroring out is not an improvement. > This came up in IRC with someone trying to create automated deployment > scripts using initdb -A and then connecting to localhost instead of > local. You could argue that this is pilot error, but it's a perfectly > reasonable thing for someone new to try, but there is nothing to > indicate the source of the problems he's seeing. So what interface *would* you suggest? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6687: initdb -A ident can almost never be correct
On Mon, Jun 11, 2012 at 06:21:43PM +0200, Magnus Hagander wrote: > On Mon, Jun 11, 2012 at 6:14 PM, David Fetter wrote: > > On Mon, Jun 11, 2012 at 06:04:22PM +0200, Magnus Hagander wrote: > >> On Mon, Jun 11, 2012 at 6:01 PM, David Fetter wrote: > >> > On Mon, Jun 11, 2012 at 05:51:06PM +0200, Magnus Hagander wrote: > >> >> On Mon, Jun 11, 2012 at 5:14 PM, wrote: > >> >> > The following bug has been logged on the website: > >> >> > > >> >> > Bug reference: 6687 > >> >> > Logged by: David Fetter > >> >> > Email address: da...@fetter.org > >> >> > PostgreSQL version: 9.1.4 > >> >> > Operating system: All > >> >> > Description: > >> >> > > >> >> > When calling initdb -A, it is assumed--wrongly in the case of ident, > >> >> > that > >> >> > every method is valid for both local and network. > >> >> > >> >> Um, what do you mean? > >> >> > >> >> If I specify initdb -A, it gives me peer on local and ident on tcp, is > >> >> that not what you expected? > >> >> > >> >> Or maybe I'm misunderstanding the problem completely.. What is > >> >> happening, and what are you expecting to happen? > >> > > >> > We have a design issue, namely that initdb -A blindly applies the auth > >> > method specified to all default accesses. This is the correct > >> > behavior for all auth methods except for ident, where it is wrong just > >> > about everywhere for network (localhost rather than local) access. > >> > >> Uh, what *would* you expect to happen if you choose "ident"? That > >> something different than what you choose is done? > > > > I'd expect it to error out because it's trying to apply ident to > > things which to an excellent approximation can never work, namely > > localhost (ipv4 and ipv6 versions). That this misbehavior is > > long-standing doesn't make it correct. > > I've certainly seen deployments over localhost that use that. In fact, > that's one of the few cases where ident can be considered "fully > secure", given that the channel is actually trusted... > > So erroring out is clearly not the right thing. That's not saying that > the interface can't be improved, but erroring out is not an > improvement. > > > > This came up in IRC with someone trying to create automated deployment > > scripts using initdb -A and then connecting to localhost instead of > > local. You could argue that this is pilot error, but it's a perfectly > > reasonable thing for someone new to try, but there is nothing to > > indicate the source of the problems he's seeing. > > So what interface *would* you suggest? Interface wouldn't change. Instead, it would check for your once-in-a-blue-moon scenario of identd answering on the network and error out if it didn't fine same. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6688: can't install from binary.
The following bug has been logged on the website: Bug reference: 6688 Logged by: Rob Email address: om...@ra1.net PostgreSQL version: 9.1.4 Operating system: OSX 10.4.11 Description: Hi, I get an error when trying to run the 9.1.4 installer binary (postgresql-9.1.4-1-osx.app) on my Mac PowerBook PPC running OS X 10.4.11. It says, "Bad CPU type in executable." Your download page says that OS X 10.4 on PPC is supported -- "A one click installer is available for for Mac OS X 10.4 and above on Intel and PPC and includes PostgreSQL, pgAdmin, PL/Java and the PL/pgSQL debugger plugin.' http://www.postgresql.org/download/macosx/ What am I missing? Or what might I be doing wrong? I simply downloaded the disk image and tried to run the installer. Thanks a lot. Rob -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6688: can't install from binary.
On Mon, Jun 11, 2012 at 6:12 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 6688 > Logged by: Rob > Email address: om...@ra1.net > PostgreSQL version: 9.1.4 > Operating system: OSX 10.4.11 > Description: > > Hi, > > I get an error when trying to run the 9.1.4 installer binary > (postgresql-9.1.4-1-osx.app) on my Mac PowerBook PPC running OS X 10.4.11. > > It says, "Bad CPU type in executable." > > Your download page says that OS X 10.4 on PPC is supported -- "A one click > installer is available for for Mac OS X 10.4 and above on Intel and PPC and > includes PostgreSQL, pgAdmin, PL/Java and the PL/pgSQL debugger plugin.' > http://www.postgresql.org/download/macosx/ > > What am I missing? Or what might I be doing wrong? I simply downloaded the > disk image and tried to run the installer. Only the 8.3 and 8.4 installers still support PPC I'm afraid. We'll need to clarify that text. Sorry for the inconvenience. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] JDBC Driver can't read UUID from database
On Mon, 11 Jun 2012, Dean Schulze wrote: > Out of curiosity why didn't the driver map the Postgresql UUID to a Java > UUID? > The example I gave of calling getString must return a String and not another type. With a recent JDBC Driver and Java version, calling getObject will return a UUID object. Kris Jurka -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6687: initdb -A ident can almost never be correct
David Fetter writes: > Interface wouldn't change. Instead, it would check for your > once-in-a-blue-moon scenario of identd answering on the network and > error out if it didn't fine same. This is nonsense. As Magnus said, localhost is the one case where identd *can* be trusted. There is no reason that we should discriminate against that case. It also does not seem to me like a good plan to insist that identd be running at the same instant initdb runs; it's not hard to think of installation scenarios where that won't be true. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.2 beta2 - pg_ctl crashes on Win32 when neither PGDATA nor -D specified
Edmund Horner writes:
> In 9.1, if I run "pg_ctl start" without providing way for it to find
> the datadir, it prints the error:
> C:\ehorner\pgsql-old\bin>pg_ctl start
> pg_ctl: no database directory specified and environment variable
> PGDATA unset
> Try "pg_ctl --help" for more information.
> In 9.2 (beta1 and beta2), it runs for a couple of seconds and then
> Windows pops up an error box saying it has "encountered a problem". I
> ...
> I think it could be something in
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=aaa6e1def292cdacb6b27088898793b1b879fedf#patch5
Hm, that patch seems to be several bricks shy of a load. I will fix
two obvious bugs in it:
(1) not dump core on boxes where printf("%s", NULL) dumps core;
(2) not try to call adjust_data_dir before complaining for lack of
a -D switch; since adjust_data_dir does not do anything to the value
of pg_config, it's just silly to do things in that order.
However,
> I note that "postgres -C data_directory" will refuse to run on the
> command line because I've got admin privileges in Windows, and that
> pg_ctl normally starts postgres.exe using CreateRestrictedProcess.
> But it does not do so for the popen call in adjust_data_dir.
if that actually is a third bug, as seems likely, somebody with access
to a windows environment will need to deal with it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.2 beta2 - pg_ctl crashes on Win32 when neither PGDATA nor -D specified
On 12 June 2012 14:23, Tom Lane wrote:
> Edmund Horner writes:
>> In 9.1, if I run "pg_ctl start" without providing way for it to find
>> the datadir, it prints the error:
>
>> C:\ehorner\pgsql-old\bin>pg_ctl start
>> pg_ctl: no database directory specified and environment variable
>> PGDATA unset
>> Try "pg_ctl --help" for more information.
>
>> In 9.2 (beta1 and beta2), it runs for a couple of seconds and then
>> Windows pops up an error box saying it has "encountered a problem". I
>> ...
>> I think it could be something in
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=aaa6e1def292cdacb6b27088898793b1b879fedf#patch5
>
> Hm, that patch seems to be several bricks shy of a load. I will fix
> two obvious bugs in it:
>
> (1) not dump core on boxes where printf("%s", NULL) dumps core;
I saw that, but I couldn't decide if it was the actual problem in my
case. Later parts of adjust_data_dir appeared to be running (looking
at file system activity).
Anyway I'm happy to test it again when there's a new binary.
Edmund.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.2 beta2 - pg_ctl crashes on Win32 when neither PGDATA nor -D specified
Edmund Horner writes:
> On 12 June 2012 14:23, Tom Lane wrote:
>> Hm, that patch seems to be several bricks shy of a load. I will fix
>> two obvious bugs in it:
>> (1) not dump core on boxes where printf("%s", NULL) dumps core;
> I saw that, but I couldn't decide if it was the actual problem in my
> case. Later parts of adjust_data_dir appeared to be running (looking
> at file system activity).
The weird thing is that if it's not dumping core, the first fopen would
presumably be trying to open "/postgresql.conf", which generally ought
to fail and thus mask any problems in the rest of adjust_data_dir().
Have you by any chance got a postgresql.conf laying about in your root
directory?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 9.2 beta2 - pg_ctl crashes on Win32 when neither PGDATA nor -D specified
On 12 June 2012 14:51, Tom Lane wrote:
> Edmund Horner writes:
>> On 12 June 2012 14:23, Tom Lane wrote:
>>> Hm, that patch seems to be several bricks shy of a load. I will fix
>>> two obvious bugs in it:
>>> (1) not dump core on boxes where printf("%s", NULL) dumps core;
>
>> I saw that, but I couldn't decide if it was the actual problem in my
>> case. Later parts of adjust_data_dir appeared to be running (looking
>> at file system activity).
>
> The weird thing is that if it's not dumping core, the first fopen would
> presumably be trying to open "/postgresql.conf", which generally ought
> to fail and thus mask any problems in the rest of adjust_data_dir().
> Have you by any chance got a postgresql.conf laying about in your root
> directory?
I don't, and I couldn't see any file system requests for
postgresql.conf either (though I thought that might be because it's
failing to find a bogus parent path first e.g. something like
"(null)/postgresql.conf". But I think it's just a problem in the
snprintf statements after all:
I've managed to run it in the MSVC debugger, using the packaged pdb
files. So it does seem to be crashing on the first snprintf
statement.
pg_ctl.exe!fmtstr(char * value=0x, int leftjust=0, int
minlen=1, int maxwidth=0, int pointflag=0, PrintfTarget *
target=0x) Line 779 + 0x6 bytesC
pg_ctl.exe!dopr(PrintfTarget * target=0x0081f72c, const char *
format=0x0040b948, char * args=0x) Line 715 + 0x1c bytes C
pg_ctl.exe!pg_snprintf(char * str=0x0081fb5c, unsigned int
count=1024, const char * fmt=0x0040b948, ...) Line 171 + 0x35 bytesC
> pg_ctl.exe!adjust_data_dir() Line 1902 C
pg_ctl.exe!main(int argc=2, char * * argv=0x00da4fe0) Line 2189
C
pg_ctl.exe!__tmainCRTStartup() Line 555 + 0x17 bytes C
kernel32.dll!7c817067()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
I'm not sure I can find the exact source version pg_ctl.c that was
compiled -- I get an off-by-one error around line 1902 using the
source from a few days ago.
1900/* If there is no postgresql.conf, it can't be a config-only dir */
1901snprintf(filename, sizeof(filename), "%s/postgresql.conf", pg_config);
1902if ((fd = fopen(filename, "r")) == NULL)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP
On 26 May 2012 01:10, Bruce Momjian wrote: > Ah, turns out I only need one extra log file on Windows, not two, > because I can reuse the utility file for pg_ctl stop. The original > beta1 code usesd the utility file for pg_ctl stop and start, which is > what caused the problem. > > Applied patch attached. And now pg_upgrade in beta2 works fine. Thanks. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
