From: | Shawn Debnath <sdn(at)amazon(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pendingOps table is not cleared with fsync=off |
Date: | 2020-08-10 21:02:35 |
Message-ID: | 20200810210235.GB83133@f01898859afd.ant.amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 10, 2020 at 02:50:26PM -0400, Tom Lane wrote:
>
> Shawn Debnath <sdn(at)amazon(dot)com> writes:
> > Good catch. Question is, are the users aware of the requirement to do a
> > manual fsync if they flip the fsync GUC off and then on? Should we do
> > this on their behalf to make a good faith attempt to ensure things are
> > flushed properly via an assign hook?
>
> No. Or at least, expecting that you can do that from an assign hook
> is impossibly wrong-headed. GUC assign hooks can't have failure modes.
Okay agree, will remind myself to drink more coffee next time.
If we think a fsync should be performed in this case, assign hook
could set a value to indicate parameter was reset via SIGHUP. Next call
to ProcessSyncRequests() could check for this, do a fsync prior to
absorbing the newly submitted sync requests, and reset the flag.
fsync_pgdata() comes to mind to be inclusive.
If folks are not inclined to do the fsync, the change is good as is.
--
Shawn Debnath
Amazon Web Services (AWS)
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-08-10 21:15:50 | Re: nested queries vs. pg_stat_activity |
Previous Message | Jim Nasby | 2020-08-10 20:41:42 | Re: autovac issue with large number of tables |