|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Nathan Bossart <nathandbossart(at)gmail(dot)com>|
|Cc:||Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Fujii Masao <fujii(at)postgresql(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Weird failure with latches in curculio on v15|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2023-02-05 15:57:47 -0800, Nathan Bossart wrote:
> > For the segment files, we'd likely need a parameter to indicate whether
> > the restore is random or not.
> Wouldn't this approach still require each module to handle restoring ahead
> of time?
Yes, to some degree at least. I was just describing a few pretty obvious
The core code can make that a lot easier though. The problem of where to
store such files can be provided by core code (presumably a separate
directory). A GUC for aggressiveness can be provided. Etc.
> I agree that the shell overhead isn't the main performance issue,
> but it's unclear to me how much of this should be baked into
I don't know fully either. But just reimplementing all of it in
different modules doesn't seem like a sane approach either. A lot of it
is policy that we need to solve once, centrally.
> I mean, we could introduce a GUC that tells us how far ahead to
> restore and have a background worker (or multiple background workers)
> asynchronously pull files into a staging directory via the callbacks.
> Is that the sort of scope you are envisioning?
Closer, at least.
|Next Message||Michael Paquier||2023-02-06 00:35:16||Re: Add progress reporting to pg_verifybackup|
|Previous Message||Nathan Bossart||2023-02-05 23:57:47||Re: Weird failure with latches in curculio on v15|