This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
This entry has been waiting on author input for a while (our current
threshold is roughly two weeks), so I've marked it Returned with
Feedback.
Once you think the patchset is ready for review again, you (or any
interested party) can resurrect the patch entry by visiting
On 8/1/22 08:40, Jacob Champion wrote:
> I've just closed out the July commitfest. I'll be working to clear out
> all remaining active patches today.
"Today" was slightly optimistic. I'm down to the final stretch of forty
patches; I'll come back to those tomorrow with fresh eyes.
--Jacob
On Mon, Aug 1, 2022 at 10:34 AM Alvaro Herrera wrote:
> On 2022-Aug-01, Tom Lane wrote:
> > Thanks for all your hard work on this! An active CFM really makes
> > things work better.
>
> Agreed, great work here.
Thanks, both of you!
> I hate to suggest even more work, but it would be excellent
On 5/13/22 05:35, Bharath Rupireddy wrote:
> Hi, I'm thinking out loud - can we add all the recycled WAL files to a
> sorted list (oldest recycled WAL file to new recycled WAL file) and
> then during checkpoint, if the max_wal_size is reduced or wal_recycle
> is set to off, then start deleting the
On 5/31/22 11:44, Tomas Vondra wrote:
> I'd argue this is either just noise, and there's no actual difference.
> This could be verified by some sort of statistical testing (e.g. the
> well known t-test).
Given the conversation so far, I'll go ahead and mark this Returned with
Feedback.
On 7/13/22 12:49, Tom Lane wrote:
> Nathan Bossart writes:
>> Given the discussion in this thread, I intend to mark the commitfest entry
>> as Withdrawn shortly.
I'll mark this RwF rather than bring it forward; if you'd prefer a
different status please feel free (or let me know).
Thanks,
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
As discussed in [1], we're taking this opportunity to return some
patchsets that don't appear to be getting enough reviewer interest.
This is not a rejection, since we don't necessarily think there's
anything unacceptable about the entry, but it differs from a standard
"Returned with Feedback" in
On 8/1/22 09:33, Robert Haas wrote:
> We really need to move to a system where it's the patch author's job
> to take some action if the patch is alive, rather than having the CM
> (or any other human being) pinging to find out whether it's dead.> Having the
> default action for a patch be to
On 8/1/22 08:51, Justin Pryzby wrote:
> @Jacob: Is there any reason why it's necessary to do anything at all ?
> Does something bad happen if the patches are left in the current CF ?
> Why make not let patch authors (re) submit the patch for review when they're
> ready? Someone went to the effort
Hi all,
I've just closed out the July commitfest. I'll be working to clear out
all remaining active patches today.
Final statistics:
Needs review: 142
Waiting on Author: 44
Ready for Committer: 19
Committed: 76
Moved to next CF: 6
Returned
On 7/22/22 16:03, Jacob Champion wrote:
> On 7/15/22 16:42, Jacob Champion wrote:
>> On 7/8/22 16:42, Jacob Champion wrote:
>>> On 7/1/22 08:08, Jacob Champion wrote:
>>>> It's been July everywhere on Earth for a few hours, so the July
>>>> commitfe
Hi Julien,
On Thu, Jul 28, 2022 at 11:38 PM Julien Rouhaud wrote:
> > - Add extra statistics to explain for Nested Loop
> > https://commitfest.postgresql.org/38/2765/
> >
> > [...]
>
> As I mentioned in [1], this patch breaks the current assumption that
> INSTRUMENT_ALL will lead to
On Thu, Jul 28, 2022 at 2:51 PM Tom Lane wrote:
> > - Fix behavior of geo_ops when NaN is involved
> > https://commitfest.postgresql.org/38/2710/
>
> > Stuck in a half-committed state, which is tricky. Could maybe use a
> > reframing or recap (or a new thread?).
>
> We fixed a couple of easy
Hello,
Part 2 should include entries four commitfests and older. (For the rest,
it's probably too early to call something "stalled", so I don't plan to
do any more triage there.) Patch authors CC'd.
= Stalled Patches, Recommend Return =
I plan to return these with a note saying "needs more
Hi,
Next up is the large list of Needs Review. This part 1 should include
entries as old or older than seven commitfests running.
My heuristics for classifying these continue to evolve as I go, and
there's a lot to read, so please let me know if I've made any mistakes.
= Stalled Patches,
This needs a rebase, but after that I expect it to be RfC.
--Jacob
The new status of this patch is: Waiting on Author
On Thu, Jul 21, 2022 at 4:29 PM Jacob Champion wrote:
> v4 attempts to fix this by letting the check hooks pass
> MCXT_ALLOC_NO_OOM to pg_clean_ascii(). (It's ignored in the frontend,
> which just mallocs.)
Ping -- should I add an open item somewhere so this isn't lost?
--Jacob
On Thu, Jul 28, 2022 at 4:46 AM Andrey Borodin wrote:
> Daniil is working on this, but currently he's on vacation.
> I think we should not mark patch as RwF and move it to next CF instead.
Is there a downside to marking it RwF, from your perspective? As
Robert pointed out upthread, it can be
On Wed, Jul 27, 2022 at 7:09 PM houzj.f...@fujitsu.com
wrote:
> Sorry, I think we don't enough time to work on this recently. So please mark
> it as RWF and
> we will get back to this in the future.
Done, thanks!
--Jacob
On Thu, Jul 28, 2022 at 8:43 AM Julien Rouhaud wrote:
> Could you send a rebased version? In the meantime I will switch the entry to
> Waiting on Author.
By request in [1] I'm marking this Returned with Feedback for now.
Whenever you're ready, you can resurrect the patch entry by visiting
On Fri, Apr 8, 2022 at 7:27 AM Amul Sul wrote:
> Attached is rebase version for the latest maste head(#891624f0ec).
Hi Amul,
I'm going through past CF triage emails today; I noticed that this
patch dropped out of the commitfest when you withdrew it in January,
but it hasn't been added back with
On 7/26/22 16:20, Justin Pryzby wrote:
> I suggest that, if you send an email when marking as RWF, to mention that the
> existing patch record can be re-opened and moved to next CF.
>
> I'm aware that people may think that this isn't always a good idea, but it's
> nice to mention that it's
On 7/26/22 13:25, Robert Haas wrote:
> I certainly have no objection to being clear about such details in the
> documentation.
Cool.
> I fear the phenomenon where
> doing anything about a problem makes you responsible for the whole
> problem. If we disclaim the ability to hide the length of
Hello all,
I'm making my way through some stalled patches in Waiting on Author. If
nothing changes by the end of this CF, I'd recommend marking these
as Returned with Feedback.
Patch authors CC'd.
- jsonpath syntax extensions
https://commitfest.postgresql.org/38/2482/
As a few people
On Tue, Jul 26, 2022 at 10:52 AM Robert Haas wrote:
> On Thu, Jul 21, 2022 at 2:30 PM Jacob Champion
> wrote:
> > A minimum padding option would fix the leak here, right? If every
> > entry is the same length then there's no information to be gained, at
> > leas
On Mon, Jul 18, 2022 at 1:44 PM Andres Freund wrote:
> ISTM that you're trying to get patches to have zero reviewers if they need
> more reviewers, because that can serve as a signal in the CF app. But to me
> that's a bad proxy.
Okay. I need to put some more thought into what it is that I
On 7/15/22 16:42, Jacob Champion wrote:
> On 7/8/22 16:42, Jacob Champion wrote:
>> On 7/1/22 08:08, Jacob Champion wrote:
>>> It's been July everywhere on Earth for a few hours, so the July
>>> commitfest is now in progress:
>>>
>>> https:/
On Wed, Jun 1, 2022 at 11:09 PM KAWAMOTO Masaya wrote:
> That sounds a nice idea. But I don't think that postgres shows in the
> EXPLAIN output why the plan is selected. Would it be appropriate to
> show that GEQO is used in EXPLAIN output?
I'm reminded of Greenplum's "Optimizer" line in its
On Wed, Jul 20, 2022 at 3:42 PM Tom Lane wrote:
> Jacob Champion writes:
> > I'm currently hardcoding an elevel of ERROR on the new guc_strdup()s,
> > because that seems to be a common case for the check hooks.
>
> Really? That's almost certainly NOT okay. As an e
On Mon, Jul 18, 2022 at 9:07 AM Robert Haas wrote:
> Even there, what can be accomplished with a feature that only encrypts
> individual column values is by nature somewhat limited. If you have a
> text column that, for one row, stores the value 'a', and for some
> other row, stores the entire
On Mon, Jul 18, 2022 at 3:53 AM Peter Eisentraut
wrote:
> Some other products make use of secure enclaves to do computations on
> (otherwise) encrypted values on the server. I don't fully know how that
> works, but I suspect that asymmetric keys can play a role in that. (I
> don't have any
On Wed, Jul 20, 2022 at 3:15 PM Tom Lane wrote:
> guc_malloc's behavior varies depending on elevel. It's *not*
> equivalent to palloc.
Right, sorry -- a better way for me to ask the question:
I'm currently hardcoding an elevel of ERROR on the new guc_strdup()s,
because that seems to be a
yte counting always agrees between the two phases, no
matter how the implementation evolves. But it's hopefully moot now.
--Jacob
From dfd76f4dbcf3834371442d593d315797762bbd11 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Tue, 19 Jul 2022 10:48:58 -0700
Subject: [PATCH v3 1/2] pg_clean_ascii():
an I'd
like...
Thanks,
--Jacob
From d99b59652f0b8479a5df0bc50357b5c4617f9fc2 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Tue, 19 Jul 2022 10:48:58 -0700
Subject: [PATCH v2 1/2] pg_clean_ascii(): escape bytes rather than lose them
Rather than replace each unprintable byte with a '?' character, replace
it with a he
[resending to list]
On 7/19/22 09:14, Andres Freund wrote:
> IMO this should replace the existing ascii escape function instead.
That will affect the existing behavior of application_name and
cluster_name; is that acceptable?
--Jacob
On Fri, Jul 15, 2022 at 4:45 PM Andres Freund wrote:
> On 2022-07-15 14:51:38 -0700, Jacob Champion wrote:
> > That seems much worse than escaping for this particular patch; if your
> > cert's Common Name is in (non-ASCII) UTF-8 then all you'll see is
> > "CN=?&q
On 7/18/22 15:32, Justin Pryzby wrote:
> On Mon, Jul 18, 2022 at 12:00:01PM -0700, Jacob Champion wrote:
>> And thank you for speaking up so quickly! It's a lot easier to undo
>> partial damage :D (Speaking of which: where is that CF update stream you
>> m
On 7/18/22 12:32, Andres Freund wrote:
> I'm not following - I'm talking about the patch author needing a while to
> address the higher level feedback given by a reviewer. The author might put
> out a couple new versions, which each might still benefit from review. In that
> - pretty common imo -
[dev hat]
On 7/15/22 18:07, Andres Freund wrote:
> IDK, I've plenty times given feedback and it took months till it all was
> implemented. What's the point of doing further rounds of review until then?
I guess I would wonder why we're optimizing for that case. Is it helpful
for that patch to
On 7/17/22 08:17, Nathan Bossart wrote:
> On Fri, Jul 15, 2022 at 09:37:14PM -0500, Justin Pryzby wrote:
>> I'm not suggesting to give the community regulars special treatment, but you
>> could reasonably assume that when they added themselves and then "didn't
>> remove
>> themself", it was on
On 7/15/22 19:59, Michael Paquier wrote:
> On this point, I'd like to think that a window of two weeks is a right
> balance. That's half of the commit fest, so that leaves plenty of
> time for one to answer. There is always the case where one is on
> vacations for a period longer than that, but
On 7/18/22 06:13, Justin Pryzby wrote:
> On Mon, Jul 18, 2022 at 03:05:51PM +0200, Alvaro Herrera wrote:
>> Maybe we should have two reviewers columns -- one for history-tracking
>> purposes (and commit msg credit) and another for current ones.
>
> Maybe. Or, the list of reviewers shouldn't be
state.
>> I think this may have been the goal but I don't think it actually works
>> in practice. The app refuses to let you carry a RwF patch to a new CF.
>
> I was able to do what Peter said. I don't know why the cfapp has that
> restriction, it seems like an artificial
On 7/15/22 16:42, Jacob Champion wrote:
> If you have thoughts/comments on this approach, please share them!
Okay, plenty of feedback to sift through here.
[CFM hat]
First of all: mea culpa. I unilaterally made a change that I had assumed
would be uncontroversial; it clearly was not, an
On 7/15/22 16:51, Andres Freund wrote:
> I'd make it dependent on whether there have been previous rounds of feedback
> or not. If somebody spent a good amount of time reviewing a patch previously,
> but then didn't review the newest version in the last few weeks, it doesn't
> seem useful to
On 7/15/22 16:15, Justin Pryzby wrote:
> On Fri, Jul 15, 2022 at 03:17:49PM -0700, Jacob Champion wrote:
>> Also, I would like to see us fold cfbot output into the official CF,
>> rather than do the opposite.
>
> That's been the plan for years :)
Is there something other tha
On 7/8/22 16:42, Jacob Champion wrote:
> On 7/1/22 08:08, Jacob Champion wrote:
>> It's been July everywhere on Earth for a few hours, so the July
>> commitfest is now in progress:
>>
>> https://commitfest.postgresql.org/38/
Halfway through!
We are now at
[changing the subject line, was "[Commitfest 2022-07] Begins Now"]
On Fri, Jul 15, 2022 at 1:37 AM Wenjing Zeng wrote:
> Please move the Global Temporary table to check next month, that is at 202208.
> I need more time to process the existing issue.
Hi Wenjing,
My current understanding is that
On 7/15/22 14:57, Justin Pryzby wrote:
> On Fri, Jul 08, 2022 at 02:41:52PM -0700, Jacob Champion wrote:
>
>> If there are no objections, I'll start doing that during next Friday's
>> patch sweep.
>
> I think it's fine to update the cfapp fields to reflect reality...
>
On 7/15/22 14:19, Andres Freund wrote:
> On 2022-07-15 14:01:53 -0700, Jacob Champion wrote:
>> On 7/15/22 13:35, Andres Freund wrote:
>>> I don't know, but I don't think not caring at all is a good
>>> option. Particularly for unauthenticated data I'd say th
On 7/15/22 13:35, Andres Freund wrote:
>> (And do we want to fix it now, regardless?)
>
> Yes.
Cool. I can get on board with that.
>> What guarantees are we supposed to be making for log encoding?
>
> I don't know, but I don't think not caring at all is a good
> option. Particularly for
On 7/15/22 12:11, Andres Freund wrote:
> This might have been discussed somewhere, but I'm worried about emitting
> unescaped data from pre-auth clients. What guarantees that subject / issuer
> name only contain printable ascii-chars? Printing terminal control chars or
> such would not be great,
On 7/12/22 11:29, Peter Eisentraut wrote:
>
> Updated patch, to resolve some merge conflicts.
Thank you for working on this; it's an exciting feature.
> The CEK key
> material is in turn encrypted by an assymmetric key called the column
> master key (CMK).
I'm not yet understanding
On 7/15/22 09:34, Peter Eisentraut wrote:
> Committed like that.
Thanks for all the reviews!
--Jacob
On Thu, Jul 14, 2022 at 1:12 PM Peter Eisentraut
wrote:
> Concretely, I was thinking like the attached top-up patch.
>
> The other way can surely be made to work somehow, but this seems much
> simpler and with fewer questions about the details.
Ah, seeing it side-by-side helps. That's much
On Mon, Jul 11, 2022 at 6:09 AM Peter Eisentraut
wrote:
> I squashed those two together. I also adjusted the error message a bit
> more for project style. (We can put both lines into detail.)
Oh, okay. Log parsers don't have any issues with that?
> I had to read up on this "ex_data" API.
On Sat, Jul 9, 2022 at 6:49 AM Graham Leggett wrote:
> Please don’t invent another format, or try and truncate the data. This is a
> huge headache when troubleshooting.
I hear you, and I agree that correlating these things across machines
is something we should be making easier. I'm just not
On 7/1/22 08:08, Jacob Champion wrote:
> It's been July everywhere on Earth for a few hours, so the July
> commitfest is now in progress:
>
> https://commitfest.postgresql.org/38/
One week down, three to go.
I forgot to put the overall status in the last email. We start
On 3/31/22 07:37, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Mar 31, 2022 at 10:11 AM Tom Lane wrote:
>>> ... Would it be feasible or reasonable
>>> to drop reviewers if they've not commented in the thread in X amount
>>> of time?
>
>> In theory, this might cause someone who made a
up to the
final ereport(ERROR), using errdetail() and errhint(). I can squash it
into 0001 if you like it, or drop it if you don't. (This approach
could be adapted to the client, too.)
Thanks!
--Jacob
commit 7489e52168b76df3a84c68d79fb22651a05a0c05
Author: Jacob Champion
Date: Fri Jul 8 09:19:
On 4/8/22 05:21, Stephen Frost wrote:
> Added a few more tests and updated the documentation too. Sadly, seems
> we've missed the deadline for v15 though for lack of feedback on these.
> Would really like to get some other folks commenting as these are new
> pg_hba and postgresql.conf options
On Mon, Mar 28, 2022 at 11:07 PM Kyotaro Horiguchi
wrote:
>
> Rebased.
Unfortunately this will need another rebase over latest.
[CFM hat] Looking through the history here, this has been bumped to
Ready for Committer a few times and then bumped back to Needs Review
after a required rebase.
On Thu, Mar 31, 2022 at 2:36 AM Kyotaro Horiguchi
wrote:
>
> At Thu, 31 Mar 2022 18:33:18 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > I don't think this can be commited to 15. So I post the fixed version
> > then move this to the next CF.
>
> Then done. Thanks!
Hello! This patchset will need
On Thu, Apr 7, 2022 at 11:29 AM Marko Tiikkaja wrote:
> I can help with review and/or other work here. Please give me a
> couple of weeks.
Hi Marko, did you get a chance to pick up this patchset? If not, no
worries; I can mark this RwF and we can try again in a future
commitfest.
Thanks,
On Thu, Mar 31, 2022 at 11:53 PM Kyotaro Horiguchi
wrote:
> So this is that. v5 creates a regular snapshot.
This patch will need a quick rebase over 905c020bef9, which added
`extern` to several missing locations.
Thanks,
--Jacob
On Thu, Jun 30, 2022 at 11:23 PM Amit Langote wrote:
>
> I will continue investigating what to do about points (1) and (2)
> mentioned above and see if we can do away with using SQL in the
> remaining cases.
Hi Amit, looks like isolation tests are failing in cfbot:
On Wed, Jun 15, 2022 at 3:45 AM Christoph Heiss
wrote:
> `make check-world` reports no regressions.
cfbot is reporting a crash in contrib/btree_gist:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/38/3686
Thanks,
--Jacob
On Fri, May 27, 2022 at 1:09 AM Amit Langote wrote:
> 0001 contains the mechanical changes of moving PartitionPruneInfo out
> of Append/MergeAppend into a list in PlannedStmt.
>
> 0002 is the main patch to "Optimize AcquireExecutorLocks() by locking
> only unpruned partitions".
This patchset
On Fri, Jul 1, 2022 at 1:51 PM Jacob Champion wrote:
> Sorry for the misunderstanding! v3 adds the Issuer to the logs as well.
Resending v3; I messed up the certificate diff with my gitconfig.
--Jacob
From 8d03e043cd86ec81dfb49a138e871c5ac110dc06 Mon Sep 17 00:00:00 2001
From: Jacob Champ
On Thu, Jun 30, 2022 at 2:54 AM Graham Leggett wrote:
>
> I added this to httpd a while back:
>
> SSL_CLIENT_CERT_RFC4523_CEA
>
> It would be good to interoperate.
What kind of interoperation did you have in mind? Are there existing
tools that want to scrape this information for observability?
On Thu, Jun 30, 2022 at 2:43 AM Peter Eisentraut
wrote:
>
> On 13.05.22 00:36, Jacob Champion wrote:
> > v2 limits the maximum subject length and adds the serial number to the
> > logs.
>
> I wrote that pg_stat_ssl uses the *issuer* plus serial number to
> identify a ce
Hello!
It's been July everywhere on Earth for a few hours, so the July
commitfest is now in progress:
https://commitfest.postgresql.org/38/
New patches may be registered for the next commitfest in September.
Pick some patches to review and have fun!
Happy hacking,
--Jacob
' && $digit2 >= '0' && $digit3 >= '0')
|| ($digit1 >= '1' && $digit2 >= '1' && $digit3 >= '0'))
From e16a23b9cd2a2600f45636ca399d6239329f23c8 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Fri, 24 Jun 2022 15:40:42 -0700
Sub
On Wed, Jun 29, 2022 at 9:04 PM Nikolay Shaplov wrote:
> В письме от четверг, 30 июня 2022 г. 06:47:48 MSK пользователь Nikolay Shaplov
> написал:
>
> > Hi! I am surely feel this patch is important. I have bigger patch
> > https://commitfest.postgresql.org/38/3536/ and this test makes sense as a
On 3/3/22 13:20, Andres Freund wrote:
> On 2022-03-03 16:07:37 -0500, Robert Haas wrote:
>> I agree that the feature is desirable, but I think getting there is
>> going to require a huge amount of effort that may amount to a total
>> rewrite of the patch.
>
> Agreed. I think this needs very
On 5/12/22 01:46, Etsuro Fujita wrote:
> On Wed, May 11, 2022 at 7:39 PM Etsuro Fujita wrote:
>> I’m planning to commit this as a follow-up patch for commit 04e706d42.
>
> Done.
FYI, I think cfbot is confused about the patch under review here. (When
I first opened the thread I thought the patch
Justin Pryzby wrote:
> I'm planning to close this patch until someone can shepherd it.
I've marked it RwF for now.
--Jacob
Hello all,
I'll be opening the July Commitfest in approximately 24 hours, so you
have a little more time to register any patchsets you'd like the
community to review. And remember to keep your review karma positive:
over the next month, try to review other patches of equivalent
complexity to the
This patch is hanging open in the March commitfest. There was a bit of
back-and-forth on whether it should be rejected, but no clear statement on the
issue, so I'm going to mark it Returned with Feedback. If you still feel
strongly about this patch, please feel free to re-register it in the
On 4/8/22 10:04, Joshua Brindle wrote:
> It's unclear if I will be able to continue working on this featureset,
> this email address will be inactive after today.
I'm assuming the answer to this was "no". Is there any interest out
there to pick this up for the July CF?
--Jacob
On Mon, Jun 27, 2022 at 12:05 PM Jacob Champion wrote:
> v5 adds a second patch which implements a client-certificate analogue
> to gssencmode; I've named it sslcertmode.
...and v6 fixes check-world, because I always forget about postgres_fdw.
--Jacob
diff --git a/contrib/postgres_fdw/ex
On Fri, Jun 24, 2022 at 12:17 PM Jacob Champion wrote:
> Both NOT (via ! negation) and "none" are implemented in v4.
v5 adds a second patch which implements a client-certificate analogue
to gssencmode; I've named it sslcertmode. This takes the place of the
require_auth=[!
Hi all,
Just a reminder that the July 2022 commitfest will begin this coming
Friday, July 1. I'll send out reminders this week to get your patches
registered/rebased, and I'll be updating stale statuses in the CF app.
Thanks,
--Jacob
On Thu, Jun 23, 2022 at 10:33 AM Jacob Champion wrote:
> - I think NOT is a important case in practice, which is effectively a
> negative OR ("anything but this/these")
Both NOT (via ! negation) and "none" are implemented in v4.
Examples:
# The server must use SCRAM.
On Wed, Jun 22, 2022 at 5:56 PM David G. Johnston
wrote:
> That just makes me want to not implement OR'ing...
>
> The existing set of individual parameters doesn't work as an API for
> try-and-fallback.
>
> Something like would be less problematic when it comes to setting multiple
> related
eplacement
connection option, fixes the bugs/suggestions pointed out upthread,
and adds a documentation first draft. I tried combining this with the
NOT work but it was too much to juggle, so that'll wait for a v4+,
along with require_auth=none and "cert mode".
Thanks for the detailed review!
--Jac
On Wed, Jun 22, 2022 at 9:26 AM Joe Conway wrote:
> On 6/22/22 11:35, Jacob Champion wrote:
> > On Wed, Jun 22, 2022 at 8:10 AM Joe Conway wrote:
> Why would you want to do it differently than
> SessionUserId/OuterUserId/CurrentUserId? It is analogous, no?
Like I said, no
On Wed, Jun 22, 2022 at 8:10 AM Joe Conway wrote:
> On the contrary, I would argue that not having the identifier for the
> external "user" available is a security concern. Ideally you want to be
> able to trace actions inside Postgres to the actual user that invoked them.
If auditing is also
401 - 500 of 820 matches
Mail list logo
