On Mon, Jul 28, 2025 at 6:30 PM Michael Paquier wrote:
> My understanding of the problem is that it is a choice of efficiency
> vs entropy, and that it's not really possible to have both parts of
> the cake.
That was my understanding too, but then [1] called that into question.
If -- and I don't
On Mon, Jul 28, 2025 at 2:42 PM David G. Johnston
wrote:
> I don’t understand calling out sigterm as an exception, the same
> abort-and-shutdown action happens there too.
RestoreArchivedFile() has a special case for SIGTERM, though?
> And in any case signals are turned into exit status values a
On Mon, Jul 28, 2025 at 1:58 PM Jean-Christophe Arnu wrote:
> Or
>
> The recovery will be aborted and the server will stop if any of the following
> events occur:
> - the command was terminated by a signal other than SIGTERM (which is used as
> part of a database server shutdown);
> - the comman
Hi all,
On Thu, Jun 26, 2025 at 4:33 PM Jacob Champion
wrote:
> My plan, if this code seems reasonable, is to backport 0001-0003, but
> keep the larger 0004 on HEAD only until it has proven to be stable.
> It's a big new suite and I want to make sure it's not flapping on some
On Mon, Jul 28, 2025 at 10:48 AM Andres Freund wrote:
> I don't think there's anything special to check for CI specific changes, so I
> guess "... all good" covers it...
Sounds good. I will take another look at this with a committer hat and
push Sometime Soon.
Thanks!
--Jacob
On Mon, Jul 28, 2025 at 8:19 AM Jean-Christophe Arnu wrote:
> You're also right. That's more consistent and easier to read.
> Thank you for pointing this out.
I agree that reusing archive_command's wording is probably the way to
go. I think archive_cleanup_command and recovery_end_command have th
On Mon, Jul 28, 2025 at 5:08 AM Daniel Gustafsson wrote:
> Reading over the v6 version posted upthread, I agree with the patch being
> ready. Are you taking care of it Jacob?
I was admittedly a bit nervous about pushing changes to the infra.
Andres, Bilal, do you have a list of things to check a
On Mon, Jul 28, 2025 at 4:36 AM Daniel Gustafsson wrote:
> There has in the past been discussions (at least off-list in hallway tracks)
> about allowing randomness to be chosen separately from underlying factors such
> as OpenSSL support, at the time it didn't seem worth the trouble but that may
>
On Thu, Jul 24, 2025 at 2:18 PM Jean-Christophe Arnu wrote:
> Could we perhaps improve the documentation by stating that return codes over
> 125 or (at least) 128 will lead to the server not starting?
>
> This may help people better understand the behaviour of the restore_command
> and quickly s
On Thu, Jul 24, 2025 at 12:04 PM Dave Cramer wrote:
> Patch attached
+/* Replication Protocol sent by the primary */
+
+#define PqMsg_XlogData 'w'
+#define PqMsg_PrimaryKeepAlive 'k'
+#define PqMsg_PrimaryStatusUpdate 's'
+
+
+/* Replication Protocol sent by the standby */
+
+
milar to your
results.
> On Tue, Jul 22, 2025 at 11:46 AM Jacob Champion
> wrote:
> > That is _really_ surprising to me at first glance. I thought
> > RAND_bytes() was supposed to be a userspace PRNG, which I would
> > naively expect to take much less time than pulling data f
On Tue, Jul 22, 2025 at 11:32 AM Masahiko Sawada wrote:
> While getentropy() has better portability, according to the
> getentropy() manual, the maximum length is limited to 256 bytes. It
> works in some cases such as generating UUID data but seems not
> appropriate for our general pg_strong_rando
On Fri, Dec 13, 2024 at 12:54 AM Alexander Kuznetsov
wrote:
> ping. What do you think about reasoning below? Maybe we should consider
> proposing different patch for removing redundant check there?
To move this forward a bit, your reasoning:
> 1. slot2 is NULL at line 968,
> 2. The while loop at
On Fri, Jul 18, 2025 at 3:29 PM Daniel Gustafsson wrote:
> Ugh, In preparing for going on vacation this fell off the radar. I'll try to
> get to looking at it tomorrow during downtime unless beaten to it.
Your earlier mail made me worried I'd missed something, but is the
attached diff what Andre
On Fri, Jul 18, 2025 at 12:55 PM Andres Freund wrote:
>
> Hi,
I think we're talking past each other, so let me try to focus on just
a few items here. I'm happy to go back and respond point-by-point if
needed.
> I don't know your fix really looks like - afaict you haven't shared it. So
> it's har
On Fri, Jul 18, 2025 at 11:11 AM Jacob Champion
wrote:
> The current behavior for GSS is, IMO, an
> obvious oversight.
(A better way to word this would have been "clearly an oversight"; I
didn't mean to imply that the correct behavior is obvious. The
opposite, in fact.)
--Jacob
On Wed, Jul 16, 2025 at 11:50 AM Jacob Champion
wrote:
> On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote:
> > Do you have a WIP patch?
>
> I'm working on one now.
The attached still needs some documentation work, and closer
inspection of the new assertions and OpenSSL e
On Wed, Jul 16, 2025 at 4:35 PM Andres Freund wrote:
> Why do we care about not hitting the socket? We always operate the socket in
> non-blocking mode anyway?
IIUC, that would change pqReadData() from a bounded read to an
unbounded one. Then we have to somehow protect against a server that
can s
On Wed, Jul 16, 2025 at 2:34 PM Andres Freund wrote:
> > Based on my understanding of [1], readahead makes this overall problem
> > much worse by opportunistically slurping bytes off the wire and doing
> > absolutely nothing with them until you call SSL_read() enough times to
> > finally get to th
On Wed, Jul 16, 2025 at 11:11 AM Andres Freund wrote:
> If one modifies libpq to use openssl readahead (which does result in speedups,
> because otherwise openssl think it's useful to do lots of 5 byte reads from
> the socket), I see occasional hangs in libpq.
Now that is a very interesting coinc
On Wed, Jul 16, 2025 at 7:36 AM Merlin Moncure wrote:
> Agreed. Here's a little more detail on the case I noticed:
>
> * postgres backend thread managing several libpq connections, with polling
> is_busy loop
> * when client pushed a lot of log messages (say, with 'RAISE NOTICE'), the
> server w
On Wed, Jul 16, 2025 at 4:12 AM Nazir Bilal Yavuz wrote:
> > For me it looks like 'Meson Auto' can be confused with 'Autoconf'. We
> > can rename it as a 'Meson Auto Feature Detection' but that is a bit
> > longer. Do you have any ideas? If you think 'Meson Auto' is good
> > enough, we can continu
On Wed, Jul 2, 2025 at 4:12 PM Jacob Champion
wrote:
> I'll work on proving that code paths other than PQconsumeInput() are
> affected. If they are, I'll start a patch for pqReadData().
Here's one way for a server implementation to hang the client during
PQconnectPoll():
On Tue, Jul 1, 2025 at 12:33 AM Jelte Fennema-Nio wrote:
> I think maybe we
> should show the search/filter bar by default, because I keep
> forgetting it exists and I continue to use regular Ctrl+F instead.
Hmm, I think I agree.
> I quite dislike the current topic system.
Me too. :)
> Unsurpr
On Tue, Jul 1, 2025 at 12:52 AM Daniel Gustafsson wrote:
>
> > On 1 Jul 2025, at 09:33, Jelte Fennema-Nio wrote:
>
> > I quite dislike the current topic system. Partially because it's
> > impossible to filter by a topic (like you can now do with tags), but
> > primarily because the actual availab
On Tue, Jul 15, 2025 at 2:04 PM Jelte Fennema-Nio wrote:
>
> On Mon, 30 Jun 2025 at 22:48, Jacob Champion
> wrote:
> > I would also like to request that CFMs be given the ability to add and
> > edit (but maybe not delete?) tags.
>
> This should be possible now.
T
On Thu, Jul 10, 2025 at 7:41 AM wrote:
> I agree with the patch. Works in my OSes
Thanks Ivan! Committed.
--Jacob
On Thu, Jul 10, 2025 at 2:59 AM Nazir Bilal Yavuz wrote:
> Andres off-list mentioned that if we explicitly enable features for
> *all* of the tasks, then none of the tasks will be testing the auto
> feature option and I agree with Andres. My suggestion is setting
> features to auto for Debian - Me
checks on the results.
Sounds good, thanks for the review!
On Wed, Jul 9, 2025 at 11:39 AM Jacob Champion
wrote:
> Here is a draft patch for Ivan's reported issue; I still need to put
> it through its paces with some more unusual setups, but I want to get
> cfbot on it.
On HEAD,
On Wed, Jul 9, 2025 at 12:07 PM Tom Lane wrote:
> Jacob Champion writes:
> > Here is a draft patch for Ivan's reported issue; I still need to put
> > it through its paces with some more unusual setups, but I want to get
> > cfbot on it.
>
> I'm confused
On Wed, Jul 9, 2025 at 11:13 AM Tom Lane wrote:
> Jacob Champion writes:
> > I'll work up a patch to send through the CI. I can't currently test
> > RHEL8 easily -- Rocky 8 is incompatible with my Macbook? -- which I
> > will need to rectify eventually, but I
On Wed, Jul 9, 2025 at 10:36 AM Tom Lane wrote:
> Per "man dlopen", you have to link with libdl to use these functions
> on this platform. (Curiously, although RHEL9 still says that in the
> documentation, it doesn't seem to actually need -ldl.) I was able
> to resolve this by adding -ldl in lib
On Mon, Jul 7, 2025 at 5:41 AM Nazir Bilal Yavuz wrote:
> It seems CFBot is using these patches [1], resharing actual patch [2]
> with the hopes that it will be used by CFBot.
Whoops, thanks for reposting that. I plan to get this pushed today so
that it doesn't start blocking the Meson work.
--J
On Thu, Jul 3, 2025 at 11:54 AM Tom Lane wrote:
> I hadn't noticed (or maybe I forgot) this thread, so when the
> same problem was reported at [1] I just went ahead and pushed the
> submitted patch, which is only cosmetically different from your 0001.
> Apologies for treading on your toes.
No wor
On Wed, Jul 2, 2025 at 3:18 PM Jelte Fennema-Nio wrote:
> I think you might have meant: "If libpq doesn't
> allow it, even though the spec suggets it should, then people will still
> blame the server implemantion".
Yes. Same for clients which disallow corner cases that the spec is
silent on but l
On Tue, Jul 1, 2025 at 1:42 PM Jacob Champion
wrote:
> I do
> not yet understand why this protection is not extended to
> GSS-encrypted connections.
After repurposing some of my test code for d98cefe11, I'm able to
reproduce the hang with gssencmode when the server uses a
smaller
On Wed, Jul 2, 2025 at 5:45 AM Ivan Kush wrote:
>
> Thanks for the clarification! I thought linker flags should be installed
> globally for all compilation targets.
Not for libcurl, since the libpq-oauth module split.
> Another question:
>
> Why don't we set LIBS in the configure in "checking fo
On Tue, Sep 10, 2024 at 11:49 AM Jacob Champion
wrote:
> I need to switch away from this for a bit.
"a bit"
In an effort to get this unstuck (and ideally solved during this
commitfest) here are my most recent thoughts:
> I agree that PQconsumeInput() needs to ensure th
On Tue, Jul 1, 2025 at 1:15 AM Jelte Fennema-Nio wrote:
>
> Pretending that
> libpq is the "golden standard" for our protocol just seems plain wrong
> to me.
Not what I said. I'm saying that if a server implementation claims
Postgres compatibility but fails to talk to deployed versions of libpq
i
On Mon, Jun 30, 2025 at 11:44 AM Jelte Fennema-Nio wrote:
> > It looks like Heikki has an open item for this, so I'll defer to him
>
> Oh... Sorry for the confusion. I added that open item to the list (so
> it would not be missed), and I added Heikki as the owner because he
> committed the origina
On Mon, Jun 30, 2025 at 1:20 PM Jacob Champion
wrote:
> This category of tag is the best. It is completely new information,
> not captured anywhere else in the UI, that is useful at the top level
> and helps drive reviews forward by helping the community find
> interesting things.
O
On Mon, Jun 23, 2025 at 12:01 PM David G. Johnston
wrote:
>
> Yes, categories, and give each category its own line in the table.
I'm headed in the opposite direction. Let me elaborate with some very
strong opinions about the existing tags. (No one has to share my
strong opinions.)
- Help - Bikes
On Mon, Jun 30, 2025 at 10:02 AM Daniel Gustafsson wrote:
> > On 30 Jun 2025, at 18:58, Andres Freund wrote:
> > Probably just needs to be added to the installed_targets list.
>
> Thanks for the report, I'll take a look today to get it fixed.
Thanks both!
Looking at the installed_targets stuff,
On Wed, Jun 25, 2025 at 12:12 AM Jelte Fennema-Nio wrote:
> Attached is an attempt at implementing the above. I did not test it
> against these systems though.
With 0001, psycopg2 appears to function again when talking to a server
that doesn't send a cancellation key, so that's good.
It looks li
On Wed, Jun 25, 2025 at 3:46 AM Nazir Bilal Yavuz wrote:
> I wanted to experiment with it.
That was fast, thank you!
> First, I got the current list of
> features from upstream, then disabled the auto features, then
> explicitly enabled these features. I did this only for FreeBSD to show
> my id
Hi all,
The current implementation of the OAuth flow is overly eager to signal
readiness when there's nothing to do, so sometimes we burn CPU for no
reason. This was discussed briefly back in [1], but I'll summarize
here so no one has to dig through that megathread.
= Background =
A major intera
On Tue, Jun 24, 2025 at 2:03 PM Tom Lane wrote:
> I confirm Jacob's result that our meson.build fails to think
> that is available, so we do need to do something.
(To clarify for other readers: it's the OAuth feature test I added
that fails. The existing test for HAVE_SYS_EVENT_H is working fine
On Tue, Jun 24, 2025 at 1:27 AM Nazir Bilal Yavuz wrote:
> I think this is a good idea. Another point is that CI images and their
> packages are updated automatically, so it would be easier to catch if
> something breaks when the VM is updated.
Yes, that's a great point too. Okay, sounds like the
On Tue, Jun 24, 2025 at 2:50 PM Tom Lane wrote:
> Can't say that I find this to be impressive software engineering:
> rather than having only one probe failure mode to worry about,
> we have two, depending on whether the compiler knows __has_include().
> Pretty close to the worst of all possible w
On Tue, Jun 24, 2025 at 1:29 PM Peter Eisentraut wrote:
> Note that Autoconf uses a compilation test, not a preprocessor test, for
> its AC_CHECK_HEADERS, so it uses .check_header() semantics. And this
> was the result of a long transition, because the compile test was
> ultimately deemed to be b
On Mon, Jun 23, 2025 at 5:19 PM Tom Lane wrote:
> As far as I recall, we've always thought that autoconf's approach
> of "explicitly specify the features you expect to get" is the
> right way to do things. I don't love meson's default you-get-
> whatever-seems-available approach at all, though ma
On Tue, Jun 24, 2025 at 1:36 AM Jelte Fennema-Nio wrote:
> Okay, that sounds widely used enough to continue that we should
> probably change the new PG18 behaviour of PQgetCancel and
> PQcancelCreate like I suggested. Failing all psycopg2 connection
> attempts against AWS its proxy service doesn't
On Mon, Jun 23, 2025 at 11:52 AM Jelte Fennema-Nio wrote:
> On Mon, 23 Jun 2025 at 18:29, Jacob Champion
> wrote:
> > - "dblink" seems overly specific compared to the others.
>
> It seemed roughly as specific as postgres_fdw to me. Maybe we should
> make sure they
Hi all,
I noticed that the OpenBSD build in CI wasn't running the libcurl
tests. Turns out the feature test I added in b0635bfda is subtly
broken, because it uses cc.check_header() rather than cc.has_header().
On OpenBSD, apparently, the header can't be compiled
without including additional prere
On Mon, Jun 23, 2025 at 9:24 AM Jelte Fennema-Nio wrote:
> On Mon, 23 Jun 2025 at 18:02, Jacob Champion
> wrote:
> > If anyone today is relying on "backend-key-less" connection, this is
> > potentially a breaking change. For example, psycopg2 now complains:
> >
On Mon, Jun 23, 2025 at 1:17 AM Jelte Fennema-Nio wrote:
> The tags that are currently available are some default ones that I
> thought might be useful. If you're missing certain tags or don't like
> the default ones, please respond to this thread. If you have the right
> permissions, you can even
On Thu, Jun 19, 2025 at 5:12 AM Jelte Fennema-Nio wrote:
> I'd be surprised if many clients handle it correctly if it is not
> sent. Looking quickly at the code for pgbouncer and libpq for PG17
> (and lower) they definitely don't. They won't throw an error, but
> instead of doing nothing when the
On Fri, Jun 20, 2025 at 3:08 AM Ivan Kush wrote:
>
> Hello!
>
> This patch fixes CPPFLAGS, LDFLAGS, LIBS when checking AsyncDNS libcurl
> support in configure
Hi Ivan, thanks for the report! Your patch puts new logic directly
after an AC_MSG_ERROR() call, so any effect has to come from the fact
t
On Thu, Mar 6, 2025 at 12:57 PM Jacob Champion
wrote:
> 3) There is a related performance bug on other platforms. If a Curl
> timeout happens partway through a request (so libcurl won't clear it),
> the timer-expired event will stay set and CPU will be burned to spin
&g
On Fri, Jun 6, 2025 at 1:18 PM Nico Williams wrote:
> However no one will be using a discrete or firmware TPM for TLS server
> certificate private key usage: discrete TPMs are way way too slow for
> that, and firmware TPMs are... also way too slow. You wouldn't bother
> with a software TPM for th
On Fri, Jun 6, 2025 at 9:37 AM Andres Freund wrote:
> It's not just crashes, e.g. the startup packet timeout is also handled by
> _exit() - and it can be triggered remotely.
Fair point...
> ISTM that if crypto providers
> can't handle _exit(), we have a bigger problem.
...so I guess I need to f
On Fri, Jun 6, 2025 at 9:25 AM Nico Williams wrote:
> I'd expect all subsystems to recover cleanly from unclean shutdowns. I
> know, that's a lot to expect, but nowadays pretty much all filesystems
> used in production do, for example.
I guess, but if we stop cleaning up entirely, we will sudden
On Fri, Jun 6, 2025 at 7:17 AM Tom Lane wrote:
> Peter Eisentraut writes:
> > Since we now require Python 3.6, we can also remove PL/Python test
> > alternative expected files for earlier Python versions. See attached patch.
>
> +1. So nice to get rid of src/pl/plpython/expected/README.
Awesom
On Fri, Jun 6, 2025 at 4:56 AM Peter Eisentraut wrote:
> It seems weird to me that openssl spends so much effort tidying up its
> memory allocations just before exiting. We could just skip that.
> Looking through the code of OPENSSL_cleanup(), there might be one or two
> cases of log or trace fil
On Tue, Jun 3, 2025 at 12:48 AM Peter Eisentraut wrote:
>
> On macOS, when building with the make system, the exported symbols list
> (SHLIB_EXPORTS) is ignored. I don't think that is intentional. It was
> probably just forgotten, since that combination has never actually been
> used until now (
On Wed, May 28, 2025 at 2:59 PM Tom Lane wrote:
> (That should make the above-depicted elog unreachable, but
> belt and suspenders too isn't a bad plan.)
I like that approach, if delegation on Mac ends up being too much of a pain.
--Jacob
On Wed, May 28, 2025 at 9:25 AM Jacob Champion
wrote:
> Personally, I'd be more happy to "maintain GSS on Mac using
> non-deprecated interfaces" than "maintain GSS via Heimdal,
> best-effort, some of the time". I think the former puts less of a
> burden
On Wed, May 28, 2025 at 8:53 AM Tom Lane wrote:
> Even granting that we're okay with letting people build against
> Heimdal, I'm not clear on the path forward. Your patch proposes
> to effectively disable gss_accept_delegation, which isn't real
> palatable (and would require docs and test fixes t
On Thu, May 8, 2025 at 11:38 PM Heikki Linnakangas wrote:
> It didn't occur to me that you could write it simply as 'msgLength - 4'.
> That depends on knowing that the preceding fields are exactly 4 bytes
> long, but that's clear enough if we just add a comment on that, see
> attached.
Sorry for
On Wed, May 21, 2025 at 12:54 PM Melanie Plageman
wrote:
> Attached is a patch that updates these as well as changes all usages
> of log_connections in the tests. I made some judgment calls about
> where we might want expanded or reduced log_connections aspects. As
> such, the patch could use a on
On Mon, May 19, 2025 at 6:23 AM Aleksander Alekseev
wrote:
> In my experience people who have been contributing for some time use
> format-patch and provide at least a draft of the commit message,
> because they know it's more convenient both for the reviewers (the
> patch has better chances to be
On Fri, May 16, 2025 at 12:12 PM Tom Lane wrote:
> That outcome seems entirely horrible to me. If you want to flag the lack
> of a commit message somehow, fine, but don't prevent CI from running.
Personally I also prefer nudges to gates. Just like people already
deprioritize "Waiting on Author"
On Mon, May 12, 2025 at 8:49 AM Jacob Champion
wrote:
>
> On Mon, May 12, 2025 at 3:50 AM Christoph Berg wrote:
> > Since nothing in libpq should need curl for compiling, should we drop
> > it there instead?
>
> The static build (libpq.a) still needs libcurl. The modul
On Mon, May 12, 2025 at 3:50 AM Christoph Berg wrote:
> Since nothing in libpq should need curl for compiling, should we drop
> it there instead?
The static build (libpq.a) still needs libcurl. The module is only
compiled for use by the shared library.
--Jacob
On Thu, May 8, 2025 at 12:11 PM Heikki Linnakangas wrote:
> Polished this up a tiny bit, and committed.
Thanks! I think the uint8->int change for cancel_key_len is more than
just cosmetic; it most likely fixes a bug where a key size of 256
wrapped around to 0. I'll double-check that this fixes th
On Thu, May 8, 2025 at 1:07 PM Tom Lane wrote:
> I'm not aware of one, but it seems like a reasonable idea ...
I've created a skeleton at
https://wiki.postgresql.org/wiki/Minimum_Dependency_Versions, based on
our dev documentation and some recent threads. Still plenty to fill
in, if anyone knows
On Thu, May 8, 2025 at 5:22 AM Aleksander Alekseev
wrote:
> Thanks for the patch. It looks good to me. It's well documented and
> covered with tests. I can confirm that the tests pass. Also they fail
> if I decrease the $nesting_limit value to 15.
Thanks for the review!
--Jacob
On Wed, May 7, 2025 at 3:39 PM Álvaro Herrera wrote:
> Well, Jacob did say that he tested it with 3.81, so this patch should be
> okay. Upping the minimum version can be discussed elsewhere ... or
> maybe never, if we end up replacing it wholesale with Meson/ninja.
To be fair, I did invite debat
On Wed, May 7, 2025 at 2:45 PM Jonathan S. Katz wrote:
> I did a double take on the current sentence, and revised it to:
>
> ==
> PostgreSQL 18 introduces `oauth` authentication, which lets users
> authenticate using OAuth 2.0 mechanisms supported through PostgreSQL
> extensions.
> ==
>
> I don't
On Tue, May 6, 2025 at 8:46 PM Jonathan S. Katz wrote:
> Here's the next update
Thanks!
> PostgreSQL 18 introduces `oauth` authentication, which people can create
> extensions that support OAuth 2.0 based authentication mechanisms that
> PostgreSQL can authenticate with.
Suggested alternative
On Wed, May 7, 2025 at 11:55 AM Fabrízio de Royes Mello
wrote:
> LGTM
Thanks for the review!
>> Tested with GNU Make 3.81 (the compilation of which was slightly
>> painful; does anyone want to debate pulling that minimum version up
>> sometime soon?) and 4.3.
>
> Not sure if all animals have a m
Hi all,
I forgot to put a recursion limit in the new OAuth parsers; the
server-side depth checks don't apply to the client, and it's not using
the incremental parser to move the burden from the stack to the heap.
Luckily, we track the nesting level already, so a fix (attached) can
be pretty small.
Hello!
Wolfgang reported over in [1] that I've missed a comma when appending
to the PKG_CONFIG_REQUIRES_PRIVATE list, making libpq.pc look ugly:
Requires.private: libssl, libcrypto libcurl
pkg-config itself appears to be papering over my mistake (a quick code
inspection suggests it treats co
On Sun, May 4, 2025 at 5:58 AM Wolfgang Walther wrote:
> The only inconsistency I was able to find is the autoconf-generated
> libpq.pc file, which has this:
>
>Requires.private: libssl, libcrypto libcurl
Oh, I see what I did. Will fix, thanks.
> I was only able to test the latter in an end-
Hi all,
A connection with only a hostaddr (no host) can't be cancelled via
PQcreateCancel(), because we'll crash in emitHostIdentityInfo(). The
problem is that the synthetic connhost entry we've created for
cancellation has an incorrect type field, which causes the following
code to make bad decis
On Thu, May 1, 2025 at 7:44 PM Bruce Momjian wrote:
> https://momjian.us/pgsql_docs/release-18.html
> +Add support for the "oauth" authentication (Jacob Champion, Daniel
> Gustafsson, Thomas Munro)
Should be either 'support for "oauth" authenti
On Fri, May 2, 2025 at 11:56 AM Jacob Champion
wrote:
> -I/opt/homebrew/Cellar/openssl@3/3.5.0/include
Except it _is_ right there.
Oh, ha -- I'm not using Homebrew's Curl in this minimal build. Looks
like it's coming from the sysroot.
% ls -l
/Library/Developer/Com
On Fri, May 2, 2025 at 11:52 AM Tom Lane wrote:
> $ pkg-config --cflags libcurl
> -I/opt/local/include -I/opt/local/libexec/openssl3/include
> -I/opt/local/include
>
> I bet Homebrew's libcurl packaging doesn't do that.
Nope, Homebrew breaks them out into smaller pieces:
% PKG_CONFIG_PATH=/
On Fri, May 2, 2025 at 11:26 AM Tom Lane wrote:
> Yeah, they are both under /opt/local/include in a MacPorts setup.
> But disabling NLS doesn't break it for me. I tried
>
> meson setup build --auto-features=disabled -Dlibcurl=enabled
>
> to make sure that /opt/local/include wasn't getting pulled
On Fri, May 2, 2025 at 10:31 AM Nathan Bossart wrote:
> Yup, thanks!
Great, thanks. I'll push it soon.
--Jacob
On Fri, May 2, 2025 at 10:35 AM Tom Lane wrote:
> FWIW, on my Mac a meson build from HEAD goes through fine, with or
> without this patch. I'm getting openssl and libcurl from MacPorts
> not Homebrew, but I don't know why that would make any difference.
Do your and live in the same place? Mine
On Fri, May 2, 2025 at 8:59 AM Jacob Champion
wrote:
> libintl is already coming in via frontend_stlib_code, so that's fine.
> So now I'm wondering if any other static clients of libpq-int.h (if
> there are any) need the ssl dependency too, for correctness, or if
> it'
On Fri, May 2, 2025 at 8:46 AM Jacob Champion
wrote:
> Yeah, I wonder if libintl is being similarly "cheated" on the Meson side.
libintl is already coming in via frontend_stlib_code, so that's fine.
So now I'm wondering if any other static clients of libpq-int.h (if
ther
On Fri, May 2, 2025 at 8:11 AM Nathan Bossart wrote:
>
> After commit b0635bf, I'm seeing the following meson build failures on
> macOS:
Thanks for the report, and sorry for the breakage.
> In file included from
> ../postgresql/src/interfaces/libpq-oauth/oauth-curl.c:51:
> ../po
On Thu, May 1, 2025 at 7:44 PM Bruce Momjian wrote:
> I will probably add markup in 1-3 weeks. Let the feedback begin. ;-)
Thanks!
>
> Version 18 contains a number of changes that may affect compatibility
> with previous releases. Observe the following incompatibilities:
>
>
On Mon, Apr 21, 2025 at 9:57 AM Jacob Champion
wrote:
> So to recap: I'm happy to add a Google compatibility mode, but I'd
> like to gather some evidence that their device flow can actually
> authorize tokens for third parties safely, before we commit to that.
> Thoughts
On Thu, May 1, 2025 at 12:24 PM Jacob Champion
wrote:
> I'm running the attached fixup through CI now.
(Pushed, and indri is happy again.)
--Jacob
On Thu, May 1, 2025 at 10:38 AM Jacob Champion
wrote:
> I've thrown some more Autoconf testing at Rocky, Mac, and Ubuntu.
>
> So, committed.
I forgot --enable-nls in my Mac testing, so indri complains about my
omission of -lintl... I'd incorrectly thought it was no longer n
On Wed, Apr 30, 2025 at 11:09 AM Daniel Gustafsson wrote:
> I'll try to kick the tyres a bit more as well.
Thanks! Alpine seems to be happy with the dlopen() arrangement. And
I've thrown some more Autoconf testing at Rocky, Mac, and Ubuntu.
So, committed. Thanks everyone for all the excellent fe
On Wed, Apr 30, 2025 at 5:55 AM Daniel Gustafsson wrote:
> > To keep things moving: I assume this is unacceptable. So v10 redirects
> > every access to a PGconn struct member through a shim, similarly to
> > how conn->errorMessage was translated in v9. This adds plenty of new
> > boilerplate, but
1 - 100 of 1198 matches
Mail list logo
