Re: [BUGS] npgssql 5gb installation

2012-11-20 Thread Ashesh Vashi 
On Tue, Nov 20, 2012 at 3:56 PM, Peter Kroon  wrote:

> Hi,
>
> *9.2.1 W732*
> I've installed Npgsql via stackbuilder.
> I could not get it to "run".
> <%@ Assembly name="Npgsql" %> failed and
> <%@ Import Namespace="Npgsql" %> failed as well.
> So I uninstall and found out that npgsql is 5gb.
>
Hi Peter,

Can you please tell us, what is the content of that directory?
--

Thanks & Regards,

Ashesh Vashi
EnterpriseDB INDIA: Enterprise PostgreSQL Company



*http://www.linkedin.com/in/asheshvashi*


>
> Screenshot: http://5060.nl/postgresql/npgsql.jpg
>
> I wanted to test npgsql vs odbc.
> I'll stick to odbc for now.
>
> Peter
>

[BUGS] BUG #7683: pg_upgrade missing configuration file

2012-11-20 Thread bernhard . schrader 
The following bug has been logged on the website:

Bug reference:  7683
Logged by:  Bernhard Schrader
Email address:  bernhard.schra...@innogames.de
PostgreSQL version: 9.2.1
Operating system:   Debian Squeeze
Description:

Hi there,

short term explanation, I have the problem in Debian that I can't do a
normal pg_upgrade if I do not link /etc/postgresql/x.y/main/postgresql.conf
to /var/lib/postgresql/x.y/main/postgresql.conf, the /var/lib is the normal
datadirectory, which i add to the -d option, but debian has a seperate
configuration directory. As there are direct parameter missing for adding
this directory to the pg_upgrade command I have to link it. Also, trying to
add /etc/postgresql/x.y/main/ as data directory doesn't help, the values for
the data directory should be readable throughout the config. But if I try
it, it gives me the error message:

/usr/lib/postgresql/9.2/bin/pg_upgrade -b /usr/lib/postgresql/9.0/bin/ -B
/usr/lib/postgresql/9.2/bin/ -d /etc/postgresql/9.0/main/ -D
/etc/postgresql/9.2/main/ -p 5432 -P 5433 -v
Running in verbose mode
Finding the real data directory for the old cluster
/usr/lib/postgresql/9.0/bin/postmaster: invalid option -- 'C'
Try "postmaster --help" for more information.

Could not get data directory using "/usr/lib/postgresql/9.0/bin/postmaster"
-D "/etc/postgresql/9.0/main/" -C data_directory: No such file or directory
Failure, exiting

Which shouldn't be surprising because 9.0 doesn't has the -C option, but 9.2
has it. 

Here the output if i set the data directory correctly to
/var/lib/postgresql/x.y/main without link to postgresql.conf:

/usr/lib/postgresql/9.2/bin/pg_upgrade --check -b
/usr/lib/postgresql/9.0/bin/ -B /usr/lib/postgresql/9.2/bin/ -d
/var/lib/postgresql/9.0/main/ -D /var/lib/postgresql/9.2/main/ -p 5432 -P
5433 -v
Running in verbose mode
Performing Consistency Checks
-
Checking current, bin, and data directories ok
Checking cluster versions   ok
pg_control values:

First log file ID after reset:32
First log file segment after reset:   18
pg_control version number:903
Catalog version number:   201008051
Database system identifier:   5570989883231871453
Latest checkpoint's TimeLineID:   3
Latest checkpoint's NextXID:  0/2415720
Latest checkpoint's NextOID:  407531
Latest checkpoint's NextMultiXactId:  188
Latest checkpoint's NextMultiOffset:  376
Latest checkpoint's oldestXID:654
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Maximum data alignment:   8
Database block size:  8192
Blocks per segment of large relation: 131072
WAL block size:   8192
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index:  32
Maximum size of a TOAST chunk:1996
Date/time type storage:   64-bit integers
Float4 argument passing:  by value
Float8 argument passing:  by value
pg_control values:

