[BUGS] pltclu install problems

2012-05-21 Thread Szunomár Péter 
Hello,

i'm trying to install pltclu (or pltcl) language on my database on
localhost.
System: Windows 7 Ultimate
Postgres: 8.3.5 or 9.1 (same error on both)

Even if i start the createlang.exe pltclu or run the CREATE LANGUAGE pltclu
sql command from PgAdmin, i receive the following error message:


ERROR:  could not load library "C:/Program
Files/PostgreSQL/9.1/lib/pltcl.dll": unknown error 126
** Error **
ERROR: could not load library "C:/Program
Files/PostgreSQL/9.1/lib/pltcl.dll": unknown error 126
SQL state: 58P01


But the file exists on the named path. What is wrong?

Thanks!
Peter

[BUGS] BUG #6653: Service does not start in standby-mode

2012-05-21 Thread axw-sk 
The following bug has been logged on the website:

Bug reference:  6653
Logged by:  Sebastian K.
Email address:  axw...@ipa.fhg.de
PostgreSQL version: 9.0.7
Operating system:   Windows 7 i386
Description:

I want to set up a standby server for backup.

The server has a new installation of postgresql.

recovery.conf:
restore_command = 'copy "c:\\Users\\Administrator\\Desktop\\%f" "%p"'
standby_mode = 'on'

The files of the base backup are placed on the Desktop of the standby
server.

Additionally, the files are already copied to the pg_xlog directory.

Problem:
Placing the recovery.conf file in the data directory prevents the postgres
service to start.

Windows-Error-Log:
Starting service timeout.

PG-Log:
2012-05-21 12:38:38 CEST LOG:  Datenbanksystem wurde während der
Wiederherstellung am 2012-05-21 12:34:21 CEST heruntergefahren
2012-05-21 12:38:38 CEST LOG:  Standby-Modus eingeschaltet
2012-05-21 12:38:38 CEST FATAL:  das Datenbanksystem startet
2012-05-21 12:38:38 CEST WARNUNG:  WAL wurde mit wal_level=minimal erzeugt,
eventuell fehlen Daten
2012-05-21 12:38:38 CEST TIPP:  Das passiert, wenn vorübergehend
wal_level=minimal gesetzt wurde, ohne ein neues Base-Backup zu erzeugen.
2012-05-21 12:38:38 CEST LOG:  konsistenter Wiederherstellungszustand
erreicht bei 0/15FBB78
2012-05-21 12:38:38 CEST LOG:  Datensatz mit Länge null bei 0/15FBB78
2012-05-21 12:38:39 CEST FATAL:  das Datenbanksystem startet
2012-05-21 12:38:40 CEST FATAL:  das Datenbanksystem startet
2012-05-21 12:38:41 CEST FATAL:  das Datenbanksystem startet
2012-05-21 12:38:42 CEST FATAL:  das Datenbanksystem startet
2012-05-21 12:38:43 CEST FATAL:  das Datenbanksystem startet
2012-05-21 12:38:44 CEST FATAL:  das Datenbanksystem startet

The base backup was created with following settings in postgresql.conf:
wal_level = archive
archive_mode = on
archive_command = 'copy


-- 
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.2beta1 regression: pg_restore --data-only does not set sequence values any more

2012-05-21 Thread Andrew Dunstan 



On 05/16/2012 10:23 AM, Andrew Dunstan wrote:



On Wed, May 16, 2012 at 9:08 AM, Tom Lane > wrote:


Martin Pitt mailto:mp...@debian.org>> writes:
> while packaging 9.2 beta 1 for Debian/Ubuntu the postgresql-common
> test suite noticed a regression: It seems that pg_restore
--data-only
> now skips the current value of sequences, so that in the upgraded
> database the sequence counter is back to the default.

I believe this is a consequence of commit
a4cd6abcc901c1a8009c62a27f78696717bb8fe1, which introduced the
entirely
false assumption that --schema-only and --data-only have something to
do with the order that entries appear in the archive ...



Darn, will investigate.




[cc -hackers]

