Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
will do.
[0] https://postgr.es/m/20240321183823.GA1800896%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
magnitude.
> * Code needs more than zero comments.
Yup.
> * Is it worth trying to make a subroutine, or at least a macro,
> so as not to have 2 copies of the code?
I think so. I'll try that in the next version.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Mar 22, 2024 at 04:41:49PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> LGTM
>
> Thanks for looking, I'll push that shortly.
Are there any changes you'd like to see for the Bloom patch [0]? I'd like
to see about getting that committed for v17. One thing that
On Sun, Mar 24, 2024 at 03:53:17PM -0500, Nathan Bossart wrote:
> Here's a new version of 0001 with some added #ifdefs that cfbot revealed
> were missing.
Sorry for the noise. cfbot revealed another silly mistake (forgetting to
reset the "i" variable in the assertion path). That
Here's a new version of 0001 with some added #ifdefs that cfbot revealed
were missing.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From cc2bc5ca5b49cd8641af8b2231a34a1aa5091bb9 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 20 Mar 2024 14:20:24 -0500
Subject: [PA
On Sat, Mar 23, 2024 at 08:37:20AM -0400, Robert Haas wrote:
> On Fri, Mar 22, 2024 at 4:51 PM Nathan Bossart
> wrote:
>> Actually, shouldn't this one be back-patched to v16? If so, I'd do that
>> one separately from the other changes we are discussing.
>
> Sure, tha
On Fri, Mar 22, 2024 at 03:45:06PM -0500, Nathan Bossart wrote:
> On Fri, Mar 22, 2024 at 03:58:59PM -0400, Robert Haas wrote:
>> On Fri, Nov 10, 2023 at 12:41 PM Nathan Bossart
>> wrote:
>>> I still think we should update the existing note about privileges for
>>
On Fri, Mar 22, 2024 at 03:58:59PM -0400, Robert Haas wrote:
> On Fri, Nov 10, 2023 at 12:41 PM Nathan Bossart
> wrote:
>> Looking again, I'm kind of hesitant to add too much qualification to this
>> note about losing superuser privileges.
>
> The note in question is:
>
On Fri, Mar 22, 2024 at 11:54:48AM -0500, Nathan Bossart wrote:
> On Fri, Mar 22, 2024 at 12:53:15PM -0400, Tom Lane wrote:
>> Would you like to review the catcache patch further, or do you
>> think it's good to go?
>
> I'll take another look this afternoon.
LGTM
--
Nath
On Fri, Mar 22, 2024 at 12:53:15PM -0400, Tom Lane wrote:
> Would you like to review the catcache patch further, or do you
> think it's good to go?
I'll take another look this afternoon.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ble is probably pretty safe and
provides the majority of the benefit, but anything fancier should probably
be reserved for v17 or v18.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Mar 22, 2024 at 09:47:39AM -0500, Nathan Bossart wrote:
> hash hash+simd hash+simd+bloom
> create 1.27 1.27 1.28
> grant 0.18 0.11 0.03
For just hash+bloom, I'm seeing 1.29 and 0.04.
--
Nathan Bossart
Amazon Web Servic
On Thu, Mar 21, 2024 at 08:59:54PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Thu, Mar 21, 2024 at 03:40:12PM -0500, Nathan Bossart wrote:
>>> On Thu, Mar 21, 2024 at 04:31:45PM -0400, Tom Lane wrote:
>>>> I don't think we have any really cheap way to d
On Thu, Mar 21, 2024 at 08:03:32PM -0500, Nathan Bossart wrote:
> On Thu, Mar 21, 2024 at 08:59:54PM -0400, Tom Lane wrote:
>> However ... I just remembered that we have a Bloom filter implementation
>> in core now (src/backend/lib/bloomfilter.c). How about using that
>&
er_oid check if the filter passes?
Seems worth a try. I've been looking for an excuse to use that...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Mar 21, 2024 at 03:40:12PM -0500, Nathan Bossart wrote:
> On Thu, Mar 21, 2024 at 04:31:45PM -0400, Tom Lane wrote:
>> I don't think we have any really cheap way to de-duplicate the role
>> OIDs, especially seeing that it has to be done on-the-fly within the
>
On Wed, Mar 20, 2024 at 11:57:25AM -0400, Greg Sabino Mullane wrote:
> My mistake. Attached please find version 3, which should hopefully make
> cfbot happy again.
Here is what I have staged for commit. I plan to commit this within the
next few days.
--
Nathan Bossart
Amazon Web Se
doned because we didn't have any concrete use-cases at the
time. (I'm looking into some additional optimizations in a separate thread
[1] that would likely apply here, too.)
[0] https://postgr.es/m/20230308002502.GA3378449%40nathanxps13
[1] https://postgr.es/m/20240321183823.GA1800896%40nathanxps13
On Thu, Mar 21, 2024 at 10:24:12AM -0700, Andres Freund wrote:
> I was out while this was proposed and committed. Just wanted to say: Thanks!
> It was high time that we added this...
Definitely. I hope we are able to build on this in the near future.
--
Nathan Bossart
Amazon Web Se
On Thu, Mar 21, 2024 at 12:09:44PM -0500, Nathan Bossart wrote:
> On Thu, Mar 21, 2024 at 11:30:30AM +0700, John Naylor wrote:
>> Further, now that the algorithm is more SIMD-appropriate, I wonder
>> what doing 4 registers at a time is actually buying us for either SSE2
>> o
On Thu, Mar 21, 2024 at 12:09:44PM -0500, Nathan Bossart wrote:
> It does still eventually win, although not nearly to the same extent as
> before. I extended the benchmark a bit to show this. I wouldn't be
> devastated if we only got 0001 committed for v17, given these results.
ithm is more SIMD-appropriate, I wonder
> what doing 4 registers at a time is actually buying us for either SSE2
> or AVX2. It might just be a matter of scale, but that would be good to
> understand.
I'll follow up with these numbers shortly.
--
Nathan Bossart
Amazon Web Services: http
On Thu, Mar 21, 2024 at 03:24:17PM +0100, Daniel Gustafsson wrote:
>> On 21 Mar 2024, at 15:11, Nathan Bossart wrote:
>> I added that to maintain the line break that was in the non-Markdown
>> version. I'd rather match the style of the following paragraph (patch
>
sion. I'd rather match the style of the following paragraph (patch
attached) than mess with .gitattributes.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/README.md b/README.md
index 445eb2f2d0..f6104c038b 100644
--- a/README.md
+++ b/README.md
@@ -11,11 +11,10 @@ and f
On Wed, Mar 20, 2024 at 09:31:16AM -0500, Nathan Bossart wrote:
> On Wed, Mar 20, 2024 at 01:57:54PM +0700, John Naylor wrote:
>> On Tue, Mar 19, 2024 at 11:30 PM Nathan Bossart
>> wrote:
>>> I tried to trim some of the branches, and came up with the attached
On Wed, Mar 20, 2024 at 02:53:01PM -0400, Robert Haas wrote:
> On Wed, Mar 20, 2024 at 2:35 PM Nathan Bossart
> wrote:
>> Committed.
>
> Thanks. Sorry you had to clean up after me. :-(
No worries.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Mar 19, 2024 at 01:15:02PM -0500, Nathan Bossart wrote:
> Assuming there are no objections or feedback, I plan to commit these two
> patches within the next couple of days.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Mar 19, 2024 at 09:15:22PM -0400, Greg Sabino Mullane wrote:
> Rebased version attached (v2), with another sentence in the sgml to explain
> the optional use of -d
cfbot seems quite unhappy with this:
https://cirrus-ci.com/build/6429518263484416
--
Nathan Bossart
Amaz
On Wed, Mar 20, 2024 at 01:57:54PM +0700, John Naylor wrote:
> On Tue, Mar 19, 2024 at 11:30 PM Nathan Bossart
> wrote:
>> I tried to trim some of the branches, and came up with the attached patch.
>> I don't think this is exactly what you were suggesting, but I think it's
&
On Tue, Mar 19, 2024 at 01:47:53PM -0500, Nathan Bossart wrote:
> On Mon, Mar 11, 2024 at 04:59:36PM +0100, Alvaro Herrera wrote:
>> All in all, I support the original patch.
>
> I'll commit this in a few days if there are no objections.
Actually, I just took a look at the patch
On Tue, Mar 19, 2024 at 12:30:50PM +1300, David Rowley wrote:
> Looks good.
Committed. Thanks for the suggestion and for reviewing!
Paul, I suspect your patches will need to be rebased after commit cc4826d.
Would you mind doing so?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Mar 14, 2024 at 08:52:55PM -0500, Nathan Bossart wrote:
> Subject: [PATCH v1 1/2] Revert "Temporary patch to help debug pg_walsummary
> test failures."
> Subject: [PATCH v1 2/2] Fix possible overflow in MaybeRemoveOldWalSummaries().
Assuming there are no objections
On Mon, Mar 11, 2024 at 04:59:36PM +0100, Alvaro Herrera wrote:
> All in all, I support the original patch.
I'll commit this in a few days if there are no objections.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Mar 19, 2024 at 04:53:04PM +0700, John Naylor wrote:
> On Tue, Mar 19, 2024 at 10:16 AM Nathan Bossart
> wrote:
>> 0002 does the opposite of this. That is, after we've completed as many
>> blocks as possible, we move the iterator variable back to "end -
>>
t" is an exact multiple of blocks, and loop over
> them
0002 does the opposite of this. That is, after we've completed as many
blocks as possible, we move the iterator variable back to "end -
block_size" and do one final iteration to cover all the remaining elements.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
've decided to stop.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 2f4a7747025cd3288453fdabd520638e37e3633c Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 18 Mar 2024 10:44:08 -0500
Subject: [PATCH v4 1/3] pg_lfind32(): Optimize processing remaining elements.
Disc
On Mon, Mar 18, 2024 at 04:29:19PM -0500, Nathan Bossart wrote:
> Agreed. Will send an updated patch shortly.
As promised...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From b673663b1d1344549cbd0912220f96ba1712afc6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: M
On Tue, Mar 19, 2024 at 10:27:58AM +1300, David Rowley wrote:
> On Tue, 19 Mar 2024 at 10:08, Nathan Bossart wrote:
>> On Tue, Mar 19, 2024 at 10:02:18AM +1300, David Rowley wrote:
>> > The only thing I'd question in the patch is in pg_popcount_fast(). It
>> > looks
_popcount_available() returns true,
can I safely assume I'm on a 64-bit machine?"
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ge to have
> pg_popcount_slow() do it and not pg_popcount_fast().
The only reason I left it out was because I couldn't convince myself that
it wasn't dead code, given we assume that popcntq is available in
pg_popcount64_fast() today. But I don't see any harm in adding that just
in case.
--
Nath
On Mon, Mar 18, 2024 at 12:30:04PM -0500, Nathan Bossart wrote:
> Here is a more fleshed-out version of what I believe David is proposing.
> On my machine, the gains aren't quite as impressive (~8.8s to ~5.2s for the
> test_popcount benchmark). I assume this is because this pa
_popcount extension and run "CREATE
EXTENION test_popcount;".
> Another Question: Is there a reason "time psql" is used over the Postgres
> "\timing" command?
I don't think there's any strong reason. I've used both.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Mar 18, 2024 at 11:20:18AM -0500, Nathan Bossart wrote:
> I don't think David was suggesting that we need to remove the runtime
> checks for AVX512. IIUC he was pointing out that most of the performance
> gain is from removing the function call overhead, which your v8-0002 patch
a similar
optimization for systems without AVX512 by inlining the code for
pg_popcount64() and pg_popcount32().
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Mar 18, 2024 at 09:56:32AM +1300, David Rowley wrote:
> Maybe it's worth exploring something along the lines of the attached
> before doing the AVX512 stuff. It seems like a pretty good speed-up
> and will apply for CPUs without AVX512 support.
+1
--
Nathan Bossart
Amazon Web
I'll commit the attached patch shortly.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/backend/commands/statscmds.c b/src/backend/commands/statscmds.c
index 5f49479832..1db3ef69d2 100644
--- a/src/backend/commands/statscmds.c
+++ b/src/backend/commands/statscmds.c
@@
On Fri, Mar 15, 2024 at 12:41:49PM -0500, Nathan Bossart wrote:
> I've also attached the results of running this benchmark on my machine at
> HEAD, after applying 0001, and after applying both 0001 and 0002. 0001
> appears to work pretty well. When there is a small "tail," it
rrays are longer. It might be
possible to mitigate by using 2 registers when the "tail" is long enough,
but I have yet to try that.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 3a4d74eeab18d9e8f510e11185109ed910e40268 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Da
d re-ran the
tests a couple of times because I had a difficult time believing the amount
of improvement.)
[0]
https://postgr.es/m/CAFBsxsE7otwnfA36Ly44zZO%2Bb7AEWHRFANxR1h1kxveEV%3DghLQ%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
quot;if invalidation_reason is rows_removed or
>> wal_level_insufficient it's the reason for conflict with recovery".
>
> Fair point. I think we can go either way. Bertrand, Nathan, and
> others, do you have an opinion on this matter?
WFM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
rebased for cfbot
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From d3f497906daf1c405059b2c292f1eeb5cfeb742b Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 15 Feb 2023 14:28:53 -0800
Subject: [PATCH v19 1/5] introduce routine for checking mutually exclusive
str
On Thu, Mar 14, 2024 at 04:00:10PM -0500, Nathan Bossart wrote:
> Separately, I suppose it's probably time to revert the temporary debugging
> code adding by commit 5ddf997. I can craft a patch for that, too.
As promised...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Jan 24, 2024 at 12:05:15PM -0600, Nathan Bossart wrote:
> There might be an overflow risk in the cutoff time calculation, but I doubt
> that's the root cause of these failures:
>
> /*
>* Files should only be removed if the last modificatio
Hi Maiquel,
On Thu, Feb 29, 2024 at 10:02:21PM +, Maiquel Grassi wrote:
> Sorry for the delay. I will make the adjustments as requested soon.
We have only a few weeks left before feature-freeze for v17. Do you think
you will be able to send an updated patch soon?
--
Nathan Bossart
Ama
On Wed, Mar 13, 2024 at 01:09:18PM +0700, Yugo NAGATA wrote:
> On Tue, 12 Mar 2024 22:07:17 -0500
> Nathan Bossart wrote:
>> I did some light editing to prepare this for commit.
>
> Thank you. I confirmed the test you improved and I am fine with that.
Committed.
--
Nathan
On Wed, Mar 13, 2024 at 09:49:26AM -0700, Jeff Davis wrote:
> Looks good to me. Thank you for expanding on the comment, as well.
Thanks for reviewing! Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
e volunteers, I could probably give this a try once v17 is
frozen.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
gt; architecture-specific fashion.
>
> I see the point here; however, this will take some time to get right
> especially since I don't have a Windows box to do compiles on. Should I
> attempt to do this in this patch?
This might also be less important given the absence of any imminent new
code with this macro. This might even be a necessary step
towards building these files in an architecture-specific fashion.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
I did some light editing to prepare this for commit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 38c78bd92a7b4d4600e6f0dbe58283c21ea87d50 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 12 Mar 2024 22:04:25 -0500
Subject: [PATCH v10 1/1]
On Thu, Mar 07, 2024 at 10:50:00AM -0600, Nathan Bossart wrote:
> Given all of this code was previously reviewed and committed, I am planning
> to forge ahead and commit this early next week, provided no objections or
> additional feedback materialize.
Jeff Davis and I spent some additi
On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
>> I've read that the use of the term "minor release" can be confusing. While
>> the versioning page clearly describes what is eli
32-bit chunks. Any remaining
bytes will be processed one-by-one.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
n minor releases. I think a "minor release" of Postgres is
more similar to what other projects would call a "patch version."
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Mar 08, 2024 at 04:03:22PM -0600, Nathan Bossart wrote:
> On Fri, Mar 08, 2024 at 09:33:19AM +, Dean Rasheed wrote:
>> I think this is good to go.
>
> Thanks. In v4, I've added a first draft of the commit messages, and I am
> planning to commit this early nex
er parameter to allow vacuum to proceed removing the rows which
> otherwise it wouldn't have been as those would be required by some
> slot.
Yeah, the idea is to help prevent transaction ID wraparound, so I would
expect max_slot_xid_age to ordinarily be set relatively high, i.e., 1.5B+.
On Sat, Mar 09, 2024 at 11:57:18AM +0900, Yugo NAGATA wrote:
> On Fri, 8 Mar 2024 16:17:58 -0600
> Nathan Bossart wrote:
>> Is this guaranteed to be TOASTed for all possible page sizes?
>
> Should we use block_size?
>
> SHOW block_size \gset
> INSERT INTO test
minates the test
> timeout.
Thanks for confirming! I'm assuming this just masks the underlying
issue...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Mar 08, 2024 at 03:31:55PM +0900, Yugo NAGATA wrote:
> On Thu, 7 Mar 2024 16:56:17 -0600
> Nathan Bossart wrote:
>> to me. Do you think it's worth adding something like a
>> pg_column_toast_num_chunks() function that returns the number of chunks for
>> the TOASTe
g to commit this early next week.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 460da2161265b042079727c1178eff92b3d537b6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 8 Mar 2024 14:35:07 -0600
Subject: [PATCH v4 1/3] vacuumdb: Allow specifying objects to pr
tes
testing it out and looking at the code, and it seems generally reasonable
to me. Do you think it's worth adding something like a
pg_column_toast_num_chunks() function that returns the number of chunks for
the TOASTed value, too?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ps://postgr.es/m/CA%2BhUKGL0bikWSC2XW-zUgFWNVEpD_gEWXndi2PE5tWqmApkpZQ%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
d and didn't see any recent benchmark results for the
latest form of the patch. I think it's worth verifying that we are still
seeing the expected improvements.
[0] https://postgr.es/m/202402071953.5c4z7t6kl7ts%40alvherre.pgsql
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
he configure file in the submitted patch is not relevant, only
> configure.ac matters.
Agreed. I didn't intend for this to be a major review point, and I
apologize for the extra noise.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
or the
> previous message?
I do not know, sorry. I personally use mutt for the lists.
> BTW: Created the commit-fest submission.
Thanks. I intend to provide a more detailed review shortly, as I am aiming
to get this one committed for v17.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
I don't think anything discussed in this thread is ready for v17, so I am
going to punt it to v18.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Mar 05, 2024 at 10:12:35AM -0600, Nathan Bossart wrote:
> Thanks to Jeff's recent work with commits 2af07e2 and 59825d1, the issue
> that led to the revert of the MAINTAIN privilege and the pg_maintain
> predefined role (commit 151c22d) should now be resolved. Spe
in vacuumdb, but I believe that
would require a much more invasive patch, and I've already spent far more
time on this change than I wanted to.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 84b3f5a8275d53707b15208d761567372b7b20a5 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Da
Here is another rebase. Given the size of this patch set and the lack of
review, I am going to punt this one to v18.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From dd69e5987b477818f60b202af5fb9b2603dc8acb Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 15 Feb 2
On Wed, Mar 06, 2024 at 10:02:43AM +0530, Bharath Rupireddy wrote:
> On Wed, Mar 6, 2024 at 1:22 AM Nathan Bossart
> wrote:
>> I was thinking of something more like
>>
>> typedef enum
>> {
>> NO_FORCE_SWITCH_TO_STREAMING,
On Tue, Mar 05, 2024 at 05:14:46PM -0800, Jacob Champion wrote:
> On Tue, Mar 5, 2024 at 1:51 PM Nathan Bossart
> wrote:
>> I don't have a strong opinion about making this configurable, but I do
>> think we should consider making this a hash table so that we can set
>&g
> /*
> * Module Load Callback
> */
> void
> _PG_init(void)
> {
> + if (!process_shared_preload_libraries_in_progress)
> + ereport(ERROR,
> +
> (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> +
On Tue, Mar 05, 2024 at 11:38:37PM +0530, Bharath Rupireddy wrote:
> On Tue, Mar 5, 2024 at 7:34 AM Nathan Bossart
> wrote:
>> Is there any way to simplify this? For
>> example, would it be possible to make an enum that tracks the
>> streaming_replication_retry_inte
On Wed, Mar 06, 2024 at 12:50:38AM +0530, Bharath Rupireddy wrote:
> On Mon, Mar 4, 2024 at 2:11 PM Bertrand Drouvot
> wrote:
>> On Sun, Mar 03, 2024 at 03:44:34PM -0600, Nathan Bossart wrote:
>> > Unless I am misinterpreting some details, ISTM we cou
//wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Mar 05, 2024 at 11:50:36AM +0100, Daniel Gustafsson wrote:
>> On 4 Mar 2024, at 23:49, Nathan Bossart wrote:
>> * Should this be a "Warning" and/or moved to the top of the page? This
>> seems like a relatively important notice that folks should see when
&
per_Meeting#The_Path_to_un-reverting_the_MAINTAIN_privilege
[1] https://commitfest.postgresql.org/47/4836/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From d2598b78f0796be20ad322fcb3b9ef7cfaa76491 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 5 Mar 2024 09:49:49 -0600
S
On Mon, Oct 23, 2023 at 03:25:42PM -0500, Nathan Bossart wrote:
> rebased
I saw that this thread was referenced elsewhere [0], so I figured I'd take
a fresh look. From a quick glance, I'd say 0001 and 0002 are pretty
reasonable and could probably be committed for v17. 0003 probably requi
iseconds; 0 disables
I think we might want to turn this feature off by default, at least for the
first release.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
uot;Warning" and/or moved to the top of the page? This
seems like a relatively important notice that folks should see when
beginning to use pgcrypto.
* Should we actually document the exact list of algorithms along with
detailed reasons? This list seems prone to becoming outdated.
--
Nathan Bo
iven it has been reviewed by multiple
> committers so far? The scope of the change is pretty contained as well.
I think so. I would still encourage you to create an entry for this so
that it is automatically tested via cfbot [0].
[0] http://commitfest.cputube.org/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
his e-mail signature,
which has an accent over the first 'A'. I assume that's why it's not
showing up correctly in some places.
Anyway, I've committed this now. Thanks for taking a look!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
we document the errormessage there.
Thanks for reviewing. How does this look?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 437e4fa9ec27ecf870530fc579cd7673dfcf96af Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 4 Mar 2024 11:15:37 -0600
Subject: [PATCH v5 1/1] Add macro
On Sun, Mar 03, 2024 at 11:40:00PM +0530, Bharath Rupireddy wrote:
> On Sat, Mar 2, 2024 at 3:41 AM Nathan Bossart
> wrote:
>> Would you ever see "conflict" as false and "invalidation_reason" as
>> non-null for a logical slot?
>
> No. Because both
particularly severe to me, especially for a
benchmarking program, but I'd be curious to hear what others think.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
hat looks clean IMHO.
Would you ever see "conflict" as false and "invalidation_reason" as
non-null for a logical slot?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
if not all, of these changes seem extraneous. Do we actually need to
more strictly check SIZEOF_VOID_P?
[0] https://commitfest.postgresql.org/48/
[1] https://postgr.es/m/20230211020042.uthdgj72kp3xlqam%40awork3.anarazel.de
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
If the benchmarks show that
the locking is a problem, we can reevaluate, but otherwise IMHO we should
try to keep it as simple/flexible as possible.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Feb 29, 2024 at 10:02:21PM +, Maiquel Grassi wrote:
> Sorry for the delay. I will make the adjustments as requested soon.
Looking forward to it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
201 - 300 of 1916 matches
Mail list logo
