I noticed that "make maintainer-clean" doesn't remove
src/include/utils/guc_tables.inc.c. This seems to fix it:
diff --git a/src/include/Makefile b/src/include/Makefile
index 3f94543f327..58eb6da27fe 100644
--- a/src/include/Makefile
+++ b/src/include/Makefile
@@ -74,7 +74,7 @@ uninstall:
clean:
On Wed, Sep 03, 2025 at 11:11:24AM +, chiranmoy.bhattacha...@fujitsu.com
wrote:
> Since the CommitFest is underway, could we get some feedback to improve
> the patch?
I see that there was some discussion about a Neon implementation upthread,
but I'm not sure we concluded anything. For popcou
On Tue, Sep 02, 2025 at 04:54:59PM -0500, Nathan Bossart wrote:
> Committed.
Gah, the commit message lists your name under the Discussion tag, and I
missed adding the link to the archives. Please forgive the brain fade.
--
nathan
On Tue, Sep 02, 2025 at 11:02:37AM -0500, Nathan Bossart wrote:
> LGTM. In the original thread, it looks like this was added in v32 [0] and
> effectively switched to a bool in v58 [1].
I was worried that we might need to bump SLOT_VERSION for this, but I see
that as of v18 [0], we require
Committed.
--
nathan
On Tue, Sep 02, 2025 at 09:47:49AM -0300, Ranier Vilela wrote:
> IMO in the struct ReplicationSlotPersistentData, the field *synced* has
> wrong type declaration. The intention was *bool* not *char* type.
>
> Since it is only used in Boolean comparison.
LGTM. In the original thread, it looks lik
On Mon, Sep 01, 2025 at 03:19:46PM +0900, Michael Paquier wrote:
> I highly doubt that there are a lot of comments assigned to LOs, so
> these numbers are pretty cool IMO. Security labels are a pain to test
> in the upgrade path, or test_dummy_label could be extended with a new
> TAP test and a pg
GUC.
Thus far, we've been operating under the assumption that we'll be able to
choose a number far beyond any realistic usage. If others have opinions
about this, please share...
--
nathan
>From a7d8c29dc6a9edf83e3607c84cf5d15dc464da9f Mon Sep 17 00:00:00 2001
From: Nathan Bossart
On Mon, Sep 01, 2025 at 10:18:46AM +, Bertrand Drouvot wrote:
> Changes look good.
Thanks for looking.
> Not directly related, but I think that we can get rid of:
>
> size = add_size(size, LWLOCK_PADDED_SIZE);
>
> in LWLockShmemSize() and of:
>
> ptr += LWLOCK_PADDED_SIZE - ((uintptr_t) pt
On Sat, Aug 30, 2025 at 05:56:12PM -0400, Bruce Momjian wrote:
> On Sat, Aug 30, 2025 at 03:02:10PM -0500, Nathan Bossart wrote:
>> The 18beta1 announcement [0] has a good list, too. *facepalm* That one
>> seems to match mine pretty closely.
>
> Yes, the list usually
On Sat, Aug 30, 2025 at 02:42:47PM -0500, Nathan Bossart wrote:
> On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:
>> AFAIK nobody has started on the "new features and enhancements" section.
>
> Quick first attempt:
>
> * btree skip scan
>
On Sat, Aug 30, 2025 at 01:51:23PM -0500, Nathan Bossart wrote:
> AFAIK nobody has started on the "new features and enhancements" section.
Quick first attempt:
* btree skip scan
* async i/o
* oauth
* virtual generated columns
* OLD/NEW support in RETURNING
* pg_upgrade improv
On Sat, Aug 30, 2025 at 12:38:06PM -0400, Bruce Momjian wrote:
> First, the release notes are incomplete because the "new features and
> enhancements" and "Acknowledgments" sections are empty.
Corey Huinker claims to be working on the list of acknowledgments [0], but
I don't see any patches propos
On Fri, Aug 29, 2025 at 09:51:38PM -0500, Nathan Bossart wrote:
> I've also attached a rebased patch that addresses all the latest feedback.
> A reworked verison of the test patch is also included, but that's mostly
> intended for CI purposes and is still not intended for commit
resses all the latest feedback.
A reworked verison of the test patch is also included, but that's mostly
intended for CI purposes and is still not intended for commit (yet).
--
nathan
>From cf8eee964066152f6aa7dce045f3b338d0959599 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 27
On Fri, Aug 29, 2025 at 09:43:26AM -0500, Nathan Bossart wrote:
> Good idea. Here's a new version of the patch. If CI is happy with it,
> I'll go ahead and commit it.
Committed.
--
nathan
Committed.
--
nathan
On Thu, Aug 28, 2025 at 05:53:23PM -0500, Sami Imseih wrote:
>> I think this patch set will require reworking the "GetNamedLWLockTranche
>> crashes on Windows in normal backend" patch [0], but AFAICT we can easily
>> adjust it to scan through NamedLWLockTrancheNames instead.
>
> Except, we will ne
On Fri, Aug 29, 2025 at 10:40:25PM +0800, cca5507 wrote:
> When reading the code about slot sync, I find the $subject, attach a
> patch to fix it.
LGTM. I looked through the original thread [0] for clues about the origins
of this parameter, but it's a very long thread, and ctrl+f didn't help. It
t IMHO it kind-of defeats the purpose,
which is to make this stuff simpler and easier to follow.
--
nathan
>From babaa2bfedd24932b6df13bfea0f4b01e911a311 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 29 Aug 2025 09:33:55 -0500
Subject: [PATCH v2 1/1] Make LWLockCounter a global variable.
In lwlock
001
From: Nathan Bossart
Date: Thu, 28 Aug 2025 16:22:02 -0500
Subject: [PATCH v1 1/1] Make LWLockCounter a global variable.
---
src/backend/postmaster/launch_backend.c | 3 +++
src/backend/storage/lmgr/lwlock.c | 15 ---
src/include/storage/lwlock.h| 1 +
3 files ch
On Mon, Aug 25, 2025 at 10:07:26AM -0500, Nathan Bossart wrote:
> Now that this is reverted, can the related open item be marked as resolved?
Since there has been no further discussion, I will go ahead and resolve the
open item.
--
nathan
out these patches. They simplify the API and
the code while also fixing the problem with tranche name visibility.
[0]
https://postgr.es/m/CAA5RZ0v1_15QPg5Sqd2Qz5rh_qcsyCeHHmRDY89xVHcy2yt5BQ%40mail.gmail.com
--
nathan
>From 484ebb5cc6ae4300aea654b0f148889d63367256 Mon Sep 17 00:00:00 2001
From
On Tue, Aug 26, 2025 at 02:56:22PM -0500, Sami Imseih wrote:
> Here is v12 that replaces the LWLock to access the shared memory with a
> ShmemLock and implements a local counter.
This looks much closer to what I was imagining.
/* Initialize the LWLock tranche for the DSA. */
-
On Tue, Aug 26, 2025 at 09:00:53PM +0900, Fujii Masao wrote:
> On Tue, Aug 26, 2025 at 1:20 AM Nathan Bossart
> wrote:
>> Okay. I'll plan on committing the documentation update in the next 24-48
>> hours, provided no additional feedback materializes.
>
> The p
On Mon, Aug 25, 2025 at 04:59:41PM -0500, Sami Imseih wrote:
> hmm, can we really avoid a shared lock when reading from shared memory?
> considering access for both reads and writes can be concurrent to shared
> memory. We are also taking an exclusive lock when writing a new tranche.
We probably w
On Mon, Aug 25, 2025 at 03:38:13PM -0700, Masahiko Sawada wrote:
> While reading walsummarizer.c code, I noticed that in
> WakeupWalSummarizer() we acquire the WALSummarizerLock lock in
> LW_EXCLUSIVE mode despite only reading
> WalSummarizerCtl->summarizer_pgprocno. The attached patch uses
> LW_SH
On Mon, Aug 25, 2025 at 04:37:21PM -0500, Sami Imseih wrote:
> When we lookup from shared array only, we need to take a shared lock
> every lookup. Acquiring that lock is what I am trying to avoid. You
> are saying it's not worth optimizing that part, correct?
Why do we need a shared lock here? I
On Mon, Aug 25, 2025 at 04:28:09PM -0500, Sami Imseih wrote:
> Here it is.
Looks reasonable to me. I'll leave this one around for a week or two to
give others a chance to comment.
--
nathan
On Fri, Aug 22, 2025 at 03:01:53PM -0500, Sami Imseih wrote:
> I kept the local array to serve consecutive reads and to avoid having to
> take a shared lock on shared memory every time GetLWTrancheName is
> called. A new LWLock to protect this array is required.
I'm not seeing why we need this cac
On Fri, Aug 22, 2025 at 05:33:55PM -0400, Tom Lane wrote:
> Sami Imseih writes:
>> One point I did not make earlier is that the tranche name lengths will
>> need to be as long as we allow in dsm_registry.c.
>
>> #define DSMR_NAME_LEN 128
>
> Huh. Why is that different from NAMEDATALEN in the fi
On Mon, Aug 25, 2025 at 02:03:11PM -0300, Ranier Vilela wrote:
> If you don't mind I think that have one more source.
Good catch. Committed.
--
nathan
On Mon, Aug 25, 2025 at 01:44:22PM -0500, Sami Imseih wrote:
> Another approach is to just change GetNamedLWLockTranche to use
> NamedLWLockTrancheArray since that is already copied in EXEC_BACKEND, and
> allow GetNamedLWLockTranche to continue to be used outside of startup. In
> this case, we will
On Mon, Aug 25, 2025 at 12:58:08PM -0500, Sami Imseih wrote:
>> If this fails, why doesn't the call in pgss_shmem_startup() also fail? Was
>> pg_stat_statements not loaded via shared_preload_libraries?
>
> because the array is valid in postmaster, but it's not for a normal backend,
> since it's n
On Fri, Aug 22, 2025 at 02:21:55PM -0500, Sami Imseih wrote:
> While working on [0], I observed that $SUBJECT. I encountered this issue
> while building test cases for [0], and in which GetNamedLWLockTranche is
> called outside of startup.
>
> [...]
>
> I repro'd this on a Windows machine, but on
On Tue, Aug 26, 2025 at 12:24:27AM +0900, Yugo Nagata wrote:
> Thank you for the clarification. I understand your points now,
> so I'll withdraw my proposal.
Okay. I'll plan on committing the documentation update in the next 24-48
hours, provided no additional feedback materializes.
--
nathan
On Mon, Aug 25, 2025 at 12:13:27PM -0300, Fabrízio de Royes Mello wrote:
> On Mon, Aug 25, 2025 at 11:57 AM Nathan Bossart
> wrote:
>> I noticed a couple more opportunities to use the PqMsg_* macros.
>
> Nice. LGTM!
Thanks, committed.
--
nathan
[RMT hat]
On Thu, Aug 21, 2025 at 06:42:48PM -0400, Tom Lane wrote:
> Alexander Korotkov writes:
>> On Tue, Aug 19, 2025 at 10:50 PM Tom Lane wrote:
>>> Therefore, I vote for reverting bc22dc0e0. Hopefully only
>>> temporarily, but it's too late to figure out another way for v18,
>>> and I don'
I noticed a couple more opportunities to use the PqMsg_* macros.
--
nathan
>From 7cdd91579734de76fcd52cabdb49671ee309ddf6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 25 Aug 2025 09:53:48 -0500
Subject: [PATCH v1 1/1] Use PqMsg_* macros in fe-protocol3.c.
---
src/include/li
On Mon, Aug 25, 2025 at 10:30:32AM +0900, Yugo Nagata wrote:
> The documentation fix looks good to me. However, it’s not very user-friendly
> that,
> when the user lacks the required privileges, an error from the internal query
> is
> raised. Instead, how about checking whether the user has the n
On Sat, Aug 23, 2025 at 05:32:30AM -0400, Corey Huinker wrote:
> On Fri, Aug 22, 2025 at 11:20 PM Fujii Masao wrote:
>> On Sat, Aug 23, 2025 at 12:00 PM Nathan Bossart
>> wrote:
>>> Hm. Maybe we should just document that the option requires SELECT
>>&g
On Sat, Aug 23, 2025 at 10:59:43AM +0900, Fujii Masao wrote:
> I tested by creating many tables with make installcheck and running
> vacuumdb --missing-stats-only on the regression database.
> Without the patch, the query to find tables to analyze took about 60 ms,
> but with the patch it took 18 s
On Fri, Aug 22, 2025 at 09:01:36AM -0500, Nathan Bossart wrote:
> We'll also need documentation and test updates, of course.
Here is an attempt at the docs/tests. I also fixed a couple of small
issues in the query.
--
nathan
>From e75f534d4662a4c0ba3ee0518c08b3692cdc0255 Mon Sep
Committed.
--
nathan
On Fri, Aug 22, 2025 at 10:19:32AM +0900, Fujii Masao wrote:
> At first, I just wondered whether vacuumdb --missing-stats-only would work
> on older servers, since the patch adds access to the attgenerated column,
> which might not exist there. But that's not an issue, because
> --missing-stats-onl
On Thu, Aug 21, 2025 at 07:27:23PM -0400, Corey Huinker wrote:
> Ok, I took the RLS and permissions quals from pg_stats and pg_stats_ext
> and put them in the corresponding EXISTs tests. The queries could be
> written a bit more succinctly (ex. we only need to do the RLS checks once)
> but putting
On Thu, Aug 21, 2025 at 11:29:56AM -0400, Corey Huinker wrote:
> On Thu, Aug 21, 2025 at 9:56 AM Nathan Bossart
> wrote:
>> Since we're running out of time for v18, I went ahead and updated the
>> patch. I've also added an open item for this.
>
> +1 on the fix,
On Thu, Aug 21, 2025 at 12:59:52PM -0500, Nathan Bossart wrote:
> I think there's a problem with the privilege checks for pg_stats (and
> friends) versus ANALYZE. pg_stats checks for SELECT privileges on the
> column, while ANALYZE checks for MAINTAIN privileges. If a role lacks
&
On Thu, Aug 21, 2025 at 12:52:17PM -0400, Corey Huinker wrote:
> Here's the query changes, no regression test just yet.
I think there's a problem with the privilege checks for pg_stats (and
friends) versus ANALYZE. pg_stats checks for SELECT privileges on the
column, while ANALYZE checks for MAIN
On Thu, Aug 21, 2025 at 11:13:44AM +0900, Fujii Masao wrote:
> On Thu, Aug 21, 2025 at 4:19 AM Nathan Bossart
> wrote:
>> Nice find. I would suggest adding the virtual generated column to
>> regression_vacuumdb_test when it is first created so that we can just rely
>> on
On Thu, Aug 21, 2025 at 03:19:40AM -0400, Corey Huinker wrote:
> Assuming that I'm not missing something, the fix seems straightforward.
> I'll set about coding it up tomorrow if nobody has done so by then.
I've added an open item for this.
--
nathan
On Wed, Aug 20, 2025 at 01:53:38PM +0900, Yugo Nagata wrote:
> The patch conflicted with the latest commit, so I rebased it.
Nice find. I would suggest adding the virtual generated column to
regression_vacuumdb_test when it is first created so that we can just rely
on the existing test cases. In
On Wed, Aug 20, 2025 at 11:47:38AM -0500, Nathan Bossart wrote:
> This function returns the values in the sequence tuple, primarily for
> pg_dump (see commit bd15b7d). IIUC your patch would break pg_dump on v18
> and newer versions.
Concretely, after the following commands, the pat
On Wed, Aug 20, 2025 at 07:16:55PM +0530, vignesh C wrote:
> pg_sequences and pg_sequence_last_value return NULL for last_value,
> which aligns with the expectation that the sequence hasn't been used
> yet. However, pg_get_sequence_data returns the start value (1) even
> though is_called is false.
On Wed, Aug 20, 2025 at 10:29:03AM +0900, Richard Guo wrote:
> On Wed, Aug 20, 2025 at 2:38 AM Nathan Bossart
> wrote:
>> There is still an open item for this one, but it's not clear whether we are
>> planning to do anything about this for v18, especially since nobody
On Tue, Aug 19, 2025 at 05:40:23PM -0400, Andres Freund wrote:
> LGTM
Thanks, committed.
--
nathan
This comment mentions that pg_buffercache locks all buffer partitions
simultaneously, but it hasn't done so since v10 (see commit 6e654546fb).
--
nathan
>From 68b81e3bf70d5da0a0e2d0a0087218df7fde1101 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 19 Aug 2025 16:27:33 -0500
On Tue, Aug 19, 2025 at 04:16:26PM -0500, Sami Imseih wrote:
> If there is agreement on setting limits, may I propose
> 1024 tranches and NAMEDATALEN. Both seem reasonably sufficient.
Let's proceed with that approach for now. We can worry about the exact
limits once this is closer to commit.
--
On Mon, Aug 11, 2025 at 04:12:48PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Thu, Jun 19, 2025 at 12:10:52PM -0700, Salvatore Dipietro wrote:
>>> We can notice that with low concurrency (1,2,4) results are similar
>>> while with medium concurrency (8,16)
On Tue, Aug 19, 2025 at 03:52:33PM -0500, Sami Imseih wrote:
> If we limit the tranche name to NAMEDATALEN and also limit the
> number of tranches an extension can register, we can put this
> all in static shared memory (We would still need to have a backend local
> cache to allow lookups to avoid
On Tue, Aug 19, 2025 at 09:49:26AM +0200, Hannu Krosing wrote:
> Have you considered re-creating pg_shdepend from
> pg_largeobject_metadata directly instead of having special cases for
> dumping it ?
I considered it when you last brought up the idea [0], but my testing
indicated that it's measurab
On Tue, Aug 19, 2025 at 02:37:19PM -0400, Andres Freund wrote:
> On 2025-08-19 13:31:35 -0500, Nathan Bossart wrote:
>> On Tue, Aug 19, 2025 at 02:06:50PM -0400, Andres Freund wrote:
>> > Possibly stupid question - is it really worth having a dynamic structure
>> &g
On Tue, Aug 19, 2025 at 02:06:50PM -0400, Andres Freund wrote:
> Possibly stupid question - is it really worth having a dynamic structure here?
> The number of tranches is strictly bound, it seems like it'd be simpler to
> have an array of tranch nmes in shared memory.
Tranches can be allocated po
On Mon, Jun 23, 2025 at 04:16:09PM -0700, Noah Misch wrote:
> On Wed, Jun 11, 2025 at 05:22:53PM +0200, Peter Eisentraut wrote:
>> There is an open item for PG18 for this. So here is a patch that adds a
>> comment back, mostly from your descriptions in this thread.
>>
>> > > The change to AccessS
On Wed, Jul 30, 2025 at 03:17:38PM +0900, Richard Guo wrote:
> On Wed, Jul 30, 2025 at 3:45 AM Tomas Vondra wrote:
>> Does this mean we can close the PG18 open item tracking this?
>>
>> * virtual generated columns and planning speed
>> Owner: Peter Eisentraut
>>
>>
>> If I understand correct
On Tue, Aug 19, 2025 at 08:09:53AM +, Bertrand Drouvot wrote:
> On Mon, Aug 18, 2025 at 05:53:44PM -0500, Sami Imseih wrote:
>> > (or some other shmem-based
>> > data structure we have yet to introduce, like a dslist/dsarray).
>>
>> This will be an interesting API to invest time in, if there c
On Mon, Aug 18, 2025 at 04:10:38PM -0500, Nathan Bossart wrote:
> Attached is a patch to fix $subject, which appears to be the result of
> commit bb952c8c8b.
Committed.
--
nathan
On Mon, Aug 18, 2025 at 01:06:42PM -0500, Sami Imseih wrote:
> Attached is v10,
I've been staring at the latest patch for a bit, and I'm a bit concerned
at how much complexity it adds. I think it's a good idea to keep a local
array of tranche names indexed by tranche ID, but the code for managing
Attached is a patch to fix $subject, which appears to be the result of
commit bb952c8c8b.
--
nathan
>From 1df952b77d4875466801b93477164cddd00f9eec Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 18 Aug 2025 16:04:06 -0500
Subject: [PATCH v1 1/1] Fix misspelling of "tranche&q
On Fri, Aug 15, 2025 at 03:25:20PM -0500, Nathan Bossart wrote:
> On Fri, Aug 15, 2025 at 04:13:30PM -0400, Andres Freund wrote:
>> IMO, the only way to actually make pg_stat_statements scale is to move to a
>> model much more like our regular stats. I.e. accumulate counters in b
On Fri, Aug 15, 2025 at 04:13:30PM -0400, Andres Freund wrote:
> IMO, the only way to actually make pg_stat_statements scale is to move to a
> model much more like our regular stats. I.e. accumulate counters in backend
> local memory and only occasionally update the shared stats.
Agreed. I rememb
On Fri, Aug 15, 2025 at 11:25:55AM -0500, Sami Imseih wrote:
> I noticed a few things where this behavior becomes very suspicious.
>
> For example, in pgss_startup_hook, every time startup_hook is run
> we take an exclusive LW lock. so, all backends now may be competing
> for that lock by nature o
ly.
[0] https://postgr.es/m/Zs4hJ6-Fg8DMgU_P@nathan
--
nathan
>From ecb70a2bb492c5ca47e86cadbce91d395f011316 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 1 Aug 2024 09:30:32 -0500
Subject: [PATCH v1 1/1] replace p_s_s entry spinlocks with lwlocks
---
contrib/pg_stat_statements/pg_stat_statemen
On Thu, Aug 14, 2025 at 11:29:08AM +0200, Álvaro Herrera wrote:
> On 2025-May-01, Tom Lane wrote:
>> One other thing that comes to mind is that pg_stat_statements
>> has stretched the intention of "short straight-line code segment"
>> to the point of unrecognizability. Maybe it needs to stop using
On Fri, Aug 15, 2025 at 10:36:47AM -0500, Sami Imseih wrote:
> But that could potentially be dangerous if code in the startup hook gets
> re-executed? I guess the doc below is giving a vague warning that one
> should be careful what they put in that hook.
The docs seem reasonably clear that these
On Fri, Aug 15, 2025 at 09:17:22AM -0500, Sami Imseih wrote:
> While working on a related area, I noticed that shmem_startup_hook
> is called twice under EXEC_BACKEND.
>
> The first call occurs in CreateSharedMemoryAndSemaphores() during
> postmaster startup (!IsUnderPostmaster), which is expected
(new thread)
On Fri, Jul 18, 2025 at 11:05:04AM -0500, Nathan Bossart wrote:
> I'm cautiously optimistic that we can find some better gains for upgrades
> from v16 and newer. That would involve dumping lo_create() commands for
> all LOs with comments/seclabels, dumping the releva
I haven't followed the latest discussion, but I took a look at the patch.
+ It is possible to use a tranche_id that was not
retrieved
+ using LWLockNewTrancheId, but this is not
recommended.
+ The ID may clash with an already registered tranche name, or the
specified
+ name
On Mon, Jul 21, 2025 at 07:19:54PM -0400, Andres Freund wrote:
> RMT, note that there were two issues in this thread, the original report by
> Tom has been addressed (in e9a3615a522). I guess the best thing would be to
> split the open items entry into two?
I went ahead and marked the open item a
On Thu, Jun 19, 2025 at 12:10:52PM -0700, Salvatore Dipietro wrote:
> We can notice that with low concurrency (1,2,4) results are similar
> while with medium concurrency (8,16)
> the No-ISB approach can introduce some regression especially on
> smaller instances. However, we can see some significan
Committed.
--
nathan
On Wed, Aug 06, 2025 at 11:25:53PM +0900, Fujii Masao wrote:
> On Wed, Aug 6, 2025 at 1:01 PM Mircea Cadariu
> wrote:
>> Overall, I like the change. But I have one question: should this be treated
>> as
>> a bug fix that we back-patch to supported branches, or is it more of
>> an improvement tha
On Wed, Aug 06, 2025 at 12:09:28PM -0500, Nathan Bossart wrote:
> On Tue, Aug 05, 2025 at 09:20:09PM -0500, Nathan Bossart wrote:
>> That explains it. I didn't find any past discussions about this particular
>> name, but commit de160e2 was being developed concurrently. I
this works...
--
nathan
>From 328cf708480fc6c7e4687f96938b584b1cf67d00 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 5 Aug 2025 22:18:11 -0500
Subject: [PATCH v6 1/1] Expand usage of protocol characters.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Tue, Aug 05, 2025 at 09:20:09PM -0500, Nathan Bossart wrote:
> That explains it. I didn't find any past discussions about this particular
> name, but commit de160e2 was being developed concurrently. I'll use
> nameSpace instead.
Committed.
--
nathan
Okay, I think I've addressed all the latest feedback in v5.
--
nathan
>From 00540a80854d3fc598a4b99daddfe1e7c0817b5c Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 5 Aug 2025 22:18:11 -0500
Subject: [PATCH v5 1/1] Expand usage of protocol characters.
MIME-Version: 1.0
Cont
On Tue, Aug 05, 2025 at 06:10:54PM -0400, Tom Lane wrote:
> =?utf-8?Q?=C3=81lvaro?= Herrera writes:
>> On 2025-Aug-05, Nathan Bossart wrote:
>>> I noticed that this function has a "namspace" parameter. The attached
>>> patch adds the missing 'e'.
&g
I noticed that this function has a "namspace" parameter. The attached
patch adds the missing 'e'.
--
nathan
>From 3f1431517cee250f1280adca739de0d6b9c77080 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 5 Aug 2025 16:01:34 -0500
Subject: [PATCH v1 1
Here is an updated patch that includes 1) added uses of PqMsg_* macros, 2)
new PqReplMsg_* macros, and 3) new PqBackupMsg_* macros. Thoughts?
--
nathan
>From 6a1d03725009837c5ce99dcfc283fa565d587d13 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 5 Aug 2025 14:53:42 -0500
Subj
On Mon, Aug 04, 2025 at 02:11:26PM -0700, Jacob Champion wrote:
> On Mon, Aug 4, 2025 at 12:56 PM Nathan Bossart
> wrote:
>> The replication protocol uses many of the
>> existing PqMsg macros already, so it would be a little strange if only a
>> subset of the replicatio
On Mon, Aug 04, 2025 at 02:31:05PM +0200, Álvaro Herrera wrote:
> +/* Replication Protocol, sent by the primary */
> +
> +#define PqReplMsg_WALData'w'
> +#define PqReplMsg_PrimaryKeepAlive 'k'
> +#define PqReplMsg_PrimaryStatusUpdate's'
> +
> +/* Replic
On Mon, Aug 04, 2025 at 11:32:19AM -0500, Sami Imseih wrote:
> With a local hash table, I don't think it's necessary to introduce new
> code for managing
> a DSA based list of tranche names as is done in v3. We can go back to
> storing the shared
> trance names in dshash.
>
> What do you think?
M
On Sat, Aug 02, 2025 at 11:09:16AM +0200, Peter Eisentraut wrote:
> These were introduced (commit efdc7d74753) at the same time as we were
> moving to using the standard inttypes.h format macros (commit a0ed19e0a9e).
> It doesn't seem useful to keep a new already-deprecated interface like this
> wi
On Fri, Aug 01, 2025 at 12:42:16PM -0700, Jeff Davis wrote:
> - --with-statistics
> + --statistics
> - --with-statistics
> + --statistics
> - --with-statistics
> + --statistics
nitpick: --statistics should be moved to maintain alphabetical ordering.
--
nathan
I've attached a rebased version of the patch.
On Mon, Jul 21, 2025 at 11:26:44PM -0500, Sami Imseih wrote:
> Unlike the local list of tranche names, appending to and searching the
> shared memory list requires an LWLock; in exclusive mode to append, and
> shared mode to search.
The thing that sto
On Wed, Jul 30, 2025 at 02:51:59PM -0400, Andrew Dunstan wrote:
> OK, now that's reverted...
Can we close the open item for this one now? Or is there something else
remaining?
--
nathan
Committed.
--
nathan
On Mon, Jul 28, 2025 at 01:46:34PM -0500, Nathan Bossart wrote:
> On Mon, Jul 28, 2025 at 09:22:29AM -0700, David G. Johnston wrote:
>> On Monday, July 28, 2025, Frédéric Yhuel wrote:
>>> On 7/28/25 16:47, Nathan Bossart wrote:
>>>> Obviously, this wording isn
Committed.
--
nathan
[RMT hat]
On Tue, Jul 22, 2025 at 03:51:12PM +0200, Tomas Vondra wrote:
> In general, it doesn't change the earlier conclusions at all. Most of
> the earlier observations apply to these results from these machines with
> reasonably different types of storage. So I still think we should stick
> to
1 - 100 of 2003 matches
Mail list logo