Well, the trouble is that we have these pesky SECTION_NONE entries for 
things like comments, security labels and ACLs that need to be dumped in 
the right section, so we can't totally ignore the order. But we could 
(and probably should) ignore the order for making decisions about 
everything BUT those entries.


So, here's a revised plan:

--section=data will dump exactly TABLE DATA, SEQUENCE SET or BLOBS 
entries
--section=pre-data will dump SECTION_PRE_DATA items (other than 
SEQUENCE SET) plus any immediately following SECTION_NONE items.

--section=post-data will dump everything else.

Comments?


cheers

andrew

--
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 #6656: Wrong timestamptz + interval calculation

2012-05-21 Thread mw 
The following bug has been logged on the website:

Bug reference:  6656
Logged by:  Marcus Wirsing (Hesotech GmbH)
Email address:  m...@hesotech.de
PostgreSQL version: 9.1.3
Operating system:   Windows 7 64Bit
Description:

When I execute the statement

select timestamptz '2012-03-01 00:00:00+00' + interval '1 month'

I expect the result:
"2012-04-01 02:00:00+02"

but postgres returns:

"2012-04-01 01:00:00+02"

My local time zone is UTC+1.


-- 
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 #6655: restore backup

2012-05-21 Thread gloria_evelis 
The following bug has been logged on the website:

Bug reference:  6655
Logged by:  Gloria Valladares
Email address:  gloria_eve...@hotmail.com
PostgreSQL version: 8.4.0
Operating system:   Ubuntu
Description:

/usr/bin/pg_restore --host localhost --port 5432 --username postgres
--dbname "Mantenimiento" --verbose
"/media/GVALLADARES/20120521_backup.backup"
pg_restore: [archivador] versión no permitida (1.12) en el encabezado del
archivo


-- 
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 #6657: Documentation bug for PQconnectdbParams

2012-05-21 Thread ediven 
The following bug has been logged on the website:

Bug reference:  6657
Logged by:  Eric Diven
Email address:  edi...@edsiohio.com
PostgreSQL version: 9.0.2
Operating system:   Solaris
Description:

First off, I should thank you all for the generally excellent documentation.
 The plpgsql documentation has been particularly helpful, in large part
thanks to the relevant and well-explained examples.

That said, I would humbly suggest that the documentation for the
PQconnectdbParams function omits certain details.  Notably, the function
will return NULL if you pass in a keywords array with an unrecognized
keyword.

I'll be the first to admit that passing in a keyword of "host_addr" instead
of "hostaddr" was kind of a dumb mistake on my part, but I'd argue that I'd
have figured it out a lot sooner if this were the documented behavior of
PQconnectdbParams for this case.

I realize I'm submitting this against an out of date version of postgresql,
and the the behavior might have changed since then, but since the
documentation covers all of 9.0.x, I would say that it still bears
updating.

Thanks,

Eric Diven

Example code follows:

#include 

int main (int argc, char *argv[])
{
PGconn *conn = NULL;
char *keys[] = { "host_addr", "user", "password", NULL };
char *values[] = { "192.168.0.42", "user", "password", NULL };

conn = PQconnectdbParams (keys, values, 0);

printf ("%p\n", conn);
return 0;
}



-- 
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 #6654: Full text search doesn't find europe

2012-05-21 Thread wbrana 
The following bug has been logged on the website:

Bug reference:  6654
Logged by:  wbrana
Email address:  wbr...@gmail.com
PostgreSQL version: 9.1.3
Operating system:   Linux
Description:

CREATE INDEX idx_post_text ON posts USING gin
(to_tsvector('english'::regconfig, post_text::text)) 
select *  from v_search WHERE to_tsvector('english', post_text) @@ 'europe'
returns no rows, but
select *  from v_search WHERE to_tsvector('english', post_text) @@ 'japan'
returns row with "Japan and Europe"



-- 
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

2012-05-21 Thread Edmund Horner 
Hum.  My first email sent to this list a few days ago still has not
arrived, so these two are kind of orphaned.  Should I resend it?

-- 
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 #6654: Full text search doesn't find europe

