Re: More info on pg_stat_activity Wait Event Name when is DataFileRead

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: PegoraroF10 <marcos(at)f10(dot)com(dot)br>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More info on pg_stat_activity Wait Event Name when is DataFileRead
Date: 2021-04-19 16:57:57
Message-ID: CA+Tgmob38k0M-Y8uerzdP0GFRLrsVS-qdRtgrGhsGVtdabF5hA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 19, 2021 at 12:17 PM PegoraroF10 <marcos(at)f10(dot)com(dot)br> wrote:
> I´m sure problem was hardware and I hope it does not occur anymore.
> If I have a logical replication and on replica I do a Vacuum Full, Cluster
> or any other EXCLUSIVE LOCK operation which, replication will wait for that.
> I was thinking was about a time to release that lock, or in my situation a
> hardware problem. If N seconds
> later and that file is not released then change DataFileRead to
> DataFileRead + relfilenode

But how would we implement that with reasonable efficiency? If we
called setitimer() before every read() call to set the timeout, and
then again to clear it after the read(), that would probably be
hideously expensive. Perhaps it would work to have a background
"heartbeat" process that pings every backend in the system every 1s or
something like that, and make the signal handler do this, but that
supposes that the signal handler would have ready access to this
information, which doesn't seem totally straightforward to arrange,
and that it would be OK for the signal handler to grab a lock to
update shared memory, which as things stand today is definitely not
safe.

I am not trying to say that there is no way that something like this
could be made to work. There's probably something that can be done. I
don't think I know what that thing is, though.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jehan-Guillaume de Rorthais 2021-04-19 17:02:14 Re: multi-install PostgresNode fails with older postgres versions
Previous Message Tom Lane 2021-04-19 16:53:29 Re: pg_amcheck option to install extension