On Fri, 2021-01-29 at 17:30 -0500, Tom Lane wrote:
> What happens if ALTER USER RENAME is done while the session is still
> alive?
IMO the authenticated identity should be write-once. Especially since
one of my goals is to have greater auditability into events as they've
actually happened. So ALTE
On Fri, 2021-01-29 at 18:40 -0500, Tom Lane wrote:
> Ah. So basically, this comes into play when you consider that some
> outside-the-database entity is your "real" authenticated identity.
> That seems reasonable when using Kerberos or the like, though it's
> not real meaningful for traditional pa
On Sun, 2021-01-31 at 12:27 +0100, Magnus Hagander wrote:
> > (There's also the fact that I think pg_ident mapping for LDAP would be
> > just as useful as it is for GSS or certs. That's for a different
> > conversation.)
>
> Specifically for search+bind, I would assume?
Even for the simple bind c
On Mon, 2021-02-01 at 11:49 -0500, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > But yes, I think the enforced cleartext password proxying is at the
> > core of the problem. LDAP also encourages the idea of centralized
> > password-reuse, which is not exactly a great thi
On Mon, 2021-02-01 at 18:44 +0100, Magnus Hagander wrote:
> What people would *really* want I think is "alow auto-creation of new
> roles, and then look up which other roles they should be members of
> using ldap" (or "using this script over here" for a more flexible
> approach). Which is of course
On Mon, 2021-02-01 at 17:01 -0500, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > And I'm not holding
> > my breath for LDAP servers to start implementing federated identity,
> > though that would be nice.
>
> Not sure exactly what
On Mon, 2021-02-01 at 18:01 -0500, Stephen Frost wrote:
> Ok.. but what's 'go' mean here? We already have views and such for GSS
> and SSL, is the idea to add another view for LDAP and add in columns
> that are returned by pg_stat_get_activity() which are then pulled out by
> that view? Or did y
On Mon, 2021-02-01 at 18:40 -0500, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > My goal is to get this one single point of reference, for all of the
> > auth backends. The LDAP mapping conversation is separate.
>
> Presumably this would be the DN
On Mon, 2021-02-01 at 21:49 +0100, Daniel Gustafsson wrote:
> > On 29 Jan 2021, at 19:46, Jacob Champion wrote:
> > I think the bad news is that the static approach will need support for
> > ENABLE_THREAD_SAFETY.
>
> I did some more reading today and noticed that th
On Mon, 2021-02-01 at 21:49 +0100, Daniel Gustafsson wrote:
> > Embedded NULLs are now handled in a similar manner to the OpenSSL side,
> > though because this failure happens during the certificate
> > authentication callback, it results in a TLS alert rather than simply
> > closing the connection
On Thu, 2021-01-28 at 18:22 +, Jacob Champion wrote:
> = Proposal =
>
> I propose that every auth method should store the string it uses to
> identify a user -- what I'll call an "authenticated identity" -- into
> one central location in Port, after authentica
On Thu, 2021-02-04 at 16:30 +0900, Michael Paquier wrote:
> On Tue, Feb 02, 2021 at 08:33:35PM +0000, Jacob Champion wrote:
> > Note that this changes the error message printed during the invalid-
> > root tests, because NSS is now sending the root of the chain. So the
> &g
resql.org/message-id/a9ee5e4e8e844d06c2bcf70c6ed3306ccb4897f1.camel%40vmware.com
From 49bc25665e1a878114d2b89bdab8fd8761e7c432 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Wed, 3 Feb 2021 11:04:42 -0800
Subject: [PATCH 1/8] test/kerberos: only search forward in logs
The log content tests
On Fri, 2021-02-05 at 15:55 -0500, Tom Lane wrote:
> We have, almost invariably, regretted it when we tried to use short
> timeouts in test cases.
That's what I was afraid of. I can work around it easily enough on my
local machine, so it's not really a blocker in any sense.
That just leaves the f
On Sat, 2021-01-30 at 16:18 -0500, Andrew Dunstan wrote:
> Here's a version of the patch that does it that way. For fun I have
> modified the certificate so it has two OU fields in the DN.
> diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
> [...]
> + Common Name (C
On Tue, 2021-02-02 at 22:22 +, Jacob Champion wrote:
> Given the feedback above, I'll continue to flesh out the PoC patch,
> focusing on 1) storing the identity in a single place for all auth
> methods and 2) exposing it consistently in the logs as part of
> log_connections.
On Mon, 2021-02-08 at 23:35 +, Jacob Champion wrote:
> Note that I haven't compiled or tested on
> Windows and BSD yet, so the SSPI and BSD auth changes are eyeballed for
> now.
I've now tested on both.
> - For the SSPI auth method, I pick the format of the identity
On Fri, 2021-12-03 at 22:32 +0100, Peter Eisentraut wrote:
> This feature does support deterministic
> encryption as an alternative to the default randomized encryption, so
> in that mode you can do equality lookups, at the cost of some
> security.
> + if (enc_det)
> +
On Tue, 2021-12-07 at 16:39 +0100, Peter Eisentraut wrote:
> On 06.12.21 21:44, Jacob Champion wrote:
> > I think reusing a zero IV will potentially leak more information than
> > just equality, depending on the cipher in use. You may be interested in
> > synthetic IVs and no
On Tue, 2021-11-23 at 18:27 +, Jacob Champion wrote:
> Now that the MITM CVEs are published [1], I wanted to share my wishlist
> of things that would have made those attacks difficult/impossible to
> pull off.
Now that we're post-commitfest, here's my summary of t
On Tue, 2021-12-07 at 22:21 +0100, Tomas Vondra wrote:
> IMO it's impossible to solve this attack within TCE, because it requires
> ensuring consistency at the row level, but TCE obviously works at column
> level only.
I was under the impression that clients already had to be modified to
figure
On Wed, 2021-12-08 at 02:58 +0100, Tomas Vondra wrote:
>
> On 12/8/21 00:26, Jacob Champion wrote:
> > On Tue, 2021-12-07 at 22:21 +0100, Tomas Vondra wrote:
> > > IMO it's impossible to solve this attack within TCE, because it requires
> > > ensuring co
should
the behavior be?
The patchset roadmap:
- 0001 moves inet_net_pton() to src/port, since libpq will need it.
- 0002 implements the new functionality and adds tests.
WDYT?
Thanks,
--Jacob
From db56d6593a4574c243ccee1dbb4c8c1f1c712795 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date:
On Thu, 2021-12-16 at 14:54 +0900, Kyotaro Horiguchi wrote:
> In RFC2828 and 6125,
>
> > In some cases, the URI is specified as an IP address rather than a
> > hostname. In this case, the iPAddress subjectAltName must be present
> > in the certificate and must exactly match the IP in the UR
On Thu, 2021-12-16 at 10:50 -0500, Andrew Dunstan wrote:
> Good job, this is certainly going to be useful.
Thanks!
> I don't think we should fall back on the CN. It would seem quite odd to
> do so for IP addresses but not for DNS names.
So there's at least one compatibility concern with disablin
On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
> > On 30 Nov 2021, at 20:03, Jacob Champion wrote:
> >
> > On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
> > > > Speaking of IP addresses in SANs, it doesn't look like our OpenSSL
>
s://www.postgresql.org/message-id/flat/1a61806047c536e7528b943d0cfe12608118ca31.ca...@vmware.com
From 2a88b8cbdbe790df55240850995852e8f2d304eb Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Thu, 2 Dec 2021 09:37:08 -0800
Subject: [PATCH 1/4] hba: correct messages when ldap_url_parse() fa
On Thu, 2021-12-09 at 11:04 +0100, Tomas Vondra wrote:
> On 12/9/21 01:12, Jacob Champion wrote:
> >
> > The rabbit hole I led you down is one where we use the rest of the row
> > as AD, to try to freeze pieces of it in place. That might(?) have some
> > useful securit
On Fri, 2021-12-10 at 15:43 +0200, Heikki Linnakangas wrote:
> ProcessStartupPacket() currently reads the first 4 bytes coming from the
> client to decide what kind of a connection it is, and I believe a TLS
> ClientHello message always begins with the same sequence of bytes, so it
> would be ea
On Fri, 2021-12-17 at 16:54 +0900, Kyotaro Horiguchi wrote:
> Sorry for the silly mistake.
>
> At Fri, 17 Dec 2021 15:40:10 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > > NSS departs slightly from the spec and will additionally try to match
> > > an IP address against the CN, but only if there
On Sun, 2022-01-02 at 13:29 -0800, Andres Freund wrote:
> Hi,
>
> On 2021-12-16 01:13:57 +0000, Jacob Champion wrote:
> > Attached is a patch for libpq to support IP addresses in the server's
> > Subject Alternative Names, which would allow admins to issue certs for
On Fri, 2021-12-17 at 10:06 +0100, Peter Eisentraut wrote:
> On 17.12.21 00:48, Jacob Champion wrote:
> > WDYT? (My responses here will be slower than usual. Hope you all have a
> > great end to the year!)
>
> Looks interesting. I wonder whether putting this into pg_ident.co
On Fri, 2021-12-24 at 14:08 +, Keith Burdis wrote:
> Has consideration been given to having something like ssl-mode=tls-
> only where the SSLRequest message is skipped and the TLS handshake
> starts immediately with the protocol continuing after that?
From an implementation standpoint, I think
On Mon, 2022-01-03 at 12:36 -0500, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > On Fri, 2021-12-17 at 10:06 +0100, Peter Eisentraut wrote:
> > > On 17.12.21 00:48, Jacob Champion wrote:
> > > > WDYT? (My responses here will be slower t
On Thu, 2021-12-16 at 18:44 +, Jacob Champion wrote:
> It sounds like both you and Andrew might be comfortable with that same
> behavior? I think it looks like a sane solution, so I'll implement that
> and we can see what it looks like. (My work on this will be paused over
>
On Mon, 2022-01-03 at 19:42 -0500, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> >
> > That last point was my motivation for the authn_id patch [1] -- so that
> > auditing could see the actual user _and_ the generic role. The
> > information
On Mon, 2022-01-03 at 16:19 +, Jacob Champion wrote:
> On Fri, 2021-12-17 at 15:40 +0900, Kyotaro Horiguchi wrote:
> >
> > + inet_net_pton_ipv4(const char *src, u_char *dst)
> > (calls inet_net_pton_ipv4_internal(src, dst, true))
> > + inet_pton_ipv4(const char *sr
On Tue, 2022-01-04 at 22:24 -0500, Stephen Frost wrote:
> On Tue, Jan 4, 2022 at 18:56 Jacob Champion wrote:
> >
> > Could you talk more about the use cases for which having the "actual
> > user" is better? From an auditing perspective I don't see why
>
On Wed, Apr 14, 2021 at 8:42 AM Dave Page wrote:
> Attached is a patch to clean this up. It will log denials as such
> regardless of whether or not either selinux or sepgsql is in
> permissive mode. When either is in permissive mode, it'll add "
> permissive=1" to the end of the log messages. e.g.
On Wed, 2021-12-22 at 09:24 +0100, Peter Eisentraut wrote:
> The fix is that we need to catch the PostgreSQL error and turn it into a
> Python exception, like we do for other places where plpy.* methods call
> into PostgreSQL internals.
Tested on Ubuntu 20.04, with 3.11.0a3 (built by hand) and 3
On Fri, 2021-03-19 at 17:21 +0900, Michael Paquier wrote:
> On Thu, Mar 18, 2021 at 05:14:24PM +0900, Michael Paquier wrote:
> > Looking at 0001, I am not much a fan of relying on the position of the
> > matching pattern in the log file. Instead of relying on the logging
> > collector and one sing
On Fri, 2021-03-19 at 16:54 +, Jacob Champion wrote:
> One additional improvement I would suggest, now that the rotation logic
> is simpler than it was in my original patch, is to rotate the logfile
> regardless of whether the test is checking the logs or not. (Similarly,
> we
On Mon, 2021-03-22 at 18:22 +0100, Magnus Hagander wrote:
> On Mon, Mar 22, 2021 at 7:16 AM Michael Paquier wrote:
> >
> > I have briefly looked at 0002 (0001 in the attached set), and it seems
> > sane to me. I still need to look at 0003 (well, now 0002) in details,
> > which is very sensible a
On Mon, 2021-03-22 at 15:16 +0900, Michael Paquier wrote:
> On Fri, Mar 19, 2021 at 06:37:05PM +0000, Jacob Champion wrote:
> > The same effect can be had by moving the log rotation to the top of the
> > test that needs it, so I've done it that way in v7.
>
> After t
On Tue, 2021-03-23 at 00:38 +0100, Daniel Gustafsson wrote:
> This rebase also includes a fix for pgtls_init which was sent offlist by
> Jacob.
> The changes in pgtls_init can potentially be used to initialize the crypto
> context for NSS to clean up this patch, Jacob is currently looking at that.
On Wed, 2021-03-24 at 09:28 +0900, Michael Paquier wrote:
> On Wed, Mar 24, 2021 at 12:05:35AM +0000, Jacob Champion wrote:
> > I can work around it temporarily for the
> > tests, but this will be a problem if any libpq clients load up multiple
> > independent databases
zation
before authentication could signal a serious bug -- but I don't feel
too strongly about it.
v10 attached, which reverts to v8 test behavior, with minor updates to
the commit message and test comment.
--Jacob
From 0b8764ac61ef37809a79ded2596c5fcd2caf25bb Mon Sep 17 00:00:00 2001
From:
On Wed, 2021-03-24 at 13:00 -0400, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > Right, but to clarify -- I was asking if *NSS* supports loading and
> > using separate certificate databases as part of its API. It seems like
> > the internals ma
On Wed, 2021-03-24 at 14:10 -0400, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > I could see this being a problem if two client certificate nicknames
> > collide across multiple in-use databases, maybe?
>
> Right, in such a case either cert might
On Thu, 2021-03-25 at 16:41 +0900, Michael Paquier wrote:
> On top of what's
> proposed, would it make sense to have a second logdetail for the case
> of a mock authentication? We don't log that yet, so I guess that it
> could be useful for audit purposes?
It looks like the code paths that lead to
thod=scram-sha-256/,
- "Basic SCRAM sets the username as the authenticated identity");
-
-$node->start;
-
# Test channel_binding
test_connect_fails(
$common_connstr,
@@ -132,7 +102,7 @@ test_connect_fails(
qr/channel binding required, but server authenticated client without
ch
On Fri, 2021-03-26 at 00:22 +0100, Daniel Gustafsson wrote:
> > On 23 Mar 2021, at 20:04, Stephen Frost wrote:
> >
> > Eh, poor wording on my part. You're right, the question, reworded
> > again, was "Would someone want to get the context returned by
> > NSS_InitContext?". If we think there's a
On Fri, 2021-03-26 at 15:33 -0400, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > Databases that are opened *after* the first one are given their own
> > separate slots. [...]
>
> This is more-or-less what we would want though, right..? I
ng for check_usermap below, because
authentication
+* has already succeeded and we want the log file to reflect
that.
*/
if (!port->peer_dn)
{
From c21a83e71d2829accf004f5b8437a6eb115b0860 Mon Sep 17 00:00:00 2001
From: Jacob Champ
On Mon, 2021-03-29 at 16:50 +0900, Michael Paquier wrote:
> On Fri, Mar 26, 2021 at 10:41:03PM +0000, Jacob Champion wrote:
> > For a few of the bugs I was tracking down, it was imperative. The tests
> > aren't isolated enough (or at all) to keep one from affecting the
>
On Tue, 2021-03-30 at 09:55 +0900, Michael Paquier wrote:
> On Mon, Mar 29, 2021 at 11:53:03PM +0000, Jacob Champion wrote:
> > It's not a matter of the tests being stable, but of the tests needing
> > to change and evolve as the implementation changes. A big part of that
&g
On Tue, 2021-03-30 at 17:06 +, Jacob Champion wrote:
> Would it be acceptable to adjust the tests for live rotation using the
> logging collector, rather than a full restart? It would unfortunately
> mean that we have to somehow wait for the rotation to complete, since
> that&#x
On Fri, 2021-03-26 at 18:05 -0400, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
> > Yeah. I was hoping to avoid implementing our own locks and refcounts,
> > but it seems like it's going to be required.
>
> Yeah, afraid so.
I think it gets wo
"$common_connstr user=yetanotheruser sslcert=ssl/client.crt
sslkey=ssl/client_tmp.key",
- "auth_option clientcert=verify-ca succeeds with mismatching username
and Common Name"
+ "auth_option clientcert=verify-ca succeeds with mismatching username
and Common N
of
> regexes. That's what 0003 is basically doing already.
Rebased on top of your patch as v19, attached. (v17 disappeared into
the ether somewhere, I think. :D)
Now that it's easy to add log_like to existing tests, I fleshed out the
LDAP tests with a few more cases. They don't
a bit in contradiction with the comments a couple of lines
> above anyway.
What do you mean by this? I took another look at the comment and it
seems to match the implementation.
v21 attached, which is just a rebase of my original v19.
--Jacob
[1]
https://www.postgresql.org/message-id/8c08c6
On Tue, 2021-04-06 at 14:15 +0900, Michael Paquier wrote:
> On Mon, Apr 05, 2021 at 04:40:41PM +0000, Jacob Champion wrote:
> > This loses the test fixes I made in my v19 [1]; some of the tests on
> > HEAD aren't testing anything anymore. I've put those fixups into 0001
On Wed, 2021-04-07 at 10:20 +0900, Michael Paquier wrote:
> Anyway, using a FATAL in this code path is fine by me at the end, so I
> have applied the patch. Let's see now what the buildfarm thinks about
> it.
Looks like the farm has gone green, after some test fixups. Thanks for
all the reviews!
On Tue, 2021-10-19 at 20:21 +0200, Daniel Gustafsson wrote:
> > On 15 Oct 2021, at 14:01, Daniel Gustafsson wrote:
> > The attached contains the requested fixes, and has been tested on all (by
> > us)
> > supported versions of OpenSSL. Unless there are objections I will apply
> > this
> > to ma
On Tue, 2021-10-26 at 18:16 -0400, Tom Lane wrote:
> Per "21.2. User Name Maps", I think that the map parameter is supposed
> to translate from the startup packet's user name to the SQL role name.
I may have misunderstood what you wrote, but IIUC the startup packet's
user name _is_ the SQL role na
On Wed, 2021-10-27 at 10:12 -0400, Andrew Dunstan wrote:
> Possibly slightly off topic, but
>
> The cert+map pattern is very useful in conjunction with pgbouncer. Using
> it with an auth query to get the password pgbouncer doesn't even need to
> have a list of users, and we in effect delegate auth
On Wed, 2021-10-27 at 12:53 -0400, Jonathan S. Katz wrote:
> The patch I propose just layers on top of the existing functionality --
> you could even argue that it's "fixing a bug" that we did not add the
> current "map" support for the case of "clientcert=verify-full" given we
> do introspect
On Tue, 2021-09-28 at 18:15 +, Jacob Champion wrote:
> | authn authz
> -+---
> envvar | PGAUTHUSERPGUSER
> conninfo | authuser user
> frontend | conn->pgauthuser conn->pguser
> backend
On Thu, 2021-11-04 at 12:03 +0100, Magnus Hagander wrote:
> Thanks for the pointer, PFA a rebase.
I think the Unix socket handling needs the same "success" fix that you
applied to the TCP socket handling above it:
> @@ -1328,9 +1364,23 @@ PostmasterMain(int argc, char *argv[])
> e
On Wed, 2021-11-17 at 14:44 -0500, Jaime Casanova wrote:
> I'm trying to add more parallelism by copying individual segments
> of a relfilenode in different processes. Does anyone one see a big
> problem in trying to do that? I'm asking because no one did it before,
> that could not be a good sign.
On Sat, 2021-11-20 at 16:16 -0500, Tom Lane wrote:
> One more point is that the proposed business about
>
> * ImpersonateDatabaseUser will either succeed silently (0-RTT), or
> fail. Upon failure, no further commands will be processed until
> ImpersonateDatabaseUser succeeds.
>
> seems to re
Hello all,
Now that the MITM CVEs are published [1], I wanted to share my wishlist
of things that would have made those attacks difficult/impossible to
pull off.
= Implicit TLS =
The frontend/backend protocol uses a STARTTLS-style negotiation, which
has had a fair number of implementation vulner
On Wed, 2021-11-17 at 14:34 -0600, Justin Pryzby wrote:
> On Wed, Nov 17, 2021 at 02:44:52PM -0500, Jaime Casanova wrote:
> >
> > - why we read()/write() at all? is not a faster way of copying the file?
> > i'm asking that because i don't actually know.
>
> No portable way. Linux has this:
> h
On Tue, 2021-11-23 at 13:51 -0600, Justin Pryzby wrote:
>
> I guess you're concerned for someone who wants to be able to run pg_upgrade
> and
> preserve the ability to start the old cluster in addition to the new.
Right. What I'm worried about is, if disk space or write performance on
the new cl
On Wed, 2021-11-24 at 09:40 -0500, Robert Haas wrote:
> I am not really persuaded by Jacob's argument that, had this only
> worked the other way from the start, this bug wouldn't have occurred.
> That's just a tautology, because we can only have bugs in the code we
> write, not the code we didn't w
On Wed, 2021-11-24 at 14:03 -0500, Tom Lane wrote:
> > I don't buy the idea that, because we have fixed that particular
> > vulnerability, we've rendered this entire class of bugs "hypothetical".
> > There will be more code and more clients. There will always be bugs.
> > I'd rather the bugs that p
On Wed, 2021-11-24 at 14:01 -0500, Robert Haas wrote:
> The bar for actually ripping it out
> on an expedited time scale would be proving not only that it's broken
> in multiple ways, but that it's so badly broken that it can't be fixed
> with any reasonable amount of effort. And I just don't see o
On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
> > Speaking of IP addresses in SANs, it doesn't look like our OpenSSL
> > backend can handle those. That's a separate conversation, but I might
> > take a look at a patch for next commitfest.
>
> Please do.
Didn't get around to it for N
On Mon, 2021-11-08 at 15:32 -0500, Stephen Frost wrote:
> Where does that leave us with what Jonathan is suggesting though? For
> my 2c, we shouldn't allow 'map=' to be used for scram or md5 because
> it'll just confuse users, until and unless we actually do the PGAUTHUSER
> thing and then we can
On Sun, Mar 25, 2018 at 8:11 PM, Craig Ringer wrote:
> As others have noted, you'll want to find a way to handle this in the least
> SSL-implementation-specific manner possible. IMO if it can't work with
> OpenSSL, Windows's SSL implementation and OS X's SSL framework it's a
> non-starter.
+1.
>
On Thu, Apr 12, 2018 at 11:00 AM, Tom Lane wrote:
> Andrew Gierth writes:
>> Is it worth exploring the idea of changing to a non-recursive style of
>> makefile?
>
> Not post-feature-freeze, for sure. Whether it's worth the work as a
> long-term project, I dunno.
I've been taking a look at this
On Fri, Oct 4, 2019 at 7:51 AM Tom Lane wrote:
> I concur with Joe here. The reason why some of the existing
> memset's use "false" is for symmetry with other places where we use
> "memset(p, true, n)" to set an array of bools to all-true. That
> coding is unfortunately a bit dubious --- it woul
On Tue, Oct 30, 2018 at 2:39 AM Iwata, Aya wrote:
> I create a first libpq trace log patch.
Couple additional thoughts from a read-through of the patch:
- PQtrace() and the new trace-logging machinery overlap in some places
but not others -- and if both are set, PQtrace() will take precedence.
I
On Sun, Feb 4, 2024 at 6:51 AM vignesh C wrote:
> We should do something about these kinds of entries, there were few
> suggestions like tagging under a new category or so, can we add a new
> status to park these entries something like "Waiting for direction".
> The threads which have no discussio
On Wed, Feb 22, 2023 at 5:40 AM Peter Eisentraut
wrote:
> I think the tradeoff here is, given how rarely those rules are used, is
> it worth maintaining duplicate implementations or complicated bridging?
>
> It's clearly something to deal with eventually, but it's not high priority.
Yeah... in th
; mark data
consumed */
@@ src/interfaces/libpq/fe-connect.c: keep_going:
/* We will come back to here
/* Get the type of request. */
if (pqGetInt((int *) &areq, 4, conn))
{
On Wed, Feb 22, 2023 at 11:43 AM Heikki Linnakangas wrote:
> I separated the earlier message-length checks so that you get "invalid
> invalid authentication request" or "received invalid protocol
> negotiation message", depending on whether it was an 'R' or 'v' message.
> With that, "invalid inval
On Wed, Feb 22, 2023 at 4:26 AM Heikki Linnakangas wrote:
> On 20/01/2023 03:28, Jacob Champion wrote:
> > If you want to multiplex protocols on a port, now is an excellent time
> > to require clients to use ALPN on implicit-TLS connections. (There are
> > no clients that
On Tue, Feb 28, 2023 at 10:33 AM Greg Stark wrote:
> On Wed, 22 Feb 2023 at 07:27, Heikki Linnakangas wrote:
> > Good idea. Do we want to just require the protocol to be "postgres", or
> > perhaps "postgres/3.0"? Need to register that with IANA, I guess.
>
> I had never heard of this before, it d
On Mon, Feb 27, 2023 at 12:43 PM Stephen Frost wrote:
> * Jacob Champion (jchamp...@timescale.com) wrote:
> > This patchset should ideally have required zero client side changes, but
> > because our SCRAM implementation is slightly nonstandard too -- it
> > doesn't e
pg_partman users migrate between old- and
new-style partition schemes, but that's speculation.
On 1/20/23 09:53, Jacob Champion wrote:
>> 2) While this strategy works well for ongoing replication, it's not
>> enough to get the initial synchronization correct. The subscriber
On 2/16/23 10:57, Jacob Champion wrote:
> v14 rebases over the test and solution conflicts from 9244c11afe2.
Since we're to the final CF for PG16, here's a rough summary.
This patchset provides two related features: 1) the ability for a client
to explicitly allow or deny particular
On 2/16/23 10:38, Jacob Champion wrote:
> Thanks for the nudge, v7 rebases over the configure conflict from 9244c11afe.
I think/hope this is well-baked enough for a potential commit this CF,
so I've adjusted the target version. Let me know if there are any
concerns about the approach.
On Sun, Feb 26, 2023 at 7:36 PM Jeff Davis wrote:
>
> On Sun, 2023-02-26 at 09:57 -0800, Andres Freund wrote:
> > If you tell meson where to find the pkg-config file in those
> > directories it'd
> > also work. -Dpkg_config_path=...
>
> Setup is able to find it, which is good, but it seems like it
On Tue, Feb 28, 2023 at 1:59 PM Tom Lane wrote:
> I also discovered that nodeAppend.c is relying on bms_del_members
> not reducing a non-empty set to NULL, because it uses the nullness
> of appendstate->as_valid_subplans as a state boolean.
I seem to recall that Deep and I tripped into this durin
On Tue, Feb 28, 2023 at 6:53 PM Stephen Frost wrote:
> * Jacob Champion (jchamp...@timescale.com) wrote:
> > Yes. Interoperable authentication is going to have to solve those
> > sorts of problems somehow, though. And there are a bunch of levers to
> > pull: clients aren&#x
On 2/1/23 11:59, Sergey Dudoladov wrote:
> Justin, thank you for the fast review. The new version is attached.
This is looking very good. One bigger comment:
> + myextra = (int *) guc_malloc(ERROR, sizeof(int));
> + *myextra = newlogconnect;
If I've understood Tom correctly in [1], both
On 3/2/23 14:56, Tom Lane wrote:
> Jacob Champion writes:
>> If I've understood Tom correctly in [1], both of these guc_mallocs
>> should be using a loglevel less than ERROR, to avoid forcing a
>> postmaster exit when out of memory. (I used WARNING in that thread
>
On Sat, Feb 25, 2023 at 5:22 PM Justin Pryzby wrote:
> This resolves cfbot warnings: windows and cppcheck.
> And refactors zstd routines.
> And updates docs.
> And includes some fixes for earlier patches that these patches conflicts
> with/depends on.
This'll need a rebase (cfbot took a while to
On Fri, Mar 3, 2023 at 10:55 AM Justin Pryzby wrote:
> Thanks for looking. If your zstd library is compiled with thread
> support, could you also try with :workers=N ? I believe this is working
> correctly, but I'm going to ask for help verifying that...
Unfortunately not (Ubuntu 20.04):
p
101 - 200 of 1187 matches
Mail list logo