First log file ID after reset:0
First log file segment after reset:   2
pg_control version number:922
Catalog version number:   201204301
Database system identifier:   5812825747830308730
Latest checkpoint's TimeLineID:   1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:  0/1773
Latest checkpoint's NextOID:  12844
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:1763
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Maximum data alignment:   8
Database block size:  8192
Blocks per segment of large relation: 131072
WAL block size:   8192
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index:  32
Maximum size of a TOAST chunk:1996
Date/time type storage:   64-bit integers
Float4 argument passing:  by value
Float8 argument passing:  by value
"/usr/lib/postgresql/9.0/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D
"/var/lib/postgresql/9.0/main/" -o "-p 5432 -c autovacuum=off -c
autovacuum_freeze_max_age=20  -c listen_addresses='' -c
unix_socket_permissions=0700" start >> "pg_upgrade_server.log" 2>&1
*failure*
There were problems executing ""/usr/lib/postgresql/9.0/bin/pg_ctl" -w -l
"pg_upgrade_server.log" -D "/var/lib/postgresql/9.0/main/" -o "-p 5432 -c
autovacuum=off -c autovacuum_freeze_max_age=20  -c
listen_addresses='' -c unix_socket_permissions=0700" start >>
"pg_upgrade_server.log" 2>&1"
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure.

connection to database failed: could not connect to server: No such file or
directory

Re: [BUGS] BUG #7676: pgSocketCheck dosen`t return

2012-11-20 Thread Tom Lane 
yongchao...@newtouch.cn writes:
> I have this problem today: one thread of our application hung, and
> we found the thread waiting for the result of poll() function. poll()
> was called by pgSocketCheck(). So is it a bug of pg?

So far as anyone can tell, this trace just indicates that the
application is waiting for a response from the server.  If there's
a bug there, you'd need to provide more or different information to
prove it.  I think more likely you need to be consulting
http://wiki.postgresql.org/wiki/Slow_Query_Questions

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 #7684: pg_dumpall doesn't sort "CREATE SERVER"s options correctly

2012-11-20 Thread timur . luchkin 
The following bug has been logged on the website:

Bug reference:  7684
Logged by:  Timur Luchkin
Email address:  timur.luch...@gmail.com
PostgreSQL version: 9.2.1
Operating system:   OpenSolaris
Description:

Looks like pg_dumpall sorts 'create server FOREIGN DATA WRAPPER' options
(keys) as varchar and not as integer. 
Example from dumped sql (see "pX" option key):

CREATE SERVER can_master_cluster FOREIGN DATA WRAPPER plproxy OPTIONS (
connection_lifetime '1800',
p0 'dbname=database11 host=xxx-11 port=9811',
p1 'dbname=database12 host=xxx-12 port=9812',
p10 'dbname=database21 host=xxx-21 port=9821',
p11 'dbname=database22 host=xxx-22 port=9822',
p12 'dbname=database23 host=xxx-23 port=9823',
p13 'dbname=database24 host=xxx-24 port=9824',
p14 'dbname=database25 host=xxx-25 port=9825',
p15 'dbname=database26 host=xxx-26 port=9826',
p2 'dbname=database13 host=xxx-13 port=9813',
p3 'dbname=database14 host=xxx-14 port=9814',
p4 'dbname=database15 host=xxx-15 port=9815',
p5 'dbname=database16 host=xxx-16 port=9816',
p6 'dbname=database17 host=xxx-17 port=9817',
p7 'dbname=database18 host=xxx-18 port=9818',
p8 'dbname=database19 host=xxx-19 port=9819',
p9 'dbname=database20 host=xxx-20 port=9820'
);

which causes next error during the load:
ERROR:  Pl/Proxy: partitions must be numbered consecutively
HINT:  next valid partition number is 2
STATEMENT:  CREATE SERVER can_master_cluster ...

Old 9.0 'pg_dumpall' doing job correct.




-- 
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 #7685: last_value() not consistent throughout window partition

2012-11-20 Thread wes 
The following bug has been logged on the website:

