On Thu, Mar 20, 2025 at 3:02 PM David Rowley wrote:
> For making this work, I think the attached should be about the guts of
> the code changes. I didn't look at the comments. Right now I can't
> think of any reason why this can't be done, but some experimentation
> might reveal some reason that i
Hi,
On Wed, Apr 09, 2025 at 12:03:06PM +0900, Michael Paquier wrote:
> On Tue, Apr 08, 2025 at 06:42:53AM +, Bertrand Drouvot wrote:
> > Fully agree. Will need to find another way to prevent a process to wait
> > between the
> > wakeup and the detach. I'll open a dedicated thread.
>
> By the
Amit Langote writes:
> Should the following paragraph in src/backend/optimizer/README be
> updated to reflect the new reality after recent changes?
> An EquivalenceClass can contain "em_is_child" members, which are copies
> of members that contain appendrel parent relation Vars, transpose
On Mon, Apr 7, 2025 at 2:13 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> In the new v4 version
> of the patch the first option is implemented.
>
The patches don't apply cleanly using git am but patch -p1 applies
them cleanly. However I see following compilation errors
RuntimeError: command
On Wed, Apr 9, 2025 at 10:51 AM David Rowley wrote:
>
> On Wed, 9 Apr 2025 at 17:09, Amit Langote wrote:
> > Should the following paragraph in src/backend/optimizer/README be
> > updated to reflect the new reality after recent changes?
> >
> > An EquivalenceClass can contain "em_is_child" mem
On Wed, 9 Apr 2025 at 17:09, Amit Langote wrote:
> Should the following paragraph in src/backend/optimizer/README be
> updated to reflect the new reality after recent changes?
>
> An EquivalenceClass can contain "em_is_child" members, which are copies
> of members that contain appendrel pa
hi.
attached patch is for address pg_dump inconsistency
when parent is "not null not valid" while child is "not null".
The following query before/after pg_dump should return the same result.
select conrelid::regclass::text, conname, convalidated, coninhcount,
conislocal, conparentid, contype
fro
On Thu, Apr 3, 2025 at 3:16 PM Zhijie Hou (Fujitsu) wrote:
>
> On Thu, Apr 3, 2025 at 1:38 PM Masahiko Sawada wrote:
>
> >
> > On Wed, Apr 2, 2025 at 7:58 PM Amit Kapila
> > wrote:
> > >
> > > On Thu, Apr 3, 2025 at 7:50 AM Zhijie Hou (Fujitsu)
> > > wrote:
> > > >
> > > > On Thu, Apr 3, 2025 a
On Wed, Mar 26, 2025 at 3:54 PM Amit Kapila wrote:
>
> On Tue, Mar 25, 2025 at 5:30 PM Ashutosh Bapat
> wrote:
> >
> > On Thu, Mar 20, 2025 at 5:54 PM Amit Kapila wrote:
> > >
> > > *
> > > +
> > > + pg_createsubscriber
> > > + option
> > > +
> > > +
> > > + -a
> > > + --a
Hi,
In another thread I had previously suggested adding a 2nd synopsis to
the pg_createsubscriber docs. See [1, comment #5].
--
CURRENT
pg_createsubscriber [option...] { -d | --database }dbname { -D |
--pgdata }datadir { -P | --publisher-server }connstr
SUGGESTION
pg_createsubscriber [option
On Tue, Apr 08, 2025 at 06:42:53AM +, Bertrand Drouvot wrote:
> Fully agree. Will need to find another way to prevent a process to wait
> between the
> wakeup and the detach. I'll open a dedicated thread.
By the way, there is a small thing that's itching me a bit about the
change done in LogS
On Wed, 09 Apr 2025 at 10:34, Junwang Zhao wrote:
> On Wed, Apr 9, 2025 at 5:22 AM David Rowley wrote:
>>
>> On Wed, 9 Apr 2025 at 03:46, Peter Eisentraut wrote:
>> > To avoid creating an array on the stack, you could maybe write it with a
>> > pointer instead, like:
>> >
>> > const char * const
On Tue, Apr 08, 2025 at 11:21:31PM -0300, Euler Taveira wrote:
> The logical replication creates origin names as pg_SUBOID_RELID or pg_SUBOID.
> It means the maximum origin name is 24. This limited origin name also applies
> to pglogical that limits the name to 54 IIRC. I think that covers the majo
> On 8 Apr 2025, at 04:10, Jacob Champion
> wrote:
>
> On Mon, Apr 7, 2025 at 3:26 PM Jacob Champion
> wrote:
>> Sounds good. Any opinions from the gallery on what a "libpq plugin
>> subdirectory" in pkglibdir should be called? ("client", "modules",
>> "plugins"...?)
>
> Hm, one immediate cons
On Mon, Apr 7, 2025 at 2:58 PM Christoph Berg wrote:
> Why is this module worse? (I guess the answer is internal data
> structures... but does it have to be worse?)
It doesn't have to be, in general, and the coupling surface is small
enough (libpq_append_conn_error) that we have a relatively easy
On Wed, Apr 9, 2025 at 5:22 AM David Rowley wrote:
>
> On Wed, 9 Apr 2025 at 03:46, Peter Eisentraut wrote:
> > To avoid creating an array on the stack, you could maybe write it with a
> > pointer instead, like:
> >
> > const char * const query = "...";
> >
> > I haven't tested whether that resul
On Tue, Apr 8, 2025, at 5:25 PM, Nathan Bossart wrote:
> On Tue, Apr 08, 2025 at 04:44:02PM +0530, Amit Kapila wrote:
> > On Fri, Apr 4, 2025 at 7:58 PM Nathan Bossart
> > wrote:
> >> On Fri, Apr 04, 2025 at 05:16:43PM +0530, Amit Kapila wrote:
> >> > Can we dodge adding this push call if we rest
Hi,
I was looking at the recent push for the pg_createsubscription "--all"
option [1], because I was absent for several weeks prior.
I found some minor non-functional issues as follows:
==
doc/src/sgml/ref/pg_createsubscriber.sgml
1.
+ If the database name is not specified in publish
On Tue, Apr 8, 2025 at 11:12 PM Dean Rasheed wrote:
> On Tue, 8 Apr 2025 at 12:31, Andrei Lepikhov wrote:
> > On 4/4/25 09:37, Richard Guo wrote:
> > > With more exposure to the changes in ChangeVarNodes(), I have some
> > > more concerns. As I understand it, ChangeVarNodes() is designed to
> >
On Mon, Apr 7, 2025 at 7:34 PM Thomas Munro wrote:
>
> On Thu, Feb 13, 2025 at 1:40 PM Melanie Plageman
> wrote:
> > Thomas mentioned this to me off-list, and I think he's right. We
> > likely need to rethink the way parallel bitmap heap scan workers get
> > block assignments for reading and pref
On Mon, 7 Apr 2025 at 20:37, vignesh C wrote:
>
Thanks a lot to all the members who participated in the commitfest.
Here are the final numbers at the end of the commitfest:
status | End of Commitfest
+---
Needs review:
On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:14 AM Bruce Momjian wrote:
> > How does this patch help us avoid having to handle curl CVEs and its
> > curl's additional dependencies? As I understand the patch, it makes
> > libpq _not_ have additional de
On 4/8/25 15:06, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 17:44:19 +0500, Kirill Reshke wrote:
>> On Mon, 7 Apr 2025 at 23:00, Tomas Vondra wrote:
>>> I'll let the CI run the tests on it, and
>>> then will push, unless someone has more comments.
>>>
>>
>>
>> Hi! I noticed strange failure afte
Hi,
On 2025-04-08 01:17:17 +0200, Daniel Gustafsson wrote:
> > On 7 Apr 2025, at 17:43, Andres Freund wrote:
>
> >> + /*
> >> + * Hold the process lock to protect writes to process specific memory. Two
> >> + * processes publishing statistics do not block each other.
> >> + */
> >
> > s/specifi
Hi,
On 2025-04-07 09:09:39 +0200, Bernd Helmle wrote:
> Am Sonntag, dem 06.04.2025 um 23:02 -0400 schrieb Andres Freund:
> > On 2025-04-05 19:22:58 +0200, Alvaro Herrera wrote:
> > > I have pushed this now, hoping it won't explode.
> >
> > I have a WIP patch that adds gcc specific allocator attri
On 2025/04/09 6:27, Daniel Gustafsson wrote:
On 8 Apr 2025, at 18:41, Fujii Masao wrote:
I noticed that the third argument of pg_get_process_memory_contexts() is named
"retries" in pg_proc.dat, while the documentation refers to it as "timeout".
I've committed this patch as it was obvious
On 4/8/25 15:06, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 17:44:19 +0500, Kirill Reshke wrote:
>> On Mon, 7 Apr 2025 at 23:00, Tomas Vondra wrote:
>>> I'll let the CI run the tests on it, and
>>> then will push, unless someone has more comments.
>>>
>>
>>
>> Hi! I noticed strange failure a
Hi,
On 2025-04-09 01:10:09 +0200, Tomas Vondra wrote:
> On 4/8/25 15:06, Andres Freund wrote:
> > Hi,
> >
> > On 2025-04-08 17:44:19 +0500, Kirill Reshke wrote:
> >> On Mon, 7 Apr 2025 at 23:00, Tomas Vondra wrote:
> >>> I'll let the CI run the tests on it, and
> >>> then will push, unless someo
Hi,
On 2025-04-09 00:47:59 +0200, Tomas Vondra wrote:
> On 4/8/25 16:59, Andres Freund wrote:
> > Hi,
> >
> > On 2025-04-08 09:35:37 -0400, Andres Freund wrote:
> >> On April 8, 2025 9:21:57 AM EDT, Tomas Vondra wrote:
> >>> On 4/8/25 15:06, Andres Freund wrote:
> On 2025-04-08 17:44:19 +05
On Tue, Apr 8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> Jacob Champion:
> > On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther
> > wrote:
> > > And that should also not be a problem for distributions - they could
> > > offer a libpq and a libpq_oauth package, where only one of them can
On 4/8/25 16:59, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 09:35:37 -0400, Andres Freund wrote:
>> On April 8, 2025 9:21:57 AM EDT, Tomas Vondra wrote:
>>> On 4/8/25 15:06, Andres Freund wrote:
On 2025-04-08 17:44:19 +0500, Kirill Reshke wrote:
I think it's not right that something
hi,
On 2025-04-08 12:06:47 -0400, Melanie Plageman wrote:
> And a somewhat related point, with buffered IO, READ_STREAM_SEQUENTIAL
> disables prefetching to encourage OS readahead. I don't know if any
> other users than sequential scan should do this.
Worth adding that prefetches are only issued
On Mon, Apr 7, 2025 at 9:41 AM Jacob Champion
wrote:
> > Not sure, the code looks correct at first glance. However, you could
> > also just keep the libpq-oauth strings in the libpq catalog. There
> > isn't really a need to make a separate one, since the versions you end
> > up installing are lo
On 4/8/25 15:41, Hannu Krosing wrote:
On Tue, Apr 8, 2025 at 8:39 PM Nathan Bossart wrote:
...
I've also verified that the dependency information is carried over in
upgrades to later versions (AFAICT all the supported ones).
If I remember correctly the change to not copying
pg_largeobject
> On 8 Apr 2025, at 18:41, Fujii Masao wrote:
> I noticed that the third argument of pg_get_process_memory_contexts() is named
> "retries" in pg_proc.dat, while the documentation refers to it as "timeout".
I've committed this patch as it was obviously correct, thanks!
> Also, as I mentioned ear
On Wed, 9 Apr 2025 at 03:46, Peter Eisentraut wrote:
> To avoid creating an array on the stack, you could maybe write it with a
> pointer instead, like:
>
> const char * const query = "...";
>
> I haven't tested whether that results in different or better compiled
> code. The original code is pro
Heikki Linnakangas writes:
> On 08/04/2025 16:55, Tom Lane wrote:
>> + The trigger will replace the field's value only if that value is
>> + initially zero or null (after the action of the SQL statement that
>> + inserted or updated the row). Also, if the sequence's next value is
>> + zer
On Tue, Apr 8, 2025 at 6:37 PM Tom Lane wrote:
>
> Hannu Krosing writes:
> > I think we do preserve role oids
>
> Oh ... I'd been looking for mentions of "role" in
> pg_upgrade_support.c, but what I should have looked for was
> "pg_authid". So yeah, we do preserve role OIDs, and maybe that's
> e
Jacob Champion:
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
And that should also not be a problem for distributions - they could offer a
libpq and a libpq_oauth package, where only one of them can be installed at the
same time, I guess? *
My outsider understanding is that maintain
On Wed, 9 Apr 2025 at 03:54, Bruce Momjian wrote:
> We did have this discussion when AoE was chosen for PG 18 and the idea
> was that as long as it is before April 18 midnight wherever you are, it
> is not feature freeze yet.
I think it maybe once made sense for the moment to stop accepting new
p
On Wed, 9 Apr 2025 at 02:24, Tom Lane wrote:
>
> David Rowley writes:
> > I've pushed the patch now. Thanks for all the reviews of my adjustments.
>
> Shouldn't the CF entry be marked committed?
I've done that now.
88f55bc97 added code to do faster lookups of ec_derives clauses, so I
think that
On Tue, Apr 8, 2025 at 06:42:19PM +0200, Daniel Gustafsson wrote:
> > On 8 Apr 2025, at 18:33, Bruce Momjian wrote:
>
> > Would we have to put out minor releases for curl CVEs? I don't think we
> > have to for OpenSSL so would curl be the same?
>
> Why do you envision this being different from
On Tue, Apr 08, 2025 at 04:44:02PM +0530, Amit Kapila wrote:
> On Fri, Apr 4, 2025 at 7:58 PM Nathan Bossart
> wrote:
>> On Fri, Apr 04, 2025 at 05:16:43PM +0530, Amit Kapila wrote:
>> > Can we dodge adding this push call if we restrict the length of the
>> > origin name to some reasonable limit
On Wed, 2025-04-02 at 17:58 +0530, Shlok Kyal wrote:
> I reviewed the patch and I have a comment:
Thank you and vignesh for the feedback. This patch didn't quite make it
for v18, but I will address it for the next CF.
Regards,
Jeff Davis
On Tue, Apr 8, 2025 at 3:34 AM Daniel Gustafsson wrote:
> > On 8 Apr 2025, at 04:10, Jacob Champion
> > wrote:
> > Hm, one immediate consequence of hardcoding pkglibdir is that we can
> > no longer rely on LD_LIBRARY_PATH for pre-installation testing.
> > (Contrast with the server, which is able
On 08/04/2025 16:55, Tom Lane wrote:
Well, I don't mind pushing it, but does anyone want to review
it first? It sounded like Heikki had at least eyeballed the
patch, but I'm not sure if he's ready to sign off on it.
It looks good to me.
diff --git a/doc/src/sgml/contrib-spi.sgml b/doc/src/sg
On Tue, Apr 8, 2025 at 11:25 AM Bruce Momjian wrote:
> However, is this
> true for libpq libraries or database server libraries. Does it matter?
The dependency on Curl is through libpq. We have some server-side
features that pull in libpq and would transitively depend on Curl. But
for Curl to be
On Tue, Apr 8, 2025 at 10:36 AM Jacob Champion
wrote:
> Yeah, but it's one of those things that feels like it must have been
> solved by the others in the space. Once it's installed, the concern
> goes away (unless you demand absolute relocatability without
> recompilation). I'll take a look at ho
On 2025-04-08 Tu 11:45 AM, Peter Geoghegan wrote:
On Tue, Apr 8, 2025 at 11:20 AM Nathan Bossart wrote:
+1 for UTC.
+1, I think that AoE is needlessly obscure
+1
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On Tue, Apr 8, 2025 at 02:11:19PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 13:02:11 -0400, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> > > Jacob Champion:
> > > > On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther
> > > > wrote:
> > > > >
Hi,
On 2025-04-08 13:02:11 -0400, Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 06:57:18PM +0200, Wolfgang Walther wrote:
> > Jacob Champion:
> > > On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther
> > > wrote:
> > > > And that should also not be a problem for distributions - they could
> > > >
On Tue, Apr 8, 2025 at 10:10 AM Wolfgang Walther
wrote:
> And if that means making libpq modular at run-time, then this should be
> planned and built with all deps, and other use-cases (like static linking) in
> mind - and not like it is right now.
I think that'd be neat in concept, but specifi
Nathan Bossart writes:
> On Tue, Apr 08, 2025 at 01:36:58PM -0400, Tom Lane wrote:
>> Hmm ... one annoying thing for this project is that AFAICS pg_upgrade
>> does *not* preserve database OIDs, which is problematic for using
>> COPY to load pg_shdepend rows.
> I think it does; see commit aa01051.
Nathan Bossart writes:
> Unless I'm missing something, we don't seem to have had any dependency
> handling before commit 12a53c7. Was that broken before we moved to SQL
> commands?
Sounds like it :-(
regards, tom lane
On Tue, Apr 08, 2025 at 05:13:15PM +0200, Daniel Gustafsson wrote:
>> On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
>> Frankly, I think the name "anywhere on Earth" is confusing, since it
>> really is "everywhere on Earth":
>
> I find both of the above needlessly confusing when we instead could u
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
> This means that shipping another .so file will not happen with this approach.
> Assuming OAuth will be picked up by some of the bigger providers, that
> would... make me feel quite bad about it, actually.
It occurs to me that I didn't res
On Tue, Apr 08, 2025 at 01:36:58PM -0400, Tom Lane wrote:
> Hmm ... one annoying thing for this project is that AFAICS pg_upgrade
> does *not* preserve database OIDs, which is problematic for using
> COPY to load pg_shdepend rows.
I think it does; see commit aa01051.
--
nathan
Hmm ... one annoying thing for this project is that AFAICS pg_upgrade
does *not* preserve database OIDs, which is problematic for using
COPY to load pg_shdepend rows.
regards, tom lane
On Tue, Apr 8, 2025 at 10:15 AM Bruce Momjian wrote:
> Well, if we think we are going to do that, it seems we would need a
> different architecture than the one being proposed for PG 18, which
> could lead to a lot of user/developer API churn.
A major goal of the current patch proposal is to expl
Hannu Krosing writes:
> In copy case I would expect the presence of grants to not make much
> difference.
aclitemin is slower than a lot of other datatype input functions,
but it's still got to be faster than a GRANT.
regards, tom lane
On Tue, Apr 8, 2025 at 10:13:46AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 10:10 AM Wolfgang Walther
> wrote:
> > And if that means making libpq modular at run-time, then this should be
> > planned and built with all deps, and other use-cases (like static linking)
> > in mind - and
Ashutosh Bapat writes:
> Any timezone based deadline might be seen as unfair to those for whom
> that time falls in their respective nights. AoE removes that
> unfairness.
... only with an interpretation of AoE that is shared by nobody.
It's quite clear that everyone else on this thread reads the
On Tue, Apr 8, 2025 at 9:57 AM Wolfgang Walther wrote:
> if it's really the case that cURL is that much worse
(it is not, but I am sympathetic to the argument that if you don't use
it, you don't need it in the process space)
> However, if the other deps are considered problematic as well, then t
On Tue, Apr 8, 2025 at 12:07 PM Melanie Plageman
wrote:
> We've said before that maintenance_io_concurrency should govern work
> done on behalf of many different sessions. That was said to include at
> least vacuum and recovery. I need to change the index vacuum users to
> use READ_STREAM_MAINTENA
Jacob Champion:
However, if the other deps are considered problematic as well, then the
ship has already sailed, and there is not point for a special case here
anymore.
I think this line of argument is unlikely to find traction. Upthread
there were people asking if we could maybe split out other
Junwang Zhao writes:
> On Tue, Apr 8, 2025 at 4:29 PM Japin Li wrote:
>> - static const char query[] = "set client_encoding to '%s'";
>> + const char query[] = "set client_encoding to '%s'";
> I doubt that, if you remove the *static*, it will allocate more memory
> on stack and
Nathan Bossart writes:
> I do think it's worth considering going back to copying
> pg_largobject_metadata's files for upgrades from v16 and newer.
(If we do this) I don't see why we'd need to stop at v16. I'm
envisioning that we'd use COPY, which will be dealing in the
text representation of acl
On Tue, Apr 8, 2025 at 10:00:56AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:49 AM Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 09:43:01AM -0700, Jacob Champion wrote:
> > > By adding the new .so to a different package. For example, RPM specs
> > > would just let you say "hey, th
On Tue, Apr 8, 2025 at 9:49 AM Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 09:43:01AM -0700, Jacob Champion wrote:
> > By adding the new .so to a different package. For example, RPM specs
> > would just let you say "hey, this .so I just built doesn't go into the
> > main client package, it goes
On Tue, Apr 8, 2025 at 9:32 AM Wolfgang Walther wrote:
> And that should also not be a problem for distributions - they could offer a
> libpq and a libpq_oauth package, where only one of them can be installed at
> the same time, I guess? *
My outsider understanding is that maintaining this sort
On Tue, Apr 08, 2025 at 12:37:43PM -0400, Tom Lane wrote:
> Hannu Krosing writes:
>> I think we do preserve role oids
>
> Oh ... I'd been looking for mentions of "role" in
> pg_upgrade_support.c, but what I should have looked for was
> "pg_authid". So yeah, we do preserve role OIDs, and maybe th
On Tue, Apr 8, 2025 at 09:43:01AM -0700, Jacob Champion wrote:
> On Tue, Apr 8, 2025 at 9:33 AM Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> > > It allows packagers to ship the OAuth library separately, so end users
> > > that don't want the additiona
On Tue, Apr 8, 2025 at 9:30 PM Peter Eisentraut wrote:
>
> On 08.04.25 16:59, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> >> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> >> Earth):
> >>
> >>
> >> https://wiki.postgres
Hi,
Over the course of the last two releases, we have added many read
stream users. Each user specifies any number of flags (defined at the
top of read_stream.h) which govern different aspects of the read
stream behavior.
There are a few inconsistencies (many caused by me) that I want to
iron out
On Tue, Apr 8, 2025 at 12:29 PM Andrew Dunstan wrote:
> The fact that there is this confusion is an indication that the AoE
> experiment is a failure. If it's not obvious, and people have to think
> about it, then it's not working. And I bet there is a huge number of
> people who have never even h
> On 8 Apr 2025, at 18:41, Fujii Masao wrote:
> On 2025/04/08 18:46, Daniel Gustafsson wrote:
>>> On 8 Apr 2025, at 10:03, Daniel Gustafsson wrote:
>>> There was a bug in the shmem init function which caused it to fail on
>>> Windows,
>>> the attached fixes that.
>> With this building green in C
On Tue, Apr 8, 2025 at 9:33 AM Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 09:17:03AM -0700, Jacob Champion wrote:
> > It allows packagers to ship the OAuth library separately, so end users
> > that don't want the additional exposure don't have to install it at
> > all.
>
> Okay, so how would t
> On 8 Apr 2025, at 18:33, Bruce Momjian wrote:
> Would we have to put out minor releases for curl CVEs? I don't think we
> have to for OpenSSL so would curl be the same?
Why do you envision this being different from all other dependencies we have?
For OpenSSL we also happily build against a ve
On 2025/04/08 18:46, Daniel Gustafsson wrote:
On 8 Apr 2025, at 10:03, Daniel Gustafsson wrote:
There was a bug in the shmem init function which caused it to fail on Windows,
the attached fixes that.
With this building green in CI over several re-builds, and another pass over
the docs and
On Tue, Apr 8, 2025 at 11:45:09AM -0400, Peter Geoghegan wrote:
> On Tue, Apr 8, 2025 at 11:20 AM Nathan Bossart
> wrote:
> > +1 for UTC.
>
> +1, I think that AoE is needlessly obscure
We did have this discussion when AoE was chosen for PG 18 and the idea
was that as long as it is before April
Jacob Champion:
The currently proposed patch would have you package and install a
separate .so module implementing OAuth, which the staticlib would load
once when needed. Similarly to how you still have to somehow
dynamically link your static app against Curl.
As a staticlib user, how do you fee
On 2025-04-08 Tu 12:11 PM, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
On 08.04.25 16:59, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Ear
On Tue, Apr 08, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
> On 08.04.25 16:59, Bruce Momjian wrote:
>> Anywhere on Earth (AoE) is a calendar designation that indicates
>> that a period expires when the date passes everywhere on Earth.
>
> Yes, that works intuitively when you spec
On 08.04.25 14:22, Junwang Zhao wrote:
When I read the libpq source code, I found unnecessary static type qualifiers
in PQsetClientEncoding().
diff --git a/src/interfaces/libpq/fe-connect.c
b/src/interfaces/libpq/fe-connect.c
index 0258d9ace3c..300ddfffd55 100644
--- a/src/interfaces/libpq/fe-c
On 08/04/2025 19:11, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
On 08.04.25 16:59, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Earth):
On Tue, Apr 8, 2025 at 06:00:27PM +0200, Peter Eisentraut wrote:
> On 08.04.25 16:59, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
> > > Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
> > > Earth):
> > >
> > >
> > > https://wi
On Tue, Apr 8, 2025 at 9:14 AM Bruce Momjian wrote:
> How does this patch help us avoid having to handle curl CVEs and its
> curl's additional dependencies? As I understand the patch, it makes
> libpq _not_ have additional dependencies but moves the dependencies to a
> special loadable library th
On Tue, Apr 8, 2025 at 06:01:42PM +0200, Wolfgang Walther wrote:
> Jacob Champion:
> > The above is discussing a patch to split this into its own loadable
> > module.
>
> Wasn't sure where to put this exactly, the thread is long and I couldn't
> find any discussion around it:
>
> How does the pr
On Tue, Apr 8, 2025 at 5:46 PM Nathan Bossart wrote:
>
> On Tue, Apr 08, 2025 at 09:35:24AM +0200, Hannu Krosing wrote:
> > On Tue, Apr 8, 2025 at 12:17 AM Nathan Bossart
> > wrote:
> >> That being said, I
> >> regularly hear about slow upgrades with many LOs, so I think it'd be
> >> worthwhile
On 4/8/25 11:20, Nathan Bossart wrote:
On Tue, Apr 08, 2025 at 05:13:15PM +0200, Daniel Gustafsson wrote:
On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
Frankly, I think the name "anywhere on Earth" is confusing, since it
really is "everywhere on Earth":
I find both of the above needlessly con
On 08.04.25 16:59, Bruce Momjian wrote:
On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
Earth):
https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
https://www.timeandda
Jacob Champion:
The above is discussing a patch to split this into its own loadable
module.
Wasn't sure where to put this exactly, the thread is long and I couldn't
find any discussion around it:
How does the proposal with a loadable module affect a static libpq.a?
I have not tried, yet, bu
Committed.
--
nathan
On Tue, Apr 8, 2025 at 12:34:02PM +0200, Daniel Gustafsson wrote:
> > On 8 Apr 2025, at 04:10, Jacob Champion
> > wrote:
> >
> > On Mon, Apr 7, 2025 at 3:26 PM Jacob Champion
> > wrote:
> >> Sounds good. Any opinions from the gallery on what a "libpq plugin
> >> subdirectory" in pkglibdir shou
On Tue, Apr 8, 2025 at 11:20 AM Nathan Bossart wrote:
> +1 for UTC.
+1, I think that AoE is needlessly obscure
--
Peter Geoghegan
On Tue, Apr 08, 2025 at 09:35:24AM +0200, Hannu Krosing wrote:
> On Tue, Apr 8, 2025 at 12:17 AM Nathan Bossart
> wrote:
>> That being said, I
>> regularly hear about slow upgrades with many LOs, so I think it'd be
>> worthwhile to try to improve matters in v19.
>
> Changing the LO export to dum
Hi,
On 2025-04-08 11:13:51 -0400, Bruce Momjian wrote:
> On Tue, Apr 8, 2025 at 08:04:22AM -0700, Jacob Champion wrote:
> > On Tue, Apr 8, 2025 at 7:32 AM Bruce Momjian wrote:
> > > Uh, where are we on the inclusion of curl in our build? Maybe it was
> > > explained but I have not seen it.
> >
> On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
>
> On Tue, Apr 8, 2025 at 10:36:45AM -0400, Bruce Momjian wrote:
>> Since we recorded feature freeze as April 8, 2025 0:00 AoE (anywhere on
>> Earth):
>>
>> https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items#Important_Dates
>> https://www.
On Tue, Apr 8, 2025 at 11:20:11AM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-04-08 11:13:51 -0400, Bruce Momjian wrote:
> > On Tue, Apr 8, 2025 at 08:04:22AM -0700, Jacob Champion wrote:
> > > On Tue, Apr 8, 2025 at 7:32 AM Bruce Momjian wrote:
> > > > Uh, where are we on the inclusion of cu
Daniel Gustafsson writes:
> On 8 Apr 2025, at 16:59, Bruce Momjian wrote:
>> Frankly, I think the name "anywhere on Earth" is confusing, since it
>> really is "everywhere on Earth":
> I find both of the above needlessly confusing when we instead could use UTC
> which is a more universally unders
1 - 100 of 149 matches
Mail list logo
