On Wed, Dec 7, 2022 at 3:22 PM Andrey Chudnovsky
wrote:
>
>> I think it's okay to have the extension and HBA collaborate to
>> provide discovery information. Your proposal goes further than
>> that, though, and makes the server aware of the chosen client flow.
>> That appears to be an architectur
Hi,
TImescale makes use of inheritance in its partitioning implementation,
so we can't make use of the publish_via_partition_root publication
option during logical replication. We don't guarantee that the exact
same partitions exist on both sides, so that's a major roadblock for
our implementing l
On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
> The distinction that Theme+Security would make is that capabilities
> can be categorized by the area of the system:
> -- planner
> -- replication
> -- logging
> ...
> but also by the security implications of what is being done:
> --
On 12/31/22 06:17, Peter Eisentraut wrote:
> On 21.12.22 06:46, Peter Eisentraut wrote:
>> And another update. The main changes are that I added an 'unspecified'
>> CMK algorithm, which indicates that the external KMS knows what it is
>> but the database system doesn't. This was discussed a whi
On Wed, Jan 18, 2023 at 7:16 PM Greg Stark wrote:
> I had a conversation a while back with Heikki where he expressed that
> it was annoying that we negotiate SSL/TLS the way we do since it
> introduces an extra round trip. Aside from the performance
> optimization I think accepting standard TLS co
On 1/10/23 11:36, Jacob Champion wrote:
> 1) I'm playing around with a marker in pg_inherits, where the inhseqno
> is set to a sentinel value (0) for an inheritance relationship that
> has been marked for logical publication. The intent is that the
> pg_inherits helpers wil
On Fri, Jan 20, 2023 at 11:09 AM Jim Jones wrote:
> Well, I am not suggesting to change the current behavior of PostgreSQL in
> that matter. Quite the contrary, I find this feature very convenient,
> specially when you need to deal with many different clusters. What I am
> proposing is rather the
On Mon, Jan 23, 2023 at 8:35 AM Robert Haas wrote:
> I will admit that this is not an open-and-shut case, because a
> passwordless login back to the bootstrap superuser account from the
> local machine is a pretty common scenario and doesn't feel
> intrinsically unreasonable to me, and I hadn't th
On Sat, Jan 21, 2023 at 4:35 AM Jim Jones wrote:
> Well, I see there is indeed a significant overlap between our patches -
> but yours has a much more comprehensive approach! If I got it right,
> the new slcertmode=disable would indeed cancel the existing certs in
> '~/.postgresql/ in case they ex
On 1/23/23 11:05, Andres Freund wrote:
> There's not enough documentation for SYSTEM_USER imo.
If we were to make use of SYSTEM_USER programmatically (and based on
what Robert wrote downthread, that's probably not what's desired), I
think we'd have to make more guarantees about how it can be parse
On 1/23/23 11:52, Robert Haas wrote:
> On Mon, Jan 23, 2023 at 2:47 PM Robert Haas wrote:
>> Second, the reason why I described it as a manufactured issue is
>> because it's a bit like asking someone to stand under a ladder and
>> then complaining when they get hit in the head by a falling object.
On Tue, Jan 24, 2023 at 5:50 AM Robert Haas wrote:
> I think this has some potential, but it's pretty complex, seeming to
> require protocol extensions and having backward-compatibility problems
> and so on.
Yeah.
> What do you think about something in the spirit of a
> reverse-pg_hba.conf? The
On Wed, Jan 25, 2023 at 7:47 AM Israel Barth Rubio
wrote:
> I imagine more people might have already hit a similar situation too. While
> the
> workaround can seem a bit weird, in my very humble opinion the user/client is
> somehow still the one to blame in this case as it is providing the "wrong
On 1/24/23 12:04, Robert Haas wrote:
> I find the concept of "ambient authentication" problematic. I don't
> know exactly what you mean by it. I hope you'll tell me,
Sure: Ambient authority [1] means that something is granted access based
on some aspect of its existence that it can't remove (or ev
On Fri, Jan 27, 2023 at 12:13 PM Cary Huang wrote:
> > (Eventually I'd like to teach the server not to ask for a client
> > certificate if it's not going to use it.)
>
> If clientcert is not requested by the server, but yet the client still
> sends the certificate, the server will still verify it
On Sun, Jan 29, 2023 at 5:02 AM Jim Jones wrote:
> On 27.01.23 21:13, Cary Huang wrote:
> > But, if the server does request clientcert but client uses
> "sslcertmode=disable" to connect and not give a certificate, it would
> also result in authentication failure. In this case, we actually would
>
On Fri, Jan 27, 2023 at 1:08 PM Robert Haas wrote:
> > 1) Forwarding the original ambient context along with the request, so
> > the server can check it too.
>
> Right, so a protocol extension. Reasonable idea, but a big lift. Not
> only do you need everyone to be running a new enough version of
>
On Wed, Jan 25, 2023 at 11:00 AM Peter Eisentraut
wrote:
> > When writing the paragraph on RSA-OAEP I was reminded that we didn't
> > really dig into the asymmetric/symmetric discussion. Assuming that most
> > first-time users will pick the builtin CMK encryption method, do we
> > still want to ha
On Tue, Jan 31, 2023 at 5:20 AM Aleksander Alekseev
wrote:
> To my knowledge there are no open questions left. I think the
> patch is as good as it will ever get.
A committer will need to decide whether they're willing to maintain
0003 or not, as mentioned with the v11 post. Which I suppose is th
On Mon, Jan 30, 2023 at 2:21 PM Robert Haas wrote:
> On Mon, Jan 30, 2023 at 4:12 PM Jacob Champion
> wrote:
> > For our case, assuming that connections have side effects, one
> > solution could be for the client to signal to the server that the
> > connection should us
On Wed, Jan 4, 2023 at 9:33 AM Jacob Champion wrote:
> Is there a good way to remind people that, hey, this exists as a
> patchset? (Other than me pinging the list every so often.)
I've withdrawn this patchset for now, but if anyone has any ideas on
where and how I can better propo
On Tue, Jan 31, 2023 at 5:26 AM Peter Eisentraut
wrote:
> See here for example:
> https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine?view=sql-server-ver15
Hm. I notice they haven't implemented more than one algorithm, so I
wonder if the
On Tue, Jan 17, 2023 at 3:18 PM Jacob Champion wrote:
> As a concrete example, Timescale's extension control file could look
> like this:
>
> default_version = '2.x.y'
> module_pathname = '$libdir/timescaledb-2.x.y'
> ...
> dump_versio
On 2/6/23 08:22, Robert Haas wrote:
> I don't think that's quite the right concept. It seems to me that the
> client is responsible for informing the server of what the situation
> is, and the server is responsible for deciding whether to allow the
> connection. In your scenario, the client is not
I
have attached here and will register in the CF.
Thanks,
--JacobFrom 75b1be5f484a28e543290e208474d3603a3270bf Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 13 Feb 2023 10:30:43 -0800
Subject: [PATCH] PQconnectPoll: poison connection on gssenc error
Currently, conn->status isn
949a5e994235a60731ff827dcfc5157007d937ca Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Fri, 18 Nov 2022 13:45:34 -0800
Subject: [PATCH] PQconnectPoll: fix unbounded authentication exchanges
A couple of code paths in CONNECTION_AWAITING_RESPONSE will eagerly read
bytes off a connection that should be closed. Don&#
On Thu, Feb 16, 2023 at 3:31 AM Jelte Fennema wrote:
>
> Patch looks good to me. Definitely an improvement over the status quo.
Thanks for the review!
> Looking at the TLS error handling though I see these two lines:
>
> && conn->allow_ssl_try/* redundant? */
> && !conn->wait_ssl_try) /* red
support.
(--with-ssl=openssl)])
2: e4d9731e1e = 2: 5de1c458b1 libpq: force sslmode=verify-full for system CAs
From 5de1c458b19dc73608b1518d87f153b733ce1921 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 24 Oct 2022 15:24:11 -0700
Subject: [PATCH v7 2/2] libpq: force sslmode=verify-full f
x27; && $digit3 >= '0')
- || ($digit1 >= '1' && $digit2 >= '1' && $digit3 >= '0'))
+ }
+
+ $self->GenerateConfigHeader('src/include/pg_config.h', \%define, 1);
3: 6c3b
On Thu, Feb 16, 2023 at 10:59 PM Michael Paquier wrote:
> I am adding Stephen Frost
> in CC to see if he has any comments about all this part of the logic
> with gssencmode.
Sounds good.
> I agree that
> PQconnectPoll() has grown beyond the point of making it easy to
> maintain. I am wondering
On Mon, Feb 20, 2023 at 2:35 PM Stephen Frost wrote:
> Having skimmed back through this thread again, I still feel that the
> direction that was originally being taken (actually support something in
> libpq and the backend, be it with libiddawc or something else or even
> our own code, and not jus
patch.gz
Description: application/gzip
0005-libpq-include-username-in-SCRAM-header.patch.gz
Description: application/gzip
0006-Implement-LDAP-SCRAM-bridge-via-auth-provider.patch.gz
Description: application/gzip
From ec9e0ae311d9bbe04610ad4abe294d23b20db268 Mon Sep 17 00:00:00 2001
From: Jacob Cha
On Fri, Mar 25, 2022 at 5:00 PM Jacob Champion wrote:
> v4 rebases over the latest version of the pluggable auth patchset
> (included as 0001-4). Note that there's a recent conflict as
> of d4781d887; use an older commit as the base (or wait for the other
> thread to be updated)
On Tue, Sep 27, 2022 at 1:51 AM Masahiko Sawada wrote:
> I think we can fix it by the attached patch but I'd like to discuss
> whether it's worth fixing it.
Whoops. So every time it's changed, we leak a little postmaster memory?
Your patch looks good to me and I see no reason not to fix it.
Tha
On Mon, Sep 26, 2022 at 6:39 PM Andrey Chudnovsky
wrote:
> For the providing token directly, that would be primarily used for
> scenarios where the same party controls both the server and the client
> side wrapper.
> I.e. The client knows how to get a token for a particular principal
> and doesn't
On 9/26/22 06:29, Drouvot, Bertrand wrote:
> Please find attached V4 taking care of Jacob's previous comments.
> + /*
> + * InitializeSystemUser should already be called once we are sure that
> + * authn_id is not NULL (means auth_method is actually valid).
> + * But keep the te
On Tue, Sep 27, 2022 at 6:14 PM Masahiko Sawada wrote:
> No. Since cluster_name is PGC_POSTMATER, we leak a little postmaster
> memory only once when starting up. application_name is PGC_USERSET but
> since we normally allocate memory in PortalMemoryContext we eventually
> can free it.
Oh, I see;
On Fri, Sep 30, 2022 at 7:47 AM Andrey Chudnovsky
wrote:
> > How should we communicate those pieces to a custom client when it's
> > passing a token directly? The easiest way I can see is for the custom
> > client to speak the OAUTHBEARER protocol directly (e.g. SASL plugin).
> > If you had to par
;),
- conn->require_auth,
-
auth_description(areq));
- }
+ if (!reason)
+ reason = auth_description(areq);
+
+ appendPQEx
On Wed, Oct 12, 2022 at 11:01 PM Michael Paquier wrote:
> One thing that would reduce the complexity of the equation is
> to drop support for tls-server-end-point in the backend in PG >= 16 as
> the versions of OpenSSL we still support on HEAD would cover
> completely tls-exporter.
Is the intent
On Wed, Oct 12, 2022 at 9:40 AM Jacob Champion wrote:
> On 10/5/22 06:33, Peter Eisentraut wrote:
> > I think it would be good to put some provisions in place here, even if
> > they are elementary. Otherwise, there will be a significant burden on
> > the person who imp
mplementation in 0002 goes all the way down to
conninfo_add_defaults(). Maybe this is overly complex. Should I just
make sslmode a derived option, via connectOptions2()?
Thanks,
--Jacob
From 14311929a443f25f5064cdb01b57fae8d575e66d Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 24 Oct 202
On Tue, Oct 25, 2022 at 4:01 AM wrote:
> Yeah I agree that not forcing verify-full when using system CAs is a
> giant foot-gun, and many will stop configuring just until it works.
>
> Is there any argument for not checking hostname when using a CA pool
> for which literally anyone can create a cer
On Tue, Oct 25, 2022 at 7:26 AM Andrew Dunstan wrote:
> I don't find too much difficulty in having one option's default depend
> on another's value, as long as it's documented.
My patch is definitely missing the documentation for that part right
now; I wanted to get feedback on the approach befor
On Mon, Aug 8, 2022 at 8:45 AM Andres Freund wrote:
> On 2022-08-08 08:37:41 -0700, Jacob Champion wrote:
> > Agreed. This probably bleeds over into the other documentation thread
> > a bit -- how do we want to communicate the subtle points to people in
> > a CF?
>
> W
On Thu, Oct 27, 2022 at 1:04 AM John Naylor
wrote:
> This does not work for me in a fresh install until running
>
> meson test --suite setup
>
> In fact, we see in
>
> https://wiki.postgresql.org/wiki/Meson
>
> meson test --suite setup --suite main
(Is there a way to declare a dependency on the s
On Thu, Oct 27, 2022 at 4:03 PM Andres Freund wrote:
> Tests can have dependencies, and they're correctly built. The problem however
> is that, for historical reasons if I understand correctly, dependencies of
> tests are automatically included in the default 'all' target. Which means if
> you jus
On Mon, Oct 31, 2022 at 8:18 AM Jehan-Guillaume de Rorthais
wrote:
> However, I'm not strictly sure who is responsible to set these statuses. The
> reviewer? The author? The commiter? The CF manager? I bet on the reviewer, but
> it seems weird a random reviewer can reject a patch on its own behalf
On Tue, Oct 25, 2022 at 1:20 PM Jacob Champion wrote:
> I wanted to get feedback on the approach before wordsmithing too
> much.
I've added this to tomorrow's CF [1]. Thomas, if you get (or already
have) a PG community username, I can add you as an author.
Thanks,
--
On Tue, Nov 1, 2022 at 5:30 AM wrote:
> Sweet. I just created an account with username `habets`.
Added!
OpenSSL 3.0.0 doesn't get along with one of my new tests:
# Failed test 'sslrootcert=system does not connect with private CA: matches'
# at /Users/admin/pgsql/src/test/ssl/t/001_sslte
On Tue, Nov 1, 2022 at 10:03 AM Jacob Champion wrote:
> I'm not familiar with "unregistered scheme" in this context and will
> need to dig in.
Unfortunately I can't reproduce with 3.0.0 on Ubuntu :(
I'm suspicious that it may be related to [1], in which cas
On Mon, Oct 31, 2022 at 1:27 PM Jonathan S. Katz wrote:
> Having a set of SCRAM secret building functions would help in a few areas:
I have mixed-to-negative feelings about this. Orthogonality with other
methods seems reasonable, except we don't really recommend that people
use those other method
A few notes:
> + else if (beresp == 'v')
> + {
> + if
> (pqGetNegotiateProtocolVersion3(conn))
> + {
> + /* We'll come back w
On Tue, Nov 1, 2022 at 10:55 AM Jacob Champion
wrote:
> On Tue, Nov 1, 2022 at 10:03 AM Jacob Champion
> wrote:
> > I'm not familiar with "unregistered scheme" in this context and will
> > need to dig in.
>
> Unfortunately I can't reproduce with 3.0.
On 10/5/22 06:23, Jelte Fennema wrote:
> In my first version of this patch, this is exactly what I did. But then
> I got this feedback from Jacob, so I changed it to reusing PGconn:
>
>> [snip]
>
> I changed it back to use PGcancelConn as per your suggestion and I
> agree that the API got bette
On Wed, 2021-04-07 at 15:32 +0200, Peter Eisentraut wrote:
> Committed like that. (Default to on, but it's easy to change if there
> are any further thoughts.)
Hi Peter,
It looks like this code needs some guards for a NULL conn->pghost. For example
when running
psql 'dbname=postgres sslmo
On Tue, 2021-06-01 at 15:38 +0300, Aleksander Alekseev wrote:
> I came across this patch and noticed that it rotted a little,
> especially after removing inheritance_planner() in 86dc9005. I
> managed to resolve the conflicts on current `master` (eb89cb43), see
> the attached patch. The code compil
On Sat, 2021-06-05 at 09:47 -0700, Zhihong Yu wrote:
> On Fri, Jun 4, 2021 at 4:14 PM Jacob Champion wrote:
> > Agreed. I'm going to double-check with Deep that the new calls
> > to table_tuple_fetch_row_version() should be projecting the full row,
> > then post an up
ay, so I don't know if this
latest rebase introduced it or not.)
Attached is a quick patch; does it work on your machine?
--Jacob
From 7a7b8904ef22212190bb988fab1ef696fe1a59de Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 14 Jun 2021 15:04:26 -0700
Subject: [PATCH] test/ssl: fix NSS se
On Wed, 2021-06-16 at 00:08 +0200, Daniel Gustafsson wrote:
> > On 15 Jun 2021, at 00:15, Jacob Champion wrote:
> > Attached is a quick patch; does it work on your machine?
>
> It does, thanks! I've included it in the attached v37 along with a few tiny
> non-function
On Wed, 2021-06-16 at 15:31 +0200, Daniel Gustafsson wrote:
> > On 16 Jun 2021, at 01:50, Jacob Champion wrote:
> > I've been tracking down reference leaks in the client. These open
> > references prevent NSS from shutting down cleanly, which then makes it
> > imposs
bably means the mechanism isn't implemented to spec.
--Jacob
[1]
https://www.postgresql.org/message-id/d1b467a78e0e36ed85a09adf979d04cf124a9d4b.ca...@vmware.com
[2] https://datatracker.ietf.org/doc/html/rfc4422
From a6a65b66cc3dc5da7219378dbadb090ff10fd42b Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Tue, 1
From 0541598e4f0bad1b9ff41a4640ec69491b393d54 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 3 May 2021 11:15:15 -0700
Subject: [PATCH 2/7] src/common: remove logging from jsonapi for shlib
The can't-happen code in jsonapi was pulling in logging code, which for
libpq is not inclu
On Fri, 2021-06-18 at 11:31 +0300, Heikki Linnakangas wrote:
> On 08/06/2021 19:37, Jacob Champion wrote:
> > We've been working on ways to expand the list of third-party auth
> > methods that Postgres provides. Some example use cases might be "I want
> > to let an
On Fri, 2021-06-18 at 13:07 +0900, Michael Paquier wrote:
> On Tue, Jun 08, 2021 at 04:37:46PM +0000, Jacob Champion wrote:
> > 1. Prep
> >
> > 0001 decouples the SASL code from the SCRAM implementation.
> > 0002 makes it possible to use common/jsonapi from the fr
On Thu, 2021-06-24 at 14:56 +0900, Michael Paquier wrote:
> Looking more closely at that, I actually find a bit crazy the
> requirement for any logging within jsonapi.c just to cope with the
> fact that json_errdetail() and report_parse_error() just want to track
> down if the caller is giving some
On Wed, 2021-06-23 at 16:38 +0900, Michael Paquier wrote:
> On Tue, Jun 22, 2021 at 10:37:29PM +0000, Jacob Champion wrote:
> > Currently, the SASL logic is tightly coupled to the SCRAM
> > implementation. This patch untangles the two, by introducing callback
> > structs for
On Sun, 2021-06-27 at 10:43 +0900, Michael Paquier wrote:
> On Sat, Jun 26, 2021 at 01:43:50PM -0400, Tom Lane wrote:
> > BTW, so far as the original topic of this thread is concerned,
> > it sounds like Jacob's ultimate goal is to put some functionality
> > into libpq that requires JSON parsing.
On Sat, 2021-06-26 at 09:36 +0900, Michael Paquier wrote:
> On Fri, Jun 25, 2021 at 08:58:46PM +0000, Jacob Champion wrote:
> > On Thu, 2021-06-24 at 14:56 +0900, Michael Paquier wrote:
> > > Looking more closely at that, I actually find a bit crazy the
> > > require
On Tue, 2021-06-29 at 14:50 -0400, Tom Lane wrote:
> Jacob Champion writes:
> > What would you think about a src/port of asprintf()? Maybe libpq
> > doesn't change quickly enough to worry about it, but having developers
> > revisit stack allocation for strings every
On Thu, 2021-03-04 at 00:03 +, Jacob Champion wrote:
> Hello all,
>
> Andrew pointed out elsewhere [1] that it's pretty difficult to add new
> certificates to the test/ssl suite without blowing away the current
> state and starting over. I needed new cases for the NSS bac
On Wed, 2021-06-30 at 11:03 -0400, Tom Lane wrote:
> It does not look to me like json_errdetail can sensibly be used in
> frontend, since it returns palloc'd strings in some paths and
> constants in others. There'd be no way to avoid a memory leak
> in a frontend usage. So I think the dependency
On Wed, 2021-06-30 at 20:20 +0200, Peter Eisentraut wrote:
> I note that popular places such as the Apache and nginx SSL/TLS modules
> just use SSL in their documentation, and they are probably under much
> more scrutiny in this area.
For Apache, that's not strictly true [1, 2]. mod_ssl and its
On Sat, 2021-06-26 at 09:47 +0900, Michael Paquier wrote:
> On Fri, Jun 25, 2021 at 11:40:33PM +0000, Jacob Champion wrote:
> > I can definitely move it (into, say, auth-sasl.c?). I'll probably do
> > that in a second commit, though, since keeping it in place during the
&g
On Wed, 2021-06-30 at 18:29 -0400, Tom Lane wrote:
> I wrote:
> > Peter Eisentraut writes:
> > > Could we set this rule up a little bit differently so that it is only
> > > run when the library is built.
> > > Right now, make world on a built tree makes 17 calls to this "nm" line,
> > > and make
On Wed, 2021-06-30 at 18:56 -0400, Tom Lane wrote:
> Jacob Champion writes:
> > On Wed, 2021-06-30 at 18:29 -0400, Tom Lane wrote:
> > > Looks like we'd have to make use of a dummy stamp-file, more or less
> > > as attached. Any objections?
> > Spitballi
Hi all,
Ashwin, Deep, and I were discussing this patch today. We agree that
it's fairly difficult to review in its current state, and the lack of a
concrete implementation of the new API isn't helping. (A big chunk of
the context for the patch exists in the zedstore megathread, which
isn't exactly
On Tue, 2021-06-08 at 17:32 +0800, Quan Zongliang wrote:
> Hi,
>
> In the KnownAssignedTransactionIdes sub-module, two lines of unused code
> were found in a previous change.
Huh. Looks like this code died as part of 2fc7af5e966?
CC'ing Thomas just in case we're missing something, but I'll mark
On Thu, 2021-07-01 at 14:14 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Somewhere in the $(shlib) rule would seem most appropriate. But I don't
> > understand the rest: What ifeq, and why .DELETE_ON_ERROR?
>
> The variant of this I'd been thinking of was
>
> $(shlib): $(OBJS) | $(SH
On Wed, 2021-06-30 at 10:42 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Jun-30, Tom Lane wrote:
> > > You mentioned __gcov_exit, but I'm not sure if we need an
> > > exception for that. I see it referenced by the individual .o
> > > files, but the completed .so has no such referen
On Fri, 2021-07-02 at 18:20 -0400, Tom Lane wrote:
> What configure options are you using?
Just `./configure --enable-coverage`, nothing else. I distclean'd right
before for good measure.
> Does "nm -u" report "exit" being referenced from any *.o in libpq,
> or from any *_shlib.o in src/port/ or
On Fri, 2021-07-02 at 18:45 -0400, Tom Lane wrote:
> Jacob Champion writes:
> > On Fri, 2021-07-02 at 18:20 -0400, Tom Lane wrote:
> > > What configure options are you using?
> > Just `./configure --enable-coverage`, nothing else. I distclean'd right
> >
On Mon, 2021-07-05 at 17:17 +0900, Michael Paquier wrote:
> On Wed, Jun 30, 2021 at 10:30:12PM +0000, Jacob Champion wrote:
> > Done in v3, with a second patch for the code motion.
>
> I have gone through that, tweaking the documentation you have added as
> that's the meat
On Wed, 2021-07-07 at 01:42 -0400, Tom Lane wrote:
> Michael Paquier writes:
> > It seems to me that this does not address yet the problems with the
> > palloc/pstrdup in jsonapi.c though, which would need to rely on
> > malloc() if we finish to use this code in libpq. I am not sure yet
> > that
On Wed, 2021-07-07 at 14:08 +0900, Michael Paquier wrote:
> On Tue, Jul 06, 2021 at 06:20:49PM +0000, Jacob Champion wrote:
> > On Mon, 2021-07-05 at 17:17 +0900, Michael Paquier wrote:
> >
> > > Hmm. Does the RFCs tell us anything about that?
> >
> > Just
On Mon, 2021-04-05 at 14:07 +0900, Kyotaro Horiguchi wrote:
> At Fri, 2 Apr 2021 11:51:26 +0200, Pavel Stehule
> wrote in
> > with this patch, the formatting is correct
>
> I think the hardest point of this issue is that we don't have a
> reasonable authoritative source that determines characte
Hi Magnus,
I'm only just starting to page this back into my head, so this is by no
means a full review of the v7 changes -- just stuff I've noticed over
the last day or so of poking around.
On Tue, 2021-06-29 at 11:48 +0200, Magnus Hagander wrote:
> On Thu, Mar 11, 2021 at 1
On Thu, 2021-07-08 at 16:27 +0900, Michael Paquier wrote:
> I agree that this looks like an improvement in terms of the
> expectations behind a SASL mechanism, so I have done the attached to
> strengthen a bit all those checks. However, I don't really see a
> point in back-patching any of that, as
On Sun, 2021-07-11 at 13:16 +0900, Michael Paquier wrote:
> On Fri, Jul 09, 2021 at 11:31:48PM +0000, Jacob Champion wrote:
> > On Thu, 2021-07-08 at 16:27 +0900, Michael Paquier wrote:
> > > + * outputlen: The length (0 or higher) of the client resp
On Mon, 2022-05-02 at 15:14 +0200, Daniel Gustafsson wrote:
> Using a pg_ prefix
> makes them sound like actual useful tools though with (albeit small) risk for
> confusion? Noah's suggestion of libpq_ is perhaps better: libpq_testclient.
+1
I also like Justin's idea of only installing the test
gth of log output used
for debugging? Maybe I should just hardcode a smaller limit and
truncate anything past that? Or we could just log the Common Name,
which should be limited to 64 bytes...
I'll add this to the July commitfest.
Thanks,
--Jacob
From e38e9afd8adfa5c39ea1f43f6c4d5b9238ec
On Tue, 2022-05-03 at 21:06 +0200, Peter Eisentraut wrote:
> The information in pg_stat_ssl is limited to NAMEDATALEN (see struct
> PgBackendSSLStatus).
>
> It might make sense to align what your patch prints to identify
> certificates with what is shown in that view.
Sure, a max length should be
On Wed, 2022-05-04 at 15:53 +0200, Peter Eisentraut wrote:
> Just saying that cutting it off appears to be acceptable. A bit more
> than 63 bytes should be okay for the log.
Gotcha.
> In terms of aligning what is printed, I meant that pg_stat_ssl uses the
> issuer plus serial number to identify
On Thu, 2022-05-05 at 15:12 +, Jacob Champion wrote:
> On Wed, 2022-05-04 at 15:53 +0200, Peter Eisentraut wrote:
> > In terms of aligning what is printed, I meant that pg_stat_ssl uses the
> > issuer plus serial number to identify the certificate unambiguously.
>
> Oh
v10 is rebased over latest; I've also added a PGDLLIMPORT to the new global.
--Jacob
From c8b3d2df4ce461fc65a27699419a54a5b7bb2001 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 14 Feb 2022 08:10:53 -0800
Subject: [PATCH v10 1/2] Add API to retrieve authn_id from SQL
The aut
On Wed, Jun 1, 2022 at 12:55 AM Michael Paquier wrote:
>
> Jacob, do you still have plans to work on this patch?
Yes, definitely. That said, the more the merrier if there are others
interested in taking a shot at it. There are a large number of
alternative implementation proposals.
Thanks,
--Jac
On Wed, Jun 1, 2022 at 1:44 PM Aleksander Alekseev
wrote:
> This is a follow-up thread to `RFC: compression dictionaries for JSONB` [1].
> I would like to share my current progress in order to get early feedback. The
> patch is currently in a draft state but implements the basic functionality. I
On Thu, Jun 2, 2022 at 6:30 AM Aleksander Alekseev
wrote:
> > I saw there was some previous discussion about dictionary size. It
> > looks like this approach would put all dictionaries into a shared OID
> > pool. Since I don't know what a "standard" use case is, is there any
> > risk of OID exhaus
On Thu, Jun 2, 2022 at 6:52 AM Robert Haas wrote:
> I'm not sure what it SHOULD be called, exactly: that's one of the hard
> problems in computer science.[1]
Yeah...
All right, here's the full list of previous suggestions, I think:
- SharedPort
- MyProcShared
- ProcParallelInfo
- ProcInfoParall
On Fri, Jun 3, 2022 at 7:36 PM Michael Paquier wrote:
>
> On Fri, Jun 03, 2022 at 10:04:12AM -0400, Tom Lane wrote:
> > I agree with Robert's complaint that Parallel is far too generic
> > a term here. Also, the fact that this data is currently in struct
> > Port seems like an artifact.
> >
> > D
401 - 500 of 1187 matches
Mail list logo
