On Wed, Mar 27, 2024 at 01:47:38PM -0300, Ranier Vilela wrote:
> Em qua., 27 de mar. de 2024 às 13:41, Nathan Bossart <
> nathandboss...@gmail.com> escreveu:
>> On Wed, Mar 27, 2024 at 01:21:23PM -0300, Ranier Vilela wrote:
>> > I think that left an oversight in a com
On Tue, Mar 26, 2024 at 09:48:57PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I just did the minimal fix for now, i.e., I moved the new label into the
>> SIMD section of the function. I think it would be better stylistically to
>> move the one-by-one logic to an i
ould. I don't see any reason not to, and my compiler
doesn't complain, either.
> LGTM otherwise, and I like the fact that the #if structure
> gets a lot less messy.
Thanks for reviewing. I've attached a v2 that I intend to commit when I
get a chance.
--
On Mon, Mar 25, 2024 at 03:05:51PM -0500, Nathan Bossart wrote:
> On Mon, Mar 25, 2024 at 06:42:36PM +, Amonson, Paul D wrote:
>> Ok, CI turned green after my re-post of the patches. Can this please get
>> merged?
>
> Thanks for the new patches. I intend to take anoth
On Wed, Mar 27, 2024 at 04:37:35PM -0500, Nathan Bossart wrote:
> On Wed, Mar 27, 2024 at 05:10:13PM -0400, Tom Lane wrote:
>> LGTM otherwise, and I like the fact that the #if structure
>> gets a lot less messy.
>
> Thanks for reviewing. I've attached a v2 that I inten
12.
* I think we need to verify there isn't a huge performance regression for
smaller arrays. IIUC those will still require an AVX512 instruction or
two as well as a function call, which might add some noticeable overhead.
--
Nathan Bossart
Amazon Web Services
On Thu, Mar 28, 2024 at 04:38:54PM -0500, Nathan Bossart wrote:
> Here is a v14 of the patch that I think is beginning to approach something
> committable. Besides general review and testing, there are two things that
> I'd like to bring up:
>
> * The latest patch set from P
much, but I want to know how portable the XGETBV
instruction is. Unless I can assume that all x86_64 systems and compilers
support that instruction, we might need an additional configure check
and/or CPUID check. It looks like MSVC has had support for the _xgetbv
intrinsic for quite a while, but I'
you recall why you added this?
[0] https://cirrus-ci.com/task/5787206636273664?logs=configure#L159
[1]
https://postgr.es/m/attachment/158206/v12-0002-Feature-Added-AVX-512-acceleration-to-the-pg_popcoun.patch
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
defined in pg_popcount_a...
It might be nice if we conditionally built pg_popcount_avx512.o in autoconf
builds, too, but AFAICT we still need to wrap most of that code with
macros, so I'm not sure it's worth the trouble. I'll take another look at
this...
[0] http://commitfest.cputube
lability of XGETBV on the CPU.
If that's not safe, we might need to add another CPUID test.
It would probably be easy enough to add a couple of tests for this, but if
we don't have reason to believe there's any practical case to do so, I
don't know why we would. I'm curiou
On Fri, Mar 29, 2024 at 10:59:40AM -0500, Nathan Bossart wrote:
> It might be nice if we conditionally built pg_popcount_avx512.o in autoconf
> builds, too, but AFAICT we still need to wrap most of that code with
> macros, so I'm not sure it's worth the trouble. I'll tak
On Fri, Mar 29, 2024 at 12:30:14PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>>> I see google web references to the xgetbv instruction as far back as 2009
>>> for Intel 64 bit HW and 2010 for AMD 64bit HW, maybe you could test for
>>> _xgetbv() MSVC built-in.
checks for both
autoconf/meson.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From d7864391c455ea77b8e555e40a358c59de1bd702 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 27 Mar 2024 16:39:24 -0500
Subject: [PATCH v16 1/1] AVX512 popcount support
---
config/c-
On Fri, Mar 29, 2024 at 02:13:12PM -0500, Nathan Bossart wrote:
> * If the compiler understands AVX512 intrinsics, we assume that it also
> knows about the required CPUID and XGETBV intrinsics, and we assume that
> the conditions for TRY_POPCNT_FAST are true.
Bleh, cfbot's 3
On Fri, Mar 29, 2024 at 03:08:28PM -0500, Nathan Bossart wrote:
>> +#if defined(HAVE__GET_CPUID)
>> +__get_cpuid_count(7, 0, &exx[0], &exx[1], &exx[2], &exx[3]);
>> +#elif defined(HAVE__CPUID)
>> +__cpuidex(exx, 7, 0);
>
> Is there any reason
.
It looks like that's available on gcc, clang, and msvc, although it
sometimes requires -mxsave, so that's applied to
pg_popcount_avx512_choose.o as needed. I doubt this will lead to SIGILLs,
but it's admittedly a little shaky.
--
Nathan Bossart
Amazon Web Services: htt
n I'll give it a few more days for
any additional feedback before committing.
[0]
https://postgr.es/m/CAFBsxsE7otwnfA36Ly44zZO+b7AEWHRFANxR1h1kxveEV=g...@mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, Mar 30, 2024 at 03:03:29PM -0500, Nathan Bossart wrote:
> My current plan is to add some new tests for
> pg_popcount() with many bytes, and then I'll give it a few more days for
> any additional feedback before committing.
Here is a v18 with a couple of new tests. Otherw
On Mon, Apr 01, 2024 at 01:06:12PM +0200, Alvaro Herrera wrote:
> On 2024-Mar-31, Nathan Bossart wrote:
>> +popcnt = _mm512_reduce_add_epi64(accum);
>> +return popcnt + pg_popcount_fast(buf, bytes);
>
> Hmm, doesn't this arrangement cause an extra function call t
al problem
> here is schizophrenia about when to set up pltargs, and we could
> fix it more nicely as attached. (Perhaps the Asserts are overkill
> though.)
Your fix seems fine to me.
[0] https://postgr.es/m/20230504234235.GA2419591%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Mar 27, 2024 at 10:08:26AM -0500, Nathan Bossart wrote:
> On Wed, Mar 27, 2024 at 10:54:05AM -0400, Tom Lane wrote:
>> Michael Banck writes:
>>> What is the status of this? In the commitfest, this patch is marked as
>>> "Needs Review" with Nathan as
On Mon, Apr 01, 2024 at 03:28:26PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> The one design point that worries me a little is the non-configurability of
>> --transaction-size in pg_upgrade. I think it's fine to default it to 1,000
>> or something, but given ho
e? That might be handy in the
future.
I haven't looked too closely, but I'm pretty skeptical that the test suite
in your patch would be stable. Unfortunately, I don't have any better
ideas at the moment besides not adding a test for this new role.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
masked-out portions. I
searched around a little bit but haven't found anything that seemed
definitive.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
happy to do so if folks feel
that it is necessary, and I'd be grateful for thoughts on how to proceed on
this one.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From cedad23b7b35e77fde164b1d577c37fb07a578c6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 1 Apr 2024
On Tue, Apr 02, 2024 at 01:09:57AM +0300, Ants Aasma wrote:
> On Tue, 2 Apr 2024 at 00:31, Nathan Bossart wrote:
>> On Tue, Apr 02, 2024 at 12:11:59AM +0300, Ants Aasma wrote:
>> > What about using the masking capabilities of AVX-512 to handle the
>> > tail in the
On Mon, Apr 01, 2024 at 05:11:17PM -0500, Nathan Bossart wrote:
> Here is a v19 of the patch set. I moved out the refactoring of the
> function pointer selection code to 0001. I think this is a good change
> independent of $SUBJECT, and I plan to commit this soon. In 0002, I
>
On Tue, Apr 02, 2024 at 01:43:48PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2024-Apr-02, Nathan Bossart wrote:
>>> Another idea I had is to turn pg_popcount() into a macro that just uses the
>>> pg_number_of_ones array when called for few bytes:
>&g
On Tue, Apr 02, 2024 at 01:40:21PM -0500, Nathan Bossart wrote:
> On Tue, Apr 02, 2024 at 01:43:48PM -0400, Tom Lane wrote:
>> I don't like the double evaluation of the macro argument. Seems like
>> you could get the same results more safely with
>>
&g
On Tue, Apr 02, 2024 at 05:01:32PM -0500, Nathan Bossart wrote:
> In v21, 0001 is just the above inlining idea, which seems worth doing
> independent of $SUBJECT. 0002 and 0003 are the AVX-512 patches, which I've
> modified similarly to 0001, i.e., I've inlined the &q
On Tue, Apr 02, 2024 at 05:20:20PM -0500, Nathan Bossart wrote:
> Sorry for the noise. I noticed a couple of silly mistakes immediately
> after sending v21.
Sigh... I missed a line while rebasing these patches, which seems to have
grossly offended cfbot. Apologies again for the
On Tue, Mar 26, 2024 at 02:14:14PM -0500, Nathan Bossart wrote:
> On Mon, Jan 15, 2024 at 08:50:25AM -0600, Nathan Bossart wrote:
>> Thanks for reviewing. I've marked this as ready-for-committer, and I'm
>> hoping to commit it in the near future.
>
> This one proba
I committed v23-0001. Here is a rebased version of the remaining patches.
I intend to test the masking idea from Ants next.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 295b03530de5f42fe876b4489191da2f8dc83194 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed,
On Wed, Apr 03, 2024 at 12:41:27PM -0500, Nathan Bossart wrote:
> I committed v23-0001. Here is a rebased version of the remaining patches.
> I intend to test the masking idea from Ants next.
0002 was missing a cast that is needed for the 32-bit builds. I've fixed
that in v25.
On Tue, Apr 02, 2024 at 11:30:39PM +0300, Ants Aasma wrote:
> On Tue, 2 Apr 2024 at 00:31, Nathan Bossart wrote:
>> On Tue, Apr 02, 2024 at 12:11:59AM +0300, Ants Aasma wrote:
>> > What about using the masking capabilities of AVX-512 to handle the
>> > tail in the
On Thu, Apr 04, 2024 at 04:28:58PM +1300, David Rowley wrote:
> On Thu, 4 Apr 2024 at 11:50, Nathan Bossart wrote:
>> If we can verify this approach won't cause segfaults and can stomach the
>> regression between 8 and 16 bytes, I'd happily pivot to this approach so
choice easy.
IIRC the inlined version starts losing pretty quickly after 8 bytes. As I
noted in my previous message, I think we have enough data to switch to your
approach already, so I think it's a moot point.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
p; (total_len == dummy_lex.input_length);
| ~^~~~~~~~~~~~
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
; else if (!has_privs_of_role(GetUserId(), proc->roleId) &&
>!has_privs_of_role(GetUserId(),
> ROLE_PG_SIGNAL_BACKEND))
> {
> return SIGNAL_BACKEND_NOPERMISSION;
> }
There's no need for the explicit superuser() check in the
pg_signal_autovacuum section. That's built into has_privs_of_role()
already.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
be
used uninitialized in this function [-Werror=maybe-uninitialized]
2018 | if (lex->incremental && !lex->inc_state->is_last_chunk &&
|
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Here is an updated patch set. IMHO this is in decent shape and is
approaching committable.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From df59d3e78604e4530f5096bafc08ac94e13d82d2 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 27 Mar 2024 16:39:24 -0500
Subj
I don't know how concerned
to be about users distinguishing autovacuum workers from other superuser
backends, _but_ if roles with pg_signal_autovacuum can't even figure out
the PIDs for the autovacuum workers, then this feature seems kind-of
useless. Perhaps we should allow roles with privileges of
pg_signal_autovacuum to see the autovacuum workers in pg_stat_activity.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
k it would make sense to
> have the extra code if it gives a noticeable benefit for large cases.
Yeah, I did see this, but I also wasn't sure if it was worth further
complicating the code. I can test with and without your fix and see if it
makes any difference in the benchmarks.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Apr 05, 2024 at 07:58:44AM -0500, Nathan Bossart wrote:
> On Fri, Apr 05, 2024 at 10:33:27AM +0300, Ants Aasma wrote:
>> The main issue I saw was that clang was able to peel off the first
>> iteration of the loop and then eliminate the mask assignment and
>> repla
On Fri, Apr 05, 2024 at 10:15:45AM -0400, Andrew Dunstan wrote:
> On 2024-04-04 Th 15:54, Nathan Bossart wrote:
>> On Thu, Apr 04, 2024 at 03:31:12PM -0400, Andrew Dunstan wrote:
>> > Does the attached patch fix it for you?
>> It clears up 2 of the 3 warnings for me:
roach for me.
I'm not following what you mean by this. Are you suggesting that we should
keep the existing superuser message for the autovacuum workers?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
h I really wanted to avoid
because of the weird function overhead juggling) or find another way to do
a partial load into an __m512i.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, Apr 06, 2024 at 02:51:39PM +1300, David Rowley wrote:
> On Sat, 6 Apr 2024 at 14:17, Nathan Bossart wrote:
>> On Sat, Apr 06, 2024 at 12:08:14PM +1300, David Rowley wrote:
>> > Won't Valgrind complain about this?
>> >
>> > +pg_popcount_avx512(co
On Sat, Apr 06, 2024 at 02:41:01PM -0500, Nathan Bossart wrote:
> Here is what I have staged for commit, which I intend to do shortly.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
intentional.
> Anyway, we can certainly just dismiss this warning if it
> doesn't correspond to any real problem in our code.
> But I thought I'd raise the question.
That's probably the right thing to do, unless there's some action we can
take to suppress this warning
On Sun, Apr 07, 2024 at 08:23:32PM -0500, Nathan Bossart wrote:
> The Intel documentation for _mm256_undefined_si256() [0]
> indicates that it is intended to return "undefined elements," so it seems
> like the use of an uninitialized variable might be intentional.
See also http
file with git blame commands to identify where all of
> these were introduced. All are new to PG17.
>
> Any objections?
Looks reasonable to me.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ent, as well,
>>> because autovacuum workers operate like regular backends. This name
>>> can also be confused with the autovacuum launcher.
>>
>> Ok. What would be a good choice? Is `pg_signal_autovacuum_worker` good
>> enough?
>
> Sounds fine to me. Perhaps others have an opinion about that?
WFM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
of workers drops below
the new parameter's value. I don't think we should kill existing workers,
or anything else like that.
TBH I've been sitting on this idea for a while now, only because I think it
has a slim chance of acceptance, but IMHO this is a simple change that
could hel
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 5897631d5f09032565d92d5b8547baf3d24eef87 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 15 Feb 2023 14:28:53 -0800
Subject: [PATCH v21 1/5] introduce routine for checking mutually exclusive
string G
; +pg_cmp_u32(uint32 a, uint32 b)
> +{
> + return (a > b) - (a < b);
> +}
> +
> +static inline int
> +pg_cmp_s64(int64 a, int64 b)
> +{
> + return (a > b) - (a < b);
> +}
> +
> +static inline int
> +pg_cmp_u64(uint64 a, uint64 b)
>
ensitive
enough to be worth the effort.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
so it doesn't seem like much of a stretch to expect it to
have privileges for pg_current_logfile(), too. Are there any other
functions that pg_monitor ought to have privileges for?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
a separate pg_cmp_size() or pg_cmp_size_t().
>
> Do we want to have something similar for "int" as well? It seems to be
> quite common and even though it usually is an int32, it does not have to be.
I don't think we need separate functions for int and int32. As Tom n
(int) 0 or (int) 1, which might be worth a short comment.
But that's just nitpicking...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ture enough back then?)
I haven't played with it at all, but the topic reminds me of this thread:
https://postgr.es/m/flat/CALDaNm1B9naPDTm3ox1m_yZvOm3KA5S4kZQSWWAeLHAQ%3D3gV1Q%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ckwards, and I think we should expand on some of the commentary in int.h.
For example, the comment at the top of int.h seems very tailored to the
existing functions and should probably be adjusted. And the "comparison
routines for integers" comment might benefit from some additional details
On Mon, Feb 12, 2024 at 12:27:54PM +, Pavlo Golub wrote:
>> Are there any other
>> functions that pg_monitor ought to have privileges for?
>>
> Not that I'm aware of at the moment. This one was found by chance.
Okay. I'll plan on committing this in the nex
On Sun, Feb 11, 2024 at 03:44:42PM +0100, Mats Kindahl wrote:
> On Sat, Feb 10, 2024 at 9:53 PM Nathan Bossart
> wrote:
>> and I think we should expand on some of the commentary in int.h.
>> For example, the comment at the top of int.h seems very tailored to the
>> exist
On Mon, Feb 12, 2024 at 05:08:40PM +0100, Peter Eisentraut wrote:
> On 10.02.24 21:13, Nathan Bossart wrote:
>> I haven't played with it at all, but the topic reminds me of this thread:
>>
>>
>> https://postgr.es/m/flat/CALDaNm1B9naPDTm3ox1m_yZvOm3KA5S4kZQSW
_logfile_rotate() uses pg_rotate_logfile(), while core's
pg_rotate_logfile() uses pg_rotate_logfile_v2(). I suppose trying to
rename these might be more trouble than it's worth at this point, though...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Feb 12, 2024 at 06:09:06PM +0100, Mats Kindahl wrote:
> Here are the two fixed patches.
These patches look pretty good to me. Barring additional feedback, I'll
plan on committing them in the next few days.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
;> indirect function call" is just 1) load target address from variable 2)
>> making
>> an indirect jump to that address. With -fno-plt the callsites themselves load
>> the address from the GOT.
>
> That sounds more accurate than what I wrote. Thanks.
+1, thanks for the detailed explanation, Andres.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
s. I'm not sure that's still true with
> the more complicated optimized version.
You aren't kidding [0]. Besides perhaps adding a comment in
sort_template.h, is there anything else you think we should do about this
now?
[0] https://godbolt.org/z/bbTqK54zK
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ng inlined sorts, which are pretty rare at the moment. Your patches
should still be a net improvement in many cases because most qsorts use a
function pointer to the comparator.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Feb 12, 2024 at 09:49:45AM -0600, Nathan Bossart wrote:
> Okay. I'll plan on committing this in the next few days.
Here is what I have staged for commit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From bfe542c5d7b3c981e75ac6551abb34fbdf646eea Mon Sep
On Wed, Feb 14, 2024 at 08:59:06AM +0100, Daniel Gustafsson wrote:
> LGTM.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
st lead to merge problems when somebody else changes the
> current catversion. We rely on the committer to remember to do this
> (which is an imperfect system, but...)
+1, I only included it in the patch I posted so that I didn't forget it...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
minpack
>> (catalog
>> version bump omitted on purpose to avoid conflicts until commit).
>
> I don't see any references you missed, so +1.
Seems reasonable to me, too.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
i.postgresql.org/wiki/FOSDEM/PGDay_2024_Developer_Meeting#The_Path_to_un-reverting_the_MAINTAIN_privilege
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Feb 14, 2024 at 11:55:43AM -0800, Noah Misch wrote:
> I took a look over each of these. +1 for all. Thank you.
Committed. Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Feb 14, 2024 at 01:02:26PM -0600, Nathan Bossart wrote:
> BTW I have been testing reverting commit 151c22d (i.e., un-reverting
> MAINTAIN) every month or two, and last I checked, it still applies pretty
> cleanly. The only changes I've needed to make are to the catversion a
Here is what I have staged for commit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 8e5a66fb3a0787f15a900a89742862c89da38a1d Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 15 Feb 2024 10:53:11 -0600
Subject: [PATCH v8 1/3] Remove direct calls to pg_qs
_("unknown"),
+ cipher ? cipher :
_("unknown"),
+ (compression &&
strcmp(compression, "off") != 0) ? _("on") : _("off"));
+ }
Could we pull some of this information from pg_stat_ssl instead of from
libpq? The reason I suggest this is because I think it would be nice if
the query that \conninfo+ uses could be copy/pasted as needed and not rely
on hard-coded values chosen by the client.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Feb 16, 2024 at 01:45:52PM +0100, Mats Kindahl wrote:
> Looks good to me.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
atches waiting on it. IIRC I was worried about not having
enough support for this change, but I might now have it.
[0] https://commitfest.postgresql.org/47/4330/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
;
> ?
>
> If so, that does seem more convenient.
I think that's about right. The upthread feedback from Andres [0] provides
some additional context.
[0] https://postgr.es/m/20231110231150.fjm77gup2i7xu6hc%40alap3.anarazel.de
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Here is a v3 of the patch set with the first draft of the commit messages.
There are no code differences between v2 and v3.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From f1441aca96f157c5557d9a961fe85902b510f293 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri,
these.
> +/*
> + * Safe search path when executing code as the table owner, such as during
> + * maintenance operations.
> + */
> +#define GUC_SAFE_SEARCH_PATH "pg_catalog, pg_temp"
Is including pg_temp actually safe? I worry that a user could use their
temporary schema to inject objects that would take the place of
non-schema-qualified stuff in functions.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sun, Jan 21, 2024 at 11:07:15PM -0600, Nathan Bossart wrote:
> I attempted to fix this in v2 of the patch set.
If there are no objections, I plan to commit these patches early next week.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Feb 23, 2024 at 05:34:49PM -0800, Andres Freund wrote:
> On 2024-02-23 14:58:12 -0600, Nathan Bossart wrote:
>> +/*
>> + * pg_atomic_write_membarrier_u32 - write with barrier semantics.
>> + *
>> + * The write is guaranteed to succeed as a whole, i.e., it's
oncerning SSL and
> GSS, I think libpq is better prepared to handle this.
At the moment, the psql support cutoff appears to be v9.2 (see commit
cf0cab8), which has been out of support for over 6 years. If \conninfo+
happens to work for older versions, then great, but I don't think we should
expend too much energy in this area.
[0] https://postgr.es/m/20240216155449.GA1236054%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ng like a
> `pg_signal_autovacuum` role which can signal running autovac to cancel. But
> I don't see how we can handle specific `application_name` with this
> solution.
pg_signal_autovacuum seems useful given commit 3a9b18b.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ink this would be nice. If the Markdown version is reasonably readable
as plain-text, maybe we could avoid maintaining two READMEs files, too.
But overall, +1 to modernizing the README a bit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Feb 23, 2024 at 03:52:16PM -0600, Nathan Bossart wrote:
> If there are no objections, I plan to commit these patches early next week.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Feb 26, 2024 at 03:55:10PM -0600, Nathan Bossart wrote:
> Committed.
I noticed that I forgot to update a couple of comments. While fixing
those, I discovered additional oversights that have been around since 2017.
I plan to commit this shortly.
--
Nathan Bossart
Amazon Web Servi
s role have such little scope...
-1. I don't see why giving a role privileges of pg_signal_autovacuum
should also give them the ability to signal all other non-superuser
backends.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ements which allows to cancel running autovac
> to non-superuser (via `pg_signal_autovacuum` role or some other mechanism)?
If we need to add tests for pg_signal_backend, I think it's reasonable to
keep those in a separate patch from pg_signal_autovacuum.
--
Nathan Bossart
Amazon
On Tue, Feb 27, 2024 at 04:22:34PM -0800, Jeff Davis wrote:
> Do we need a documentation update here? If so, where would be a good
> place?
I'm afraid I don't have a better idea than adding a short note in each
affected commands's page.
> On Fri, 2024-02-23 at 15:30 -06
On Wed, Feb 28, 2024 at 02:46:11PM +0100, Daniel Gustafsson wrote:
>> On 26 Feb 2024, at 21:30, Tom Lane wrote:
>> Nathan Bossart writes:
>>> I think this would be nice. If the Markdown version is reasonably readable
>>> as plain-text, maybe we could avoid main
d content to both afterwards. The former has my vote since
it seems like it would require less churn. In any case, I think it would
be useful to keep the Markdown effort separate from the content effort
somehow (e.g., separate threads).
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jan 05, 2024 at 05:03:57PM -0600, Nathan Bossart wrote:
> I gave it a try.
Is there any interest in this? If not, I'll withdraw the commitfest entry.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
y to follow these for my blog; posts end up looking like this:
>
> https://justatheory.com/2024/02/extension-metadata-typology.text
>
> (Append `.text` to any post to see the raw(ish) Markdown.
Here is what converting the current README to Markdown with no other
content changes m
On Wed, Feb 28, 2024 at 01:08:03PM -0600, Nathan Bossart wrote:
> -PostgreSQL Database Management System
> -=
> +# PostgreSQL Database Management System
This change can be omitted, which makes the conversion even simpler.
--
Nathan Bossart
Amazon Web
301 - 400 of 2774 matches
Mail list logo
