Обсуждение: Portal suddenly disappears?
While looking at pgpool-II user's complain, I see weired thing in the PostgreSQL log. Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4559-1] LOG: 00000: statement: PREPARE pgpool19528 AS SELECT count(*) from(SELECT has_function_privilege('measure', Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4559-2] 'pgpool_regclass(cstring)', 'execute') WHERE EXISTS(SELECT * FROMpg_catalog.pg_proc AS p WHERE p.proname = 'pgpool_regclass')) Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4559-3] AS s Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4559-4] LOCATION: exec_parse_message, postgres.c:1159 Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4560-1] LOG: 00000: statement: <BIND> pgpool19528 Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4560-2] LOCATION: exec_bind_message, postgres.c:1460 Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4561-1] ERROR: 34000: portal "pgpool19528" does not exist Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4561-2] LOCATION: exec_execute_message, postgres.c:1669 The portal "portal19528" was created by a bind message (pgpool-II uses the identical name as the named statement) then subsequent exec_bind_message failed to find the portal. Could it ever happen? According to the user, PostgreSQL version is 8.1.23. Could it be a source of problem? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
Tatsuo Ishii <ishii@postgresql.org> writes: > While looking at pgpool-II user's complain, I see weired thing in the > PostgreSQL log. > Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4559-1] LOG: 00000: statement: PREPARE pgpool19528 AS SELECT count(*)from (SELECT has_function_privilege('measure', > Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4559-2] 'pgpool_regclass(cstring)', 'execute') WHERE EXISTS(SELECT * FROMpg_catalog.pg_proc AS p WHERE p.proname = 'pgpool_regclass')) > Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4559-3] AS s > Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4559-4] LOCATION: exec_parse_message, postgres.c:1159 > Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4560-1] LOG: 00000: statement: <BIND> pgpool19528 > Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4560-2] LOCATION: exec_bind_message, postgres.c:1460 > Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4561-1] ERROR: 34000: portal "pgpool19528" does not exist > Jan 14 10:04:57 dayrhegrdp005 postgres[25223]: [4561-2] LOCATION: exec_execute_message, postgres.c:1669 > The portal "portal19528" was created by a bind message (pgpool-II uses > the identical name as the named statement) then subsequent > exec_bind_message failed to find the portal. Could it ever happen? I'm confused too. Surely there are lots of ways a portal could get dropped, but most of them would have left traces in the postmaster log, I'd think, since you evidently have log_statement == LOGSTMT_ALL. What was log_min_messages set to? > According to the user, PostgreSQL version is 8.1.23. Could it be a > source of problem? However, it's pretty hard to get excited about debugging something that happened in a release branch that's been out of support for more than three years. regards, tom lane
>> The portal "portal19528" was created by a bind message (pgpool-II uses >> the identical name as the named statement) then subsequent >> exec_bind_message failed to find the portal. Could it ever happen? > > I'm confused too. Surely there are lots of ways a portal could get > dropped, but most of them would have left traces in the postmaster log, > I'd think, since you evidently have log_statement == LOGSTMT_ALL. > What was log_min_messages set to? I don't have it at this moment. I requested the user to give the log_min_messages setting. >> According to the user, PostgreSQL version is 8.1.23. Could it be a >> source of problem? > > However, it's pretty hard to get excited about debugging something > that happened in a release branch that's been out of support for > more than three years. Right. I will ask the user to upgrade to supported versions. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp
>> I'm confused too. Surely there are lots of ways a portal could get >> dropped, but most of them would have left traces in the postmaster log, >> I'd think, since you evidently have log_statement == LOGSTMT_ALL. >> What was log_min_messages set to? > > I don't have it at this moment. I requested the user to give the > log_min_messages setting. It turned out that it is set to default: notice. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp