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
> On 8 May 2025, at 22:24, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 8 May 2025, at 15:49, Tom Lane wrote:
>>> I was feeling itchy about having two copies of code that looks none
>>> too set-in-stone. Maybe we should just do that. Any preferenc
> On 8 May 2025, at 15:49, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 7 May 2025, at 23:54, Tom Lane wrote:
>>> +# Determine whether this build uses OpenSSL or LibreSSL. As a heuristic,
>>> the
>>> +# HAVE_SSL_CTX_SET_CERT_CB macro isn'
> On 7 May 2025, at 23:54, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> I haven't looked at the test in question yet, but we do skip some SSL tests
>> if
>> running against libressl already so I assume this will be able to follow the
>> same pattern.
&
nks for the patch, it looks correct to me so I will apply it in a bit.
--
Daniel Gustafsson
gt; that test case when using LibreSSL. Not sure what the most
> appropriate check would look like.
I haven't looked at the test in question yet, but we do skip some SSL tests if
running against libressl already so I assume this will be able to follow the
same pattern.
--
Daniel Gustafsson
> On 7 May 2025, at 18:04, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 7 May 2025, at 06:34, Tom Lane wrote:
>>> I couldn't help noticing that the backtraces went through
>>> lib/libssl/tls13_legacy.c, which doesn't give a warm feeling
&
no-op as we already use TLS_method() but via
an alias.
There's likely more OpenSSL code we can modernize, hopefully we can make some
progress on that during the v19 cycle.
--
Daniel Gustafsson
tls_method.diff
Description: Binary data
t.
https://postgr.es/m/CAFj8pRB10wvW0CC9Xq=1XDs=zcqxer3cblcnza+qix4cuh-...@mail.gmail.com
--
Daniel Gustafsson
> On 1 May 2025, at 00:04, Robert Haas wrote:
>
> On Wed, Apr 30, 2025 at 5:24 PM Daniel Gustafsson wrote:
>> Attached is a current v4 with a few small tweaks.
>
> Sorry to turn up late here, but I strongly disagree with the notion
> that this is a bug in the DSM or
rce owners.
> Earlier the chances of CurrentResourceOwner changing between the two
> functions were zero.
> May be something can be done to keep resowner assignments under both these
> functions
> in sync.
Hmm, that's a good question, not sure. Do you have a repro for this handy
e
patch slightly but due to $life and $work events have yet to have time to push
it.
--
Daniel Gustafsson
[0] 3eb40b3e-45c7-426a-b7f8-81f7d05a9...@oss.nttdata.com
> On 30 Apr 2025, at 19:59, Jacob Champion
> wrote:
> On Wed, Apr 30, 2025 at 5:55 AM Daniel Gustafsson wrote:
>> Nitpick, but it won't be .so everywhere. Would this be clearar if spelled
>> out
>> with something like "do not rely on libpq-int.h when buil
ere it is though.
+#if defined(USE_DYNAMIC_OAUTH) && defined(LIBPQ_INT_H)
+#error do not rely on libpq-int.h in libpq-oauth.so
+#endif
Nitpick, but it won't be .so everywhere. Would this be clearar if spelled out
with something like "do not rely on libpq-int.h when building libpq-oauth as
dynamic shared lib"?
--
Daniel Gustafsson
id go ahead with the strncpy and nul terminator assignment, mostly
out of muscle memory, but I agree that this would be a good place for a
strlcpy() instead.
--
Daniel Gustafsson
> On 25 Apr 2025, at 15:40, George MacKerron wrote:
>
>> On 25 Apr 2025, at 13:53, Daniel Gustafsson wrote:
>>>
>>>> (2) sslrootcert=system on Windows doesn’t do a thing that would be
>>>> extremely useful in some common situations. Namely: connec
ven disallow the ssl prefixed ones there.
I think that would be a mistake, 'SSL' has long lost its original meaning and
is now interpreted to be an umbrella term for "secure connections with
certificates and things". Sticking to ssl_* will most likely be the least
confusing for our users.
--
Daniel Gustafsson
> On 3 Apr 2025, at 16:26, Daniel Gustafsson wrote:
>
>> On 3 Apr 2025, at 14:41, George MacKerron wrote:
>
>> (2) sslrootcert=system on Windows doesn’t do a thing that would be extremely
>> useful in some common situations. Namely: connecting securely to
> On 23 Apr 2025, at 22:26, Jacob Champion
> wrote:
>
> On Tue, Apr 22, 2025 at 12:45 PM Jacob Champion
> wrote:
>> Great, thanks for the quick review!
>
> And pushed. Thanks everyone!
Congratulations on your first commit, looking forward to many more to come!
--
Daniel Gustafsson
> On 23 Apr 2025, at 02:01, Jacob Champion
> wrote:
> On Tue, Apr 22, 2025 at 3:10 AM Daniel Gustafsson wrote:
>> The attached
>> v3 allocates via the JSON api, no specific error handling should be required
>> as
>> it's already handled today.
>
>
pain?)
My preference is that no operation can silently work on a failed object, but
it's not a hill (even more so given where we are in the cycle). The attached
v3 allocates via the JSON api, no specific error handling should be required as
it's already handled today.
--
Daniel Gustafsson
variable, errbuf->len, is short and very descriptive I
wonder if we shouldn't just use this as it makes the code even clearer IMO.
--
Daniel Gustafsson
Do you have the error message/log for the failure handy?
--
Daniel Gustafsson
es about reentrancy for that to be safe.
Do you mean that an interrupt handler will make DSA allocations? I don't think
that would be something we'd want to allow regardless of this patch. Or did I
misunderstand the above?
--
Daniel Gustafsson
> On 21 Apr 2025, at 20:28, Jacob Champion
> wrote:
>
> On Mon, Apr 21, 2025 at 11:20 AM Daniel Gustafsson wrote:
>> Sure, but I fear we'll get an endless stream of static analysis reports for
>> the
>> allocation leaking if we don't free it.
>
> On 21 Apr 2025, at 17:33, Jacob Champion
> wrote:
>
> On Sat, Apr 19, 2025 at 2:15 PM Daniel Gustafsson wrote:
>> Since there is no way to determine if the allocation succeeded from outside
>> of
>> the JSON api it might be better to keep the calloc and ex
to determine if the allocation succeeded from outside of
the JSON api it might be better to keep the calloc and explicitly free it?
(Could a JsonLexContextBroken() function be useful perhaps?)
--
Daniel Gustafsson
v2-0001-Allocate-JsonLexContexts-on-the-heap-to-avoid-war.patch
Description: Binary data
_17_STABLE branches if there's no objection.
+1
--
Daniel Gustafsson
want to
> rewrite away the goto's in these callers ...
Agreed, moving to heap allocated structures for these callsites seem much
better. Something like the attached should be enough I think?
--
Daniel Gustafsson
0001-Allocate-JsonLexContexts-on-the-heap-to-avoid-warnin.patch
Description: Binary data
> On 17 Apr 2025, at 01:12, Tom Lane wrote:
>
> Michael Paquier writes:
>> On Wed, Apr 16, 2025 at 04:19:02PM +0200, Daniel Gustafsson wrote:
>>> Agreed, while it's perfectly safe today the end method should not make
>>> assumptions about the use of th
2) Do nothing.
>
> I'd like to do #1.
I vote for #1 as well.
--
Daniel Gustafsson
y
so that should be safe. Since I committed at least one of these, let me know
if you want me to tackle it.
--
Daniel Gustafsson
> On 17 Apr 2025, at 00:12, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 16 Apr 2025, at 23:42, Tom Lane wrote:
>>> I'm not sure
>>> how other than giving up on stack allocation of JsonLexContexts,
>>> though, especially if we consider
s is
> * updated to remove the list of matched varinfos"
> I've attached a patch for that.
Seems like a correct change.
--
Daniel Gustafsson
d EndCompressorZstd().
Agreed, while it's perfectly safe today the end method should not make
assumptions about the use of the private_data pointer upon return and should
leave it set to NULL.
--
Daniel Gustafsson
> On 15 Apr 2025, at 23:03, David Rowley wrote:
> My vote is to make the levels 1-based in all locations where we output
> the context information.
I agree with this, pg_get_process_memory_contexts() also use 1-based levels
fwiw.
--
Daniel Gustafsson
> On 15 Apr 2025, at 14:41, Robert Haas wrote:
>
> On Tue, Apr 15, 2025 at 3:46 AM Daniel Gustafsson wrote:
>>> On 15 Apr 2025, at 06:22, Amul Sul wrote:
>>> Attached is a patch that corrects the code comment for
>>> process_directory_recursively() in
partition \"%s\".")
>
> So we can easily understand which index is already attached for
> partition \"%s\".
That seems like it could be handy. As this relates to chaning old and existing
behavior, and we are in feature freeze, I suggest registering this in the
commitfest app.
--
Daniel Gustafsson
.
Agreed. The second paragraph in the comment also seem a bit odd, how about the
below while we are there fixing things?
- * If processing is a user-defined tablespace, the tsoid should be the OID
+ * If processing a user-defined tablespace, the tsoid should be the OID
--
Daniel Gustafsson
> On 9 Apr 2025, at 20:45, Daniel Gustafsson wrote:
>
>> On 9 Apr 2025, at 20:41, Jacob Champion
>> wrote:
>>
>> Hello,
>>
>> On Thu, Apr 3, 2025 at 8:51 AM Daniel Gustafsson wrote:
>>> Committed, after another round of testing and look
t to automate?
Existing spellcheckers for code usually have quite high rates of false
positives, so any automated tooling would have to avoid that to not become a
burden rather than a help. Personally I think it's something which is best
suited for manual processing with manual review of findings, much like static
code analysis.
--
Daniel Gustafsson
case of an error so if we really
want to clamp down on path generation we should probably check that as well.
--
Daniel Gustafsson
afe to let it prove itself in testable
versions before going further back with it.
--
Daniel Gustafsson
v3-0001-Don-t-try-to-enlarge-resourceowner-when-releasing.patch
Description: Binary data
> On 9 Apr 2025, at 13:48, Daniel Gustafsson wrote:
>> On 9 Apr 2025, at 12:02, Peter Eisentraut wrote:
>> could probably do with a less generic name?
>
> Good point, unless objected to I'll apply the attached renaming which then
> also
> contain the PGDLLIM
lit this into its own loadable
> module. Andres and Christoph's feedback has been shaping where we put
> that module, exactly.
There is also an open item registered for this.
--
Daniel Gustafsson
n the shmem init function which caused it to fail on Windows,the attached fixes that.
--Daniel Gustafsson
v29-0001-Add-function-to-get-memory-context-stats-for-pro.patch
Description: Binary data
> On 9 Apr 2025, at 20:41, Jacob Champion
> wrote:
>
> Hello,
>
> On Thu, Apr 3, 2025 at 8:51 AM Daniel Gustafsson wrote:
>> Committed, after another round of testing and looking.
>
> I think we may want to consider marking sslkeylogfile as a debug
> option
less generic name?
Good point, unless objected to I'll apply the attached renaming which then also
contain the PGDLLIMPORT addition.
--
Daniel Gustafsson
0001-Rename-global-variable-backing-DSA-area.patch
Description: Binary data
t;modules",
>> "plugins"...?)
>
> 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 to relocate extension paths
> based on its executable location.)
That strikes me as a signifant drawback.
--
Daniel Gustafsson
, sorry about it getting a bit lost among all the emails.
--
Daniel Gustafsson
[0] cah2l28shr0j3je5v3cxdfmdh-agtsnh2v8pr23x0uhrmbdq...@mail.gmail.com
> 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
uild against a version (and until recently,
several versions) which is EOL and don't even recieve security fixes.
--
Daniel Gustafsson
both of the above needlessly confusing when we instead could use UTC
which is a more universally understood concept.
--
Daniel Gustafsson
> On 8 Apr 2025, at 13:40, Nazir Bilal Yavuz wrote:
> This is already fixed on b2bdb972c0, attached patch just adds
> $MBUILD_TARGET to the NetBSD and OpenBSD CI tasks.
After review and testing, I applied this to master.
--
Daniel Gustafsson
> 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 code with pgindent etc done, I pu
> On 7 Apr 2025, at 17:43, Andres Freund wrote:
>
> Hi,
>
> On 2025-04-07 15:41:37 +0200, Daniel Gustafsson wrote:
>> I think this function can be a valuable debugging aid going forward.
>
> What I am most excited about for this is to be able to measure server-w
readability
* Various bits of polish
I think this function can be a valuable debugging aid going forward.
--
Daniel Gustafsson
v26-0001-Add-function-to-get-memory-context-stats-for-pro.patch
Description: Binary data
s, number is better. I'll go ahead with that in the morning.
--
Daniel Gustafsson
> On 6 Mar 2025, at 14:12, Dave Page wrote:
> On Thu, 6 Mar 2025 at 12:19, Daniel Gustafsson <mailto:dan...@yesql.se>> wrote:
>> > On 6 Mar 2025, at 12:05, Dave Page > > <mailto:dp...@pgadmin.org>> wrote:
>> >
>> > Further to my p
query buffer\n");
+ "if set to an interval value, overrides the default two
second \\watch interval\n");
--
Daniel Gustafsson
shouldn't or that needs to be removed from the GUC declaration.
--
Daniel Gustafsson
> On 2 Apr 2025, at 23:44, Daniel Gustafsson wrote:
> I think this version is close to a committable state, will spend a little more
> time testing, polishing and rewriting the commit message. I will also play
> around with placement within the memory context code files to keep it f
> On 3 Apr 2025, at 16:26, Daniel Gustafsson wrote:
>> On 3 Apr 2025, at 14:41, George MacKerron wrote:
>> Your diff certainly fixes (1b), so it’s definitely an improvement.
>
> Thanks, unless Jacob objects I propose to apply that backpatched down to when
> sslrootcert=
as
correct (we don't do that for any), but at least it will catch if setting a
default totally breaks \watch.
--
Daniel Gustafsson
v7-0001-psql-Make-default-watch-interval-configurable.patch
Description: Binary data
Assert(read_stream_next_buffer(stream, NULL) == InvalidBuffer);
Is there a non programmer-error case where this can happen? The Assert right
after a loop around the same function seems to imply there is a race or toctou
case which if so could use a comment.
--
Daniel Gustafsson
is going to have? Perhaps
> some other feature (pg_service as URL?) is going to need libcurl as
> well, but it should be configurable separately.
Perhaps --with-oauth-client for the opt-in libpq-oauth?
--
Daniel Gustafsson
> On 3 Apr 2025, at 22:54, Melanie Plageman wrote:
> On Thu, Apr 3, 2025 at 4:22 PM Daniel Gustafsson wrote:
>> + while (p->pos < apw_state->prewarm_stop_idx)
>> + {
>> + BlockInfoRecord blk = p->block_info[p->pos];
>> +
>> + CH
I'm not
sure it's worth the churn really as it's been there since 2012. Changing it
might introduce conflicts in backpatching for little gain.
> - Two DEBUG2 messages in `xlog.c` seem less important to fix (0003).
>
> - I don't think it's worth bothering with those in developer tools (0004).
Agreed.
--
Daniel Gustafsson
I made in
> the #ifdefs.
> - 0002 should fix some timeouts in 002_client.pl reported by Andres on
> Discord. I allowed a short connect_timeout to propagate into tests
> which should not have it.
Thanks, both LGTM so pushed.
--
Daniel Gustafsson
> 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
> it for another spin across CI before looking at committing it. There are no
> functionality changes, only polish.
Committed, after another r
our
efforts are much appreciated! Don't take no's in this thread as an objection
to your idea and mission. Most likely we will support winstore in some way in
v19, we just need to make sure we develop features in a way which is
sustainable wrt our available resources and our development process.
--
Daniel Gustafsson
that's not really a concern.
--
Daniel Gustafsson
ll be in the way for anyone running autoheader. Any objection to me
pushing the attached?
--
Daniel Gustafsson
timingsafe.diff
Description: Binary data
;system" means is a good idea, but I also don't think
limiting ourselves to those two values is helpful. We either need to make a
new param. to over time replace sslrootcert with, which can handle multiple
different values; or we need to retrofit a DSL/syntax to sslrootcert for
differentiating. Both have in common that the coding task is magnitudes easier
than figuring out the user experience.
Something to consider for v19 work.
--
Daniel Gustafsson
rootcertsystem.diff
Description: Binary data
r a niche feature and I while I'm still not
sure 1Mb is the right value I think from experimentation that it's closer.
I think this version is close to a committable state, will spend a little more
time testing, polishing and rewriting the commit message. I will also play
around with pla
probably should allow
winstore (and other such stores for other platforms when/if they happen) I
don't think making it the only option is the right way.
> The winstore is new to me. Is there no way to get OpenSSL to switch
> its default store without code changes?
AFAIK one cannot change the default store in OpenSSL short of recompiling
OpenSSL.
--
Daniel Gustafsson
I took another pass at this one and did a few small tweaks, so I would to take
it for another spin across CI before looking at committing it. There are no
functionality changes, only polish.
--
Daniel Gustafsson
v11-0001-libpq-Add-support-for-dumping-SSL-keylog-to-file.patch
Description
> On 1 Apr 2025, at 19:01, Alvaro Herrera wrote:
> Thanks!
Thanks for taking this one across the finishing line!
--
Daniel Gustafsson
1 - 100 of 1541 matches
Mail list logo
