-+
- /* Define to 1 if you have the declaration of
-`LLVMCreateGDBRegistrationListener', and to 0 if you don't. */
- #undef HAVE_DECL_LLVMCREATEGDBREGISTRATIONLISTENER
-
## src/interfaces/libpq/fe-secure-openssl.c ##
@@ src/interfaces/libpq/fe-secure-openssl.c: initialize
On Sun, Apr 2, 2023 at 1:36 PM Daniel Gustafsson wrote:
> > On 31 Mar 2023, at 19:59, Jacob Champion wrote:
> > I can make that change; note that it'll also skip some of the new tests
> > with OpenSSL 1.0.1, where there's no SSL_CTX_set_cert_cb. If that's
> > acceptab
On Fri, Mar 31, 2023 at 3:17 PM Peter Smith wrote:
> OK, my understanding is that TimescaleDB uses some kind of
> quasi-partitioned/inherited tables (aka hypertables? [1]) internally,
> and your proposed WIP patch provides a set_logical_root() function
> which combines with the logical
On 3/31/23 03:04, shiy.f...@fujitsu.com wrote:
> I noticed that a similar problem has been discussed in this thread, see [1]
> [2]
> [3] [4].
Ah, thank you. I didn't go far back enough in the thread...
> It seems complicated to fix it if we want to automatically skip tables
> that have been
On 3/30/23 20:01, Peter Smith wrote:
> For example, Just imagine if logic could be made smarter to recognize
> that since there was already the 'part_def' being subscribed so it
> should NOT use the default 'copy_data=true' when the REFRESH launches
> the ancestor table 'part'...
>
> Even if that
On 3/31/23 02:14, Daniel Gustafsson wrote:
>> On 14 Mar 2023, at 20:20, Jacob Champion wrote:
>
>> Rebased over yesterday's Meson changes in v8.
>
> I had a look at this and agree that it's something we should do.
Great, thanks for the review!
> + # Let tests diffe
On Wed, Mar 29, 2023 at 2:00 AM Amit Kapila wrote:
> Pushed.
While rebasing my logical-roots patch over the top of this, I ran into
another situation where mixed viaroot settings can duplicate data. The
key idea is to subscribe to two publications with mixed settings, as
before, and add a
On Wed, Mar 29, 2023 at 6:35 AM Justin Pryzby wrote:
> If you have a zstd library with thread support, you could test with
> -Z zstd:workers=3. But I think threads aren't enabled in the common
> libzstd packages. Jacob figured out how to compile libzstd easily using
> "meson wraps" - but I
On Wed, Mar 15, 2023 at 9:50 PM Justin Pryzby wrote:
> On Fri, Mar 10, 2023 at 12:48:13PM -0800, Jacob Champion wrote:
> > It looks like pg_dump's meson.build is missing dependencies on zstd
> > (meson couldn't find the headers in the subproject without them).
>
> I sa
On Tue, Mar 28, 2023 at 2:59 AM wangw.f...@fujitsu.com
wrote:
> The scenario of this bug is to subscribe to two publications at the same time,
> and these two publications publish parent table and child table respectively.
> And option via_root is specified in both publications or only in the
>
On Mon, Mar 20, 2023 at 11:22 PM Amit Kapila
wrote:
> If the tests you have in mind are only related to this patch set then
> feel free to propose them here if you feel the current ones are not
> sufficient.
I think the new tests added by Wang cover my concerns (thanks!). I share
Peter's comment
On 3/20/23 09:32, Robert Haas wrote:
> I think this is the root of our disagreement.
Agreed.
> My understanding of the
> previous discussion is that people think that the major problem here
> is the wraparound-to-superuser attack. That is, in general, we expect
> that when we connect to a
On Thu, Mar 23, 2023 at 10:18 PM Michael Paquier wrote:
> I have spent a couple of hours looking at the whole again today,
> testing that with OpenSSL to make sure that everything was OK. Apart
> from a few tweaks, that seemed pretty good. So, applied.
Thank you!
--Jacob
$c->{'opts'}"
++ );
++ is($result, $c->{'present'}, "ssl_client_cert_present() for
$c->{'opts'}");
++}
++
+ done_testing();
+
## src/tools/msvc/Solution.pm ##
@@ src/tools/msvc/Solution.pm: sub GenerateFiles
HAVE_SETPROCTITLE_
On Fri, Mar 17, 2023 at 9:45 PM Amit Kapila wrote:
> > There are a bunch of moving parts and hidden subtleties here, and I fell
> > into a few traps when I was working on my patch, so it'd be nice to have
> > additional coverage. I'm happy to contribute effort in that area if it's
> > helpful.
>
On Thu, Mar 16, 2023 at 11:28 PM wangw.f...@fujitsu.com
wrote:
> Attach the new patch set.
Hi,
I ran into this problem while hacking on [1], so thank you for tackling
it! I have no strong opinions on the implementation itself; I just want
to register a concern that the tests have not kept up
e1c458b1 = 2: 11b69d0bc0 libpq: force sslmode=verify-full for system CAs
From 84f67249e683d79a9a004b3f12507e77be3d9c6f Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 24 Oct 2022 15:30:25 -0700
Subject: [PATCH v8 1/2] libpq: add sslrootcert=system to use default CAs
Based on a patch by Thomas H
Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Tue, 18 Oct 2022 16:55:36 -0700
Subject: [PATCH v17 2/2] require_auth: decouple SASL and SCRAM
Rather than assume that an AUTH_REQ_SASL* code refers to SCRAM-SHA-256,
future-proof by separating the single allowlist into a list of allowed
auth
On Sat, Mar 11, 2023 at 8:47 PM Peter Geoghegan wrote:
> I was joking. But I did have a real point: once we have tests for the
> xidStopLimit mechanism, why not take the opportunity to correct the
> long standing issue with the documentation advising the use of single
> user mode?
Does
On Fri, Mar 10, 2023 at 3:16 PM Jacob Champion wrote:
> > Could you send a new patch with all these adjustments? That would
> > help a lot.
>
> Will do!
Here's a v16:
- updated 0001 patch message
- all test names should have commas rather than colons now
- new test for an
On Thu, Mar 9, 2023 at 6:17 AM Robert Haas wrote:
> That seems like a circular argument. If you call the problem the
> confused deputy problem then the issue must indeed be that the deputy
> is confused, and needs to talk to someone else to get un-confused. But
> why is the deputy necessarily
On Fri, Mar 10, 2023 at 3:09 PM Michael Paquier wrote:
> >> + reason = libpq_gettext("server did not complete
> >> authentication"),
> >> -+ result = false;
> >> ++ result = false;
> >> + }
> >
> > This
On 3/8/23 22:35, Michael Paquier wrote:
> I have been reviewing 0001, finishing with the attached, and that's
> nice work. My notes are below.
Thanks!
> pqDropServerData() is in charge of cleaning up the transient data of a
> connection between different attempts. Shouldn't
Hi,
This'll need another rebase over the meson ICU changes.
On Wed, Mar 8, 2023 at 10:59 AM Jacob Champion
wrote:
> I did some smoke testing against zstd's GitHub release on Windows. To
> build against it, I had to construct an import library, and put that
> and the DLL into the `li
On Wed, Mar 8, 2023 at 11:40 AM Robert Haas wrote:
> On Wed, Mar 8, 2023 at 2:30 PM Jacob Champion wrote:
> > I don't think I necessarily like that option better than SASL-style,
> > but hopefully that clarifies it somewhat?
>
> Hmm, yeah, I guess that's OK.
Okay, cool.
On Wed, Mar 8, 2023 at 1:47 PM Tom Lane wrote:
> Pavel's proposed check would break that too. There's going to be some
> interval where the SQL definitions are not in sync with the .so version,
> so you really want the .so to support at least two versions' worth of
> SQL objects.
I think we're
On Tue, Mar 7, 2023 at 2:40 AM Aleksander Alekseev
wrote:
> So far I only have a couple of nitpicks, mostly regarding the code coverage
> [1]:
Yeah, I need to work on error cases and their coverage in general.
There are more cases that I need to reject as well (marked TODO).
> +Datum
>
On Tue, Feb 7, 2023 at 10:16 AM Jacob Champion wrote:
> Even more concretely, here's a draft patch. There's no nuance --
> setting dump_version affects all past versions of the extension, and
> it can't be turned off at restore time. So extensions opting in would
> have to be writte
On Wed, Mar 8, 2023 at 11:22 AM Pavel Stehule wrote:
> There is agreement - I call this check from functions.
I think pg_auto_failover does this too, or at least used to.
Timescale does strict compatibility checks as well. It's not entirely
comparable to your implementation, though.
--Jacob
On Wed, Mar 8, 2023 at 11:11 AM Pavel Stehule wrote:
> installation from rpm or deb packages
Right, but I thought the safe order for a downgrade was to issue the
SQL downgrade first (thus putting the system back into the
post-upgrade state), and only then replacing the packages with prior
On Wed, Mar 8, 2023 at 11:18 AM Tom Lane wrote:
>
> Jacob Champion writes:
> > On Wed, Mar 8, 2023 at 10:49 AM Tom Lane wrote:
> >> This is a bad idea. How will you do extension upgrades, if the new .so
> >> won't run till you apply the extension
On Tue, Mar 7, 2023 at 11:04 AM Robert Haas wrote:
>
> On Thu, Feb 9, 2023 at 4:46 PM Jacob Champion wrote:
> > 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 fo
On Wed, Mar 8, 2023 at 10:49 AM Tom Lane wrote:
> This is a bad idea. How will you do extension upgrades, if the new .so
> won't run till you apply the extension upgrade script but the old .so
> malfunctions as soon as you do?
Which upgrade paths allow you to have an old .so with a new version
On Sat, Mar 4, 2023 at 8:57 AM Justin Pryzby wrote:
> pryzbyj=# CREATE TABLE t1 AS SELECT i,array_agg(j) FROM
> generate_series(1,444)i,generate_series(1,9)j GROUP BY 1;
> $ ./src/bin/pg_dump/pg_dump -d pryzbyj -Fc -Z zstd:long=1 |wc -c
> 82023
> $ ./src/bin/pg_dump/pg_dump -d pryzbyj -Fc -Z
On Fri, Mar 3, 2023 at 6:35 PM Michael Paquier wrote:
> I was refreshing my mind with 0001 yesterday, and except for the two
> parts where we need to worry about AUTH_REQ_OK being sent too early
> and the business with gssenc, this is a rather straight-forward. It
> also looks like the the
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):
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 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 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 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 a
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
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
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.
Tha
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 meth
rs 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
>> still does a COP
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
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
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 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
/* Get the type of request. */
if (pqGetInt((int *) , 4, conn))
{
-+ libpq_append_conn_error(conn, "server
sent truncated authentication request");
++ libpq_append_conn_er
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
lication/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 Champion
Date: Thu, 16 Feb 2023 13:40:47 -0800
Subject: [PATCH] WIP: support official SASL channel bindings
...
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
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
&& $digit3 >= '0'))
+ }
+
+ $self->GenerateConfigHeader('src/include/pg_config.h', \%define, 1);
3: 6c3b1f28bc = 3: 9a84af5936 require_auth: decouple SASL and SCRAM
From 9a84af59361e09446d087cf0c79f1a9a3b61e39d Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date:
rt.
(--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 for sy
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) /*
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't
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't updated when gss
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
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_version = true
>
> whi
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
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 propose fe
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 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
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
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 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 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
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
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
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 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
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
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
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
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 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 will pre
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
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
On 1/12/23 11:04, Jacob Champion wrote:
> On Wed, Jan 11, 2023 at 1:03 PM Tom Lane wrote:
>> Jacob Champion writes:
>>> Right, I think it would have to be opt-in. Say, a new control file
>>> option dump_version or some such.
>>
>> That would requi
On Fri, Jan 13, 2023 at 10:44 AM Jacob Champion wrote:
> And my thought was that the one-time
> initialization could be moved to a place that doesn't need to know the
> connection options at all, to make it easier to reason about the
> architecture. Say, next to the WSAStart
On Sun, Jan 15, 2023 at 12:03 PM Andrey Chudnovsky
wrote:
> 2. Removed Device Code implementation in libpq. Several reasons:
>- Reduce scope and focus on the protocol first.
>- Device code implementation uses iddawc dependency. Taking this
> dependency is a controversial step which
On Fri, Jan 13, 2023 at 9:10 AM Jelte Fennema wrote:
>
> > Just a quick single-issue review, but I agree with Maxim that having
> > one PRNG, seeded once, would be simpler
>
> I don't agree that it's simpler. Because now there's a mutex you have
> to manage, and honestly cross-platform threading
On Wed, Sep 14, 2022 at 7:54 AM Maxim Orlov wrote:
> For the patch itself, I think it is better to use a more precise time
> function in libpq_prng_init or call it only once.
> Thought it is a special corner case, imagine all the connection attempts at
> first second will be seeded with the
On Wed, Jan 11, 2023 at 1:03 PM Tom Lane wrote:
> Jacob Champion writes:
> > Right, I think it would have to be opt-in. Say, a new control file
> > option dump_version or some such.
>
> That would require all the installed extensions to cope with this
> the same way,
On Wed, Jan 11, 2023 at 10:23 AM Magnus Hagander wrote:
> Sorry to jump in (very) late in this game. So first, I like this general
> approach :)
Thanks!
> It feels icky to have to add configure tests just to make a test work. But I
> guess there isn't really a way around that if we want to
On Tue, Jan 10, 2023 at 7:53 PM Tom Lane wrote:
> Jacob Champion writes:
> > Unless I'm missing something obvious (please, let it be that) there's no
> > way to do this safely. Once you've marked an internal table as dumpable,
> > its schema is effectively frozen if you wa
On Wed, Jan 11, 2023 at 6:37 AM Jelte Fennema wrote:
>
> LGTM. As far as I can tell this is ready for a committer.
Thanks for the reviews!
--Jacob
On Wed, Jan 11, 2023 at 1:48 AM Aleksander Alekseev
wrote:
> After reading [1] carefully it looks like we shouldn't worry about
> this. The upgrade procedure explicitly requires to run `pg_ctl stop`
> during step 8 of the upgrade procedure, i.e. not in the immediate mode
> [2].
Yeah, pg_upgrade
Hi all,
I've been talking to other Timescale devs about a requested change to
pg_dump, and there's been quite a bit of back-and-forth to figure out
what, exactly, we want. Any mistakes here are mine, but I think we've
been able to distill it down to the following request:
We'd like to be allowed
libpq_gettext("weak sslmode
\"%s\" may not be used with sslrootcert=system\n"),
-+conn->sslmode);
++ libpq_append_conn_error(conn, "weak sslmode \"%s\" may not be
used with sslrootcert=system",
On Mon, Jan 9, 2023 at 7:40 AM Andrew Dunstan wrote:
> I'm confused. A client cert might not have a hostname at all, and isn't
> used to verify the connecting address, but to verify the username. It
> needs to have a CN/DN equal to the user name of the connection, or that
> maps to that name via
On Mon, Jan 9, 2023 at 12:41 AM Aleksander Alekseev
wrote:
> I would like to point out that we shouldn't necessarily support
> multiple inheritance in all the possible cases, at least not in the
> first implementation. Supporting simple cases of inheritance would be
> already a valuable feature
On Fri, Dec 9, 2022 at 10:21 AM Jacob Champion wrote:
> Some inheritance hierarchies won't be "partitioned" hierarchies, of
> course, but the user can simply not set that replication option for
> those publications.
The more I noodle around with this approach, the less I like
Hi,
+1 for the idea!
> +authenticated
> +Logs the original identity that an authentication method
> employs to identify a user. In most cases, the identity string equals the
> PostgreSQL username,
> +but some third-party authentication methods may alter the original
>
On Fri, Jan 6, 2023 at 2:18 AM Jelte Fennema wrote:
>
> Huge +1 from me. On Azure we're already using public CAs to sign certificates
> for our managed postgres offerings[1][2]. Right now, our customers have to go
> to the hassle of downloading a specific root cert or finding their OS default
On Tue, Jan 3, 2023 at 8:56 PM vignesh C wrote:
> I'm not sure if this should be included in commitfest as we generally
> include the postgres repository patches in the commitfest. I felt we
> could have the discussion in the thread and remove the entry from
> commitfest.
Is there a good way to
On Thu, Dec 8, 2022 at 3:10 PM Jacob Champion wrote:
> For now, it's worked around in v4. This should finally get the cfbot
> fully green.
Cirrus's switch to M1 Macs changed the Homebrew installation path, so
v5 adjusts the workaround accordingly.
--Jacob
1: b01812f604 ! 1: 7618037c86
On Tue, Jan 3, 2023 at 4:14 AM vignesh C wrote:
> The patch does not apply on top of HEAD as in [1], please post a rebased
> patch:
Hi Vignesh -- this is a patch for the CF app, not the Postgres repo,
so cfbot won't be able to apply it. Let me know if there's a better
place for me to put it.
201 - 300 of 841 matches
Mail list logo
