yone is keen on
digging through the list for any relevant fixes?
> So, can we declare that we don't support this compiler anymore?
>
> (gcc is readily available and seems to work alright, so I'm not saying the OS
> is no longer viable.)
+1 based on the findings above.
--
Daniel Gustafsson
> On 3 Sep 2025, at 10:37, Peter Eisentraut wrote:
>
> On 28.08.25 15:29, Daniel Gustafsson wrote:
>>> On 28 Aug 2025, at 08:53, Peter Eisentraut wrote:
>>> I addressed all those, and did another cleanup pass over the script. (The
>>> formatting is from pg
LE branches.
>
> Thanks for the patch. It looks good to me. I'll take care of it.
Agreed, this looks correct.
--
Daniel Gustafsson
> On 1 Sep 2025, at 03:58, Michael Paquier wrote:
>
> On Wed, Aug 27, 2025 at 09:49:34PM +0200, Daniel Gustafsson wrote:
>> When looking into why the SNI tests failed on Windows I think I found a
>> pre-existing issue that we didn't have tests for, which my patch a
> On 15 Aug 2025, at 12:20, Nazir Bilal Yavuz wrote:
> On Fri, 15 Aug 2025 at 12:19, Daniel Gustafsson wrote:
>>
>>> On 15 Aug 2025, at 10:46, Nazir Bilal Yavuz wrote:
>>> Sometimes OpenBSD CI tasks fail with 'No space left on device' [1].
>>>
t; Corey Huinker claims to be working on the list of acknowledgments [0], but
> I don't see any patches proposed yet.
FWIW I have a list of names of v18 contributors put together for an upcoming
talk which I intended to cross-reference against what got proposed here. If
the list is procure
> On 24 Aug 2025, at 23:23, Daniel Gustafsson wrote:
> I'll work on getting it in at the start of the week.
While not exactly the start of the week, this is now done.
--
Daniel Gustafsson
s "committs" to "commits" which is what it should do.
Agreed, pushed.
--
Daniel Gustafsson
#x27;t have to worry about it.
That is certainly an option.
--
Daniel Gustafsson
> On 29 Aug 2025, at 09:36, m.korot...@postgrespro.ru wrote:
>
> Daniel Gustafsson wrote 2025-08-29 10:13:
>> This is not actually a leak since the application will terminate immediately
>> if
>> a restrict key cannot be generated.
> I agree that the current
= generate_restrict_key();
if (!restrict_key)
pg_fatal("could not generate restrict key");
--
Daniel Gustafsson
e bootstrap default for these variables in guc_tables.c, although in
* principle it could be different.
*/
Apart from those small remarks, +1 on this patch. For future work, once this
has landed, it could be neat to add formatting checks to ensure long/short_desc
end with prope
ut of (happy) accident, but it can be
reproduced in HEAD as well. The attached version modifies the ssl tests to
cover this with a connection attempt. If I'm not mistaken though, there should
probably be a docs patch to make it clear how this works on Windows.
No codechanges on top of the tes
g /dev/urandom with a more modern API, but after sleeping on it
I'm less convinced that a'la carte CSPRNG configuration has enough upsides to
warrant the risk of users accidentally becoming non-FIPS compliant.
Another related thing to consider, uuid-ossp contrib module use arc4random() in
the non e2fs case.
--
Daniel Gustafsson
54)
> :sort.collations ( 0 0)
> :sort.nullsFirst ( false false)
> ```
>
> The unnecessary whitespace is now removed.
What about external parsers written for this format which might now break?
(Judging by the commitlog I believe this format is intentional and not a bug.)
--
Daniel Gustafsson
> On 24 Aug 2025, at 23:21, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 1 Jul 2025, at 17:42, Tom Lane wrote:
>>> There are some minor typos in the proposed commit message, too.
>
>> It seems that my grasp of the english language went on holiday
gt; increase it more.
I don't know Cirrus enough to know if this is a daft question, but does this
impact the cost (in actual money or credits) for running the CI tests?
--
Daniel Gustafsson
> On 6 Aug 2025, at 06:49, Fujii Masao wrote:
> I've added Assert(*line != NULL) at the start of filter_get_keyword().
> Updated patch attached.
LGTM.
--
Daniel Gustafsson
o 18 and master?
Thanks for reviving this. I am +1 on placing this behind PG_TEST_EXTRA as was
discussed upthread.
--
Daniel Gustafsson
;is empty" could be interpreted as being a null pointer, maybe we should
add a if (!*line) check (or an Assert) before we dereference the passed in
buffer?
--
Daniel Gustafsson
;s something that still needs to be done for PG18.
>
> I don't have a strong opinion, but I lean towards having them on
> by default.
I agree with that, while there might be a lot of cases where disabling
checksums is the right move it's still a sane default.
--
Daniel Gustafsson
this would not be that but a small step on
that path (whether or not that's the appropriate step is debatable).
For installations without OpenSSL, getrandom() as an API over /dev/urandom
still works when /dev is chrooted away. That subset might be too small to
spend code on though.
--
Daniel Gustafsson
d version also adds a commit message, tweaks the documentation along
with a few small changes to error message handling etc.
The base64 code this extends is the RFC 2045 variant while base64url is based
on base64 from RFC 3548 (obsoleted by RFC 4648). AFAICT this is not a problem
here but has anyone else ver
in the usage output, which is fixed in 0002.
--
Daniel Gustafsson
v2-0002-Fix-incorrect-option-name-in-usage-screen.patch
Description: Binary data
v2-0001-Consistently-handle-tab-delimiters-for-wait-event.patch
Description: Binary data
an option at configure time?
I would not be opposed to starting there.
--
Daniel Gustafsson
> On 25 Jul 2025, at 00:22, Bruce Momjian wrote:
>
> On Wed, Jul 2, 2025 at 06:23:52PM +0200, Daniel Gustafsson wrote:
>>> On 2 Jul 2025, at 04:51, Steve Chavez wrote:
>>
>>> While updating an extension to support 18beta1, I stumbled on the removal
>>
pick a commmitter
can deal with, no need for a new version IMO).
--
Daniel Gustafsson
seline we can also make use of the _priv_bytes
functions to get increased isolation.
--
Daniel Gustafsson
ng downtime unless beaten to it.
--
Daniel Gustafsson
grepping for
> "Postgres95" didn't find any, but ...
Grepping around with a bit of fuzzy matching I too was unable to find more
omissions.
--
Daniel Gustafsson
> On 11 Jul 2025, at 17:53, Bernd Helmle wrote:
> Since i wanted to dig a little deeper in this patch i took the
> opportunity and rebased it to current master, hopefully not having
> broken something seriously.
Thanks, much appreciated!
--
Daniel Gustafsson
> On 10 Jul 2025, at 09:33, Daniel Gustafsson wrote:
>
>> On 5 Jul 2025, at 10:56, Peter Eisentraut wrote:
>
>> This patch version looks good to me.
>
> Thanks for review, I'll get it committed shortly.
This was committed yesterday ahead of the beta release.
--
Daniel Gustafsson
, can we rename the job with a "- Meson
> Auto" suffix or something, to try to call the difference out
> explicitly?
+1
--
Daniel Gustafsson
> On 5 Jul 2025, at 10:56, Peter Eisentraut wrote:
> This patch version looks good to me.
Thanks for review, I'll get it committed shortly.
--
Daniel Gustafsson
> On 4 Jul 2025, at 09:33, Nazir Bilal Yavuz wrote:
> On Thu, 3 Jul 2025 at 17:07, Daniel Gustafsson wrote:
>> An alternative approach would be to instead of having opt-in's for
>> non-Windows
>> have opt-outs for Windows, ie a MESON_WINDOWS_EXCLUDES which does =di
> On 2 Jul 2025, at 13:44, Peter Eisentraut wrote:
>
> On 27.06.25 19:24, Daniel Gustafsson wrote:
>> The OpenSSL code in libpq have two issues for multithreading: the verify_cb
>> callback use a global variable to pass back error detail state and there is
>
> On 3 Jul 2025, at 15:50, Nazir Bilal Yavuz wrote:
> On Thu, 3 Jul 2025 at 16:21, Daniel Gustafsson wrote:
>> + # Like 'MESON_COMMON_FEATURES' but not shared with 'Windows - VS' task too
>> + MESON_NON_VS_FEATURES: >-
>>
>> I'm not
e -Dnls=disabled -DTAR=%TAR
% build"
+%BASH% -c "meson setup %MESON_COMMON_PG_CONFIG_ARGS% -Ddebug=true
-Doptimization=g -Db_pch=true %MESON_COMMON_NON_VS_FEATURES% -D
TAR=%TAR% build"
The MinGW build no longer disables nls, or am I missing something?
--
Daniel Gustafsson
luding since it's otherwise not
documented anywhere.
--
Daniel Gustafsson
hat conditional (which also matches what Meson does). Please see the
> attached.
Nice catch. On that note, shouldn't we also be updating ppport.h with a new
--compat-version run?
--
Daniel Gustafsson
if this looks acceptable or if further refinement is needed.
+ pg_log_error("superuser name must not be empty");
+ exit(1);
I would prefer pg_fatal() for this.
--
Daniel Gustafsson
> On 2 Jul 2025, at 10:06, Bertrand Drouvot
> wrote:
> On Wed, Jul 02, 2025 at 09:55:52AM +0200, Daniel Gustafsson wrote:
>> how about the attached?
>
> LGTM.
Thanks, committed.
--
Daniel Gustafsson
uration. The attached patch implements this change.
Big +1 on this, thanks for tackling it.
--
Daniel Gustafsson
Thanks, that does indeed look like an omission. There seems to be a few more
on the same page however, how about the attached?
--
Daniel Gustafsson
pg_buffercache.diff
Description: Binary data
the wrong thing.
Agreed, and it's not even clear that the previous code was intentionally trying
to allow an empty -U. An improved error message would be a good patch though.
--
Daniel Gustafsson
> On 1 Jul 2025, at 17:42, Tom Lane wrote:
> There are some minor typos in the proposed commit message, too.
It seems that my grasp of the english language went on holiday before I did.
The attached v9 is hopefully less terrible.
--
Daniel Gustafsson
v9-0001-pg_dump-Fix-compressi
> On 1 Jul 2025, at 17:11, Tomas Vondra wrote:
> On 7/1/25 16:24, Daniel Gustafsson wrote:
>> This version has been tested against v17 and v16 where it applies and passes
>> all tests (the latter isn't as assuring as it should be since there is a lack
>> of
> On 26 Jun 2025, at 20:01, Daniel Gustafsson wrote:
>
>> On 26 Jun 2025, at 15:33, Tom Lane wrote:
>
>> So on the whole I prefer the "void" approach. I'm not dead
>> set on that though, it's just a niggling worry.
>
> I think the likely
> On 29 Jun 2025, at 12:56, Peter Eisentraut wrote:
>
> On 27.06.25 11:15, Daniel Gustafsson wrote:
>>> On 26 Jun 2025, at 23:06, Daniel Gustafsson wrote:
>>> I'll propose changes for these comments in the morning when coffee has been
>>> had.
>>
able to fill the one role they
had, maybe it's time to just remove them?
--
Daniel Gustafsson
> On 30 Jun 2025, at 20:33, Jacob Champion
> wrote:
>
> 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
faces/libpq-oauth/libpq-oauth.a' could not be found
> ninja: build stopped: subcommand failed.
>
> 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.
--
Daniel Gustafsson
through 3.5. Parking this in the next
commitfest.
--
Daniel Gustafsson
0001-libpq-Fix-multithreading-issues-in-the-OpenSSL-suppo.patch
Description: Binary data
> On 26 Jun 2025, at 23:06, Daniel Gustafsson wrote:
> I'll propose changes for these comments in the morning when coffee has been
> had.
The attached moves to logging on stderr along with a test for this, and also
removes the WARNING prefix that was added to the other stderr
> On 26 Jun 2025, at 22:49, Peter Eisentraut wrote:
>
> On 03.04.25 17:51, Daniel Gustafsson wrote:
>>> On 1 Apr 2025, at 22:22, Daniel Gustafsson wrote:
>>>
>>> I took another pass at this one and did a few small tweaks, so I would to
>>> take
>
gument than my "match an API we're still not aligned
with". The attached v7 reverts back to void return.
--
Daniel Gustafsson
v7-0001-Initial-patch-by-Tom-Lane.patch
Description: Binary data
v7-0002-pg_dump-compression-API-write_func.patch
Description: Binary data
v7-0003-pg
presetting errno to 0 and then
> replacing that with ENOSPC.
I went over all the fwrite callsites *in this patchset* and made sure they
follow the pattern. There are a number of more fwrite calls in pg_dump (and
elsewhere) which might need the same treatment but I left those for a separate
pat
ght well have missed some changes which aren't required to
backpatch, and if so we need to pull those out.
One thing this doesn't address is the lack of testing, which also should be
tackled (having fault injection capabilities for client utils would be neat).
--
Daniel Gustafsson
v5-000
like a good improvement. The first sentence feels a bit long, but it's
no dealbreaker.
--
Daniel Gustafsson
nd it
too fails to reproduce any issue.
--
Daniel Gustafsson
g version 15.0.0 (clang-1500.3.9.4) which corresponds to
LLVM 16. Nothing so far after running a testloop suggested by Andres off-list
for two hours.
--
Daniel Gustafsson
t; hitting a segfault a couple lines later.
If I break something here while hacking I'd probably prefer a segfault to an
Assert.
--
Daniel Gustafsson
> On 17 Jun 2025, at 15:40, Ranier Vilela wrote:
> In the function *PQcancelCreate* there is a copy-and-past thinko.
> The pointer that must be checked is cancelConn.
>
> Trivial patch attached.
Nice catch, will fix.
--
Daniel Gustafsson
pg_dump (but I'm not sure it's worth spending the
cycles in every upgrade to test for this, the check phase is already quite
extensive).
--
Daniel Gustafsson
Z_NULL? I suppose we could explicitly check/translate Z_NULL to NULL,
> although Z_NULL is simply defined as 0. I don't recall if NULL has some
> additional magic.
Right, to be clear, I don't think there is a bug here (or the risk one going
forward). It's just my own prefere
> On 16 Jun 2025, at 16:20, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 16 Jun 2025, at 15:56, Tom Lane wrote:
>>> I've not checked to see what the other users of this API do, but
>>> if they're all like this then we need to fix that comme
_getc can be simplified as well as
it no longer needs to call ferror, it still needs to check feof though.
--
Daniel Gustafsson
ill feels like a case of getting to keep both
pieces when breaking it, but I wonder if we shouldn't make it harder to break?
--
Daniel Gustafsson
e over
13200 tests in the log. Are you sure you are building with ZStd compression
enabled?
--
Daniel Gustafsson
> On 16 Jun 2025, at 10:52, Evgeniy Gorbanev wrote:
>
> 16.06.2025 14:25, Daniel Gustafsson пишет:
>>> On 16 Jun 2025, at 10:14, Evgeniy Gorbanev wrote:
>>> In src/bin/pg_dump/compress_zstd.c, the Zstd_read function always
>>> returns true. But if you
return false;
As cnt is coming from fread() returning false here would be wrong as you cannot
from 0 alone know if it's EOF or an error. Instead it needs to inspect the
stream with feof() and ferror() to know how to proceed.
--
Daniel Gustafsson
x27;m lacking imagination, but I fail to see how it's a security issue to
not set a byte to \0 when it is known to be \0?
--
Daniel Gustafsson
> On 12 Jun 2025, at 08:27, Peter Eisentraut wrote:
> The rest looks good to me.
FTR this was committed last week but I missed following up here.
--
Daniel Gustafsson
>
> Why can't we strictly restrict object creation in pg_catalog?
Do you have allow_system_table_mods set to ON by any chance? As Laurenz said,
such creation is already restricted, but it can be circumvented by using said
GUC (which is *not* intended for production usage).
--
Daniel Gustafsson
ble to
be selective with statistics?
--
Daniel Gustafsson
iferation of concepts rather than trying to make it fit/shoehorn into one
of the ones we already have?
--
Daniel Gustafsson
> On 5 Jun 2025, at 13:14, Peter Eisentraut wrote:
>
> On 07.04.25 02:55, Daniel Gustafsson wrote:
>>> On 7 Apr 2025, at 02:43, David G. Johnston
>>> wrote:
>>> How about:
>>>
>>> + "if set to a number, overrides the default
accounting for that extra byte in
> EstimateLibraryStateSpace()
The last '\0' written isn't performed in relation to the size, but at a fixed
index in the buffer:
...
}
start_address[0] = '\0';
How would that cause a buffer overflow?
--
Daniel Gustafsson
reed, I was going to support this warning but this comment convinced me
otherwise. pg_upgrade is messy as it is without tasking it with more usecases.
--
Daniel Gustafsson
to UTF-8 in
>> terms of space utilization.
>
> Given this, removing it seems like a non-starter.
Agreed, it seems very unappealing to remove something so important to such a
large userbase.
--
Daniel Gustafsson
> On 26 May 2025, at 08:44, Yugo Nagata wrote:
> -additionally an index is over these is stored to
> +additionally an index over these is stored to
Fixed, thanks!
--
Daniel Gustafsson
> On 20 May 2025, at 11:56, Daniel Gustafsson wrote:
>
>> On 20 May 2025, at 04:29, Tom Lane wrote:
>
>> I want to argue for reverting, at least for v18. I do not think that
>> ProcessGetMemoryContextInterrupt is anywhere near release-quality.
>> I found ou
in the pg_upgrade check with explanatory comments
if needed, and leave the functionality as is today.
--
Daniel Gustafsson
actly what we need to make informed decisions.
How prevalent is GB18030 usage, is it used in all postgres installations in
China, most of them or in some particular cases?
--
Daniel Gustafsson
> On 23 May 2025, at 11:55, Tomas Vondra wrote:
>
> On 5/23/25 11:25, Daniel Gustafsson wrote:
>>> On 23 May 2025, at 10:10, Heikki Linnakangas wrote:
>>
>>> Aside from just documenting it, I see two things we could do:
>>>
>>> 1. Have pg
ce people get the
> better.
+1
--
Daniel Gustafsson
, right, good point. I've managed to miss this part in
> pg_regress.c. Using the same value makes even more sense.
Agreed, and +1 on the change in general.
--
Daniel Gustafsson
est at some point is another thing,
but we are seeing a very good role-model for taking responsibility for ones
work here at the very least =)
--
Daniel Gustafsson
> On 20 May 2025, at 10:52, Peter Eisentraut wrote:
> src/test/ssl/t/SSL/Server.pm
While I don't have an immediate usecase or test in mind, having the SSL tests
use log_conections=all could be handy when hacking on the TLS support.
--
Daniel Gustafsson
and does so in TopMemoryContext.
Ugh, that's indeed a showstopper. Attached is a revert of the feature, I want
to re-read and re-test before pushing to make sure I didn't miss anything but
can go ahead with it later today.
--
Daniel Gustafsson
0001-Revert-function-to-get-memory-context-stats-f
e as you say limited in what we can/should do in that case
so immediately returning is the safer option. The attached also encodes the
example from this thread as a test using an interactive background.
(The attached has a small context id fix as well but the interesting bit is the
above.)
--
Da
> On 18 May 2025, at 01:29, Paul A Jungwirth
> wrote:
>
> Here is a very small comment fix, referencing the wrong function name.
> There's a lot of suffixes flying around right here.
Agreed, that seems like the right fix.
--
Daniel Gustafsson
27;m involved in, to
remove barriers to entry. Good commit messages are obviously very important,
but having your patch rejected (yes, I know, failing to apply) might not be
strongest motivator for achieving this.
--
Daniel Gustafsson
> On 16 May 2025, at 10:40, Daniel Gustafsson wrote:
> I will go ahead and push this to all supported branches.
Done. I also ensured that the text in the legal notice match the OSI license
text while in there.
--
Daniel Gustafsson
> On 16 May 2025, at 10:00, Tom Lane wrote:
>
> Dave Page writes:
>> On Fri, 16 May 2025 at 09:12, Daniel Gustafsson wrote:
>>> As was briefly discussed in the developers meeting, and the hallway track,
>>> at
>>> PGConf.dev we have a few variations on
As was briefly discussed in the developers meeting, and the hallway track, at
PGConf.dev we have a few variations on the organization wording which really
should be aligned with the wording defined by -core in pgweb commit 2d764dbc08.
--
Daniel Gustafsson
v1-0001-Align-organization-wording-in
> On 9 May 2025, at 23:50, Michael Paquier wrote:
>
> On Fri, May 09, 2025 at 07:21:17PM +0200, Daniel Gustafsson wrote:
>> -=item $node->log_check($offset, $test_name, %parameters)
>> +=item $node->log_check($test_name, $offset, %parameters)
>>
>> Ch
ers)
+=item $node->log_check($test_name, $offset, %parameters)
Check contents of server logs.
--
Daniel Gustafsson
> On 9 May 2025, at 18:42, Tom Lane wrote:
>
> Pushed all that stuff. The SSL tests pass for me now on OpenBSD 7.7,
> and hopefully the CI environment will be happy too.
Thanks!
--
Daniel Gustafsson
> On 9 May 2025, at 02:15, Tom Lane wrote:
> Daniel Gustafsson writes:
>> If we were to end up with a
>> Libressl libtls implementation in libpq we'd still have to test with Libressl
>> against the OpenSSL compat layer in libssl since it could act as both. Not
1 - 100 of 1618 matches
Mail list logo
