I've committed 0001, and I plan to look closer at 0002 soon.
--
nathan
On Mon, Sep 08, 2025 at 11:55:14AM -0500, Nathan Bossart wrote:
> I've started preparing this for commit, and I realized that restricting
> GetNamedLWLockTranche() to shmem_startup_hook is not sufficient.
> EXEC_BACKEND builds will run this hook in every backend, so unless it'
but I've yet to dig into this further.
--
nathan
>From 155535f92df1d9cdf97739465b26ba970ed97063 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 12 Sep 2025 15:51:55 -0500
Subject: [PATCH v9 1/1] Optimize hex_encode() and hex_decode() using SIMD.
---
src/backend/utils/adt/encod
On Thu, Sep 18, 2025 at 03:05:52PM -0400, Jonathan S. Katz wrote:
> Many thanks to Nathan for pulling this together. Please see v3. Feedback
> welcome.
I'm hoping to commit this around 20:00 UTC today, and I will be happy to
address any feedback that folks have in the meantime.
--
nathan
Committed.
--
nathan
On Fri, Sep 19, 2025 at 01:04:26PM -0400, Jonathan S. Katz wrote:
> On 9/19/25 12:50 PM, Nathan Bossart wrote:
>> + An asynchronous I/O subsystem (AIO) that can improve performance of
>> + sequential scans, bitmap heap scans, vacuums, and other operations.
>>
>
On Fri, Sep 19, 2025 at 09:25:52AM -0500, Nathan Bossart wrote:
> I'm hoping to commit this around 20:00 UTC today, and I will be happy to
> address any feedback that folks have in the meantime.
Here's a v4. The content is the same except for a typo fix, some
formatting adjust
On Fri, Sep 19, 2025 at 07:41:14AM +0800, Chao Li wrote:
> Good catch. LGTM.
Committed.
--
nathan
On Mon, Sep 08, 2025 at 04:57:19PM -0500, Sami Imseih wrote:
> v2 LGTM.
Committed, thanks for reviewing. I ended up only back-patching the
documentation fix, as the test_slru bug is pretty innocuous.
--
nathan
Committed.
--
nathan
On Thu, Sep 18, 2025 at 03:25:08PM -0400, Robert Haas wrote:
> As I see it, while our feature freeze isn't perfect -- mostly because
> too many things get slipped in at the last minute that aren't really
> in great shape -- it's a lot better than the old process where nobody
> really knew what the
Most of these were missed by commit d952373a98, but I found one that seems
to have been missed by commit d08741eab5.
--
nathan
>From ba87e8b4d334c20edca1526f2d1d71280b39 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 18 Sep 2025 13:00:51 -0500
Subject: [PATCH v1 1/1] Fix obsol
On Thu, Sep 18, 2025 at 01:38:44PM -0400, Robert Haas wrote:
> That seems completely backwards to me. We should go with the version
> that was submitted weeks ago and upon which people have had the
> opportunity to comment unless you can justify each change that you now
> want to make at the last m
On Wed, Sep 17, 2025 at 11:00:00PM +0300, Alexander Lakhin wrote:
> Please look at the recovery test failures produced since ed1aad15e, with
> pg_stat_statements loaded:
I'm tracking a fix for that in another thread [0].
[0] https://postgr.es/m/aMrG8F-NkiedEugc%40nathan
--
nathan
On Sat, Sep 06, 2025 at 10:12:11AM +0900, Michael Paquier wrote:
> Yep. This plan is safe to rely on.
Committed, thanks for reviewing!
--
nathan
On Tue, Sep 16, 2025 at 02:35:55PM -0500, Nathan Bossart wrote:
> On Thu, Sep 11, 2025 at 04:18:00PM -0500, Nathan Bossart wrote:
>> I've committed 0001, and I plan to look closer at 0002 soon.
>
> I ended up rewriting 0002 as an ordinary regression test, which resulted in
&g
Barring more
feedback, I'm planning to commit this soon.
--
nathan
>From 112dc6f722daaaf3c08c8a268d19f6678a2d1cbe Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 17 Sep 2025 13:45:49 -0500
Subject: [PATCH v9 1/1] Add a test harness for the LWLock tranche code.
This code is
On Wed, Sep 17, 2025 at 11:33:52AM -0400, Robert Haas wrote:
> I don't understand why we're always doing the list of major features
> at the absolute last possible moment. I really think that should have
> been done a month ago, if not several months, so that we could have
> appropriate time for bi
On Wed, Sep 17, 2025 at 10:15:10AM -0400, Peter Geoghegan wrote:
> On Wed, Sep 17, 2025 at 1:21 AM Peter Eisentraut wrote:
>> I think there is agreement that the PointerIsValid() macro is pretty
>> useless. This patch proposes to remove it. There have been a few
>> recent mini-discussions in oth
the typical
> pattern out there, in my opinion.
Okay. I changed it in v8.
--
nathan
>From f5d462e175fe6d9ab76b1e59b98013480df5ed9b Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 16 Sep 2025 10:15:11 -0500
Subject: [PATCH v8 1/1] test_lwlock_tranches
---
src/test/modules/Makefile | 1 +
an unregistered tranche.
I added an initialization test.
--
nathan
>From 7fd394355c0ee19d00247a95554040ae35c4cacb Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 16 Sep 2025 10:15:11 -0500
Subject: [PATCH v7] 1/1] test_lwlock_tranches
---
src/test/modules/Makefile
On Thu, Sep 11, 2025 at 04:18:00PM -0500, Nathan Bossart wrote:
> I've committed 0001, and I plan to look closer at 0002 soon.
I ended up rewriting 0002 as an ordinary regression test, which resulted in
a much smaller patch with comparable coverage. (Yes, it needs some
comments.)
Thanks for reporting.
On Mon, Sep 15, 2025 at 10:43:06PM +0530, DIPESH DHAMELIYA wrote:
> Starting from commit 98fc31d (PG18 only), there is a new behaviour for
> DROP OWNED BY command where it deletes entries from pg_auth_members
> (including entries with ADMIN option). This change can cause a us
I quickly put together a patch for the stuff we've discussed in this
thread. WDYT?
--
nathan
>From 11289e1e69fc7c6fdbe5a73483efc2daf1197ec9 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 8 Sep 2025 16:08:00 -0500
Subject: [PATCH v1 1/1] Fix shmem_startup_hook documentation.
EXEC_BACKEND in docs, and it’s
> clearer than the ambiguity of saying 'on some builds'/'in other builds'.
Added in v2.
--
nathan
>From 2ed006e00e011707a1b86c31f13f7366590e56d9 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 8 Sep 2025 16:08:00 -0500
Subject: [PATCH
proach. But I'm curious how others feel about this.
v8 is an attempt to fix the casting error on MSVC.
--
nathan
>From 746dc9e3d2673ce53ae0ddc46120f13c667a2817 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 10 Sep 2025 21:37:20 -0500
Subject: [PATCH v8 1/1] Optimize hex_encode
tic that we can do
something similar for hex_decode().
--
nathan
>From f2b4f8cf844dead4658469257b771d3394a46ed0 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 10 Sep 2025 21:37:20 -0500
Subject: [PATCH v7 1/1] Optimize hex_encode() using SIMD.
---
src/backend/utils/adt/encode.c | 56
On Tue, Sep 09, 2025 at 04:11:49PM -0700, Jeff Davis wrote:
> On Tue, 2025-09-09 at 10:39 -0500, Nathan Bossart wrote:
>> My first instinct was to consider this for back-patching, but I see that
>> you didn't back-patch commit 9af672b. Is there any technical reason we
On Mon, Sep 08, 2025 at 01:35:02PM -0700, Jeff Davis wrote:
> On Mon, 2025-09-08 at 15:14 -0500, Nathan Bossart wrote:
>> I think we need to do something similar for numeric.c.
>
> Good catch. Patch LGTM.
Thanks for reviewing.
My first instinct was to consider this for back-patc
On Mon, Sep 08, 2025 at 02:47:26PM -0500, Sami Imseih wrote:
> I think v2 is fine because it is perfectly fine for a normal backend
> (EXEC_BACKEND) to call this function as long as it's processing the
> startup hook. The goal is to prevent it from being called outside of the
> startup hook.
I tho
On Mon, Sep 08, 2025 at 01:43:45PM -0400, Andres Freund wrote:
> On 2025-09-05 16:07:09 -0700, Jeff Davis wrote:
>> On Fri, 2025-09-05 at 13:25 -0700, Jeff Davis wrote:
>>> As an aside, I'm building with meson using -Dc_args="-msse4.2 -Wtype-
>>> limits -Werror=missing-braces". But I notice that th
On Thu, Sep 04, 2025 at 08:35:13PM -0500, Nathan Bossart wrote:
> On Thu, Sep 04, 2025 at 04:12:09PM -0500, Sami Imseih wrote:
>>> Yeah, I think modeling this after commit 4f2400c is a reasonable thing to
>>> explore.
>>
>> Here it is as described above.
>
On Fri, Sep 05, 2025 at 10:48:21AM -0400, Burd, Greg wrote:
> I looked at both radix tree and binary heap and how they use random sets when
> testing. Binary heap uses it to create different random sets of numbers to
> use across multiple tests while radix tree has a single function that focuses
>
tweak, so I would
> store the condition in a separate variable at the top of test_mode()
> in 006_transfer_modes.pl, or something equivalent.
How does this look?
--
nathan
>From a09d792405df4607886643adaca30c3ee3a3c03e Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 14 Aug 20
On Fri, Aug 15, 2025 at 11:39:23AM -0400, Greg Burd wrote:
> I noticed that there are no tests for Bitmapset in src/test/modules as
> is the case for other similar things like radixtree, rbtree, etc. so I
> created one. I realize that Bitmapset is already "tested" by all the
> other code that uses
On Thu, Sep 04, 2025 at 04:12:09PM -0500, Sami Imseih wrote:
>> Yeah, I think modeling this after commit 4f2400c is a reasonable thing to
>> explore.
>
> Here it is as described above.
Thanks. This looks like the right idea to me, but let's give some time for
others to comment.
--
nathan
On Thu, Sep 04, 2025 at 01:59:36PM +0900, Michael Paquier wrote:
> On Tue, Sep 02, 2025 at 09:43:40AM -0500, Nathan Bossart wrote:
>> Do you think a new pg_upgrade test for security labels is worth the
>> trouble? It seems doable, but it'd be an awfully expensive test for t
On Thu, Sep 04, 2025 at 12:30:27PM -0500, Sami Imseih wrote:
> I liked removing the repalloc calls inside this routine and did not think
> it was worth optimizing. I am OK with reverting it back. Although v1
> is incorrect since it's still initializing
> NamedLWLockTrancheRequestArray to MAX_NAMED_
On Thu, Sep 04, 2025 at 01:23:26PM -0500, Sami Imseih wrote:
> I suggest we set an in progres flag for shmem_startup_hook, as we do for
> shmem_request_hook, and error out this function if called outside of this
> hook. The error will be something like this:
>
> ```
> ERROR: cannot return the add
On Thu, Sep 04, 2025 at 03:29:52PM +0530, Rahila Syed wrote:
> Since updates to LocalLWLockCounter and LWLockTrancheNames are performed
> while holding the lock, but reading LocalLWLockCounter and then
> LWLockTrancheNames in GetLWTrancheName can occur without acquiring the
> same lock in case tran
On Wed, Sep 03, 2025 at 02:01:14PM -0500, Nathan Bossart wrote:
> Committed.
I'm having some regrets about the changes to RequestNamedLWLockTranche().
Specifically, when it is first called, it immediately allocates an array
big enough to hold 256 requests (~17 KB), whereas it used
Committed.
--
nathan
Well, commit 38b602b certainly doesn't do us any favors here since it
removed NamedLWLockTrancheArray. Given the lack of reports from the field,
I suspect the best path forward is to add an ERROR for unsafe accesses and
to fix the documentation, as discussed upthread.
--
nathan
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
1 - 100 of 2046 matches
Mail list logo
