I
worry that could be a source of confusion. IIUC your patches effectively
ignore !pg_temp if pg_temp is explicitly listed elsewhere in the list.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
postgr.es/m/DB9PR08MB6991329A73923BF8ED4B3422F5DBA%40DB9PR08MB6991.eurprd08.prod.outlook.com
[1] https://en.wikipedia.org/wiki/CPUID
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 964afc75976cce8d712d97f346d2b8eea9c1f1ee Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Sat, 28 Oc
On Fri, Oct 27, 2023 at 07:01:10AM +, Xiang Gao wrote:
> On Thu, 26 Oct, 2023 11:37:52AM -0500, Nathan Bossart wrote:
>>> We consider that a runtime check needs to be done in any scenario.
>>> Here we only confirm that the compilation can be successful.
>> >A r
I agree that the cost of a one-time-per-process probe should
> be negligible; it's the per-use cost that I worry about. If you can
> do some measurements proving that that worry is ill-founded, then
> I'm good with test-first.
Will do.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
implementation compiled : ~2.42s
* forced inlining : ~2.38s
Avoiding the runtime check produced a 0.8% improvement, and forced inlining
produced another 1.7% improvement. In comparison, even the runtime check
implementation produced a 20.8% improvement over the slicin
On Mon, Oct 30, 2023 at 10:36:01PM -0500, Nathan Bossart wrote:
> I tested pg_waldump -z with 50M 65-byte records for the following
> implementations on an ARM system:
>
> * slicing-by-8: ~3.08s
> * proposed patches applied (runtime check): ~
to set
> "!pg_temp" is by typing it out, and I'm not sure a lot of people will
> actually do that.
I thought it sounded generally useful, but if we're not going to proceed
with the primary use-case for this feature, then perhaps it's not worth
going through this p
> subscriptions.
Given the experience gained from the 2018 security fixes [0], I think this
is okay.
[0] https://postgr.es/m/20230715211333.GB3675150%40rfd.leadboat.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
to the runtime check regression (assuming we proceed with the
proposed optimization). An alternate approach could be to only use newer
instructions if they are available with the default compiler flags, but
given the current state of the buildfarm, such optimizations might not get
much uptake for a w
tions are a big portion of that pg_waldump -z command and that 2)
the CRC instructions provide significant performance gains.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Oct 31, 2023 at 04:12:40PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Okay. With that in mind, I think the path forward for new instructions is
>> as follows:
>
>> * If the special CRC instructions can be used with the default compiler
>>
On Tue, Oct 31, 2023 at 03:38:17PM -0500, Nathan Bossart wrote:
> On Tue, Oct 31, 2023 at 04:12:40PM -0400, Tom Lane wrote:
>> This seems like a reasonable proposal.
>
> Great. I think that leaves us with nothing left to do for this thread, so
> I'll withdraw it from the
On Mon, Oct 30, 2023 at 11:21:43AM -0500, Nathan Bossart wrote:
> On Fri, Oct 27, 2023 at 07:01:10AM +, Xiang Gao wrote:
>> On Thu, 26 Oct, 2023 11:37:52AM -0500, Nathan Bossart wrote:
>>>> We consider that a runtime check needs to be done in any scenario.
>>>&
ibute/option names, but those are in all-caps, so
they already stand out nicely.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
implify the spec
and future-proof against similar bugs, but it might also break a fair
number of extensions. If there aren't any other reasons to continue
supporting it, maybe it's the right long-term approach, though.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ere we are initializing the other shared memory stuff.
Since this isn't a tremendously performance-sensitive area, IMHO we should
code defensively to eliminate any doubts about correctness and to make it
easier to reason about.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Nov 01, 2023 at 10:39:04PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> What if we disallowed NULL string GUCs in v17?
>
> Well, we'd need to devise some other solution for hacks like the
> one used by timezone_abbreviations (see comment in
> check_timezon
=armv8-a+crypto])
fi
My current thinking is that we'll want to add USE_ARMV8_VMULL and
USE_ARMV8_VMULL_WITH_RUNTIME_CHECK and use those to decide exactly what to
compile. I'll admit I haven't fully thought through every detail yet, but
I'm cautiously optimistic tha
ided
> I would annotate commits with "partial", e.g.:
>
> Author: Andy Jackson (partial)
I tend to use "Co-authored-by" for this purpose.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Nov 03, 2023 at 10:46:57AM +, Xiang Gao wrote:
> On Date: Thu, 2 Nov 2023 09:35:50AM -0500, Nathan Bossart wrote:
>> The idea is that we don't want to start forcing runtime checks on builds
>> where we aren't already doing runtime checks. IOW if the compiler
On Wed, Nov 01, 2023 at 10:40:06PM -0500, Nathan Bossart wrote:
> Since this isn't a tremendously performance-sensitive area, IMHO we should
> code defensively to eliminate any doubts about correctness and to make it
> easier to reason about.
Concretely, like this.
--
Nathan Boss
t, but I
haven't noticed any difference thus far. One complication for
visiblitymap_count() is that the data passed to pg_popcount64() is masked,
which requires a couple more intructions when you're using the intrinsics.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
t waiting on someone to do the analysis/benchmarking?
[0] https://postgr.es/m/1367013190.11576.249.camel%40sussancws0025
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/bin/pg_checksums/Makefile b/src/bin/pg_checksums/Makefile
index ac736b2260..3f946ee9d6
y I need to spend some more time looking at
those...
[0] https://postgr.es/m/20231102034006.GA85609%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Nov 06, 2023 at 07:15:01PM -0800, Noah Misch wrote:
> On Mon, Nov 06, 2023 at 09:52:58PM -0500, Tom Lane wrote:
>> Nathan Bossart writes:
>> > Like I said, I don't have any proposals yet, but assuming we do want to
>> > support newer intrinsics, either open
On Tue, Nov 07, 2023 at 10:33:03AM +0100, Alvaro Herrera wrote:
> On 2023-Nov-01, Nathan Bossart wrote:
>> +1, IMHO quoting GUC names makes it abundantly clear that they are special
>> identifiers. In de4d456, we quoted the role names in a bunch of messages.
>> We didn&
> vector search support
I haven't had a chance to follow up on these in some time, so I went ahead
and marked them returned-with-feedback.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
point in the past" as the stated contract for this function seems to
suggest?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Nov 06, 2023 at 09:53:15PM -0800, Noah Misch wrote:
> On Mon, Nov 06, 2023 at 09:59:26PM -0600, Nathan Bossart wrote:
>> On Mon, Nov 06, 2023 at 07:15:01PM -0800, Noah Misch wrote:
>> > The glibc/gcc "ifunc" mechanism was designed to solve this problem of
&
On Tue, Nov 07, 2023 at 04:58:16PM -0800, Andres Freund wrote:
> On 2023-11-07 11:02:49 -0600, Nathan Bossart wrote:
>> Is there something special about all other backends being shut down that
>> ensures this returns the most up-to-date value and not something from "some
>
if (pg_crc32c_armv8_available())
{
if (pg_crc32c_armv8_crypto_available())
pg_comp_crc32c = pg_comp_crc32c_armv8_parallel;
else
pg_comp_crc32c = pg_comp_crc32c_armv8;
else
pc_comp_crc32c = pg_comp_crc32c_sb8;
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ve a performance
>> problems; it's not going to be the same one for everybody.
>
> +1
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
session user is a member of.
+ The current session user must have the SET for the
+ specified role_name, either
+ directly or indirectly via a chain of memberships with the
+ SET option.
(If the session user is a superuser, any role can be selected.)
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Oct 03, 2023 at 03:17:57PM +0530, vignesh C wrote:
> Few comments:
Pierre, do you plan to submit a new revision of this patch set for the
November commitfest? If not, the commitfest entry may be marked as
returned-with-feedback soon.
--
Nathan Bossart
Amazon Web Services: ht
me. I think it's a good idea to
keep it simple to start with. Since this is really only intended for
special tests that run in special builds, it seems like we ought to be able
to change it easily in the future as needed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Moving this to a new thread and adding it to the January commitfest.
On Thu, Nov 09, 2023 at 03:27:33PM -0600, Nathan Bossart wrote:
> On Tue, Nov 07, 2023 at 04:58:16PM -0800, Andres Freund wrote:
>> However, even if there's likely some other implied memory barrier that we
>>
On Thu, Nov 09, 2023 at 03:27:33PM -0600, Nathan Bossart wrote:
> I wonder if it's worth providing a set of "locked read" functions. Those
> could just do a compare/exchange with 0 in the generic implementation. For
> patches like this one where the overhead real
lso volatile?
The PostgreSQL atomics support appears to ensure they are volatile.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Nov 10, 2023 at 03:11:50PM -0800, Andres Freund wrote:
> On 2023-11-10 14:51:28 -0600, Nathan Bossart wrote:
>> + * This read is guaranteed to read the current value,
>
> It doesn't guarantee that *at all*. What it guarantees is solely that the
> current CPU won&#x
ppen.
Thanks for clarifying. I thought it might've been hinting at something
beyond the compare/exchange implications.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, Nov 11, 2023 at 07:38:59PM +0700, John Naylor wrote:
> On Tue, Nov 7, 2023 at 9:47 AM Nathan Bossart
> wrote:
>> Separately, I'm wondering whether we should consider using CFLAGS_VECTORIZE
>> on the whole tree. Commit fdea253 seems to be responsible for intro
, but I don't think it would be too burdensome for extension authors to
fix if we removed it completely.
Patch attached.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index 25338a90e2..f0eac078e0 1
There seems to be no interest in this patch, so I plan to withdraw it from
the commitfest system by the end of the month unless such interest
materializes.
On Fri, Feb 17, 2023 at 01:56:24PM -0800, Nathan Bossart wrote:
> The first one is the requirement that archive module authors create th
for
certain compiler/architecture combinations.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/include/port/atomics/generic.h b/src/include/port/atomics/generic.h
index cb5804adbf..95d99dd0be 100644
--- a/src/include/port/atomics/generic.h
+++ b/src/include/port/atomic
and my machine, and check-world
continues to pass.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Nov 14, 2023 at 10:59:04AM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> On Tue, Nov 14, 2023 at 04:25:24PM +0530, Amul Sul wrote:
>>> Changes looks pretty much straight forward, but patch failed to apply on the
>>> latest master head(b41b1a7f490) at me
On Tue, Nov 14, 2023 at 05:20:16PM +0100, Alvaro Herrera wrote:
> Let's leave the macro around and just remove its uses in PGDG-owned
> code. Having the macro around hurts nothing, and we can remove it in 15
> years or so.
WFM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
d to a static inline
> function.
It might be worth introducing pg_attribute_deprecated() in c.h. I'm not
too worried about this particular macro, but it seems handy in general.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Nov 14, 2023 at 11:01:15AM -0600, Nathan Bossart wrote:
> On Tue, Nov 14, 2023 at 04:36:44PM +, Dagfinn Ilmari Mannsåker wrote:
>> There's also __attribute__((deprecated)) (and and __declspec(deprecated)
>> for MSVC), but that can AFAIK only be attached to functi
t, I don't
mind going the __attribute__((deprecated)) route, but otherwise, I'd
probably just remove it completely.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
it 1833f1a 7 years ago. Debian code search shows very minimal
> usages of the above macros. Can we do away with
> tuplestore_donestoring?
Can we take these other things to a separate thread?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
o have accidentally enabled "digraph" in my .vimrc at some point...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
if PG_HAVE_ATOMIC_TEST_SET_FLAG is not defined. I haven't traced through
all the #ifdefs that lead to this point exhaustively, though, so perhaps
this is still unlikely.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
/backend/access/brin/brin.c: patch does not apply
I wonder if your mail client is modifying the patch. Do you have the same
issue if you download it from the archives?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Nov 15, 2023 at 09:52:34AM -0600, Nathan Bossart wrote:
> On Tue, Nov 14, 2023 at 07:17:32PM -0800, Andres Freund wrote:
>> Are you planning to apply the fix?
>
> Yes, I'll take care of it.
Committed and back-patched. I probably could've skipped back-patching
, I think we should ensure there's buildfarm coverage
for this kind of architecture-specific stuff.
[0] https://postgr.es/m/20230726043707.GB3211130%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ove them.
I'm fine with this because all of these macros are no-ops for all supported
versions of Postgres. Even if an extension is using them today, you'll get
the same behavior as before if you remove the uses and rebuild against
v12-v16.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
compilations of an inline function would cause problems.
[0]
https://postgr.es/m/CAFBsxsHG%3Dg6W8Mie%2B_NO8dV6O0pO2stxrnS%3Dme5ZmGqk--fd5g%40mail.gmail.com
[1]
https://postgr.es/m/CAFBsxsH1Yutrmu%2B6LLHKK8iXY%2BvG--Do6zN%2B2900spHXQNNQKQ%40mail.gmail.com
[2] https://github.com/pgcentralfoundation/pgrx/issues/1298
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
. I
don't know if it'll be feasible to keep simd.h out of all headers that
third-party code might want to use forever, but that's not an argument
against doing this right now for pgrx.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
why it would,
either.
> So it should probably end up living somewhere near the UTF-8 support, and
> the easiest way to make it not go into something pgrx currently
> includes would be
> to make it a new header file, though there's a fair amount of API we
> don't touch.
D
On Mon, Nov 13, 2023 at 03:35:28PM -0800, Andres Freund wrote:
> On 2023-11-13 16:42:31 -0600, Nathan Bossart wrote:
>> There seems to be no interest in this patch, so I plan to withdraw it from
>> the commitfest system by the end of the month unless such interest
>> material
On Mon, Nov 20, 2023 at 05:14:17PM -0800, Jubilee Young wrote:
> On Mon, Nov 20, 2023 at 2:52 PM Nathan Bossart
> wrote:
>> Does pgrx use ascii.h at all?
>
> We don't use utils/ascii.h, no.
Alright. The next minor release isn't until February, so I'll let this
t implements the same thing in the caller).
I'm mostly thinking out loud here, but could we just always do this? I
guess you might want to avoid it if your SH_EQUAL is particularly expensive
and you know repeated lookups are rare, but maybe that's uncommon enough
that we don't reall
On Thu, Nov 16, 2023 at 09:46:22AM -0600, Nathan Bossart wrote:
> On Thu, Nov 16, 2023 at 07:11:41PM +0530, Bharath Rupireddy wrote:
>> After a recent commit 6a72c42f (a related discussion [1]) which
>> removed MemoryContextResetAndDeleteChildren(), I think there are a
>> cou
ds
> about right to me, but maybe somebody has an argument for thinking about
> it differently.
That seems reasonable to me. I don't think we need to mandate that
backwards-compatibility support be removed as soon as it is eligible, but
it can be considered fair game at that point.
On Mon, Nov 20, 2023 at 10:37:47PM -0800, Jeff Davis wrote:
> It would be interesting to know how often it's a good idea to turn it
> on, though. I could try turning it on for various other uses of
> simplehash, and see where it tends to win.
That seems worthwhile to me.
--
er trying to convert
pqsignal() into a void function, but IIUC that would require an SONAME
bump. For now, I've just documented the bogosity of the return values.
Thoughts?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 5f46dc0150aba3ef75053e91f7c9a4d6624e2c4f Mon
On Tue, Nov 21, 2023 at 03:20:08PM -0600, Nathan Bossart wrote:
> +#ifdef NSIG
> +#define PG_NSIG (NSIG)
> +#else
> +#define PG_NSIG (64) /* XXX: wild guess */
> +#endif
> + Assert(signo < PG_NSIG);
cfbot seems unhappy with this on Windows.
73923bf8ed4b3422f5...@db9pr08mb6991.eurprd08.prod.outlook.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Nov 22, 2023 at 10:16:44AM +, Xiang Gao wrote:
> On Date: Fri, 10 Nov 2023 10:36:08AM -0600, Nathan Bossart wrote:
>>+__attribute__((target("+crc+crypto")))
>>
>>I'm not sure we can assume that all compilers will understand this, and I'm
On Tue, Nov 21, 2023 at 04:40:06PM -0600, Nathan Bossart wrote:
> cfbot seems unhappy with this on Windows. IIUC we need to use
> PG_SIGNAL_COUNT there instead, but I'd like to find a way to have just one
> macro for all platforms.
Here's an attempt at fixing the Windows
On Thu, Nov 23, 2023 at 05:50:48PM +0700, John Naylor wrote:
> On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart
> wrote:
>> One half-formed idea I have is to introduce some sort of ./configure flag
>> that enables all the newer instructions that your CPU understands.
>
>
> Having said that, I'm all +1 if the v1 patch proposed in this thread gets in.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
e able to use a pg_atomic_flag instead for 0002, but that code
seems intended for a slightly different use-case and has more complicated
barrier semantics.)
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 53f717e84a3aa912f9d89dce4be7f77d9bffb3c2 Mon Sep 17 00:00:00 2001
From: Na
On Sat, Nov 25, 2023 at 02:09:14PM +0700, John Naylor wrote:
> On Thu, Nov 23, 2023 at 11:51 PM Nathan Bossart
> wrote:
>>
>> On Thu, Nov 23, 2023 at 05:50:48PM +0700, John Naylor wrote:
>> > On Thu, Nov 23, 2023 at 1:49 AM Nathan Bossart
>> > wrote:
>
Thanks for taking a look.
On Wed, Nov 22, 2023 at 02:59:45PM -0800, Andres Freund wrote:
> On 2023-11-22 15:59:44 -0600, Nathan Bossart wrote:
>> +/*
>> + * Except when called with SIG_IGN or SIG_DFL, pqsignal() sets up this
>> function
>> + * as the handler for
On Mon, Nov 27, 2023 at 03:21:53PM -0600, Nathan Bossart wrote:
> On Sat, Nov 25, 2023 at 02:09:14PM +0700, John Naylor wrote:
>> Sorry, I wasn't clear, I mean: detect that a packager passed
>> "-march=x86_64-v2" in the CFLAGS, so that a symbol in header files
>&g
Here is a new version of the patch with feedback addressed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 3cda5bb87c82738ad6f8a082ef5dfeb49cd51392 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 28 Nov 2023 11:17:13 -0600
Subject: [PATCH v3 1/1] archiver except
Here is a new patch set with feedback addressed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From e4bea5353c2685457545b67396095e9b96156982 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 28 Nov 2023 14:58:20 -0600
Subject: [PATCH v3 1/3] Check that MyProc
to fix this particular issue, but I'm wondering
whether there's a bigger problem here.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Nov 28, 2023 at 04:03:49PM -0800, Andres Freund wrote:
> On 2023-11-28 16:05:16 -0600, Nathan Bossart wrote:
>> From a glance, it looks to me like the problem is that pgstat_shutdown_hook
>> is registered as a before_shmem_exit callback, while ProcKill is registered
>>
after
> we've called InitProcessGlobals(). But perhaps that should be commented upon
> somewhere?
Good call. I expanded on the MyProcPid assertion in wrapper_handler() a
bit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 8c36c9470bee558bcab3fa70d456ca976dc02
On Wed, Nov 22, 2023 at 12:49:35PM -0600, Nathan Bossart wrote:
> On Wed, Nov 22, 2023 at 02:54:13PM +0200, Ants Aasma wrote:
>> For reference, executing the page checksum 10M times on a AMD 3900X CPU:
>>
>> clang-14 -O2 4.292s (17.8 GiB/s)
>> clang-14
On Tue, Nov 28, 2023 at 06:48:59PM -0800, Andres Freund wrote:
> On 2023-11-28 20:42:47 -0600, Nathan Bossart wrote:
>> Right. Perhaps we could add a LWLockReleaseAll() to
>> pgstat_shutdown_hook() instead of the autovacuum code, but I'm afraid that
>> is still just a
On Fri, Nov 10, 2023 at 08:55:29PM -0600, Nathan Bossart wrote:
> On Fri, Nov 10, 2023 at 06:48:39PM -0800, Andres Freund wrote:
>> Yes. We should optimize pg_atomic_exchange_u32() one of these days - it can
>> be
>> done *far* faster than a cmpxchg. When I was adding t
these ones are better than those ones and what they protect against
> and what risks remain." That would be awesome.
+1. IMO the "Password Authentication" section [0] does this pretty well
already.
[0] https://www.postgresql.org/docs/devel/auth-password.html
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
the logs I can
find, and I didn't find any previous reports about this in the archives
after lots of searching, so I thought I'd at least park these notes here in
case anyone else has ideas.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Nov 23, 2023 at 08:05:26AM +, Xiang Gao wrote:
> On Date: Wed, 22 Nov 2023 15:06:18PM -0600, Nathan Bossart wrote:
>>pg_crc32c_armv8.o: CFLAGS += ${CFLAGS_CRC} ${CFLAGS_CRYPTO}
>
> It does not work correctly. CFLAGS ='-march=armv8-a+crc,
> -march=armv8-a+crypt
On Wed, Nov 29, 2023 at 03:29:05PM -0600, Nathan Bossart wrote:
> I haven't done any sort of performance testing on this yet. Some
> preliminary web searches suggest that there is unlikely to be much
> difference between cmpxchg and xchg, but presumably there's some difference
##__state.l != NIL && \
var##__state.i < var##__state.l->length && \
(var = lfirst_node(type,
&var##__state.l->elements[var##__state.i]), true));\
var##__state.i++)
There might be a way to use foreach_internal for foreach_node, too,
On Thu, Nov 30, 2023 at 07:56:27PM -0800, Andres Freund wrote:
> On 2023-11-30 21:18:15 -0600, Nathan Bossart wrote:
>> Some rudimentary tests show a >40% speedup with this patch on x86_64.
>
> On bigger machines, with contention, the wins are likely much higher. I see
> tw
me, so I will plan on committing it shortly.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
opts.json_mode)
I think it's unfortunate that this further complicates the branching in
CopyOneRowTo(), but after some quick glances at the code, I'm not sure it's
worth refactoring a bunch of stuff to make this nicer.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
pt_arg
+{
+$$ = makeDefElem("format", $2, @1);
+}
;
copy_generic_opt_arg:
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
if we have somebody using it, I think we need to fix the
> compilation and test failure issues, and start testing this code
> (perhaps I can think of setting up a buildfarm member to help here).
+1 for at least fixing the code and tests, provided we decide to keep it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Nov 30, 2023 at 10:35:22PM -0600, Nathan Bossart wrote:
> One thing on my mind is whether we should bother with the inline assembly
> versions. It looks like gcc has had __atomic since 4.7.0 (2012), so I'm
> not sure we gain much from them. OTOH they are pretty simple and s
On Mon, Dec 04, 2023 at 12:18:05PM -0600, Nathan Bossart wrote:
> Barring objections or additional feedback, I think I'm inclined to press
> forward with this one and commit it in the next week or two. I'm currently
> planning to keep the inline assembly, but I'm
ng, but I
thought it might be useful for extensions for caching, etc. and wanted to
see whether there was any interest in the feature.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From b63c28303384636699f2f514e71b62829346be4b Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: We
701 - 800 of 2971 matches
Mail list logo
