com/v1/artifact/task/5728127981191168/testrun/build-32/testrun/regress/regress/regression.diffs
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
you still planning on committing this? I can pick it up if
you are busy.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
bpq/pqcomm.h? I see that's where the authentication request
codes live today.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Aug 02, 2023 at 09:09:14AM -0700, Nathan Bossart wrote:
> On Wed, Aug 02, 2023 at 01:02:53PM +0530, Bharath Rupireddy wrote:
>> On Wed, Aug 2, 2023 at 12:45 PM Peter Eisentraut
>> wrote:
>>> I think we should change the output format to be more like initdb,
up in the same formatting issue.
I don't think it's that difficult. ІMO the bigger question is whether we
want to back-patch such a change to v16 at this point.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Aug 02, 2023 at 09:14:06AM +0200, Peter Eisentraut wrote:
> On 01.08.23 18:00, Nathan Bossart wrote:
>> One of the main purposes of this thread is to gauge interest. I'm hoping
>> there are other developers who are interested in reducing
>> pg_upgrade-related downtim
t happened.
I wonder if this is a good enough reason to _not_ proceed with this
optimization. At the moment, I'm on the fence about it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ry:
> without patch: 13.1s
> 0001: 11.7s
> 0001+0002: 10.5s
> 0001+0002+0003: 8.1s
Nice. It makes sense that 0003 would provide the most benefit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Jul 31, 2023 at 11:39:46AM -0700, Nathan Bossart wrote:
> I just realized I forgot to update the --help output for these utilities.
> I'll do that in the next version of the patch.
Done in v3. Sorry for the noise.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Aug 01, 2023 at 09:58:24AM +0200, Daniel Gustafsson wrote:
>> On 1 Aug 2023, at 09:45, Peter Eisentraut wrote:
>> On 28.07.23 01:51, Nathan Bossart wrote:
>
>>> This information can be used to better understand where the time is going
>>> an
On Tue, Aug 01, 2023 at 09:46:02AM +0200, Peter Eisentraut wrote:
> On 31.07.23 20:37, Nathan Bossart wrote:
>> -prep_status("Checking for incompatible \"aclitem\" data type in user
>> tables");
>> +prep_status("Checking for \"aclitem\&
On Mon, Jul 31, 2023 at 10:51:38AM -0700, Nathan Bossart wrote:
> Here is a new version of the patch with documentation updates and a couple
> other small improvements.
I just realized I forgot to update the --help output for these utilities.
I'll do that in the next version of the
erribly long or sophisticated.
My only remaining concern is that this timing information could cause
pg_upgrade's output to exceed 80 characters per line. I don't know if this
is something that folks are very worried about in 2023, but it still seemed
worth bringing up.
--
Nathan Bossart
On Sat, Jul 29, 2023 at 02:40:10PM -0700, Nathan Bossart wrote:
> I was about to start a new thread, but I found this one with some good
> preliminary discussion. I came to the same conclusion about introducing a
> new option instead of using syncfs() by default wherever it is
hat is
possible, then we might need to disable the cache when there is a hook.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
kes quite a while when there are
many files, and I am looking for ways to reduce the amount of downtime
required for pg_upgrade.
The attached patch adds a new --sync-method option to the relevant frontend
utilities, but I am not wedded to that name/approach.
Thoughts?
--
Nathan Bossart
Amazon Web
t; 23.932 ms'. I think MESSAGE_WIDTH needs to be bumped up - 64 or more.
Good catch. I think I'd actually propose just removing "in user tables" or
the word "incompatible" from these messages to keep them succinct.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jul 28, 2023 at 10:38:14AM -0700, Nathan Bossart wrote:
> I'm okay with simply adding the time. However, I wonder if we want to
> switch to seconds, minutes, hours, etc. if the step takes longer. This
> would add a bit of complexity, but it would improve human re
>>Ilya Kosmodemiansky
>>Melanie Plageman
>>Michael Banck
>>Michael Brewer
>>Paul Jungwirth
>>Peter Smith
>>Vigneshwaran C
>>
>> New PostgreSQL Major Contributors:
>>
>>Stacey Haysler
>>St
, "restoring datbase schemas in the new cluster", and
"sync data directory to disk". I imagine the dump, restore, and
file-copying steps will stand out once you start adding data.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Jul 19, 2023 at 10:43:11AM -0700, Nathan Bossart wrote:
> On Wed, Jun 28, 2023 at 10:24:09PM -0700, Nathan Bossart wrote:
>> The same commit that added this comment (ff402ae) also set the
>> allow_password_reuse parameter to true in vacuumdb's connectDatabase()
>> call
and to validate future improvements. I'm open to suggestions on formatting
the timing information, assuming folks are interested in this idea.
Thoughts?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From bd3fa72e58d7e9de5a4a0248895531b955ae99b4 Mon Sep 17 00:00:00 2001
F
On Wed, Jul 26, 2023 at 02:39:25PM -0700, Nathan Bossart wrote:
> Great. I spent some time on the commit message in v4. I plan to commit
> this shortly.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Mar 13, 2023 at 02:16:31PM -0700, Nathan Bossart wrote:
> At the moment, I'm thinking about either removing the check_interrupts
> function pointer argument altogether or making it optional for code paths
> where we might not want any interrupt handling to run. In the former
&
On Wed, Jul 26, 2023 at 08:06:37AM +0200, Pavel Stehule wrote:
> st 26. 7. 2023 v 6:22 odesílatel Nathan Bossart
> napsal:
>> Barring additional feedback, I think this is ready for commit.
>>
>>
> +1
Great. I spent some time on the commit message in v4. I
On Wed, Jul 26, 2023 at 05:14:08PM -0400, Tom Lane wrote:
> I think we should reword this to just generically claim that holding
> the Relation reference open for the whole transaction reduces overhead.
WFM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
omment, unfortunately, but ISTM we might want to
replace "pg_relation" with "them" instead.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Jul 26, 2023 at 11:53:06AM -0700, Nathan Bossart wrote:
> On Wed, Jul 26, 2023 at 06:48:51PM +0100, Dagfinn Ilmari Mannsåker wrote:
>> Triggered by a discussion on IRC, I noticed that there's a stray
>> reference to pg_relation in a comment that was added long after it
finally happens. -ay 11/5/94]
[0] https://dsf.berkeley.edu/postgres.html
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
arm coverage for all the
instrinsics used within Postgres, if for no other reason than to ensure
future changes do not break those platforms.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
this is ready for commit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 9346a1bbb2fc772527e4b1df82cfdc2dfbc5afb0 Mon Sep 17 00:00:00 2001
From: Kirk Wolak
Date: Wed, 17 May 2023 16:59:02 -0400
Subject: [PATCH v3 1/1] Change output of ECHO_HIDDEN comments to be SQL
comments
Simply
On Tue, Jul 25, 2023 at 05:16:56PM -0700, Nathan Bossart wrote:
> On Tue, Jul 25, 2023 at 04:24:26PM -0700, Nathan Bossart wrote:
>> I started taking a look at this and ended up adding to_binary() and a
>> bigint version of to_oct() for completeness. While I was at it, I mo
On Tue, Jul 25, 2023 at 04:24:26PM -0700, Nathan Bossart wrote:
> I started taking a look at this and ended up adding to_binary() and a
> bigint version of to_oct() for completeness. While I was at it, I moved
> the base-conversion logic out to a separate static function that
> to_bi
ew places, and I wonder if it might
deserve a comment.
I haven't had a chance to try out your benchmark, but I'm hoping to do so
in the near future.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ion that
to_binary/oct/hex all use.
>From the other discussion referenced upthread, it sounds like we might want
to replace to_binary/oct/hex with a more generic base-conversion function.
Maybe we should try to do that instead.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Jul 24, 2023 at 12:00:15PM -0700, Nathan Bossart wrote:
> Here is a sketch of this approach. It required fewer #ifdefs than I was
> expecting. At the moment, this one seems like the winner to me.
Here is a polished patch set for this approach. I've also added a 0004
that re
Given the infrequency of complaints, I'm inclined to apply
>> the more thorough fix only in HEAD, and to just raise MAX_TOKEN
>> in the back branches. Thoughts?
>>
>
> It makes sense to change it only in HEAD.
I wouldn't be opposed to back-patching the more thorough fix, but I don't
feel too strongly about it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, Jul 22, 2023 at 10:57:03PM -0700, Nathan Bossart wrote:
> On Sat, Jul 22, 2023 at 07:47:50PM -0400, Tom Lane wrote:
>> I wonder whether we can't provide some alternate definition or "skin"
>> for binaryheap that preserves the Datum API for backend code that wants
On Sat, Jul 22, 2023 at 07:47:50PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I first tried modifying
>> binaryheap to use "int" or "void *" instead, but that ended up requiring
>> some rather invasive changes in backend code, not to mention
On Sat, Jul 22, 2023 at 04:19:41PM -0700, Nathan Bossart wrote:
> In v3, I moved the Datum definitions to c.h. I first tried modifying
> binaryheap to use "int" or "void *" instead, but that ended up requiring
> some rather invasive changes in backend code,
On Thu, Jul 20, 2023 at 12:06:44PM -0700, Nathan Bossart wrote:
> Here is a work-in-progress patch set for converting ready_list to a
> priority queue. On my machine, Tom's 100k-table example [0] takes 11.5
> minutes without these patches and 1.5 minutes with them.
>
> One ite
in postgres.h and aren't available to frontend
code. I think we'll either need to move the Datum definitions to c.h or to
adjust binaryheap to use "void *".
[0] https://postgr.es/m/3612876.1689443232%40sss.pgh.pa.us
--
Nathan Bossart
Amazon Web Services: https://aws.amazon
On Fri, Jun 30, 2023 at 11:25:57AM -0700, Nathan Bossart wrote:
> I think these patches are in decent shape, so I'd like to commit them soon,
> but I will wait at least a couple more weeks in case anyone has additional
> feedback.
Committed.
--
Nathan Bossart
Amazon Web Servic
On Wed, Jun 28, 2023 at 10:24:09PM -0700, Nathan Bossart wrote:
> On Wed, Jun 28, 2023 at 09:20:03PM -0700, Gurjeet Singh wrote:
>> The comment on top of connect_utils.c:connectDatabase() seems pertinent:
>>
>>> (Callers should not pass
>>> * allow_passwo
On Tue, Jul 18, 2023 at 06:05:11PM +0200, Alvaro Herrera wrote:
> On 2023-Jul-17, Nathan Bossart wrote:
>
>> @@ -35,7 +42,11 @@ binaryheap_allocate(int capacity, binaryheap_comparator
>> compare, void *arg)
>> binaryheap *heap;
>>
>> sz = offsetof(
On Sun, Jul 16, 2023 at 08:54:24PM -0700, Nathan Bossart wrote:
> This seems worth a try. IIUC you are suggesting making binaryheap.c
> frontend-friendly and expanding its API a bit. If no one has volunteered,
> I could probably hack something together.
I spent some time on the b
views (drive-by, at least) but without any real ask for any
> changes to be made.
LGTM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Jun 28, 2023 at 10:24:09PM -0700, Nathan Bossart wrote:
> On Wed, Jun 28, 2023 at 09:20:03PM -0700, Gurjeet Singh wrote:
>> The comment on top of connect_utils.c:connectDatabase() seems pertinent:
>>
>>> (Callers should not pass
>>> * allow_passwo
artup scripts etc.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Hence, I
> remain +1 for the latest Davis proposal.
I concur.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ing making binaryheap.c
frontend-friendly and expanding its API a bit. If no one has volunteered,
I could probably hack something together.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Jul 10, 2023 at 03:43:07PM +0900, Michael Paquier wrote:
> On Wed, Jul 05, 2023 at 08:49:26PM -0700, Nathan Bossart wrote:
>> On Thu, Jul 06, 2023 at 08:21:18AM +0900, Michael Paquier wrote:
>>> Removing the GUC from this table is kind of annoying. Cannot this b
On Fri, Jul 14, 2023 at 02:02:28PM +0900, Michael Paquier wrote:
> Objection withdrawn.
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
h: hint: Try "pgbench --help" for more information.
~$ pg_restore a b c
pg_restore: error: too many command-line arguments (first is "b")
pg_restore: hint: Try "pg_restore --help" for more information.
Yet pg_ctl gives:
~$ pg_ctl st
On Wed, Jul 12, 2023 at 09:37:57PM -0700, Nathan Bossart wrote:
> On Mon, Jul 10, 2023 at 01:49:55PM -0700, Nathan Bossart wrote:
>> Great. I'm going to wait a few more days in case anyone has additional
>> feedback, but otherwise I intend to commit this shortly.
>
> I've c
-- 8<
> -
> [04:56:07.404] stderr:
> [04:56:07.404] pg_ctl: too many command-line arguments (first is "-D")
Assuming you are referring to [0], it looks like you are missing 411b720.
[0] https://github.com/michaelpq/postgres/commits/getopt_test
--
On Mon, Jul 10, 2023 at 01:49:55PM -0700, Nathan Bossart wrote:
> Great. I'm going to wait a few more days in case anyone has additional
> feedback, but otherwise I intend to commit this shortly.
I've committed 0001 for now. I'm hoping to commit the other two patches
within the next
On Tue, Jul 11, 2023 at 09:32:32AM -0700, Nathan Bossart wrote:
> Sure. І did it this way in v7.
After a couple more small edits, I've committed this. I looked through all
uses of getopt_long() in PostgreSQL earlier today, and of the programs that
accepted non-options, most accepted only
On Wed, Jul 12, 2023 at 12:43:14AM +0200, Daniel Gustafsson wrote:
> I did have coffee before now, but only found time to actually address this now
> so here is a v7 with just that change and a fresh rebase.
Thanks. I think the patch is in decent shape.
--
Nathan Bossart
Amazon Web Se
d
> place. This is mainly because a lone hyphen is less common than words
> that starts with characters other than a pyphen.
Sure. І did it this way in v7.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 7c978c11c8012cbfa67646bfc37849cb061f4e07 Mon Sep 17 00:00:00 2001
Fr
On Mon, Jul 10, 2023 at 04:43:23PM +0200, Daniel Gustafsson wrote:
>> On 8 Jul 2023, at 23:43, Nathan Bossart wrote:
>> Since "script" will be NULL and "db_used" will be false in the first
>> iteration of the loop, couldn't we move this stuff to before the lo
On Mon, Jul 10, 2023 at 04:46:07PM -0400, Joseph Koshakow wrote:
> Thanks, I think the patch set looks good to go!
Great. I'm going to wait a few more days in case anyone has additional
feedback, but otherwise I intend to commit this shortly.
--
Nathan Bossart
Amazon Web Services: ht
an take up any
changes for it in the other thread.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 691c7a30d86385cca33a7ac43a5d63c4bc39dae1 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Sun, 9 Jul 2023 11:28:56 -0700
Subject: [PATCH v6 1/3] Rename session_auth_is_superuser to
Here's a new version of the patch with the latest feedback addressed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From e662a1b6b73c92ff7862444e092406ed82b0c2c7 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 7 Jul 2023 20:00:47 -0700
Subject: [PATCH v6 1/1] Te
ll give it another try.
>> if (!force_nonopt ... )
>> {
>> if (place[1] == '-' && place[2] == 0)
>> {
>> optind+;
>> force_nonopt = true;
>> continue;
>> }
>> break;
>> }
>
> (To be honest, I see t
On Mon, Jul 10, 2023 at 03:43:07PM +0900, Michael Paquier wrote:
> Thanks. Reading through the patch, this version should be able to
> handle the dump reloads.
Thanks for reviewing. I'm currently planning to commit this sometime next
week.
--
Nathan Bossart
Amazon Web Services:
On Mon, Jul 10, 2023 at 10:12:36AM +0200, Daniel Gustafsson wrote:
> Have you had any chance to revisit this such that there is a new patch to
> review, or should it be returned/moved for now?
Not yet. I moved it to the next commitfest.
--
Nathan Bossart
Amazon Web Services:
On Sat, Jul 08, 2023 at 07:08:35PM -0400, Joseph Koshakow wrote:
> On Sat, Jul 8, 2023 at 6:09 PM Nathan Bossart
> wrote:
>
>>> I think the issue here is that if a session loses the ability to set
>>> their session authorization in the middle of a transac
ion handling to know why
> there would be a difference there.
I haven't had a chance to dig into this one yet, but that is indeed
interesting.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Thanks for the new patch.
On Thu, Jul 06, 2023 at 05:58:33PM +0200, Daniel Gustafsson wrote:
>> On 4 Jul 2023, at 21:08, Nathan Bossart wrote:
>> Also, I think it would be worth breaking check_for_data_types_usage() into
>> a few separate functions (or doing some other s
I spent some time tidying up the patch and adding a more detailed commit
message.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 2525e6aed066fe8eafdaab0d33c8c5df055c7e09 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 7 Jul 2023 20:00:47 -0700
Subject: [PATCH v
On Fri, Jul 07, 2023 at 09:57:10AM -0700, Nathan Bossart wrote:
> Yeah, I guess I should just revert it in both. Given your fix will
> hopefully be committed soon, I was hoping to avoid reverting and
> un-reverting in quick succession to prevent affecting git-blame too much.
>
On Fri, Jul 07, 2023 at 09:22:22AM -0700, Jeff Davis wrote:
> On Thu, 2023-07-06 at 22:14 -0700, Nathan Bossart wrote:
>> Since we are only reverting from v16, the REL_16_STABLE catversion
>> will be
>> bumped ahead of the one on master.
>
> I don't object to you doing
mp; $old_version < 16)
+ if ($old_version >= 14 && $old_version < 17)
{
# Fix up some privilege-set discrepancies.
$dump =~
On Thu, Jul 06, 2023 at 10:20:04AM -0700, Nathan Bossart wrote:
> On Thu, Jul 06, 2023 at 12
ch I think still makes sense,
so I left it there. That might be why it looks like I removed it.
> Also remember to bump the catversion. Other than that, it looks good to
> me.
Will do.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ood catch.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From ba8f57f2e15bcf9c147c25496f5ea7dba211fefb Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 30 Jun 2023 12:46:08 -0700
Subject: [PATCH v4 1/1] remove db_user_namespace
---
doc/src/sgml/client-auth.sgml
ump the pgsql-general thread next week to give
folks one more opportunity to object.
[0] https://postgr.es/m/20230630215608.GD2941194%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 3d46751ec7fa55d2ab776a9cb47533fe77ab0739 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
I put together a rebased version of the patch for cfbot.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From ee5805dc450f081b77ae3a7df315ceafb6ccc5e1 Mon Sep 17 00:00:00 2001
From: Daniel Gustafsson
Date: Mon, 13 Mar 2023 14:46:24 +0100
Subject: [PATCH v4 1/1] pg_upgrade:
On Tue, Jul 04, 2023 at 09:48:23AM +0200, Daniel Gustafsson wrote:
>> On 17 Mar 2023, at 10:16, Amit Kapila wrote:
>
>> Few minor comments:
>
> Have you had a chance to address the comments raised by Amit in this thread?
Not yet, sorry.
--
Nathan Bossart
Amazo
On Tue, Jul 04, 2023 at 09:30:43AM +0200, Daniel Gustafsson wrote:
>> On 4 Apr 2023, at 05:36, Nathan Bossart wrote:
>>
>> I sent this one to the next commitfest and marked it as waiting-on-author
>> and targeted for v17. I'm aiming to have something that addresses the
core part of this feature might
help reviewers. As you can see, I got distracted by the complicated
threshold logic and ended up focusing my first round of review there.
[0] https://postgr.es/m/20230209172651.cfgrebpyyr72h7fv%40alvherre.pgsql
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
orry, I'm not following. Which constant are you referring to?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
macro with the same value.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
patch.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
rrived too late and that MAINTAIN is unacceptable without commit 05e1737. I
> think you'd conform to all objections by pushing the revert to v16 and pushing
> a roll-forward of commit 05e1737 to master.
Okay, I'll adjust my plans accordingly.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
at thread [0] sit for a while.
[0] https://postgr.es/m/20230630215608.GD2941194%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jun 30, 2023 at 05:40:18PM -0400, Tom Lane wrote:
> Might be worth asking on pgsql-general whether anyone knows of
> active use of this feature. If not, I'm good with killing it.
Will do.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jun 30, 2023 at 05:29:04PM -0400, Bruce Momjian wrote:
> I am the original author, and it was a hack designed to support
> per-database user names. I am fine with its removal.
Thanks, Bruce.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
t that we should just set
BGW_LIBLEN to MAXPGPATH directly. I'm curious what folks think about this.
I also changed the added sizeofs to use the macro for consistency with the
surrounding code.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 3760f8efd0a20f60f7eda19450f97c5b2e5d
On Fri, Jun 30, 2023 at 01:05:09PM -0700, Nathan Bossart wrote:
> The attached patch simply removes the GUC.
And here's a new version of the patch with docs that actually build.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 3b7fdd41eb429bc9bb03dcecf38126fbc63dafa3 M
.
The attached patch simply removes the GUC.
[0]
https://postgr.es/m/CAA-aLv6wnwp6Qr5fZo%2B7K%3DVSr51qFMuLsCeYvTkSF3E5qEPvqA%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 6677f4b98fd0b1bd68e07d773b04caf45cf27715 Mon Sep 17 00:00:00 2001
From: Nathan Boss
On Thu, Jun 29, 2023 at 10:09:21PM -0700, Nathan Bossart wrote:
> On Thu, Jun 29, 2023 at 08:53:56PM -0400, Tom Lane wrote:
>> I'm leaning to Robert's thought that we need to revert this for now,
>> and think harder about how to make it work cleanly and safely.
>
>
On Mon, May 15, 2023 at 12:36:51PM -0700, Nathan Bossart wrote:
> On Tue, Apr 25, 2023 at 03:18:44PM +0900, Michael Paquier wrote:
>> FWIW, I agree to hold on this stuff for v17~ once it opens for
>> business. There is no urgency here.
>
> There's still some time before we
After taking another look at this, I wonder if it'd be better to fail as
soon as we see the database or user name is too long instead of lugging
them around when authentication is destined to fail.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Jun 30, 2023 at 12:05:17PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 29 Jun 2023 13:56:38 -0700, Nathan Bossart
> wrote in
>> Sorry, I'm not following. I intentionally avoided allowing combinations of
>> --schema and --table in the patches I sent. This is th
INTAIN and pg_maintain.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 29b98518b9acecd9ca08eb3397e3d3a65e9f4431 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 29 Jun 2023 20:56:12 -0700
Subject: [PATCH v1 1/1] Revert MAINTAIN privilege and pg_maintain predefined
role.
Thi
On Wed, Jun 28, 2023 at 10:24:09PM -0700, Nathan Bossart wrote:
> On Wed, Jun 28, 2023 at 09:20:03PM -0700, Gurjeet Singh wrote:
>> Nitpicking: The patch seems to have Windows line endings, which
>> explains why my `patch` complained so loudly.
>>
>> $ patch -p1 &l
Thanks for taking a look.
On Thu, Jun 29, 2023 at 02:16:26PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 28 Jun 2023 16:24:02 -0700, Nathan Bossart
> wrote in
>> I debated also allowing users to specify different types of objects in the
>> same command (e.g., "vacuumdb --
0]) is worth
considering.
[0]
https://postgr.es/m/CAKFQuwaVJkM9u%2BqpOaom2UkPE1sz0BASF-E5amxWPxncUhm4Hw%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
trailing CRs from patch; use --binary to disable.)
> patching file src/bin/scripts/reindexdb.c
>
> $ file v1-0001-harmonize-password-reuse-in-vacuumdb-clusterdb-an.patch
> v1-0001-harmonize-patch: unified diff output text, ASCII text,
> with CRLF line terminators
Huh. I didn't
801 - 900 of 1957 matches
Mail list logo
