I ran Euler's tests again on the v6 patch set.
for i in `seq 1 1`; do psql postgres -c "CREATE SEQUENCE s$i;"; done
time pg_dump -f - -s -d postgres > /dev/null
HEAD:0.607s
0001 + 0002: 0.094s
all patches: 0.094s
Barring additional feedback, I
On Wed, Jul 24, 2024 at 11:32:47AM +0530, Amit Kapila wrote:
> LGTM.
Thanks for reviewing. Committed and back-patched to v17.
--
nathan
On Tue, Jul 23, 2024 at 05:41:18PM -0400, Joseph Koshakow wrote:
> On Tue, Jul 23, 2024 at 2:14 AM jian he wrote:
>> On Tue, Jul 23, 2024 at 6:56 AM Joseph Koshakow wrote:
>>> The specific bug that this patch fixes is preventing the following
>>> statement:
>>>
>>> # INSERT INTO
nor point is the comment atop get_subscription_count() still
> refers to the function name as get_db_subscription_count().
Oops, fixed.
--
nathan
>From 19831c5a2869f949e73564abea8a36858b39bcd1 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Sat, 20 Jul 2024 21:01:29 -0500
Subject: [PATC
On Mon, Jul 22, 2024 at 04:36:33PM -0500, Nathan Bossart wrote:
> Okay. I'll plan on committing v13-0002 in the next couple of days, then.
Actually, I think my concerns about prohibiting more than necessary go away
if we do the subtraction first. If "upperIndx[i] - lowerIndx[i]"
On Mon, Jul 22, 2024 at 05:20:15PM -0400, Joseph Koshakow wrote:
> On Mon, Jul 22, 2024 at 11:17 AM Nathan Bossart
> wrote:
>> Am I understanding correctly that the main
>> behavioral difference between these two approaches is that users will see
>> different error
On Fri, Jul 19, 2024 at 04:21:37PM -0500, Nathan Bossart wrote:
> However, while looking into this, I noticed that only one get_query
> callback (get_db_subscription_count()) actually customizes the generated
> query using information in the provided DbInfo. AFAICT we can do this
>
On Fri, Jul 19, 2024 at 07:32:18PM -0400, Joseph Koshakow wrote:
> On Fri, Jul 19, 2024 at 2:45 PM Nathan Bossart
> wrote:
>> +/* dim[i] = 1 + upperIndx[i] - lowerIndx[i]; */
>> +if (pg_add_s32_overflow(1, upperIndx[i], [i]))
>> +
On Mon, Jul 22, 2024 at 03:45:19PM +0530, Amit Kapila wrote:
> On Mon, Jul 22, 2024 at 7:35 AM Michael Paquier wrote:
>> On Sat, Jul 20, 2024 at 09:03:07PM -0500, Nathan Bossart wrote:
>> >> This is an extremely expensive way to perform that check, and so I'm
>> >&g
On Fri, Jul 19, 2024 at 03:44:22PM -0500, Nathan Bossart wrote:
> I've been looking into optimizing pg_upgrade's once-in-each-database steps
> [0], and I noticed that we are opening a connection to every database in
> the cluster and running a query like
>
> SELEC
On Thu, Jul 18, 2024 at 09:57:23AM +0200, Daniel Gustafsson wrote:
>> On 17 Jul 2024, at 23:32, Nathan Bossart wrote:
>> On Wed, Jul 17, 2024 at 11:16:59PM +0200, Daniel Gustafsson wrote:
>
>>> +static void
>>> +dispatch_query(const Clus
I've been looking into optimizing pg_upgrade's once-in-each-database steps
[0], and I noticed that we are opening a connection to every database in
the cluster and running a query like
SELECT count(*) FROM pg_catalog.pg_subscription WHERE subdbid = %d;
Then, later on, we combine all of
On Fri, Jul 19, 2024 at 03:27:49PM -0400, David E. Wheeler wrote:
> I´m trying to understand the standard terms for extension libraries.
> There seem too a bewildering number of terms used to refer to a shared
> object library, for example:
>
> [...]
>
> What is the standard term for these
Given the lack of interest, I plan to mark the commitfest entry for this
patch set as "Withdrawn" shortly.
--
nathan
On Mon, Jul 08, 2024 at 02:29:16PM -0500, Nathan Bossart wrote:
> One thing that still bugs me is that there is no feedback sent to the user
> when autovacuum_max_workers is set higher than autovacuum_worker_slots. I
> think we should at least emit a WARNING, perhaps from the a
I took a look at 0003.
+/* dim[i] = 1 + upperIndx[i] - lowerIndx[i]; */
+if (pg_add_s32_overflow(1, upperIndx[i], [i]))
+ereport(ERROR,
+(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
+ errmsg("array upper bound is
On Thu, Jul 18, 2024 at 09:08:30PM -0400, Joseph Koshakow wrote:
> As a reminder:
> - 0001 is reviewed.
> - 0002 is reviewed and a bug fix.
> - 0003 is currently under review and a bug fix.
> - 0004 needs a review.
I've committed/back-patched 0002. I plan to review 0003 next.
--
nathan
I fixed a compiler warning on Windows in v6 of the patch set. Sorry for
the noise.
--
nathan
>From 139826d3b9290d547ae9b3446ad455ba713211e0 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 15 Jul 2024 13:13:05 -0500
Subject: [PATCH v6 1/4] parse sequence information
---
src/
created an enum for the sequence data types to avoid the hacky strncpy()
stuff, which was causing weird CI failures [0].
[0] https://cirrus-ci.com/task/4614801962303488
--
nathan
>From e98ff5c9a5e8962445de0d5ab68ce50ed40c121b Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 15 Jul 20
...
That doesn't seem so bad, and it'd avoid an extra pg_proc entry, but it
would probably break anything that calls pg_sequence_last_value() directly.
Thoughts?
--
nathan
>From c5e139efdae92c3902daee886075b509a0720368 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 15 Jul 2024 13:13:05 -0
On Wed, Jul 17, 2024 at 11:16:59PM +0200, Daniel Gustafsson wrote:
> First reaction after a read-through is that this seems really cool, can't wait
> to see how much v18 pg_upgrade will be over v17. I will do more testing and
> review once back from vacation, below are some comments from reading
On Wed, Jul 17, 2024 at 02:59:26PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On second thought, I worry that this change might needlessly complicate the
>> pg_sequences system view. Maybe we should just add a
>> pg_sequence_get_tuple() function th
On Tue, Jul 16, 2024 at 10:23:08PM -0500, Nathan Bossart wrote:
> On Wed, Jul 17, 2024 at 11:30:04AM +0900, Michael Paquier wrote:
>> Yeah, I have bumped on the same issue. In the long term, I also think
>> that we'd better have pg_sequence_last_value() return a row wi
On Sun, Jun 09, 2024 at 02:04:17PM -0500, Nathan Bossart wrote:
> Here's a new version of the patch with the GUC renamed to
> num_os_semaphores.
The only thing stopping me from committing this right now is Tom's upthread
objection about adding more GUCs that just expose values that you
On Tue, Jul 16, 2024 at 04:38:06PM -0500, Nathan Bossart wrote:
> Alright. Well, I guess I'll flip a coin tomorrow unless someone else
> chimes in with an opinion.
Committed and back-patched to v17. I left it as PqMsg_Progress.
--
nathan
On Wed, Jul 17, 2024 at 11:30:04AM +0900, Michael Paquier wrote:
> Yeah, I have bumped on the same issue. In the long term, I also think
> that we'd better have pg_sequence_last_value() return a row with
> is_called and the value scanned. As you say, it won't help except
> when upgrading from
On Tue, Jul 16, 2024 at 09:23:27PM -0400, Joseph Koshakow wrote:
> On Tue, Jul 16, 2024 at 1:57 PM Nathan Bossart
> wrote:
>> The reason I suggested this is so that we could omit all the prerequisite
>> isinf(), isnan(), etc. checks in the cash_mul_float8() and friends. The
>
On Tue, Jul 16, 2024 at 10:58:37PM +0300, Aleksander Alekseev wrote:
>> Thanks. The only thing that stands out to me is the name of the parallel
>> leader/worker protocol message. In the original thread for protocol
>> characters, some early versions of the patch called it a "parallel
>>
On Thu, Jul 11, 2024 at 09:09:17PM -0500, Nathan Bossart wrote:
> On second thought, maybe we should just limit this improvement to the minor
> releases with the fix so that we _can_ get rid of the workaround. Or we
> could use the hacky workaround only for versions with the bug.
Here
On Tue, Jul 16, 2024 at 09:14:35PM +0300, Aleksander Alekseev wrote:
>> As discussed elsewhere [0], we can add the leader/worker protocol
>> characters to protocol.h, but they should probably go in a separate
>> section. I'd recommend breaking that part out to a separate patch, too.
>
> OK, here
On Mon, Jul 15, 2024 at 07:55:22PM -0400, Joseph Koshakow wrote:
> On Mon, Jul 15, 2024 at 11:31 AM Nathan Bossart
> wrote:
>>I'm curious why you aren't using float8_mul/float8_div here, i.e.,
>>
>>fresult = rint(float8_mul((float8) c, f));
>>
I took a closer look at 0001.
diff --git a/src/include/libpq/protocol.h b/src/include/libpq/protocol.h
index 4b8d440365..8c0f095edf 100644
--- a/src/include/libpq/protocol.h
+++ b/src/include/libpq/protocol.h
@@ -47,6 +47,7 @@
#define PqMsg_EmptyQueryResponse 'I'
#define
On Tue, Jul 16, 2024 at 12:23:19PM -0400, Robert Haas wrote:
> TBH, I don't want to do that. I think it's too fragile. It's the sort
> of thing that just barely works given the exact behavior of these
> particular GUCs, but it relies on a bunch of subtle assumptions which
> won't be evident to
On Tue, Jul 16, 2024 at 04:09:44PM +0300, Aleksander Alekseev wrote:
> - Patch 1 replaces all the char's with PqMsg's
Thanks. I'll look into committing this one in the near future.
> - Patch 2 makes PqMsg an enum. This ensures that the problem will not
> appear again in the future and also
On Mon, Jul 15, 2024 at 04:03:13PM -0400, Robert Haas wrote:
> On Mon, Jul 15, 2024 at 2:47 PM Nathan Bossart
> wrote:
>> My understanding is that the correctness of this GUC check hook depends on
>> wal_level being a PGC_POSTMASTER GUC. The check hook would always return
>
On Mon, Jul 15, 2024 at 01:47:14PM -0500, Nathan Bossart wrote:
> On Mon, Jul 15, 2024 at 02:30:42PM -0400, Robert Haas wrote:
>> I guess I'm in the group of people who doesn't understand how this can
>> possibly work. There's no guarantee about the order in which GUC check
>>
On Mon, Jul 15, 2024 at 02:30:42PM -0400, Robert Haas wrote:
> On Sun, Jul 14, 2024 at 10:56 PM Fujii Masao
> wrote:
>> I don't think it's a rare scenario since summarize_wal can be enabled
>> after starting the server with wal_level=minimal. Therefore, I believe
>> such a configuration should be
On Fri, Jul 12, 2024 at 03:39:57PM -0500, Sami Imseih wrote:
> but Bertrand found long drifts [2[ which I could not reproduce.
> To safeguard the long drifts, continue to use the time with an
> additional safeguard to make sure the actual sleep does not exceed the
> requested sleep time.
On Mon, Jul 15, 2024 at 09:41:55AM -0700, Andres Freund wrote:
> On 2024-05-10 12:13:21 +0300, Nazir Bilal Yavuz wrote:
>> The fix is attached. It cleanly applies from REL_15_STABLE to
>> REL_12_STABLE, fixes the warnings and the tests pass.
>
> Thanks! I've applied it to all branches - while
I took a closer look at 0002.
+if (unlikely(isinf(f) || isnan(f)))
+ereport(ERROR,
+(errcode(ERRCODE_NUMERIC_VALUE_OUT_OF_RANGE),
+ errmsg("invalid float value")));
+
+fresult = rint(f * c);
+if (unlikely(f == 0.0))
+ereport(ERROR,
+
On Sat, Jul 13, 2024 at 10:24:16AM -0400, Joseph Koshakow wrote:
> On Fri, Jul 12, 2024 at 12:49 PM Nathan Bossart
> wrote:
>> IIUC some of these changes are bug fixes. Can we split out the bug fixes
>> to their own patches so that they can be back-patched?
>
> They ha
On Fri, Jul 12, 2024 at 12:14:56PM -0500, Sami Imseih wrote:
> 1/ TimestampDifference has a dependency on gettimeofday,
> while my proposal utilizes clock_gettime. There are old discussions
> that did not reach a conclusion comparing both mechanisms.
> My main conclusion from these hacker
On Sat, Jul 06, 2024 at 07:04:38PM -0400, Joseph Koshakow wrote:
> I've added another patch, 0004, to resolve the jsonb wrap-arounds.
>
> The other patches, 0001, 0002, and 0003 are unchanged but have their
> version number incremented.
IIUC some of these changes are bug fixes. Can we split out
On Fri, Jul 12, 2024 at 02:21:09PM +0900, Michael Paquier wrote:
> On Thu, Jul 11, 2024 at 08:50:57PM -0500, Nathan Bossart wrote:
>> I'm not following how this is guaranteed to trigger an autovacuum quickly.
>> Shouldn't we set autovacuum_vacuum_insert_threshold to 1 so that it
On Fri, Jul 12, 2024 at 12:01:11PM +0200, Antonin Houska wrote:
> Nathan Bossart wrote:
>> My concern with switching them to bsearch() would be the performance impact
>> of using a function pointer for the comparisons. Perhaps we could add a
>> couple of inlined binary s
On Wed, Jul 10, 2024 at 11:52:33PM -0300, Euler Taveira wrote:
> On Wed, Jul 10, 2024, at 7:05 PM, Nathan Bossart wrote:
>> Unfortunately, I think we have to keep this workaround since older minor
>> releases of PostgreSQL don't have the fix.
>
> Hmm. Right.
On second tho
On Wed, Jul 10, 2024 at 02:14:55PM +0900, Michael Paquier wrote:
> +# Only non-superuser roles granted pg_signal_autovacuum_worker are allowed
> +# to signal autovacuum workers. This test uses an injection point located
> +# at the beginning of the autovacuum worker startup.
nitpick: Superuser
On Wed, Jul 10, 2024 at 01:41:41PM -0500, Nathan Bossart wrote:
> On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote:
>> We went through a ton of permutations of that kind of
>> idea years ago, when it first became totally clear that cross-checks
>> between GU
On Thu, Jul 11, 2024 at 01:10:25PM -0500, Sami Imseih wrote:
>> I'm curious why we wouldn't just subtract "elapsed_time" from "delay" at
>> the bottom of the while loop to avoid needing this extra check.
>
> Can you elaborate further? I am not sure how this will work since delay is a
>
+ /*
+* We allow nanosleep to handle interrupts and retry with the
remaining time.
+* However, since nanosleep is susceptible to time drift when
interrupted
+* frequently, we add a safeguard to break out of the nanosleep
whenever the
On Wed, Jul 10, 2024 at 05:08:56PM -0300, Euler Taveira wrote:
> Nice improvement. The numbers for a realistic scenario (10k sequences) are
Thanks for taking a look!
> You are changing internal representation from char to int64. Is the main goal
> to
> validate catalog data? What if there is a
Committed. Thank you for reviewing!
--
nathan
On Wed, Jul 10, 2024 at 12:29:00PM -0700, Jeff Davis wrote:
>> > It might be reasonable to give implicit USAGE privileges on all
>> > schemas
>> > during maintenance commands to pg_maintain roles.
>
> That's an even more specific exception: having USAGE only in the
> context of a maintenance
On Wed, Jul 10, 2024 at 05:00:13PM +0200, Antonin Houska wrote:
> I don't quite understand why TransactionIdIsCurrentTransactionId() implements
> binary search in ParallelCurrentXids "from scratch" instead of using
> bsearch().
I believe there are a number of open-coded binary searches in the
On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote:
> We went through a ton of permutations of that kind of
> idea years ago, when it first became totally clear that cross-checks
> between GUCs do not work nicely if implemented in check_hooks.
> (You can find all the things we tried in the
On Thu, Jul 11, 2024 at 01:02:25AM +0900, Fujii Masao wrote:
> On 2024/07/10 23:18, Nathan Bossart wrote:
>> Yeah. I initially thought this patch might be okay, at least as a stopgap,
>> but Jelte pointed out a case where it doesn't work, namely when you have
>> somethi
On Wed, Jul 10, 2024 at 11:54:38AM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I haven't tested it, but from skimming around the code, it looks like
>> ProcessConfigFileInternal() would deduplicate any previous entries in the
>> file prior to applying the values and ru
On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote:
> Please, no. We went through a ton of permutations of that kind of
> idea years ago, when it first became totally clear that cross-checks
> between GUCs do not work nicely if implemented in check_hooks.
> (You can find all the things we
On Wed, Jul 10, 2024 at 04:29:14PM +0200, Jelte Fennema-Nio wrote:
> On Wed, 10 Jul 2024 at 16:18, Nathan Bossart wrote:
>> Yeah. I initially thought this patch might be okay, at least as a stopgap,
>> but Jelte pointed out a case where it doesn't work, namely when you have
&g
On Wed, Jul 10, 2024 at 10:10:30AM -0400, Robert Haas wrote:
> On Wed, Jul 10, 2024 at 1:56 AM Fujii Masao
> wrote:
>> I'm sure this patch is necessary as a safeguard for WAL summarization.
>> OTOH, I also think we should apply the patch I proposed earlier
>> in this thread, which prevents
On Wed, Jul 10, 2024 at 05:13:58PM +0900, Fujii Masao wrote:
> However, unlike the database owner, pg_maintain by definition should
> have *all* the rights needed for maintenance tasks, including MAINTAIN
> rights on tables and USAGE rights on schemas? ISTM that both
> pg_read_all_data and
On Mon, Jun 24, 2024 at 11:30:00AM +0530, Bharath Rupireddy wrote:
> 6) Vacuum command can't be run on the standby in recovery. So, to help
> invalidate replication slots on the standby, I have for now let the
> checkpointer also do the XID age based invalidation. I know
> invalidating both in
rebased
--
nathan
>From 8cab570c9c5771d58860ff4e1d8cbd38e2792d80 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 30 Apr 2024 14:41:36 -0500
Subject: [PATCH v2 1/3] parse sequence information
---
src/bin/pg_dump/pg_dump.c | 64 ---
1 file chan
rebased (due to commit ccd3802, which introduced
pg_signal_autovacuum_worker)
--
nathan
>From c9e9c04c8edf3aaedc683c1c4e6811feb2c2c267 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 18 Jun 2024 11:38:40 -0500
Subject: [PATCH v5 1/1] revamp predefined roles documentation
---
doc/
I've committed 0001. It looks like 0002 failed CI testing [0], but I
haven't investigated why.
[0] https://cirrus-ci.com/task/5668467599212544
--
nathan
into one scan through all the databases.
The code is still very rough and nowhere near committable, but this at
least gets the patch set into the editing phase.
--
nathan
>From a4110826fd703e100da7ca8419e4d0609b4346eb Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 28 Jun 2024 11:02
Committed.
--
nathan
instead of
silently proceeding with a different value than the user configured. Any
thoughts?
--
nathan
>From bd486d1ab302c4654b9cfbc57230bcf9b140711e Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Sat, 22 Jun 2024 15:05:44 -0500
Subject: [PATCH v7 1/1] allow changing autovacuum_max_work
to
the data_types_usage_checks array.
[0] https://postgr.es/m/Zov5kHbEyDMuHJI_%40nathan
--
nathan
>From 0d3353c318ca4dcd582d67ca25c47b9e3cf24921 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 28 Jun 2024 11:02:44 -0500
Subject: [PATCH v3 1/7] introduce framework for parallelizing pg_upgr
On Mon, Jul 08, 2024 at 03:22:36PM +0800, 杨伯宇(长堂) wrote:
> Besides, https://commitfest.postgresql.org/48/4995/ seems insufficient to
> this situation. Some time-consuming functions like check_for_data_types_usage
> are not yet able to run in parallel. But these patches could be a great
> starting
On Mon, Jul 08, 2024 at 01:03:42AM +0900, Fujii Masao wrote:
> If this has already been discussed and the current behavior is deemed proper,
> I'm sorry for bringing it up again. Even in that case, it would be helpful
> to document that USAGE privilege on the schema may be necessary in addition
>
On Mon, Jul 08, 2024 at 01:03:42AM +0900, Fujii Masao wrote:
> I've noticed an issue with non-superusers who have the pg_maintain role.
> When they run VACUUM on a specific table within a specific schema,
> like "VACUUM mynsp.mytbl", it fails if they don't have the USAGE privilege
> on the schema.
Committed.
--
nathan
On Fri, Jul 05, 2024 at 05:24:42PM +0800, 杨伯宇(长堂) wrote:
>> > So, I'm thinking, why not add a "--skip-check" option in pg_upgrade to
>> > skip it?
>> > See "1-Skip_Compatibility_Check_v1.patch".
>>
>> How would a user know that nothing has changed in the cluster between running
>> the check and
Committed.
--
nathan
On Wed, Jul 03, 2024 at 11:08:48PM +0900, Fujii Masao wrote:
> +/*
> + * GUC check_hook for summarize_wal
> + */
> +bool
> +check_summarize_wal(bool *newval, void **extra, GucSource source)
> +{
> + if (*newval && wal_level == WAL_LEVEL_MINIMAL)
> + {
> + GUC_check_errmsg("WAL
On Mon, Jun 03, 2024 at 10:10:58AM -0500, Nathan Bossart wrote:
> Tom, Alvaro, and Peter have all expressed a preference to use the .github/
> directory, so at the moment I still intend to proceed with the v3 patch
> unless further discussion changes things.
Committed.
We could
Committed.
--
nathan
On Mon, Jul 01, 2024 at 03:58:16PM -0400, Robert Haas wrote:
> On Mon, Jul 1, 2024 at 3:47 PM Nathan Bossart
> wrote:
>> 0001 introduces a new API for registering callbacks and running them in
>> parallel on all databases in the cluster. This new system manages a set of
>
the data type
checks yet, and that tends to eat up a sizable chunk of time when there are
many databases.
On Thu, May 16, 2024 at 08:24:08PM -0500, Nathan Bossart wrote:
> On Thu, May 16, 2024 at 05:09:55PM -0700, Jeff Davis wrote:
>> Also, did you consider connecting once to each database and ru
On Thu, May 16, 2024 at 08:33:35PM -0500, Nathan Bossart wrote:
> Here is a rebased version of 0002, which I intend to commit once v18
> development begins.
Committed.
--
nathan
Committed.
--
nathan
On Fri, Jun 21, 2024 at 04:01:55PM -0500, Nathan Bossart wrote:
> On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
>> 0001 is some cleanup after f4b54e1ed9
>
> Oops. I'll plan on committing this after the 17beta2 release freeze is
> lifted.
Committed 0001.
--
nathan
On Wed, Jun 26, 2024 at 10:40:10AM -0400, Robert Haas wrote:
> On Tue, Jun 25, 2024 at 4:19 PM Nathan Bossart
> wrote:
>> Yeah, my options were to either separate the roles or to weaken the
>> ordering, and I guess I felt like the weaker ordering was slightly less
>>
On Wed, Jun 26, 2024 at 07:58:55AM -0700, David G. Johnston wrote:
> On Wed, Jun 26, 2024 at 7:52 AM Joel Jacobson wrote:
>> Want me to fix that or will the committer handle that?
>>
>> I found some more similar cases in acronyms.sgml.
>
> Given this I'd be OK with committing as-is in the name of
On Tue, Jun 25, 2024 at 05:59:01PM -0700, David G. Johnston wrote:
> Though there was no comment on the fact we should be linking to:
>
> https://en.wikipedia.org/wiki/Access-control_list
>
> not:
>
> https://en.wikipedia.org/wiki/Access_Control_List
>
> to avoid the dis-ambiguation redirect.
On Tue, Jun 25, 2024 at 04:04:03PM -0400, Robert Haas wrote:
> Looking at this again, how happy are you with the way you've got
> several roles per instead of one for each? I realize
> that was probably part of the intent of the change, to move the data
> from below the table into the table, and
On Tue, Jun 25, 2024 at 11:28:18AM -0500, Nathan Bossart wrote:
> On Tue, Jun 25, 2024 at 12:16:30PM -0400, Robert Haas wrote:
>> pg_database_owner is a predefined role for which membership consists,
>> implicitly, of the current database owner. It cannot be granted
>> m
On Tue, Jun 25, 2024 at 02:02:09PM +0530, Amit Kapila wrote:
> On Tue, Jun 25, 2024 at 12:30 PM Masahiko Sawada
> wrote:
>> On Tue, Jun 25, 2024 at 1:54 PM Amit Kapila wrote:
>> > So, my
>> > preference is in order as follows: synchronized_standby_slots,
>> > wait_for_standby_slots,
On Tue, Jun 25, 2024 at 08:10:24AM +0200, Joel Jacobson wrote:
> On Tue, Jun 25, 2024, at 07:11, Michael Paquier wrote:
>> v1 is fine without the "privileges list" part mentioned by Nathan in
>> the first reply.
>
> v2 is exactly that, but renamed and attached, so we have an entry this
> was the
On Tue, Jun 25, 2024 at 12:16:30PM -0400, Robert Haas wrote:
> pg_database_owner is a predefined role for which membership consists,
> implicitly, of the current database owner. It cannot be granted
> membership in any role, and no role can be granted membership in
> pg_database_owner. However,
On Mon, Jun 24, 2024 at 03:53:46PM -0700, David G. Johnston wrote:
> pg_database_owner owns the initially created public schema and has an
> implicit membership list of one - the role owning the connected-to database.
> It exists to encourage and facilitate best practices regarding database
>
orrow), please be my guest. TBH I
think the existing content is pretty good, so I'm not opposed to leaving it
alone, even if the style is different than the other entries.
--
nathan
>From d76a09646bd9458450a4f5c051c36050fefbbf29 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 18 Jun 202
On Thu, Apr 11, 2024 at 01:52:26PM -0400, David E. Wheeler wrote:
> I realize this probably isn´t going to happen for 17, given the freeze,
> but I would very much welcome feedback and pointers to address concerns
> about providing a second directory for extensions and DSOs. Quite a few
> people
On Mon, Jun 24, 2024 at 02:32:27PM +0200, Joel Jacobson wrote:
> This patch is based on a suggestion from a separate thread [1]:
>
> On Mon, Jun 24, 2024, at 01:46, Michael Paquier wrote:
>> Rather unrelated to this patch, still this patch makes the situation
>> more complicated in the docs, but
On Mon, Jun 24, 2024 at 04:12:38PM +0200, Tomas Vondra wrote:
> The important observation is that this only happens if a database is
> created while the backup is running, and that it only happens with the
> FILE_COPY strategy - I've never seen this with WAL_LOG (which is the
> default since
On Fri, Jun 21, 2024 at 03:44:07PM -0500, Nathan Bossart wrote:
> I'm still not sure about this approach. At the moment, I'm leaning towards
> something more like v2 [2] where the upper limit is a PGC_POSTMASTER GUC
> (that we would set very low for TAP tests).
Like so.
--
nat
On Fri, Jun 21, 2024 at 11:22:05AM +0200, Jelte Fennema-Nio wrote:
> 0001 is some cleanup after f4b54e1ed9
Oops. I'll plan on committing this after the 17beta2 release freeze is
lifted.
--
nathan
On Tue, Jun 18, 2024 at 07:43:36PM -0500, Nathan Bossart wrote:
> On Tue, Jun 18, 2024 at 02:33:31PM -0700, Andres Freund wrote:
>> Another one:
>>
>> Have a general cap of 64, but additionally limit it to something like
>> max(1, min(WORKER_CAP, max_connections
On Fri, Jun 21, 2024 at 03:50:00PM -0400, Tom Lane wrote:
> Allow specification of physical standbys that must be synchronized
> before they are visible to subscribers (Hou Zhijie, Shveta Malik)
>
> it seems like the name ought to have some connection to
> synchronization. Perhaps
1 - 100 of 2049 matches
Mail list logo
