From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: Avoiding smgrimmedsync() during nbtree index builds |
Date: | 2022-01-13 15:52:55 |
Message-ID: | 20220113155255.GH14051@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 11, 2022 at 12:10:54PM -0500, Melanie Plageman wrote:
> On Mon, Jan 10, 2022 at 5:50 PM Melanie Plageman <melanieplageman(at)gmail(dot)com> wrote:
> >
> > I have attached a v3 which includes two commits -- one of which
> > implements the directmgr API and uses it and the other which adds
> > functionality to use either directmgr or bufmgr API during index build.
> >
> > Also registering for march commitfest.
>
> Forgot directmgr.h. Attached v4
Thanks - I had reconstructed it first ;)
I think the ifndef should be outside the includes:
> +++ b/src/include/storage/directmgr.h
..
> +#include "access/xlogdefs.h"
..
> +#ifndef DIRECTMGR_H
> +#define DIRECTMGR_H
This is failing on windows CI when I use initdb --data-checksums, as attached.
https://cirrus-ci.com/task/5612464120266752
https://api.cirrus-ci.com/v1/artifact/task/5612464120266752/regress_diffs/src/test/regress/regression.diffs
+++ c:/cirrus/src/test/regress/results/bitmapops.out 2022-01-13 00:47:46.704621200 +0000
..
+ERROR: could not read block 0 in file "base/16384/30310": read only 0 of 8192 bytes
--
Justin
Attachment | Content-Type | Size |
---|---|---|
0003-cirrus-run-initdb-with-data-checksums-for-windows.txt | text/x-diff | 931 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2022-01-13 16:20:45 | Re: PATCH: generate fractional cheapest paths in generate_orderedappend_path |
Previous Message | Maxim Orlov | 2022-01-13 15:51:18 | Re: UNIQUE null treatment option |