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 * FROM pg_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(at)postgresql(dot)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 * FROM pg_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