2012-05-21 Thread Andres Freund 
On Monday, May 21, 2012 07:26:38 PM wbr...@gmail.com wrote:
> The following bug has been logged on the website:
> 
> Bug reference:  6654
> Logged by:  wbrana
> Email address:  wbr...@gmail.com
> PostgreSQL version: 9.1.3
> Operating system:   Linux
> Description:
> 
> CREATE INDEX idx_post_text ON posts USING gin
> (to_tsvector('english'::regconfig, post_text::text))
> select *  from v_search WHERE to_tsvector('english', post_text) @@ 'europe'
> returns no rows, but
> select *  from v_search WHERE to_tsvector('english', post_text) @@ 'japan'
> returns row with "Japan and Europe"
The problem is that youre using to_tsvector('english' for parsing the text but 
don't specify the text yearch configuration for the query. The default english 
configuration does stemming, the default_text_search_configuration obviously 
not.
Try ... to_tsvector('english', post_text) @@ to_tsquery('english', 'europe')

Andres

-- 
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 #6654: Full text search doesn't find europe

2012-05-21 Thread Tom Lane 
Andres Freund  writes:
> On Monday, May 21, 2012 07:26:38 PM wbr...@gmail.com wrote:
>> CREATE INDEX idx_post_text ON posts USING gin
>> (to_tsvector('english'::regconfig, post_text::text))
>> select *  from v_search WHERE to_tsvector('english', post_text) @@ 'europe'
>> returns no rows, but
>> select *  from v_search WHERE to_tsvector('english', post_text) @@ 'japan'
>> returns row with "Japan and Europe"

> The problem is that youre using to_tsvector('english' for parsing the text 
> but 
> don't specify the text yearch configuration for the query. The default 
> english 
> configuration does stemming, the default_text_search_configuration obviously 
> not.
> Try ... to_tsvector('english', post_text) @@ to_tsquery('english', 'europe')

BTW, a good way to debug this sort of issue is to look at the actual
tsvector and tsquery values.

regression=# select to_tsvector('english', 'Japan and Europe');
 to_tsvector 
-
 'europ':3 'japan':1
(1 row)

regression=# select to_tsquery('english', 'Japan');
 to_tsquery 

 'japan'
(1 row)

regression=# select to_tsquery('english', 'Europe');
 to_tsquery 

 'europ'
(1 row)

If you just cast 'europe' directly to tsquery, which is what's going to
happen in the first example, you get the lexeme 'europe' which doesn't
match 'europ'.

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] BUG #6656: Wrong timestamptz + interval calculation

2012-05-21 Thread Tom Lane 
m...@hesotech.de writes:
> When I execute the statement
> select timestamptz '2012-03-01 00:00:00+00' + interval '1 month'
> I expect the result:
> "2012-04-01 02:00:00+02"
> but postgres returns:
> "2012-04-01 01:00:00+02"

This does not look like a bug to me.  You did not say what time zone you
are using, but I bet it is one that is UTC+1 in the winter and switches
to UTC+2 during March.  For instance, if I try this in Europe/Amsterdam
zone I get:

regression=# set timezone = 'Europe/Amsterdam';
SET
regression=# select now();
  now  
---
 2012-05-22 01:04:52.556207+02
(1 row)

regression=# select timestamptz '2012-03-01 00:00:00+00';
  timestamptz   

 2012-03-01 01:00:00+01
(1 row)

The above is correct since midnight UTC corresponds to 1AM Amsterdam
winter time ...

regression=# select timestamptz '2012-03-01 00:00:00+00' + interval '1 month';
?column?

 2012-04-01 01:00:00+02
(1 row)

... and adding '1 month' to a timestamptz is defined to produce the same
local time, so this is the correct result.

If you don't want such behavior, you could use a timezone setting that
has no DST transitions.  Or possibly you want to do the arithmetic with
the type timestamp without time zone, rather than with time zone.
Or you could express the interval to be added as so many
hours/minutes/seconds, rather than using the variable-size units of
days/weeks/months/years.

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] BUG #6655: restore backup

2012-05-21 Thread Tom Lane 
gloria_eve...@hotmail.com writes:
> PostgreSQL version: 8.4.0

> /usr/bin/pg_restore --host localhost --port 5432 --username postgres
> --dbname "Mantenimiento" --verbose
> "/media/GVALLADARES/20120521_backup.backup"
> pg_restore: [archivador] versión no permitida (1.12) en el encabezado del
> archivo

Archive version 1.12 means that the file was emitted by a 9.0 or later
version of pg_dump.  So you'll need a 9.0 or later version of pg_restore
to read it.  Depending on what server version it was dumped from, you
might have some problems restoring the objects in the dump into an 8.4
server, too.

BTW, if you really are running 8.4.0, you would be well advised to
update to a newer minor release.  The 8.4 release series is currently at
8.4.11, meaning you're missing 11 minor versions worth of bug fixes,
some of which were pretty critical.

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] BUG #6657: Documentation bug for PQconnectdbParams

2012-05-21 Thread Tom Lane 
edi...@edsiohio.com writes:
> PostgreSQL version: 9.0.2
> ...
> That said, I would humbly suggest that the documentation for the
> PQconnectdbParams function omits certain details.  Notably, the function
> will return NULL if you pass in a keywords array with an unrecognized
> keyword.

This is a known bug that was fixed in 9.0.4.  When I try it now, I get a
PGconn object back, with status CONNECTION_BAD, and PQerrorMessage returns
invalid connection option "host_addr"
which was the intended behavior all along, but there was a typo in 9.0;
see
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=672def62259354f28000e8cfb97b6668192369c2

In theory at least, you should only get a NULL back if there's
insufficient memory to create a PGconn object at all.

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

[BUGS] BUG #6658: Database do not push down static condition to subquery.

2012-05-21 Thread maxim . boguk 
The following bug has been logged on the website:

Bug reference:  6658
Logged by:  Maxim Boguk
Email address:  maxim.bo...@gmail.com
PostgreSQL version: 9.1.3
Operating system:   Linux
Description:

Hi,

I have 2 queries which have the same plan/same performance on 8.3 but on
9.1.3 fist one doesn't perform well because condition doesn't pushed down to
subquery:

--slow on 9.1.3 but fast on 8.3.13
--helper just shell view
db=# explain (analyze,verbose) select id from
(SELECT
id,
regexp_replace(btrim(((COALESCE(NULLIF(start_number, 0) || ' '::text,
''::text) || address) || ' '::text) || suburb) || ' '::text) || state) || '
'::text) || postcode), '  +'::text, ' '::text, 'g'::text) AS search_string
FROM helper
WHERE
start_number IS NOT NULL AND
start_alpha IS NOT NULL AND
end_number IS NULL
) AS _t WHERE
search_string='something';





   QUERY PLAN   




 

 Subquery Scan on _t  (cost=7715.15..2141451.98 rows=55630 width=4) (actual
time=4132.959..4132.959 rows=0 loops=1)
   Output: _t.id
   Filter: (_t.search_string = 'something'::text)
   ->  Bitmap Heap Scan on data_table (cost=7715.15..1557337.03
rows=11125999 width=45) (actual time=92.290..4066.518 rows=403344 loops=1)
 Output: id,
regexp_replace(btrimCOALESCE(((NULLIF(start_number, 0))::text || '
'::text), ''::text) || upper(regexp_replace(btrim(((COALESCE((name || '
'::text), ''::text) || COALESCE((extension || ' '::text), ''::text)) ||
COALESCE(direction, ''::text))), '  +'::text, ' '::text, 'g'::text))) || '
'::text) || upper(regexp_replace(btrim(COALESCE(locality_name, ''::text)), '
 +'::text, ' '::text, 'g'::text))) || ' '::text) ||
