On Tue, Nov 21, 2023 at 03:20:08PM -0600, Nathan Bossart wrote:
> * Overhead: The wrapper handler calls a function pointer and getpid(),
> which AFAICT is a real system call on most platforms. That might not be
> a tremendous amount of overhead, but it's not zero, eit
on a better path than the initial one. We can still add the socket
> directory and the host.
Agreed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Feb 06, 2024 at 03:06:05PM -0600, Nathan Bossart wrote:
> On Tue, Feb 06, 2024 at 08:52:09PM +, Maiquel Grassi wrote:
>> I made the adjustment in the code and updated the patch. I believe this
>> is the format suggested by you all. Would this be it?
>
> I was th
pg_catalog.inet_client_addr() AS "Client Address",
pg_catalog.inet_client_port() AS "Client Port",
pg_catalog.pg_backend_pid() AS "Session PID";
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Feb 06, 2024 at 03:55:58PM -0500, Tom Lane wrote:
> A comparison routine that is not is probably broken, agreed.
> I didn't look through the details of the patch --- I was more
> curious whether we had a version of the qsort bug, because
> if we do, we should fix that too.
+1
empted to suggest
that we make it project policy that comparison functions must be
transitive. There might be no real issues today, but if we write all
comparison functions the way Mats is suggesting, it should be easier to
reason about overflow risks.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Feb 07, 2024 at 12:48:00AM +0530, Bharath Rupireddy wrote:
> +1. Patch LGTM.
Unless there are objections, I'll plan on committing this in the next day
or two.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
PID| 21624
> (8 rows)
My first reaction is that this should instead return a single row with the
same set of columns for any connection type (the not-applicable ones would
just be set to NULL). That would match the other meta-commands like \l and
\du, and you could still get an expanded disp
arazel.de#6eb7595873392621d60e6b5a723941bc
>
> I agree that its easier to not have to refer back to the macros only to
> see that they're all invoking StartChildProcess(X). All invocations are
> within postmaster.c.
Seems reasonable to me.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Feb 06, 2024 at 05:47:56PM +0100, Daniel Gustafsson wrote:
>> On 6 Feb 2024, at 17:32, Nathan Bossart wrote:
>> IMHO this patch is worth trying to get into v17. I'd be happy to take it
>> forward if Daniel does not intend to work on it.
>
> I actually had th
for enabling
log_checkpoints by default [0], I'm hesitant to commit something like
this without further community discussion.
[0]
https://postgr.es/m/CALj2ACX-rW_OeDcp4gqrFUAkf1f50Fnh138dmkd0JkvCNQRKGA%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ng to get into v17. I'd be happy to take it
forward if Daniel does not intend to work on it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Jan 30, 2024 at 11:23:57AM +1300, David Rowley wrote:
> On Tue, 30 Jan 2024 at 08:32, Nathan Bossart wrote:
>> I'm currently +0.1 for this change. I don't see any huge problem with
>> trimming a few instructions, but I'm dubious there's any measurable impact.
>> H
happening
in a test are probably pretty small.
Could we get the LSN before and after making the change and then inspect
all summaries that include that LSN range?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Jan 29, 2024 at 04:43:32PM -0300, Ranier Vilela wrote:
> Em seg., 29 de jan. de 2024 às 16:32, Nathan Bossart <
> nathandboss...@gmail.com> escreveu:
>> -#define WORDNUM(x) ((x) / BITS_PER_BITMAPWORD)
>> -#define BITNUM(x) ((x) % BITS_PER_BITMAPWOR
ord and not straight to uint32. I
don't think the intent is that callers will provide a bitmapword to these
macros. I also wonder if it's worth asserting that x is >= 0 before
casting here.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, Jan 27, 2024 at 10:31:09AM -0600, Nathan Bossart wrote:
> On Sat, Jan 27, 2024 at 11:00:01AM +0300, Alexander Lakhin wrote:
>> I'm discouraged by "\n1" in the file name and in the
>> "examining summary..." message.
>> regress_log_002_bloc
On Fri, Jan 26, 2024 at 01:24:19PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> I see that I was planning on back-patching this to v16, but since
>> is_valid_ascii() was introduced in v15, I'm wondering if it'd be better to
>> back-patch it there so that is_valid_asci
rations in a predictable location. I
actually find the alternative less readable, but that could just be because
I spend so much time looking at Postgres code.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
:21:58.925](0.001s) ok 1 - WAL summary file exists
Ah, I think this query:
SELECT tli, start_lsn, end_lsn from pg_available_wal_summaries()
WHERE tli = $summarized_tli AND end_lsn > '$summarized_lsn'
is returning more than one row in some cases. I attached a qui
On Thu, Jan 04, 2024 at 04:43:29PM -0600, Nathan Bossart wrote:
> 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 so
On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote:
> Here is v2 with that addition.
Looks reasonable.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Jan 25, 2024 at 10:06:41AM -0500, Robert Haas wrote:
> On Wed, Jan 24, 2024 at 2:39 PM Nathan Bossart
> wrote:
>> That seems like a reasonable starting point. Even if it doesn't help
>> determine the root cause, it should at least help rule out concurrent
>> su
se to
>> remove HandleWalWriterInterrupts() and make walwriter use
>> HandleMainLoopInterrupts() instead for improved code simplicity. Thought?
>>
>> Patch attached.
>
> Nice catch. Indeed they both are the same after commit 1bdd54e662. The
> patch LGTM.
LGTM, too.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Jan 24, 2024 at 02:08:08PM -0500, Robert Haas wrote:
> On Wed, Jan 24, 2024 at 1:05 PM Nathan Bossart
> wrote:
>> Otherwise, I think we'll probably need to add some additional logging to
>> figure out what is happening...
>
> Where, though? I suppose we could:
&
re.
*/
cutoff_time = time(NULL) - 60 * wal_summary_keep_time;
Otherwise, I think we'll probably need to add some additional logging to
figure out what is happening...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
A recent buildfarm failure [0] seems to indicate a name collision with the
"abc" index in the aggregates.sql test and the "abc" table in
namespace.sql.
[0]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet=2024-01-24%2014%3A05%3A14
--
Nathan Bossart
Amazon
able to reproduce the issue on my machine, and I haven't
figured out precisely what is happening yet, but I wanted to make sure
there is awareness.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Jan 23, 2024 at 06:33:25PM +0100, Alvaro Herrera wrote:
> On 2024-Jan-22, Nathan Bossart wrote:
>
>> Here is a patch.
>
> Looks reasonable.
Committed. Thank you for the report and the reviews.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Jan 23, 2024 at 12:22:58PM -0600, Nathan Bossart wrote:
> On Tue, Jan 23, 2024 at 06:33:25PM +0100, Alvaro Herrera wrote:
>> Does this actually detect a problem if you take out the fix? I think
>> what's going to happen is that postmaster is going to crash, then do the
&g
On Tue, Jan 23, 2024 at 06:33:25PM +0100, Alvaro Herrera wrote:
> On 2024-Jan-22, Nathan Bossart wrote:
>> This might be a topic for another thread, but I do wonder whether we could
>> put a generic pg_controldata check in node->stop that would at least make
>> sure tha
On Mon, Jan 22, 2024 at 04:27:43PM -0600, Nathan Bossart wrote:
> Here is a patch.
I'd like to fix these crashes sooner than later, so I will plan on
committing this tonight (barring objections or feedback). If this needs to
be revisited later for some reason, I'm happy to do so.
--
Nat
On Mon, Jan 22, 2024 at 05:00:48PM +0530, Bharath Rupireddy wrote:
> On Mon, Jan 22, 2024 at 3:43 AM Nathan Bossart
> wrote:
>> Oops. I've attached an attempt at fixing this. I took the opportunity to
>> clean up the surrounding code a bit.
>
> The code lo
On Mon, Jan 22, 2024 at 03:38:15PM -0600, Nathan Bossart wrote:
> On Mon, Jan 22, 2024 at 01:24:54PM -0800, Andres Freund wrote:
>> On 2024-01-22 15:19:36 -0600, Nathan Bossart wrote:
>>> I think this is because the autoprewarm state was moved to a DSM segment,
>>> an
On Mon, Jan 22, 2024 at 01:24:54PM -0800, Andres Freund wrote:
> On 2024-01-22 15:19:36 -0600, Nathan Bossart wrote:
>> I think this is because the autoprewarm state was moved to a DSM segment,
>> and DSM segments are detached before the on_shmem_exit callbacks are called
>>
On Mon, Jan 22, 2024 at 02:44:57PM -0600, Nathan Bossart wrote:
> On Mon, Jan 22, 2024 at 12:41:17PM -0800, Andres Freund wrote:
>> I noticed that I was getting core dumps while executing the tests, without
>> the
>> tests failing. Backtraces are vriations of this:
On Mon, Jan 22, 2024 at 12:41:17PM -0800, Andres Freund wrote:
> I noticed that I was getting core dumps while executing the tests, without the
> tests failing. Backtraces are vriations of this:
Looking, thanks for the heads-up.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sun, Jan 21, 2024 at 09:51:18PM -0600, Nathan Bossart wrote:
> I did notice a cfbot failure [0]. After a quick glance, I'm assuming this
> is caused by the memcpy() in insert_into_bucket(). Even if the string is
> short, it will copy the maximum key size, which is bad. So, 0002 is
pi.cirrus-ci.com/v1/artifact/task/5124848070950912/log/src/test/modules/test_dsm_registry/log/postmaster.log
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
way other than SIGSEGV.
Oops. I've attached an attempt at fixing this. I took the opportunity to
clean up the surrounding code a bit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From f4c1c7a7ce8bccf7251e384f895f34beb33f839e Mon Sep 17 00:00:00 2001
From: Nathan Bossa
tring_hash(), and it
uses them for the DSM registry's dshash table. This allows us to remove
the hacky key padding code for lookups on this table.
Thoughts?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 5fe6d05f2cfa1401c2fb967fe4bb52cae3706228 Mon Sep 17 00:00:00 2001
On Wed, Jan 17, 2024 at 08:00:00AM +0530, Bharath Rupireddy wrote:
> The v8 patches look good to me.
Committed. Thanks everyone for reviewing!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Jan 17, 2024 at 06:48:37AM +0530, Bharath Rupireddy wrote:
> LGTM.
Committed. Thanks for reviewing!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Jan 18, 2024 at 02:44:35PM -0700, David G. Johnston wrote:
> LGTM too. I didn't go looking for anything else related to this, but the
> proposed changes all look needed.
Committed. Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
i.e., you could pass in NULL if you didn't want it), but I
didn't feel like the extra code in GetNamedDSMSegment() to allow this was
worth it so that callers could avoid creating a single bool.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 402eaf87776fb6a9d212da66947f47c63
On Tue, Jan 16, 2024 at 08:20:19AM -0600, Nathan Bossart wrote:
> On Tue, Jan 16, 2024 at 10:02:15AM +0530, Bharath Rupireddy wrote:
>> The v3 patch looks good to me except for a nitpick: the input
>> parameter for RequestAddinShmemSpace is 'Size' not 'int'
>>
>>
>
old enough to vote (e0dece1, 5f78aa5).
Good catch.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
e, it might be worth fleshing
out the messages a bit more. For example, instead of "PITR shutdown,"
perhaps we could say "shut down while in recovery." And maybe we should
point to the specific settings in the latter message.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
r-committer, and I'm
hoping to commit it in the near future.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sun, Jan 14, 2024 at 04:17:41PM +0530, vignesh C wrote:
> The attached v3 version patch has the changes for the same.
LGTM. I'll wait a little while longer for additional feedback, but if none
materializes, I'll commit this soon.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
this doesn't use getopt_long() instead. AFAICT this dates back to the
introduction of GUCs in 6a68f426 (May 2000).
[0] https://www.postgresql.org/docs/devel/app-postgres.html
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jan 12, 2024 at 01:45:55PM -0600, Nathan Bossart wrote:
> On Fri, Jan 12, 2024 at 11:13:46PM +0530, Abhijit Menon-Sen wrote:
>> At 2024-01-12 11:21:52 -0600, nathandboss...@gmail.com wrote:
>>> + Each backend sould obtain a pointer to the reserved shared memo
I've attached a v3 with a couple of fixes suggested in the other
thread [0]. I'll wait a little while longer in case anyone else wants to
take a look.
[0] https://postgr.es/m/ZaF6UpYImGqVIhVp%40toroid.org
--
Nathan Bossart
Amazon Web Services: https://aws.a
errdetail("Non-superusers must provide
> a password in the connection string.")));
> + }
> }
>
> PQconninfoFree(opts);
Another option could be to surround this with PG_TRY/PG_FINALLY, but your
patch seems sufficient, too.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jan 12, 2024 at 04:42:27PM -0600, Nathan Bossart wrote:
> On Wed, Dec 20, 2023 at 06:47:44PM -0500, Tom Lane wrote:
>> +char *cmdEnd = psprintf(" OWNER TO %s",
>> fmtId(te->owner));
>> +
>> +IssueCo
ate if
pg_upgrade completely missed out on this improvement.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
c to make the size be 1000 divided
> by the number of parallel restore jobs allowed.
I wonder if it'd be worth making this configurable for pg_upgrade as an
escape hatch in case the default setting is problematic.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
rve LWLocks on server startup. Like with shared
>> memory,
>
> (Would "As with shared memory" read better? Maybe, but then again maybe
> it should be left alone because you also write "Unlike with" elsewhere.)
I think "As with shared memory..."
On Fri, Jan 12, 2024 at 09:46:50AM -0600, Nathan Bossart wrote:
> On Fri, Jan 12, 2024 at 05:12:28PM +0300, Aleksander Alekseev wrote:
>> """
>> Any registered shmem_startup_hook will be executed shortly after each
>> backend attaches to shared memory.
>&g
://postgr.es/m/20240112041430.GA3557928%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 7cf22727a96757bf212ec106bd471bf55a6981b9 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 11 Jan 2024 21:55:25 -0600
Subject: [PATCH v6 1/3] reorganize shared mem
rocess allocates a new tranche_id
> (LWLockNewTrancheId) and initializes each new LWLock
> (LWLockInitialize).
> """
>
> Personally I think that reminding the corresponding function name here
> is redundant and complicates reading just a bit. But maybe it's just
> me.
Yeah, I waffled on this one. I don't mind removing it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
[0] https://postgr.es/m/20231205034647.GA2705267%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From dc5c1b37ced883021f4a92a17aa50b9d80d73fc6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 11 Jan 2024 21:55:25 -0600
Subject: [PATCH v1 1/1] reorganize
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 6cee7d220b886e9be309929da5274c5770e59845 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 15 Feb 2023 14:28:53 -0800
Subject: [PATCH v17 1/5] introduce routine for checking mutually exclusive
string G
On Thu, Jan 11, 2024 at 09:50:19AM +0700, Andrei Lepikhov wrote:
> On 9/1/2024 00:16, Nathan Bossart wrote:
>> On Mon, Jan 08, 2024 at 10:53:17AM +0530, Bharath Rupireddy wrote:
>> > 2. FWIW, I'd like to call this whole feature "Support for named DSM
>> > segments i
HV6n%3Dw1u8Q%40mail.gmail.com
[1]
https://postgr.es/m/VI1PR05MB62031A41186ACC3FC91ACFC70%40VI1PR05MB6206.eurprd05.prod.outlook.com
[2] https://postgr.es/m/dd0e070809430a31f7ddd8483fbcce59%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
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!
--
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 needs to
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
ind-of bizarre state to end up
in.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
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 needed here.
D'oh! Fixe
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
>
eems 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 thread.
--
Nathan Bos
thing 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
ypo: 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
NAMEDATALEN.
--
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 Bossart
Date: Fri, 5 Jan 2024 00:07:40 -0600
Subject: [
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 17:01:10
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
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
>
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
h 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
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
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_file = &quo
s less 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
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://postgr.es/m/at
ning 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 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 lib
ion of loop unrolling is probably more than is really necessary.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
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
e 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. Tha
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
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.
>
s 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 required injection points here? I thi
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
>
ent for
everything doesn't seem particularly burdensome.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
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 date ba
(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're su
ave 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
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 buildfar
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 registry
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
>F
401 - 500 of 1953 matches
Mail list logo
