Re: Background worker/idle sessions and caching

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeremy Finzel <finzelj(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Background worker/idle sessions and caching
Date: 2018-07-18 20:05:39
Message-ID: 22246.1531944339@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeremy Finzel <finzelj(at)gmail(dot)com> writes:
> I have a background worker running SQL functions, and I believe I have
> noticed that when I do things like change function definitions, or even add
> tables, the background worker does not pick up the schema changes until I
> restart the worker.

Maybe you need some AcceptInvalidationMessages() at appropriate points
in the worker? ProcessCatchupInterrupts() might be relevant as well,
though if you're worried about this, you probably don't want to ever
be so far behind as to get triggered by that.

There might well be a system structural bug here: I'm not sure whether
bg workers participate in shared-inval signaling at all, or whether they
can opt in or out of that. But if they do or can, then a bg worker that
isn't holding up its end of things by processing catchup interrupts can
break the entire system's processing of catchups, because of the
daisy-chain behavior that we put in awhile back to prevent all backends
from firing catchup processing at the same time. There's an assumption
that all processes that are eligible to receive catchup signals will
play nice and pass the signal on reasonably quickly.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2018-07-18 20:14:30 Re: psql's \d versus included-index-column feature
Previous Message Heikki Linnakangas 2018-07-18 20:04:54 Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)