upper(regexp_replace(btrim(COALESCE(state_code, ''::text)), '  +'::text, '
'::text, 'g'::text))) || ' '::text) ||
upper(regexp_replace(btrim(COALESCE(post_code, ''::text)), '  +'::text, '
'::text, 'g'::text, '  +'::text, ' '::text, 'g'::text)
 Recheck Cond: ((start_number IS NOT NULL) AND
(upper((start_alpha)::text) IS NOT NULL) AND (end_number IS NULL))
 ->  Bitmap Index Scan on ix_search_full5  (cost=0.00..4933.65
rows=11125999 width=0) (actual time=59.118..59.118 rows=403344 loops=1)
 Total runtime: 4133.001 ms
(8 rows)


--fast on both 9.1.3 and 8.3.13
--flat version (search_string condition manually inlined)
db=# explain (analyze, verbose)
SELECT
id
FROM helper
WHERE
start_number IS NOT NULL AND
start_alpha IS NOT NULL AND
end_number IS NULL AND
regexp_replace(btrim(((COALESCE(NULLIF(start_number, 0) || ' '::text,
''::text) || address) || ' '::text) || suburb) || ' '::text) || state) || '
'::text) || postcode), '  +'::text, ' '::text, 'g'::text) = 'something';




 QUERY PLAN 




 
-

Re: [BUGS] pltclu install problems

2012-05-21 Thread Craig Ringer 

On 05/21/2012 02:47 PM, Szunomár Péter wrote:
Even if i start the createlang.exe pltclu or run the CREATE LANGUAGE 
pltclu sql command from PgAdmin, i receive the following error message:



ERROR:  could not load library "C:/Program 
Files/PostgreSQL/9.1/lib/pltcl.dll": unknown error 126

** Error **
ERROR: could not load library "C:/Program 
Files/PostgreSQL/9.1/lib/pltcl.dll": unknown error 126

SQL state: 58P01


A dependency of pltcl is missing, like a TCL runtime. Windows gives the 
same "cannot find library" error (126) when the library its self is 
missing as when a library it depends on is missing.


If you can't figure out what's missing, use Dependency Walker 
(http://dependencywalker.com) to open pltcl.dll and see what it's 
looking for.


--
Craig Ringer

Re: [BUGS] PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP

2012-05-21 Thread Craig Ringer 

On 05/22/2012 06:28 AM, Edmund Horner wrote:

Hum.  My first email sent to this list a few days ago still has not
arrived, so these two are kind of orphaned.  Should I resend it?


You mean:

"Just a note that pg_upgrade on Windows 7 64-bit did not have this
error.  However, it was a different database in a different
environment." ?

It hit the list fine.

--
Craig Ringer

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

[BUGS] PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP

2012-05-21 Thread Edmund Horner 
(Sending this again to pgsql-bugs with no attachments; hopefully it'll
be accepted.  Apologies for any duplicates!  I'll provide the
attachments if you need them, though I suspect things may become clear
without them.)

Hello,

I'm forwarding this to pgsql-bugs after sending it to pgsql-testers.
I've been a bit confused about how to file it -- the release notes for
the 9.2 beta point to "More information on how to test and report
issues" here:  http://www.postgresql.org/developer/beta/   which could
possibly use a bit more explanation.  Between the beta not being a
normal release, and me not been an official tester, I opted to send it
there anyway since it wasn't a bug in an *existing* release.  But
there is little traffic to pgsql-testers so I have sought advice on
IRC and been advised to send it here too. :-)

I'm not an official tester but I thought I would briefly experiment
with the beta.  I run PostgreSQL as a normal user on Windows XP
at work, which may be an unusual (and increasingly obsolete) case not
covered as much by other
testers.

I ran into a bit of trouble running pg_upgrade to upgrade from my
9.1.3 cluster.  This is the first time I have run pg_upgrade.  It is
entirely possible I've done something wrong.

As a control, I was able to successfully  "upgrade" the Postgresql
9.1.3 cluster into a second, new 9.1.3 cluster, using the 9.1.3
version of pg_upgrade.  Similar command lines and no issues.

If this does look like a bug, I will help to resolve it (though I
might need some guidance).  I have attached some basic information
below.  Let me know if you need more information.

Regards,
Edmund.


Environment
Windows XP Service Pack 3
32-bit mode on Intel Core2 Duo
Data, binaries, and pg_upgrade working files are on an NTFS
partition with 4k cluster size.
User has a domain login and local admin rights.

Old cluster
Version: PostgreSQL 9.1.3
Binaries: C:\ehorner\pgsql
Data: C:\ehorner\pgdata
Locale: C
Encoding: UTF8

New cluster
Version: PostgreSQL 9.2 beta1
Binaries: C:\ehorner\pgsql92
Data: C:\ehorner\pgdata92
Locale: C
Encoding: UTF8

Sequence of steps

Unzip the PostgreSQL 9.2 demo1 binaries into c:\ehorner\pgsql92

Shut down the PostgreSQL 9.1.3 cluster (in c:\ehorner\pgsql\bin):

pg_ctl.exe stop -D c:\ehorner\pgsql

Create a new 9.2 cluster (in C:\ehorner\pgsql92\bin):

initdb.exe --no-locale -E UTF8 c:\ehorner\pgdata92

Run pg_upgrade (in C:\):

c:\ehorner\pgsql92\bin\pg_upgrade -b c:\ehorner\pgsql\bin -B
c:\ehorner\pgsql92\bin -d c:\ehorner\pgdata -D c:\ehorner\pgdata92

Expected output

A message indicating successful upgrade of the old cluster into the new one.

Actual output

Performing Consistency Checks
-
Checking current, bin, and data directories ok
Checking cluster versions   ok
Checking database user is a superuser   ok
Checking for prepared transactions  ok
Checking for reg* system OID user data typesok
Checking for contrib/isn with bigint-passing mismatch   ok
Creating catalog dump   The
process cannot access the file because it is being used by another
process.
*failure*

Consult the last few lines of "pg_upgrade_utility.log" for
the probable cause of the failure.
Failure, exiting
The process cannot access the file because it is being used by
another process.
*failure*
Consult the last few lines of "pg_upgrade_utility.log" for
the probable cause of the failure.

These files are also created (attached, except for
pg_upgrade_dump_all.sql which was 0 bytes):

pg_upgrade_dump_all.sql
pg_upgrade_internal.log
pg_upgrade_restore.log
pg_upgrade_server.log
pg_upgrade_utility.log

Running again with -v gives the output shown in output-verbose.txt.
The two lines "The process cannot access the file because it is being
used by another process." appear on stderr, which I piped along with
stdout into that file.

Finally, I have also run it using the "Filemon" program to monitor
file system calls.  Filtering on pg_upgrade gets the result shown in
filemon-output.txt.  There is some cruft from antivirus and other
bloatware which I have removed (since I shouldn't publicise the work
environment too much).  The antivirus does
query the directory information of some of the files, but does not
appear to open them.

There are some SHARING VIOLATION errors on accessing
pg_upgrade_utility.log.  My guess is that's what causes the error.
It's possible the antivirus is interfering with the file (since it
does touch it) but I do not think it explains the problem since the
9.1.3 ->  9.1.3 upgrade had no problems.  I think it could be due to
the change in dump.c where this log file name is used as a pipe
destination in another exec'd program.  Maybe

Re: [BUGS] PostgreSQL 9.2 beta1's pg_upgrade fails on Windows XP

2012-05-21 Thread Craig Ringer 

First: Best. Bug. Report. Ever.

Comments inline, though I don't know enough about the Windows side to 
help much.



 Checking for contrib/isn with bigint-passing mismatch   ok
 Creating catalog dump   The
process cannot access the file because it is being used by another
process.
 *failure*


Your speculation that antivirus may be involved is worth trying out, 
though the fact that a different upgrade worked does indeed suggest it's 
probably not that.


When you shut down the 9.1.3 cluster did you make absolutely certain 
there were no postgres.exe processes lurking around when you tested? 
Given the incredible thouroughness of your report I imagine you did, but 
it's worth checking, as a lingering `postgres.exe' could (I imagine) 
cause such an issue. Not that it should ever happen.


Do you have the option of re-trying with your AV disabled or removed?

--
Craig Ringer

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