|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|Cc:||Michael Banck <michael(dot)banck(at)credativ(dot)de>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Offline enabling/disabling of data checksums|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Sun, Mar 17, 2019 at 12:44:39PM +0100, Fabien COELHO wrote:
> I could remove the two "catalog/" includes from pg_resetwal, I assume that
> you meant these ones.
Not exactly. What I meant is that if you try to call directly
fsync_fname and fsync_parent_path from file_utils.h, then you get into
trouble because of xlog.h.. Sure you can remove also the ones you
> Hmmm. I just did that, but what about just a boolean? What other options
> could be required? Maybe some locking/checking?
It is already expected from the caller to properly take
ControlFileLock. Note I tend to worry too much about the
extensibility of published APIs these days as well, so perhaps just a
boolean would be fine, please let me reconsider that after some sleep,
and it is not like the contents of this routine are going to become
much complicated either, except potentially to control the flags on
> I kept the initial no-parameter function which calls the new one with 4
> parameters, though, because it looks more homogeneous this way in the
> backend code. This is debatable.
True, this actually makes back-patching a bit easier, and there are 13
calls of UpdateControlFile().
> Attached is an update.
Thanks, I'll take a look at that tomorrow. You have one error at the
end of update_controlfile(), where close() could issue a frontend-like
error for the backend, calling exit() on the way. That's not good.
(No need to send a new patch, I'll fix it myself.)
|Next Message||Sergei Kornilov||2019-03-17 12:53:42||Re: using index or check in ALTER TABLE SET NOT NULL|
|Previous Message||Dean Rasheed||2019-03-17 12:14:15||Re: [HACKERS] PATCH: multivariate histograms and MCV lists|