Here is a new version of the patch that uses the new atomic read/write
functions with full barriers that were added in commit bd5132d. Thoughts?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From c40594c62ccfbf75cb0d3787cb9367d15ae37de8 Mon Sep 17 00:00:00 2001
From: Nat
Committed. Thank you for reviewing!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Feb 28, 2024 at 10:05:26PM +0100, Daniel Gustafsson wrote:
>> On 28 Feb 2024, at 19:51, Nathan Bossart wrote:
>> Is there any interest in this? If not, I'll withdraw the commitfest entry.
>
> I'm still interested, please leave it in and I'll circle around to i
On Wed, Feb 28, 2024 at 02:21:49PM -0600, Nathan Bossart wrote:
> On Wed, Feb 28, 2024 at 02:07:34PM -0600, Andrew Atkinson wrote:
>> I agree that starting with the direct conversion is reasonable. Markdown
>> "modernizes" the file using a popular plain text file fo
t back!
I see many projects have files like SECURITY.md, CODE_OF_CONDUCT.md, and
CONTRIBUTING.md, and I think it would be relatively easy to add content to
each of those for PostgreSQL, even if they just link elsewhere.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
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
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 might look like.
--
Nath
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
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 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
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 -0600, Nathan Boss
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 Web
e 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
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
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
I think 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
hing 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
S, 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
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 not
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
th 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
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,
?
>
> 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
ing 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
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
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
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
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 and to
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
ql.org/wiki/FOSDEM/PGDay_2024_Developer_Meeting#The_Path_to_un-reverting_the_MAINTAIN_privilege
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
gt;> (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
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
On Wed, Feb 14, 2024 at 08:59:06AM +0100, Daniel Gustafsson wrote:
> LGTM.
Committed.
--
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 17 00
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
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
nction 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
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
es 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 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_yZvOm3KA5S4kZQSWWAeLH
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 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 next few days
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
h 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
(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
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 noted,
(), 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
nough to be worth the effort.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
t; +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)
> +{
consider that
to be connection information.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
if that's defined in some
> library.
>
>
> I think it's worth following int.h's pattern of including [s]igned/[u]nsigned
> in the name, an efficient implementation for signed might not be the same as
> for unsigned. And if we use static inlines, we need to do so for correct
&g
- (int32) (rhs)
but for int32, we need to do someting more like what's in the patch.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Mats, I apologize for steamrolling a bit here. I'll take a step back into
a reviewer role.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
rsi
testrdi, rdi
setgal
shr rdi, 63
sub eax, edi
ret
while the approach Andres suggested compiles to
xor eax, eax
cmp edi, esi
setldl
setgal
movzx edx, dl
sub eax, edx
On Wed, Feb 07, 2024 at 06:06:37PM -0800, Andres Freund wrote:
> Another branchless variant is (a > b) - (a < b). It seems to get a similar
> improvement as the overflow-checking version.
Well, that's certainly more elegant. I updated the patch to that approach
for now.
--
Na
On Wed, Feb 07, 2024 at 04:42:07PM -0800, Andres Freund wrote:
> On 2024-02-07 16:21:24 -0600, Nathan Bossart wrote:
>> The assembly for that looks encouraging, but I still need to actually test
>> it...
>
> Possible. For 16bit upcasting to 32bit is clearly the best way. For
ere?
Maybe said helper could use __builtin_sub_overflow() and fall back to the
slow "if" version only if absolutely necessary. The assembly for that
looks encouraging, but I still need to actually test it...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
qsort() doesn't overflow, no matter what the comparison function does.
>
> Looking at our ST_SORT(), it seems safe to me.
Cool.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From f5850579e92f201218c3025327b91d820eabd18e Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date:
On Wed, Feb 07, 2024 at 10:40:50AM -0800, Andres Freund wrote:
> On 2024-02-07 11:15:54 -0600, Nathan Bossart wrote:
>> Perhaps we should add a file global bool that is only set during
>> wrapper_handler(). Then we could Assert() or elog(ERROR, ...) if
>> pqsignal()
On Tue, Feb 06, 2024 at 02:37:25PM -0600, Nathan Bossart wrote:
> Unless there are objections, I'll plan on committing this in the next day
> or two.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Sorry for the noise.
On Wed, Feb 07, 2024 at 11:06:50AM -0600, Nathan Bossart wrote:
> I'd like to get this committed (to HEAD only) in the next few weeks. TBH
> I'm not wild about the weird caveats (e.g., race conditions when pqsignal()
> is called within a signal handler), but I a
On Tue, Feb 06, 2024 at 06:48:53PM -0800, Andres Freund wrote:
> On 2024-02-06 20:39:41 -0600, Nathan Bossart wrote:
>> I finally spent some time trying to measure this overhead. Specifically, I
>> sent many, many SIGUSR2 signals to postmaster, which just uses
>> dummy_
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
301 - 400 of 1915 matches
Mail list logo
