[Pgpool-general] pgpool 2.2.4: DEALLOCATED children
Tatsuo Ishii
ishii at sraoss.co.jp
Wed Sep 23 11:16:41 UTC 2009
Agustín,
> > > Hi
> > >
> > > We applied the patch with the same result. After some
> > seconds child
> > > processes go into DEALLOCATE state until pgpool gets
> > completly hang.
[snip]
> > > i attached the complete log for one of these
> > processes.
> > >
> > >
> > > Please any test we can do to help the analsys just let
> > us know.
> >
> > It seems cause of this is, pgpool sends BEGIN to PostgreSQL
> > and
> > PostgreSQL replies ERROR for unknown reason. I need to know
> > why
> > PostgreSQL emits ERROR. Can you find error messages in the
> > PostgreSQL
> > log?
Ok, I think for some reason DEALLOCATE fails and the internal list
which manages prepared objects is not updated, and same request is
issued over and over again. I need to know why DEALLOCATE fails, but
at least we should prepare for this kind of cases. Attached patches
implement this. Please try if you like.
Glyn,
> We saw a similar(ish) issue here where a pgpool backend went into an aparent infinite loop sending the same dealocate statement to the postgres server, but I couldn't reproduce it at the time.
>
> However this was on 2.2.3, and at the same time as moving to 2.2.3 I changed reset_query_list to 'ABORT; DISCARD ALL'.
>
> The next day 2.2.4 was released so we upgraded and I switched reset_query_list back to 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT'.
>
> I've not seen any issues since, using 'ABORT; DISCARD ALL' has always caused problems for me though.
What kind of problem do you have with DISCARD ALL?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
-------------- next part --------------
Index: pool_process_query.c
===================================================================
RCS file: /cvsroot/pgpool/pgpool-II/pool_process_query.c,v
retrieving revision 1.141.2.19
diff -c -r1.141.2.19 pool_process_query.c
*** pool_process_query.c 17 Sep 2009 11:17:09 -0000 1.141.2.19
--- pool_process_query.c 23 Sep 2009 11:08:33 -0000
***************
*** 1755,1761 ****
pool_write(frontend, &kind, 1);
sendlen = htonl(len1+4);
pool_write(frontend, &sendlen, sizeof(sendlen));
! status = pool_write(frontend, p1, len1);
}
/* save the received result for each kind */
--- 1755,1761 ----
pool_write(frontend, &kind, 1);
sendlen = htonl(len1+4);
pool_write(frontend, &sendlen, sizeof(sendlen));
! pool_write(frontend, p1, len1);
}
/* save the received result for each kind */
***************
*** 1863,1870 ****
ret = SimpleForwardToFrontend(kind1, frontend, backend);
if (ret != POOL_CONTINUE)
return ret;
! if (pool_flush(frontend))
! return POOL_END;
}
if (ret != POOL_CONTINUE)
--- 1863,1869 ----
ret = SimpleForwardToFrontend(kind1, frontend, backend);
if (ret != POOL_CONTINUE)
return ret;
! pool_flush(frontend);
}
if (ret != POOL_CONTINUE)
***************
*** 2035,2043 ****
}
/*
! * Describe message with a portal name receive two messages.
* 1. ParameterDescription
* 2. RowDescriptions or NoData
*/
if (kind == 'D' && *p == 'S')
{
--- 2034,2043 ----
}
/*
! * Describe message with a portal name will receive two messages.
* 1. ParameterDescription
* 2. RowDescriptions or NoData
+ * So we read one message here.
*/
if (kind == 'D' && *p == 'S')
{
***************
*** 2049,2054 ****
--- 2049,2057 ----
return POOL_END;
}
+ /*
+ * Forward to frontend until a NOTICE message received.
+ */
for (;;)
{
ret = read_kind_from_backend(frontend, backend, &kind1);
***************
*** 2166,2172 ****
return 2;
}
! send_deallocate(backend, &prepared_list, 0);
return 1;
}
--- 2169,2183 ----
return 2;
}
! /* Delete from prepared list */
! if (send_deallocate(backend, &prepared_list, 0))
! {
! /* Deallocate failed. We are in unknown state. Ask caller
! * to reset backend connection.
! */
! reset_prepared_list(&prepared_list);
! return -1;
! }
return 1;
}
More information about the Pgpool-general
mailing list