| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Allow async standbys wait for sync replication |
| Date: | 2022-03-12 22:33:32 |
| Message-ID: | 20220312223332.GA921069@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Mar 08, 2022 at 06:01:23PM -0800, Andres Freund wrote:
> To me it's architecturally the completely wrong direction. We should move in
> the *other* direction, i.e. allow WAL to be sent to standbys before the
> primary has finished flushing it locally. Which requires similar
> infrastructure to what we're discussing here.
I think this is a good point. After all, WALRead() has the following
comment:
* XXX probably this should be improved to suck data directly from the
* WAL buffers when possible.
Once you have all the infrastructure for that, holding back WAL replay on
async standbys based on synchronous replication might be relatively easy.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2022-03-13 00:45:35 | Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*) |
| Previous Message | Andres Freund | 2022-03-12 22:24:19 | Re: EXPLAIN vs track_io_timing=on vs tests |