On Mon, Dec 04, 2023 at 07:27:01AM +, Xiang Gao wrote:
> This is the latest patch. Looking forward to your feedback, thanks!
Thanks for the new patch. I am hoping to spend much more time on this in
the near future...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
way to turn on backtraces for everything, or
at least everything above a certain logging level. That would primarily be
useful for when you don't know exactly which C function is producing the
error.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ing the stuff in common/int.h) to
help prevent this sort of thing in the future. But that'd require you to
realize that your code is at risk of overflow, at which point it's probably
just as easy to restructure the logic like you've done here.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
encouraging. I assume the performance concerns stem from the use of
function pointers. Or was there something else?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
gt; means they're regularly hitting an elog(), and it ought to be promoted
> to ereport().
Perhaps this should be a GUC that defaults to LOG or ERROR.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Dec 05, 2023 at 07:47:25PM +0100, Matthias van de Meent wrote:
> On Tue, 5 Dec 2023 at 19:30, Robert Haas wrote:
>> On Tue, Dec 5, 2023 at 1:28 PM Nathan Bossart
>> wrote:
>> > Perhaps this should be a GUC that defaults to LOG or ERROR.
>>
>> Why?
So
de is pretty interesting -- I don't want to think about how long it
> would have taken me to figure that out.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
if it exists. Ignore errors */
if (needs_unlink)
unlink(filename);
/* Finish incomplete line on stdout */
-write(STDOUT_FILENO, "\n", 1);
+rc = write(STDOUT_FILENO, "\n", 1);
+(void) rc;
_exit(1);
}
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
archCatCache1
5.35% [kernel] [k] intel_gpio_irq
3.57% postgres [.] composite_to_json
3.31% postgres [.] IsValidJsonNumber
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ed sounds good
> to me. Sorry for leaving this out!
This was on an Ubuntu LTS. I always build with -Werror during development,
too.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Dec 06, 2023 at 10:33:49AM -0600, Nathan Bossart wrote:
> (format csv)
> Time: 12295.480 ms (00:12.295)
> Time: 12311.059 ms (00:12.311)
> Time: 12305.469 ms (00:12.305)
>
> (format json)
> Time: 24568.621 ms (00:24.569)
>
On Wed, Dec 06, 2023 at 06:27:04PM +0100, Peter Eisentraut wrote:
> Makes sense. Can you commit that?
Yes, I will do so shortly.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
going after later, but it's not the top of the list.
Agreed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Dec 06, 2023 at 11:30:02AM -0600, Nathan Bossart wrote:
> On Wed, Dec 06, 2023 at 06:27:04PM +0100, Peter Eisentraut wrote:
>> Makes sense. Can you commit that?
>
> Yes, I will do so shortly.
Committed. Apologies for the delay.
--
Nathan Bossart
Amazon Web
appendStringInfoString(result, outputstr);
+if (!key_scalar && IsValidJsonNumber(outputstr, (len =
strlen(outputstr
+appendBinaryStringInfo(result, outputstr, len);
else
escape_json(result, outputstr);
pfree(outpu
he carpet.
> I still need to process your feedback/discoveries on that other thread
> and it may take a few weeks for me to get to it.
I don't think we need to revert 04a09ee provided the issue is unrelated and
a fix is in development.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Moving this to a new thread...
On Thu, Dec 07, 2023 at 07:15:28AM -0500, Joe Conway wrote:
> On 12/6/23 21:56, Nathan Bossart wrote:
>> On Wed, Dec 06, 2023 at 03:20:46PM -0500, Tom Lane wrote:
>> > If Nathan's perf results hold up elsewhere, it seems like some
>> &g
numeric data type (/shrug). In any case, this seems to
speed up my test by another half a second or so.
I think there are some similar improvements that we can make for
JSONTYPE_BOOL and JSONTYPE_CAST, but I haven't tested them yet.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>F
.1.2 to see the strlen() call
> with that code [1].
Hm. I tried this first, but my compiler (gcc 9.4.0 on this machine) was
still doing the strlen()...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Dec 07, 2023 at 10:28:50PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> I did both of these in v2, although I opted to test that the first
>> character after the optional '-' was a digit instead of testing that it was
>> _not_ an 'I' or '
On Fri, Dec 08, 2023 at 11:51:15AM +0700, John Naylor wrote:
> This is less verbose and still compiles with constants:
>
> use_line_feeds ? strlen(",\n ") : strlen(",");
This one worked on my machine. I've committed the patch with that change.
Thanks eve
Here are a couple more easy micro-optimizations in nearby code. I've split
them into individual patches for review, but I'll probably just combine
them into one patch before committing.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 79727aab47c7d7cd733ce21c824
On Fri, Dec 08, 2023 at 05:56:20PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> Here are a couple more easy micro-optimizations in nearby code. I've split
>> them into individual patches for review, but I'll probably just combine
>> them into one pat
On Fri, Dec 15, 2023 at 04:56:27AM -0800, Andres Freund wrote:
> I don't think we need the inline asm. Otherwise looks good.
Committed with that change. Thanks for reviewing! I am going to watch the
buildfarm especially closely for this one.
--
Nathan Bossart
Amazon Web Service
rebased for cfbot
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From c5fc2186960c483d53789f27fcf84771e98c5ca3 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 28 Nov 2023 14:58:20 -0600
Subject: [PATCH v5 1/3] Check that MyProcPid == getpid() in all signal
handl
if we should back-patch these changes as bug
> fixes. It's probably not worth the risk, but ...
I'm not too concerned about the risks of back-patching these commits, but
if this 19-year-old bug was really first reported today, I'd agree that
fixing it in the stable branches is
128.GB1315705%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/backend/storage/lmgr/lwlock.c b/src/backend/storage/lmgr/lwlock.c
index 315a78cda9..b43972bd2e 100644
--- a/src/backend/storage/lmgr/lwlock.c
+++ b/src/backend/storage/lmgr/lwlock.c
@@ -1752,10
ously doubt we will back-patch this.
[0] https://www.postgresql.org/support/versioning/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
a DSA segment, the handle, tranche ID, etc. could just
be stored in the DSM segment. Maybe that assumption is wrong, though...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
gment attached?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
it will be even more
important that this stuff stays separate from the tools it is built with.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
_find_or_insert(), but it looks like you'd
> want an equivalent for dshash_find(), as well.
What is the use-case for only verifying the existence of a segment?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
e should keep our ears cocked for similar reports.
>From a brief glance, I believe this is long-standing behavior. Even though
we advance optind at the bottom of the loop, the next getopt_long() call
seems to reset it to the first non-option (which was saved in a previous
call).
--
Nathan Bo
intended to test the DSM registry machinery, and setting/retrieving
an atomic variable seems like a realistic use-case to me.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
omplicated without a good reason. I don't mind changing this if I'm
outvoted on this one, though.
[0] https://postgr.es/m/20231219160117.GB831499%40nathanxps13
[1] https://postgr.es/m/20231220153342.GA833819%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
o avoid requiring folks to add special
single-user-mode-only logic if we can avoid it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
asSuffix() in case of
>> OOM. The attached, which should be backpatched to 16, changes to using
>> pg_strdup instead which handles it.
>
> Looks good to me.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
llelism on blobs,
> but with this patch series we do:
>
> dumprestore
> HEAD: 14sec 15sec
> after 0002: 7sec10sec
> after 0003: 7sec3sec
Wow, thanks for putting together these patches. I intend to help review,
but I'm not sure I
On Wed, Dec 20, 2023 at 12:21:05PM +0530, vignesh C wrote:
> On Tue, 19 Dec 2023 at 21:22, Nathan Bossart wrote:
>> I'm not sure we should proceed with rewriting most/all eligible foreach
>> loops. I think it's fine to use the new macros in new code or to update
>>
]
540 | WalSummarizerCtl->pending_lsn = unsummarized_lsn;
| ~~^~
I haven't looked closely to see whether there is actually a problem here,
but the attached patch at least resolves the warning.
--
Nathan Bossart
Amazon Web Service
On Wed, Dec 27, 2023 at 09:11:02AM -0500, Robert Haas wrote:
> Thanks. I don't think there's a real bug, but I pushed a fix, same as
> what you had.
Thanks! I also noticed that WALSummarizerLock probably needs a mention in
wait_event_names.txt.
--
Nathan Bossart
Amazon Web
Here is a new version of the patch. In addition to various small changes,
I've rewritten the test suite to use an integer and a lock, added a
dsm_registry_find() function, and adjusted autoprewarm to use the registry.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Dec 27, 2023 at 01:53:27PM -0600, Nathan Bossart wrote:
> Here is a new version of the patch. In addition to various small changes,
> I've rewritten the test suite to use an integer and a lock, added a
> dsm_registry_find() function, and adjusted autoprewarm to use the regis
On Mon, Jan 01, 2024 at 07:12:26PM +0700, John Naylor wrote:
> On Thu, Nov 30, 2023 at 12:15 AM Nathan Bossart
> wrote:
>> I don't intend for this patch to be
>> seriously considered until we have better support for detecting/compiling
>> AVX2 instructions and a bui
7;s one.
See [0]. FWIW I tend to agree that we could leave this one out for now.
> 3. I think we don't need miscadmin.h inclusion in autoprewarm.c, do we?
I'll take a look at this one.
[0] https://postgr.es/m/ZYIu_JL-usgd3E1q%40paquier.xyz
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
(new thread)
On Tue, Jan 02, 2024 at 10:34:11AM -0500, Robert Haas wrote:
> On Wed, Dec 27, 2023 at 10:36 AM Nathan Bossart
> wrote:
>> Thanks! I also noticed that WALSummarizerLock probably needs a mention in
>> wait_event_names.txt.
>
> Fixed.
I think we'
On Tue, Jan 02, 2024 at 01:13:16PM -0500, Robert Haas wrote:
> On Tue, Jan 2, 2024 at 12:31 PM Nathan Bossart
> wrote:
>> I think we're supposed to omit the "Lock" suffix in wait_event_names.txt.
>
> Ugh, sorry. But also, why in the world?
That seems to da
uring we have an AVX2 replacement for
everything doesn't seem particularly burdensome.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Here's a new version of the patch set with Bharath's feedback addressed.
On Tue, Jan 02, 2024 at 11:31:14AM -0500, Robert Haas wrote:
> On Tue, Jan 2, 2024 at 11:21 AM Nathan Bossart
> wrote:
>> > Are we expecting, for instance, a 128-bit UUID being used as a key and
&g
memory, and
> + last until the server is shut down.
> +
I think is supposed to be here.
> +++
> b/src/test/modules/test_injection_points/t/002_invalid_checkpoint_after_promote.pl
0003 and 0004 add tests to the test_injection_points module. Is the idea
that we'd add any tests that re
On Wed, Jan 03, 2024 at 09:13:52PM +0700, John Naylor wrote:
> On Tue, Jan 2, 2024 at 11:11 PM Nathan Bossart
> wrote:
>> I'm tempted to propose that we move forward with this patch as-is after
>> adding a buildfarm machine that compiles with -mavx2 or -march=x86-64-v3.
I spent some time preparing this for commit, which only amounted to some
light edits. I am posting a new version of the patch in order to get one
more round of cfbot coverage and to make sure there is no remaining
feedback.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>F
we are quite sure. Maybe some small
> changes like this to clarify that.
>
> The outer loop only does a single iteration, so we expect that **any**
> optimizing compilers will unroll it, thereby optimizing it away. **We
> know for sure that gcc and clang do this optimization.**
WFM.
On Tue, Jan 02, 2024 at 10:11:23AM -0600, Nathan Bossart wrote:
> (In case it isn't clear, I'm volunteering to set up such a buildfarm
> machine.)
I set up "akepa" to run with -march=x86-64-v3.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
HO even the vague
mention of loop unrolling is probably more than is really necessary.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Jan 04, 2024 at 08:53:11AM +0900, Michael Paquier wrote:
> On Tue, Jan 02, 2024 at 11:14:56PM -0600, Nathan Bossart wrote:
>> I'm wondering how important it is to cache the callbacks locally.
>> load_external_function() won't reload an already-loaded libr
defining a module somewhere that tests would need to load,
should we just put the common callbacks in the core server? Unless there's
a strong reason to define them elsewhere, that could be a nice way to save
a step in the tests.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Nov 20, 2023 at 10:39:43PM -0600, Nathan Bossart wrote:
> Alright. The next minor release isn't until February, so I'll let this one
> sit a little while longer in case anyone objects to back-patching something
> like this [0].
>
> [0] https://post
ess usual to me when
> working on
> a patch).
Okay, I did that in v2.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 587f6a2c108fc7496fcb3d5764ca06ac5fb21326 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 5 Jan 2024 00:07:40 -0600
Subject: [PATCH v2
On Wed, Jan 03, 2024 at 11:34:25AM +0900, Michael Paquier wrote:
> On Tue, Jan 02, 2024 at 11:31:20AM -0600, Nathan Bossart wrote:
>> +# Find the location of lwlocknames.h.
>> +my $include_dir = $node->config_data('--includedir');
>> +my $lwlocknames_f
On Fri, Jan 05, 2024 at 08:38:22AM +0900, Michael Paquier wrote:
> On Thu, Jan 04, 2024 at 04:31:02PM -0600, Nathan Bossart wrote:
>> Rather than defining a module somewhere that tests would need to load,
>> should we just put the common callbacks in the core server? Unless ther
l with this extra load of work for something that I'd aim
> to be used for having improved *test* coverage, and the build switch
> should stay.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
that would give more clues for debugging purpose.
Sure, I'll add something like that. I think this particular scenario is
less likely, but that's not a reason to make the error message hard to
decipher.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jan 05, 2024 at 09:03:39AM +0700, John Naylor wrote:
> On Wed, Jan 3, 2024 at 10:29 PM Nathan Bossart
> wrote:
>> If the requirement is that normal builds use AVX2, then I fear we will be
>> waiting a long time. IIUC the current proposals (building multiple
>&
On Fri, Jan 05, 2024 at 10:42:03AM -0600, Nathan Bossart wrote:
> On Fri, Jan 05, 2024 at 07:39:39AM +, Bertrand Drouvot wrote:
>> + die "lists of predefined LWLocks in lwlocknames.txt and
>> wait_event_names.txt do not match"
>> + unless $wait
> Tung Nguyen: are you interested in updating the patch along these lines
> suggested by Nathan?
I gave it a try.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 7183005bb6786b63a5fd96ba5101849eb6f203e5 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 5 Jan 2024
at way in doc/src/sgml/meson.build for example.
I fixed this in v4.
> Except for the above, the patch looks good to me.
Thanks for reviewing!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 35a744e0114c38e3ffb48e446360b252bb7b17b4 Mon Sep 17 00:00:00 2001
From: Nathan Boss
Typo: missing "an" before "already-attached".
> +/* Return address of already-attached DSM registry entry. */
Done.
> 3. Use NAMEDATALEN instead of 64?
> +charkey[64];
I kept this the same, as I didn't see any need to tie the key size to
NAMEDATA
eed to
> remove them now, but just asking if there's something in there that
> makes this new feature unusable.
It might be possible, but IIUC you'd still need a way to know whether the
library was preloaded, i.e., all the other necessary hooks were in place.
It's convenient to just be able to check whether the shared memory was set
up for this purpose.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
seems reasonable to me.
> Similarly, I think dshash_find_or_insert() can be as simple as
> dshash_search() and
> accept HASHACTION like hash_search().
I'm not totally sure what you mean here. If you mean changing the dshash
API, I'd argue that's a topic for another thr
On Mon, Jan 08, 2024 at 02:01:39PM +0700, John Naylor wrote:
> On Thu, Nov 30, 2023 at 12:15 AM Nathan Bossart
> wrote:
>> writerssse2avx2 %
>> 25611951188-1
>> 512 9281054 +14
>> 1024 633 716 +13
>
On Mon, Jan 08, 2024 at 07:59:10AM +, Bertrand Drouvot wrote:
> + input: [files(
> +'../../backend/storage/lmgr/lwlocknames.txt',
> +'../../backend/utils/activity/wait_event_names.txt')],
>
> I think the "[" and "]" are not neede
IMHO this is a kind-of bizarre state to end up
in.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Sorry for the noise. I spent some more time tidying this up for commit,
which I am hoping to do in the next day or two.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 4e222c1a1fc1a2476746cb7b68c1d2a203816699 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 8
On Tue, Jan 09, 2024 at 09:20:09AM +0700, John Naylor wrote:
> On Tue, Jan 9, 2024 at 12:37 AM Nathan Bossart
> wrote:
>>
>> > I suspect that there could be a regression lurking for some inputs
>> > that the benchmark doesn't look at: pg_lfind32() currently nee
On Tue, Jan 09, 2024 at 02:26:20PM +0900, Michael Paquier wrote:
> On Tue, Jan 09, 2024 at 04:55:07AM +, Bertrand Drouvot wrote:
>> Thanks! v6 looks good to me.
>
> WFM. Thanks for putting in place this sanity check when compiling.
Committed. Thanks for reviewing!
--
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 1bb28cfe5d40670386ae663e14c8854dc1b5486d Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 21 Aug 2023 19:05:14 -0700
Subject: [PATCH v6 1/2] move PG_TEMP_FILE* macros to file_utils.h
---
src/backend/bac
el stuff (and a couple other things) out in the first
round to avoid prolonging the naming discussion, but we can continue to add
to protocol.h.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
s so close to release, so I was suggesting that we hold
off on that part until v17. If there isn't a concern with renaming these
functions in v16, I can proceed with something more like v2.
[0] https://postgr.es/m/20230824161913.GA1394441%40nathanxps13.lan
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Elts, coldef);
| ^~~~
This went away when I added a default case that ERROR'd or initialized
coldef to NULL.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Aug 29, 2023 at 08:44:02PM +0200, Alvaro Herrera wrote:
> On 2023-Aug-29, Nathan Bossart wrote:
>> My compiler is complaining about 1fa9241b:
>>
>> ../postgresql/src/backend/commands/sequence.c: In function ‘DefineSequence’:
>> ../postgresql/src/backend/comman
On Tue, Aug 29, 2023 at 09:15:55AM -0700, Nathan Bossart wrote:
> Thanks for the report. I'll get this fixed up. My guess is that this was
> leftover from an earlier version of the patch that used the same macro for
> identical protocol characters.
I plan to commit the attached
re use it?
I don't think I've ever used it. AFAICT it was added with hot standby mode
(efc16ea) to support 'make standbycheck', which was removed last year
(4483b2cf). Unless someone claims to be using it, it's probably fine to
just remove it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
methods should cause compiler
warnings until they are implemented.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From f5ecb3c8b5d397c94a9f8ab9a053b3a0cfd7f854 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 21 Aug 2023 19:05:14 -0700
Subject: [PATCH v7 1/2] mov
On Wed, Aug 30, 2023 at 07:56:33AM +0900, Michael Paquier wrote:
> On Tue, Aug 29, 2023 at 02:11:06PM -0700, Nathan Bossart wrote:
>> I plan to commit the attached patch shortly.
>
> WFM.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Aug 30, 2023 at 08:22:27AM +0900, Michael Paquier wrote:
> On Tue, Aug 29, 2023 at 09:46:55AM -0700, Nathan Bossart wrote:
>> This was my first reaction [0]. I was concerned about renaming the
>> exported functions so close to release, so I was suggesting that we hold
>
plicitly, I don't have any comments on the proposed patches.
I'm about to spend way too much time writing the commit message for 0002,
but I plan to commit both patches sometime today.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Aug 30, 2023 at 10:56:22AM -0400, Robert Haas wrote:
> On Wed, Aug 30, 2023 at 10:27 AM Nathan Bossart
> wrote:
>> I'm about to spend way too much time writing the commit message for 0002,
>> but I plan to commit both patches sometime today.
>
> Thanks!
aDirSyncMethod and uses it for
recovery_init_sync_method. The second adds syncfs() support in
file_utils.c. And the third adds the ability to specify syncfs in the
frontend utilities. WDYT?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From e627b8ea4dcc01ac9e2fe3a21e3b3cc109b815e4 Mon Sep 17 0
hat's worth
worrying about.
> +command_ok([ 'initdb', '-S', $datadir, '--sync-method', 'fsync' ],
> + 'sync method fsync');
>
> Removing this one may be fine, actually, because we test the sync
> paths on other places like pg_
't use it. But I suppose it wouldn't be
too much trouble to keep it around for anyone who happens to need it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Jul 25, 2023 at 11:53:36AM -0700, Nathan Bossart wrote:
> Here is a polished patch set for this approach. I've also added a 0004
> that replaces the open-coded heap in pg_dump_sort.c with a binaryheap.
> IMHO these patches are in decent shape.
I'm hoping to commit th
On Fri, Sep 01, 2023 at 01:41:41PM -0400, Tom Lane wrote:
> I've not actually looked at any of these patchsets after the first one.
> I have added myself as a reviewer and will hopefully get to it within
> a week or so.
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Sep 01, 2023 at 01:31:43PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I wonder if it'd be possible to just remove pg_get_serial_sequence().
>
> A quick search at http://codesearch.debian.net/ finds uses of it
> in packages like gdal, qgis, rails, ... We
inct error when syncfs is not supported
> than when it's truely recognized.
Later versions of the patch should have this.
> The patch should handle pg_dumpall, too.
It looks like pg_dumpall only ever fsyncs a single file, so I don't think
it is really needed there.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Sep 01, 2023 at 01:19:13PM -0500, Justin Pryzby wrote:
> What about (per git grep no-sync doc) pg_receivewal?
I don't think it's applicable there, either. IIUC that option specifies
whether to sync the data as it is streamed over.
--
Nathan Bossart
Amazon Web Se
On Wed, Aug 16, 2023 at 01:07:15PM -0700, Nathan Bossart wrote:
> Ah, that explains it. v5 of the patch is attached.
Barring additional feedback, I plan to commit this patch in the current
commitfest.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
r apply workers". Would those show up
as parallel apply workers in the view? Can we add another worker type for
those?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
egers are already
stored directly in the array thanks to the use of Datum. However, it
_would_ allow us to abandon this frontend/backend void */Datum kludge,
which is something.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Sep 01, 2023 at 01:52:48PM -0700, Nathan Bossart wrote:
> On Fri, Sep 01, 2023 at 04:00:44PM -0400, Robert Haas wrote:
>> In hindsight, I think that making binaryheap depend on Datum was a bad
>> idea. I think that was my idea, and I think it wasn't very smart.
>&g
801 - 900 of 2971 matches
Mail list logo
