Horton
Menu

Re: WIP: WAL prefetch (another approach)

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Stephen Frost <sfrost@snowman.net>, Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, David Steele <david@pgmasters.net>, Dmitry Dolgov <9erthalion6@gmail.com>, Jakub Wartak <Jakub.Wartak@tomtom.com>, Tom Lane <tgl@sss.pgh.pa.us>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Tomas Vondra <tomas.vondra@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-12-29T04:29:52Z
Lists: pgsql-hackers

Attachments

[Replies to two emails]

On Fri, Dec 10, 2021 at 9:40 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
> I am unable to apply these new set of patches on HEAD. Can you please share the rebased patch or if you have any work branch can you please point it out, I will refer to it for the changes.

Hi Ashutosh,

Sorry I missed this.  Rebase attached, and I also have a public
working branch at
https://github.com/macdice/postgres/tree/recovery-prefetch-ii .

On Fri, Nov 26, 2021 at 11:32 AM Tomas Vondra
<tomas.vondra@enterprisedb.com> wrote:
> It's great you posted a new version of this patch, so I took a look a
> brief look at it. The code seems in pretty good shape, I haven't found
> any real issues - just two minor comments:
>
> This seems a bit strange:
>
>     #define DEFAULT_DECODE_BUFFER_SIZE 0x10000
>
> Why not to define this as a simple decimal value?

Changed to (64 * 1024).

> Is there something
> special about this particular value, or is it arbitrary?

It should be large enough for most records, without being ridiculously
large.  This means that typical users of XLogReader (pg_waldump, ...)
are unlikely to fall back to the "oversized" code path for records
that don't fit in the decoding buffer.  Comment added.

> I guess it's
> simply the minimum for wal_decode_buffer_size GUC, but why not to use
> the GUC for all places decoding WAL?

The GUC is used only by xlog.c for replay (and has a larger default
since it can usefully see into the future), but frontend tools and
other kinds of backend WAL decoding things (2PC, logical decoding)
don't or can't respect the GUC and it didn't seem worth choosing a
number for each user, so I needed to pick a default.

> FWIW I don't think we include updates to typedefs.list in patches.

Seems pretty harmless? And useful to keep around in development
branches because I like to pgindent stuff...

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix recovery_prefetch docs.

  2. Prefetch data referenced by the WAL, take II.

  3. Add circular WAL decoding buffer, take II.

  4. Fix generation of ./INSTALL for the distribution tarball

  5. Revert recovery prefetching feature.

  6. Sync guc.c and postgresql.conf.sample with the SGML docs.

  7. Add information of total data processed to replication slot stats.

  8. Doc: Review for "Optionally prefetch referenced data in recovery."

  9. Add circular WAL decoding buffer.

  10. Optionally prefetch referenced data in recovery.

  11. Remove read_page callback from XLogReader.

  12. Provide ReadRecentBuffer() to re-pin buffers by ID.

  13. Provide recovery_init_sync_method=syncfs.

  14. Mark factorial operator, and postfix operators in general, as deprecated.

  15. Rationalize GetWalRcv{Write,Flush}RecPtr().

  16. Support PrefetchBuffer() in recovery.

  17. Prevent hard failures of standbys caused by recycled WAL segments