Bug reference:  7685
Logged by:  Wes Devauld
Email address:  w...@devauld.ca
PostgreSQL version: 9.2.1
Operating system:   Windows 7 Enterprise
Description:

-- The last_value(0 window function appears to be changing values
-- mid window.  An example is detailed below.

SELECT version();
--   version
-
-- PostgreSQL 9.1.6, compiled by Visual C++ build 1500, 32-bit

-

--  DB DUMP 
--
-- PostgreSQL database dump
--

-- Dumped from database version 9.1.4
-- Dumped by pg_dump version 9.1.4
-- Started on 2012-11-19 15:01:41

SET statement_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
SET client_min_messages = warning;

SET search_path = public, pg_catalog;

SET default_tablespace = '';

SET default_with_oids = false;

--
-- TOC entry 170 (class 1259 OID 25186)
-- Dependencies: 5
-- Name: bug_report; Type: TABLE; Schema: public; Owner: postgres;
Tablespace: 
--

CREATE TABLE bug_report (
d1 date NOT NULL,
d2 date NOT NULL,
v real NOT NULL
);


ALTER TABLE public.bug_report OWNER TO postgres;

--
-- TOC entry 1880 (class 0 OID 25186)
-- Dependencies: 170
-- Data for Name: bug_report; Type: TABLE DATA; Schema: public; Owner:
postgres
--

COPY bug_report (d1, d2, v) FROM stdin;
2012-11-19  2012-11-07  358363
2012-11-18  2012-11-07  358363
2012-11-17  2012-11-07  358363
2012-11-16  2012-11-07  257572
2012-11-15  2012-11-07  257572
2012-11-14  2012-11-07  257572
2012-11-13  2012-11-07  257572
2012-11-12  2012-11-07  257572
2012-11-11  2012-11-07  257572
2012-11-10  2012-11-07  257572
\.


-- Completed on 2012-11-19 15:01:42

-- Description 

select d2, last_value(v) over (partition by d2 order by d1),
   first_value(v) over (partition by d2 order by d1 desc)
from bug_report

--Returns:
--"2012-11-07";358363;358363
--"2012-11-07";358363;358363
--"2012-11-07";358363;358363
--"2012-11-07";257572;358363
--"2012-11-07";257572;358363
--"2012-11-07";257572;358363
--"2012-11-07";257572;358363
--"2012-11-07";257572;358363
--"2012-11-07";257572;358363
--"2012-11-07";257572;358363

--You can see that the last_value() 
--switches in the middle of the
--partition for the window function 
--when both columns should be 
--identical since the first/last 
--and asc/desc changes should
--cancel each other out.  


--Thanks, and good work with the product.





-- 
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 #7684: pg_dumpall doesn't sort "CREATE SERVER"s options correctly

2012-11-20 Thread Tom Lane 
timur.luch...@gmail.com writes:
> Looks like pg_dumpall sorts 'create server FOREIGN DATA WRAPPER' options
> (keys) as varchar and not as integer. 

AFAIK there's no particular guarantee that they're dumped in any
specific order.

> which causes next error during the load:
> ERROR:  Pl/Proxy: partitions must be numbered consecutively
> HINT:  next valid partition number is 2

I'd say this is either a bug or a misdesign of pl/proxy.  It should not
be expecting that FDW options are stored in any specific physical order.
Suggest reporting it at plproxy-us...@pgfoundry.org.

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

{Not A Bug} RE: [BUGS] BUG #7685: last_value() not consistent throughout window partition

2012-11-20 Thread David Johnston 
> -Original Message-
> From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-
> ow...@postgresql.org] On Behalf Of w...@devauld.ca
> Sent: Tuesday, November 20, 2012 10:28 AM
> To: pgsql-bugs@postgresql.org
> Subject: [BUGS] BUG #7685: last_value() not consistent throughout window
> partition
> 
> The following bug has been logged on the website:
> 
> Bug reference:  7685
> Logged by:  Wes Devauld
> Email address:  w...@devauld.ca
> PostgreSQL version: 9.2.1
> Operating system:   Windows 7 Enterprise
> Description:
> 
> -- The last_value(0 window function appears to be changing values
> -- mid window.  An example is detailed below.
> 
> SELECT version();
> --   version
> -
> -- PostgreSQL 9.1.6, compiled by Visual C++ build 1500, 32-bit
> 
> -
> 
> --  DB DUMP 
> --
> -- PostgreSQL database dump
> --
> 
> -- Dumped from database version 9.1.4
> -- Dumped by pg_dump version 9.1.4
> -- Started on 2012-11-19 15:01:41
> 
> SET statement_timeout = 0;
> SET client_encoding = 'UTF8';
> SET standard_conforming_strings = on;
> SET check_function_bodies = false;
> SET client_min_messages = warning;
> 
> SET search_path = public, pg_catalog;
> 
> SET default_tablespace = '';
> 
> SET default_with_oids = false;
> 
> --
> -- TOC entry 170 (class 1259 OID 25186)
> -- Dependencies: 5
> -- Name: bug_report; Type: TABLE; Schema: public; Owner: postgres;
> Tablespace:
> --
> 
> CREATE TABLE bug_report (
> d1 date NOT NULL,
> d2 date NOT NULL,
> v real NOT NULL
> );
> 
> 
> ALTER TABLE public.bug_report OWNER TO postgres;
> 
> --
> -- TOC entry 1880 (class 0 OID 25186)
> -- Dependencies: 170
> -- Data for Name: bug_report; Type: TABLE DATA; Schema: public; Owner:
> postgres
> --
> 
> COPY bug_report (d1, d2, v) FROM stdin;
> 2012-11-192012-11-07  358363
> 2012-11-182012-11-07  358363
> 2012-11-172012-11-07  358363
> 2012-11-162012-11-07  257572
> 2012-11-152012-11-07  257572
> 2012-11-142012-11-07  257572
> 2012-11-132012-11-07  257572
> 2012-11-122012-11-07  257572
> 2012-11-112012-11-07  257572
> 2012-11-102012-11-07  257572
> \.
> 
> 
> -- Completed on 2012-11-19 15:01:42
> 
> -- Description 
> 
> select d2, last_value(v) over (partition by d2 order by d1),
>first_value(v) over (partition by d2 order by d1 desc) from 
> bug_report
> 
> --Returns:
> --"2012-11-07";358363;358363
> --"2012-11-07";358363;358363
> --"2012-11-07";358363;358363
> --"2012-11-07";257572;358363
> --"2012-11-07";257572;358363
> --"2012-11-07";257572;358363
> --"2012-11-07";257572;358363
> --"2012-11-07";257572;358363
> --"2012-11-07";257572;358363
> --"2012-11-07";257572;358363
> 
> --You can see that the last_value()
> --switches in the middle of the
> --partition for the window function
> --when both columns should be
> --identical since the first/last
> --and asc/desc changes should
> --cancel each other out.
> 
> 
> --Thanks, and good work with the product.
> 

Not A Bug.

When you add an "Order By" the resultant window FRAME is from the first record 
(of the partition) up-to-and-including the current record (of the partition); 
no "future" records (in the partition) are part of the window FRAME.  Thus for 
"last_value" you are always implicitly referring to the current row (of the 
FRAME).  This is defined and documented behavior.  In order to use "last_value" 
you need to override the FRAME that the window operates on to include all rows.

http://www.postgresql.org/docs/9.2/interactive/functions-window.html - read the 
second paragraph following the table and explore from there

David J.




-- 
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 #7685: last_value() not consistent throughout window partition

2012-11-20 Thread Tom Lane 
w...@devauld.ca writes:
> -- The last_value(0 window function appears to be changing values
> -- mid window.  An example is detailed below.

So far as I can see, these results are correct per spec.  Note the
caution in the manual about these window functions:

  Note that first_value, last_value, and nth_value consider only the rows
  within the "window frame", which by default contains the rows from the
  start of the partition through the last peer of the current row. This is
  likely to give unhelpful results for last_value and sometimes also
  nth_value. You can redefine the frame by adding a suitable frame
  specification (RANGE or ROWS) to the OVER clause. See Section 4.2.8 for
  more information about frame specifications.

Since your d1 values are all distinct, the last peer is the same as the
current row, so last_value(v) ends up just producing the current row's v.
Which is what the query is producing.

If you want the last row in the partition, you could use first_value
with the opposite sort order, or use last_value with the same sort
order and RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING.
(The current SQL committee is nothing if not verbose :-()

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 #7643: Issuing a shutdown request while server startup leads to server hang

2012-11-20 Thread Tom Lane 
Hari Babu  writes:
>> We're going to need more details about how to reproduce this.

> The problem occurs only when active server is restarting by just adding a
> recovery.conf file to the data directory. 

Well, you can't just put an empty file there, but I eventually managed
to reproduce this with the suggested hack in xlog.c.

I think the key problem is that postmaster.c's sigusr1_handler() is
willing to start new children even after shutdown has been initiated.
I don't see any good reason for it to do that, so I think the
appropriate patch is as attached.

Changing that still leaves us with the postmaster thinking that the
eventual exit(1) of the startup process is a "crash".  This is mostly
cosmetic since it still shuts down okay, but we can fix it by reversing
the order of the first two checks in reaper() --- that is, if Shutdown
is set, we should prefer that code path even if we're in PM_STARTUP
state.

I concluded that it probably wasn't a good idea to have the additional
state transition in SIGINT handling.  Generally PM_STARTUP means "we're
running the startup process and nothing else", and that's useful state
info that we shouldn't throw away lightly.


regards, tom lane

diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index b223feefbab0645667449f643c6c8adee3747ef0..6f93d93fa3f7577fb9157f0bea805c427e3605dd 100644
*** a/src/backend/postmaster/postmaster.c
--- b/src/backend/postmaster/postmaster.c
*** pmdie(SIGNAL_ARGS)
*** 2261,2269 
  			if (pmState == PM_RECOVERY)
  			{
  /*
!  * Only startup, bgwriter, and checkpointer should be active
!  * in this state; we just signaled the first two, and we don't
!  * want to kill checkpointer yet.
   */
  pmState = PM_WAIT_BACKENDS;
  			}
--- 2261,2269 
  			if (pmState == PM_RECOVERY)
  			{
  /*
!  * Only startup, bgwriter, walreceiver, and/or checkpointer
!  * should be active in this state; we just signaled the first
!  * three, and we don't want to kill checkpointer yet.
   */
  pmState = PM_WAIT_BACKENDS;
  			}
*** reaper(SIGNAL_ARGS)
*** 2355,2360 
--- 2355,2372 
  			StartupPID = 0;
  
  			/*
+ 			 * Startup process exited in response to a shutdown request (or it
+ 			 * completed normally regardless of the shutdown request).
+ 			 */
+ 			if (Shutdown > NoShutdown &&
+ (EXIT_STATUS_0(exitstatus) || EXIT_STATUS_1(exitstatus)))
+ 			{
+ pmState = PM_WAIT_BACKENDS;
+ /* PostmasterStateMachine logic does the rest */
+ continue;
+ 			}
+ 
+ 			/*
  			 * Unexpected exit of startup process (including FATAL exit)
  			 * during PM_STARTUP is treated as catastrophic. There are no
  			 * other processes running yet, so we can just exit.
*** reaper(SIGNAL_ARGS)
*** 2369,2386 
  			}
  
  			/*
- 			 * Startup process exited in response to a shutdown request (or it
- 			 * completed normally regardless of the shutdown request).
- 			 */
- 			if (Shutdown > NoShutdown &&
- (EXIT_STATUS_0(exitstatus) || EXIT_STATUS_1(exitstatus)))
- 			{
- pmState = PM_WAIT_BACKENDS;
- /* PostmasterStateMachine logic does the rest */
- continue;
- 			}
- 
- 			/*
  			 * After PM_STARTUP, any unexpected exit (including FATAL exit) of
  			 * the startup process is catastrophic, so kill other children,
  			 * and set RecoveryError so we don't try to reinitialize after
--- 2381,2386 
*** sigusr1_handler(SIGNAL_ARGS)
*** 4283,4289 
  	 * first. We don't want to go back to recovery in that case.
  	 */
  	if (CheckPostmasterSignal(PMSIGNAL_RECOVERY_STARTED) &&
! 		pmState == PM_STARTUP)
  	{
  		/* WAL redo has started. We're out of reinitialization. */
  		FatalError = false;
--- 4283,4289 
  	 * first. We don't want to go back to recovery in that case.
  	 */
  	if (CheckPostmasterSignal(PMSIGNAL_RECOVERY_STARTED) &&
! 		pmState == PM_STARTUP && Shutdown == NoShutdown)
  	{
  		/* WAL redo has started. We're out of reinitialization. */
  		FatalError = false;
*** sigusr1_handler(SIGNAL_ARGS)
*** 4300,4306 
  		pmState = PM_RECOVERY;
  	}
  	if (CheckPostmasterSignal(PMSIGNAL_BEGIN_HOT_STANDBY) &&
! 		pmState == PM_RECOVERY)
  	{
  		/*
  		 * Likewise, start other special children as needed.
--- 4300,4306 
  		pmState = PM_RECOVERY;
  	}
  	if (CheckPostmasterSignal(PMSIGNAL_BEGIN_HOT_STANDBY) &&
! 		pmState == PM_RECOVERY && Shutdown == NoShutdown)
  	{
  		/*
  		 * Likewise, start other special children as needed.
*** sigusr1_handler(SIGNAL_ARGS)
*** 4331,4337 
  		signal_child(SysLoggerPID, SIGUSR1);
  	}
  
! 	if (CheckPostmasterSignal(PMSIGNAL_START_AUTOVAC_LAUNCHER))
  	{
  		/*
  		 * Start one iteration of the autovacuum daemon, even if autovacuuming
--- 4331,4338 
  		signal_child(SysLoggerPID, SIGUSR1);
  	}
  
! 	if (CheckPostmasterSignal(PMSIGNAL_START_AUTOVAC_LAUNCHER) &&
! 		Shutdown == NoShutdown)

Re: [BUGS] BUG #7676: pgSocketCheck dosen`t return

2012-11-20 Thread Amit Kapila 
On Monday, November 19, 2012 11:31 AM yongchao...@newtouch.cn wrote:
> The following bug has been logged on the website:
> 
> Bug reference:  7676
> Logged by:  yonchao
> Email address:  yongchao...@newtouch.cn
> PostgreSQL version: 8.4.6
> Operating system:   CentOS 5.5（64bit）
> Description:
> 
> I have this problem today: one thread of our application hung, and
> we found the thread waiting for the result of poll() function. poll()
> was called by pgSocketCheck(). So is it a bug of pg? I found the bug
> report from
> website(http://archives.postgresql.org/pgsql-bugs/2008-02/msg00260.php),
> and want to know:
> 
> 1. Has this problem been solved in the newest version?
> 2. If not, what shall I do to avoid this problem?
> 
> Thanks a lot!
> 
> PS:
> gdb info:
> (gdb) bt
> #0 0x00d31402 in __kernel_vsyscall ()
> #1 0x003d3dc3 in poll () from /lib/i686/nosegneg/libc.so.6
> #2 0x0013de5d in pqSocketCheck () from /usr/local/pgsql/lib/libpq.so.5
> #3 0x0013df8d in pqWaitTimed () from /usr/local/pgsql/lib/libpq.so.5
> #4 0x0013e003 in pqWait () from /usr/local/pgsql/lib/libpq.so.5
> #5 0x0013d792 in PQgetResult () from /usr/local/pgsql/lib/libpq.so.5

I have also observed similar problem in some of tests, but it appears to be 
hung due to network break and it came out after 15-20 minutes.

With Regards,
Amit Kapila. 



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