[pgpool-general: 9421] Re: FATAL: failed to read kind from backend

Ron Johnson ronljohnsonjr at gmail.com
Tue Apr 1 23:12:40 JST 2025


On Tue, Apr 1, 2025 at 5:42 AM Tatsuo Ishii <ishii at postgresql.org> wrote:

> >> On Fri, Mar 28, 2025 at 2:59 AM Tatsuo Ishii <ishii at postgresql.org>
> wrote:
> >>
> >>> >> > OK.  But what _is_ causing  the FATAL "kind mismatch" errors?
> >>> >>
> >>> >> Under investigation. I am failing to reproduce the problem.
> >>> >>
> >>> >
> >>> > Thank you.
> >>> >
> >>> > The error _seems_ to be volume-related: happens more when the system
> is
> >>> > busy.  (But maybe a busy system has more opportunity to trigger the
> bug.
> >>>
> >>> That's my thought too for now.
> >>>
> >>> > Would it help if I cranked up log_min_messages to DEBUG1 or even
> DEBUG2?
> >>>
> >>> Yes, please enable DEBUG1.
> >>>
> >>
> >> I was working on it before I saw your email. 😀   Gzip file sent
> directly
> >> to you, with extract for just the pid that had the error.).
> >>
> >> (Lord, but it generates a lot of log lines!)
> >
> > Thanks.
>
> Looking at the log file, I noticed that you are using the query cache
> feature. To break down the issue, can you disable the query cache
> feature?
>
> memory_cache_enabled = off
> enable_shared_relcache = off
>
> ("enable_shared_relcache = on" uses the query cache feature even if
> "memory_cache_enabled = off").
>

Unfortunately, the decision has been made not to use any connection
pooling, since the application vendor has not tested their applications
with pgpool (or any other).

I'll keep this in my back pocket, though.

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20250401/911b294b/attachment.htm>


More information about the pgpool-general mailing list