> On 6 Mar 2024, at 10:07, Peter Eisentraut wrote:
>
> On 22.11.23 13:47, Alvaro Herrera wrote:
>> On 2023-Mar-07, Daniel Gustafsson wrote:
>>> The attached POC diff replace fgets() with pg_get_line(), which may not be
>>> an
>>> Ok way to cross the s
unning fleets of instances. I'm marking
these Ready for Committer, unless there are objections I think we should go
ahead with these. There are probably more errors in the system which could
benefit from the same treatment, but we need to start somewhere.
--
Daniel Gustafsson
> On 4 Mar 2024, at 23:49, Nathan Bossart wrote:
>
> On Mon, Mar 04, 2024 at 10:03:13PM +0100, Daniel Gustafsson wrote:
>> Cleaning out my inbox I came across this which I still think is worth doing,
>> any objections to going ahead with it?
>
> I think the genera
> On 16 Nov 2023, at 21:49, Daniel Gustafsson wrote:
>
> In the "Allow tests to pass in OpenSSL FIPS mode" thread [0] it was discovered
> that 3DES is joining the ranks of NIST disallowed algorithms. The attached
> patch adds a small note to the pgcrypto documentation
> On 4 Mar 2024, at 18:22, Nathan Bossart wrote:
>
> On Mon, Mar 04, 2024 at 03:21:59PM +0100, Daniel Gustafsson wrote:
>> Looking at this again I think this is about ready to go in. My only comment
>> is
>> that doc/src/sgml/archive-modules.sgml probably sh
> On 14 Feb 2024, at 21:48, Daniel Gustafsson wrote:
>> On 14 Feb 2024, at 19:51, Nathan Bossart wrote:
>> On Wed, Feb 14, 2024 at 10:04:49AM -0500, Tom Lane wrote:
>>> Daniel Gustafsson writes:
>>>> Attached is a diff to show what it would look lik
essage there.
--
Daniel Gustafsson
> On 4 Mar 2024, at 02:01, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> I took the liberty to add this to the upcoming CF to make sure we don't lose
>> track of it.
>
> Thanks for doing that, because the cfbot pointed out a problem:
> I should have wri
> On 1 Mar 2024, at 14:57, Andrey M. Borodin wrote:
>
>> On 1 Mar 2024, at 17:29, Daniel Gustafsson wrote:
>>
>> The call for a CFM volunteer is still open.
>
> I always wanted to try. And most of the stuff I'm interested in is already
> commit
> On 29 Feb 2024, at 22:26, Daniel Gustafsson wrote:
> We are now hours away from starting the last commitfest for v17
It is now March 1 in all timezones, so I have switched 202403 to In Progress
and 202307 to Open. There are a total of 331 patches registered with 286 of
those in an open
can't, but the
important part is that we get someone with the time and energy to invest.
Anyone interested?
--
Daniel Gustafsson
u agree,
let's drop this from the patchset to make it easier to digest. We should make
sure we keep pluggability such that another library can be supported though,
much like the libpq TLS support.
--
Daniel Gustafsson
> On 22 Jan 2024, at 11:09, Daniel Gustafsson wrote:
> Feel free to go ahead with that
> version, or let me know if you want me to deal with it.
I took the liberty to add this to the upcoming CF to make sure we don't lose
track of it.
--
Daniel Gustafsson
> On 28 Feb 2024, at 19:50, Jelte Fennema-Nio wrote:
>
> On Wed, 28 Feb 2024 at 19:04, Daniel Gustafsson wrote:
>> This should be "equal to or higher" right?
>
> Correct, nicely spotted. Fixed that. I also updated the docs for the
> new backtrace_functions_mi
they
exist. If their consultants and suppliers, who have a higher probability of
knowing this, hasn't told them then it's highly unlikely that anything we say
will get across.
--
Daniel Gustafsson
> On 29 Feb 2024, at 09:13, Michael Banck wrote:
> In any case, users will have a couple of years to migrate as usual if
> they upgrade to v16.
As you say, there are many years left of AIX being supported so there is plenty
of runway for planning a migration.
--
Daniel Gustafsson
oint, that's more readable in this commit.
> In 0002, at the beginning of pg_SASL_init, the `password` variable now
> has an uninitialized code path. The OAuth patchset initializes it to
> NULL:
Nice catch, fixed.
--
Daniel Gustafsson
v2-0001-Refactor-SASL-exchange-to-return-tri-sta
vers, not
> sure if they would be of any use.
The main benefit would be to be able to provide a full testharness without
adding any additional dependencies over what we already have (Python being
required by meson). That should ideally make it easy to get good coverage from
BF animals as no installation is needed.
--
Daniel Gustafsson
in and I'll circle around to it.
--
Daniel Gustafsson
Management System
>
>> This change can be omitted, which makes the conversion even simpler.
>
> That's a pretty convincing proof-of-concept. Let's just do this,
> and then make sure to keep the file legible as plain text.
+1
--
Daniel Gustafsson
> On 28 Feb 2024, at 19:51, Alvaro Herrera wrote:
>
> On 2024-Feb-28, Joe Conway wrote:
>
>> Markdown is pretty readable as text, I'm not sure why we need both.
>
> *IF* people don't go overboard, yes. I agree, but let's keep an eye so
> that it doesn't become an unreadable mess. I've seen s
set.
I'm not excited about adding even more GUCs but maybe it's the least bad option
here.
+If a log entry is raised with a level higher than
+ and the name of the
This should be "equal to or higher" right?
--
Daniel Gustafsson
);
While not a bug per se, it reads a bit odd to call another operation that can
allocate memory when the oom flag has been set. I think we can move some
things around a little to make it clearer.
The attached diff contains some (most?) of the above as a patch on top of your
v17, but as a .txt to
> On 28 Feb 2024, at 18:02, Nathan Bossart wrote:
>
> On Wed, Feb 28, 2024 at 02:46:11PM +0100, Daniel Gustafsson wrote:
>>> On 26 Feb 2024, at 21:30, Tom Lane wrote:
>>> Nathan Bossart writes:
>>>> I think this would be nice. If the Markdown version is
resql.org/ftp/. That being said, a
majority of those reading the README will likely be new developers accustomed
to Markdown (or doing so via interfaces such as Github) so going to Markdown
might not be a bad idea. We can also render a plain text version with pandoc
for release builds should we want to.
--
Daniel Gustafsson
d in
sslfiles.mk and adding it to the config would make the documentation more
consistent.
> Attached is a patch attempting to fix the description issue.
Thanks, I'll have another look and will apply.
--
Daniel Gustafsson
> On 27 Feb 2024, at 22:03, Heikki Linnakangas wrote:
> Any objections to removing the ./configure --with-CC option? It's been
> deprecated since commit cb292206c5 from July 2000:
None, and removing it will chip away further at getting autoconf and meson
fully in sync so
end adding a testcase to it to keep the
regression from reappearing. src/test/regress/sql/timestamp.sql might be a
good candidate testsuite.
--
Daniel Gustafsson
> On 27 Feb 2024, at 06:08, Michael Paquier wrote:
>
> On Mon, Feb 26, 2024 at 12:28:51AM +0100, Daniel Gustafsson wrote:
>> Yeah, I think this is for HEAD only, especially given the lack of complaints
>> against backbranches.
>
> Daniel, are you planning to look a
codes
> while the logic of the function is unchanged does not strike me as
> something to backpatch as it could slightly break applications. On
> HEAD, I'm OK with that.
Yeah, I think this is for HEAD only, especially given the lack of complaints
against backbranches.
--
Daniel Gustafsson
neric enough to be translated anyways via
another (un)related ereport call then we of course use that, but ideally not
create new ones.
--
Daniel Gustafsson
ardless.
+ int errnum = 0;
Stylistic nit, we typically don't initialize a variable which cannot be
accessed before being set.
Overall the patch looks sane, please register it for the next commitfest to
make it's not missed.
--
Daniel Gustafsson
descriptve names IMHO.
The second patch sets password_needed during SASL init on the SCRAM exchanges.
This was implicit in the code but since not all future exchanges may require
password, do it explicitly per mechanism instead.
--
Daniel Gustafsson
[0] d1b467a78e0e36ed85a09adf979d04cf124a9d4b.ca
le to create a new error code specifically for
> this?
We use ERRCODE_UNDEFINED_OBJECT for similar errors elsewhere, perhaps we can
use that for these as well?
--
Daniel Gustafsson
commits f55808828569, a1675649e402 and 6f84b2da75d3 in the
postgres repo as a starting point for research. The QNX support which was
removed in 8.2 was targeting QNX4, so it may or may not be helpful.
--
Daniel Gustafsson
ng at the code
before that happened might give some insights on how to get started?
--
Daniel Gustafsson
> On 22 Feb 2024, at 10:55, Ashutosh Bapat wrote:
> On Thu, Feb 22, 2024 at 3:03 PM Daniel Gustafsson wrote:
> Somebody looking for dump/restore tests wouldn't search
> src/bin/pg_upgrade, I think.
Quite possibly not, but pg_upgrade is already today an important testsuite fo
: Dump A, restore into B, upgrade B into C, dump C and compare C
to A.
--
Daniel Gustafsson
itmap,
> gingetbitmap, blgetbitmap) the return value is of correct int64 type
That being said, changing it like this seems reasonable since the API is
defined as int64, and it will keep static analyzers quiet.
--
Daniel Gustafsson
ment.
Looks good on a quick skim, I'll take care of this shortly.
--
Daniel Gustafsson
> On 20 Feb 2024, at 13:40, Peter Eisentraut wrote:
>
> On 20.02.24 12:39, Daniel Gustafsson wrote:
>> A fifth option is to throw away our in-tree implementations and use the
>> OpenSSL
>> API's for everything, which is where this thread started. If the effort
make failures aren't missed. If we get there by slimming
down numeric_big to keep the unique coverage then that sounds like a good plan
to me.
--
Daniel Gustafsson
> On 20 Feb 2024, at 13:24, Robert Haas wrote:
>
> On Tue, Feb 20, 2024 at 5:09 PM Daniel Gustafsson wrote:
>> A fifth option is to throw away our in-tree implementations and use the
>> OpenSSL
>> API's for everything, which is where this thread started. If
;segment bin %zu (no
contiguous free pages):\n", i);
+ else
+ fprintf(stderr,
+ "segment bin %zu (at least
%d contiguous pages free):\n",
+ i, 1 << (i - 1));
--
Daniel Gustafsson
e
using the OpenSSL implementations for everything, I don't think it's too far
fetched.
--
Daniel Gustafsson
rything, which is where this thread started. If the effort to
payoff ratio is palatable to anyone then patches are for sure welcome.
> Does Linux provide some way of asking whether "fips=1" was specified
> at kernel boot time?
There is a crypto.fips_enabled sysctl but I have no idea how portable that is
across distributions etc.
--
Daniel Gustafsson
ferent API's for doing this in OpenSSL
1.0.2 and OpenSSL 3.x, so a solution must take both into consideration.
--
Daniel Gustafsson
ve in parallel_schedule, even on slow
hardware like my ~5 year old laptop. Repeated runs in CI at various parallel
groups place it at 50% the runtime of triggers.sql and 25% of brin.sql.
To make sure it's executed and not silently breaks, is it time to add this to
the regular make check?
--
Daniel Gustafsson
s and add explicit error checking at the
>> sites it points out. And then if we start using autodie in the future, any
>> inappropriate backpatching of calls lacking error checks would be caught.
>
> Yeah, that should work.
I didn't study the referenced rules but the concept see
. The cipher
must be allowed *and* the implementation must be certified.
--
Daniel Gustafsson
> On 16 Feb 2024, at 13:57, Peter Eisentraut wrote:
>
> On 16.02.24 10:16, Daniel Gustafsson wrote:
>>> 2. The crypt() and gen_salt() methods built on top of them (modes of
>>> operation, kind of) are not FIPS-compliant.
>> I wonder if it's worth try
> On 15 Feb 2024, at 16:21, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> On 15 Feb 2024, at 11:38, Peter Eisentraut wrote:
>>> We don't have a man page for pg_regress, so there is no place to
>>> comprehensively document all the options and their i
guarantees about FIPS which isn't really the case since postgres
isn't FIPS certified.
--
Daniel Gustafsson
the cooling-off period (it's a SPAM prevention
measure), but I don't have access to it. In the meantime I've added the patch
for you, and once the cooling off is over we can add your name as author.
https://commitfest.postgresql.org/47/4835/
I'm currently reviewing it
bout alternate output files which also are undocumented. Maybe
it's time to add documentation for pg_regress?
--
Daniel Gustafsson
[0] CACX+KaPOzzRHEt4w_=iqkbtpmkjyrugvng1c749yp3r6dpr...@mail.gmail.com
ut trailing
>> whitespaces when I was changing sgml files specifically.
>
> +1 from me. But when do we want it to be false? That is, why not
> declare it true for all file types?
Regression test .out files commonly have spaces at the end of the line. (Not
to mention the ECPG .c files
> On 14 Feb 2024, at 19:51, Nathan Bossart wrote:
>
> On Wed, Feb 14, 2024 at 10:04:49AM -0500, Tom Lane wrote:
>> Daniel Gustafsson writes:
>>> On 14 Feb 2024, at 11:35, Dave Page wrote:
>>>> That said, pgAdmin III has been out of support for many years
d for years in V16->.
If anyone still uses pgAdminIII then I have a hard time believing they are
diligently updating to the latest major version of postgres..
Attached is a diff to show what it would look like to remove adminpack (catalog
version bump omitted on purpose to avoid conflicts until co
> On 13 Feb 2024, at 22:29, Nathan Bossart wrote:
>
> On Mon, Feb 12, 2024 at 09:49:45AM -0600, Nathan Bossart wrote:
>> Okay. I'll plan on committing this in the next few days.
>
> Here is what I have staged for commit.
LGTM.
--
Daniel Gustafsson
> On 12 Feb 2024, at 21:46, Nathan Bossart wrote:
>
> On Mon, Feb 12, 2024 at 09:39:06PM +0100, Daniel Gustafsson wrote:
>>> On 12 Feb 2024, at 21:32, Bharath Rupireddy
>>> wrote:
>>> I happened to notice a typo in pg_rotate_logfile in ipc/signalfuncs.c
>
s
> 1.0 SQL function dropped in 2.0. The core defines pg_rotate_logfile
> SQL function instead, so use that. Here's a patch to fix the typo.
Nice catch! This needs to be backpatched all the way down to 12 as that
function wen't away a long time ago (it was marked as deprecated all the way
back in 9.1).
--
Daniel Gustafsson
The existing SSL tests pass with it,
> tested on Debian stable. (Though it took me a few iterations to figure out
> how to run the SSL tests, so it's possible I've missed something.)
We've done a fair bit of work on making them easier to run, so I'm curious if
you saw any room for improvements there as someone coming to them for the first
time?
--
Daniel Gustafsson
pped like this, and restricting it now without a clear
usecase for doing so seems invasive (and someone might very well be using
this). 0001 in the attached adjusts this.
--
Daniel Gustafsson
v2-0002-Support-wildcard-in-backtrace_functions-to-handle.patch
Description: Binary data
v2-0001-doc-C
The attached v5 is a rebase with no new changes just to get a fresh run in the
CFBot before pushing. All review comments have been addressed and the patch
has been Ready for Committer for some time, just didn't have time to get to it
in the last CF.
--
Daniel Gustafsson
v5-0001-Ref
> On 9 Feb 2024, at 00:04, Daniel Gustafsson wrote:
>
>> On 8 Feb 2024, at 15:16, Daniel Gustafsson wrote:
>
>> One option could perhaps be to include a version number for <= comparison,
>> and
>> if set to zero a function pointer to a version check fu
> On 8 Feb 2024, at 15:16, Daniel Gustafsson wrote:
> One option could perhaps be to include a version number for <= comparison, and
> if set to zero a function pointer to a version check function must be
> provided?
> That would handle the simple cases in a single place w
it is like you say, far from guaranteed
to work.
--
Daniel Gustafsson
e provided?
That would handle the simple cases in a single place without messy logic, and
leave the more convoluted checks with a special case function.
--
Daniel Gustafsson
v12-0001-pg_upgrade-run-all-data-type-checks-per-connecti.patch
Description: Binary data
> On 8 Feb 2024, at 08:01, Peter Eisentraut wrote:
> I suppose we could start using it for completely new scripts.
+1, it would be nice to eventually be able to move to it everywhere so starting
now with new scripts may make the eventual transition smoother.
--
Daniel Gustafsson
> On 1 Feb 2024, at 02:21, Yugo NAGATA wrote:
> On Tue, 30 Jan 2024 13:44:28 +0100
> Daniel Gustafsson wrote:
>> -setup_cancel_handler(void)
>> +pg_dump_setup_cancel_handler(void)
>>
>> We don't have any other functions prefixed with pg_dump_, based on th
> On 7 Feb 2024, at 14:15, Alvaro Herrera wrote:
>
> On 2024-Feb-07, Daniel Gustafsson wrote:
>
>> Since the CF app knows when the last email in the thread was, the
>> state of the patch entry and the number of CF's which is has been
>> present in; maybe we ca
> On 30 Jan 2024, at 15:44, Alvaro Herrera wrote:
> I propose to turn the list into a
>
> which looks _much_ nicer to read, as in the attached screenshot of the
> PDF.
+1, this reads a lot better.
--
Daniel Gustafsson
> On 6 Feb 2024, at 17:47, Daniel Gustafsson wrote:
>
>> On 6 Feb 2024, at 17:32, Nathan Bossart wrote:
>>
>> On Fri, Feb 02, 2024 at 12:18:25AM +0530, vignesh C wrote:
>>> With no update to the thread and the patch still not applying I'm
>>>
the state of the
patch entry and the number of CF's which is has been present in; maybe we can
extend the app to highlight these patches in a way which doesn't add more
manual intervention? It might yield a few false positives, but so will setting
it manually.
--
Daniel Gustafsson
an updated rebase shortly with the hopes of getting it
committed this week.
--
Daniel Gustafsson
> On 6 Feb 2024, at 12:45, Ильясов Ян wrote:
>
> I agree with your argument.
> Thank you for your time.
Thank you for your report!
--
Daniel Gustafsson
it mainly serves to silence analyzers. Grepping for
the pattern of allocating in the declaration doesn't reveal any other codepaths
where the allocation leaks like this.
--
Daniel Gustafsson
that have been allocated for char** dirnames is
> not freed.
dirnames isn't allocated at this point, it's palloc'd after this return
statement on line 67.
--
Daniel Gustafsson
7;t know how to
update the CFBot (it might just happen automagically).
--
Daniel Gustafsson
> On 31 Jan 2024, at 16:39, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> I think it should, the idea of that check is to catch calls to actual exits,
>> while this is instrumentation which has nothing to do with exit(2). The
>> attached diff should be enough to h
to do with exit(2). The
attached diff should be enough to handle this.
--
Daniel Gustafsson
tsan_exit_exclusion.diff
Description: Binary data
> Why is it GUC_REPORT at all? I don't see a strong need for that.
> (In particular, the report would be delivered too late to be of any
> use in client authentication.)
It's needed by PQencryptPasswordConn.
--
Daniel Gustafsson
out to avoid confusion, but I don't have strong feelings if you
think it should be added.
--
Daniel Gustafsson
ith pg_dump_, based on the naming
of the surrounding code in the file I wonder if set_cancel_handler is a more
appropriate name?
--
Daniel Gustafsson
but we should still fix it.
Unsurprisingly this seems to have been there forever (since July 2005) so needs
to be backpatched to all supported branches for the sake of consistency
--
Daniel Gustafsson
> On 23 Jan 2024, at 23:33, Tom Lane wrote:
> Anyway, v2-0001 below is the previous patch rebased up to current
> (only line numbers change), and then v2-0002 responds to your
> and Daniel's review comments.
LGTM.
--
Daniel Gustafsson
ent
across the tree, consistency within a file is preferrable (regardless of
which).
--
Daniel Gustafsson
> On 19 Jan 2024, at 17:33, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> I'll give some more time for opinions, then I'll go ahead with one of the
>> patches with a backpatch to v16.
>
> OK, I take back my previous complaint that just using st
uires that you compile with --with-llvm. If you don't have llvm in
the PATH you might need to set LLVM_CONFIG to point to your llvm-config binary.
With autotools that would be something like:
./configure --with-llvm LLVM_CONFIG=/path/to/llvm-config
--
Daniel Gustafsson
> On 18 Jan 2024, at 05:49, Kyotaro Horiguchi wrote:
>
> Thank you for upicking this up.
>
> At Wed, 17 Jan 2024 23:47:41 +0100, Daniel Gustafsson wrote
> in
>>> On 17 Jan 2024, at 21:33, Tom Lane wrote:
>>>
>>> I wrote:
>>>> Howeve
and it's quite odd that it only
happens on FreeBSD. I need to investigate further so I'll mark this waiting on
author in the meantime.
--
Daniel Gustafsson
> On 19 Jan 2024, at 11:04, Michael Banck wrote:
>
> Hi,
>
> On Fri, Jan 19, 2024 at 10:48:12AM +0100, Daniel Gustafsson wrote:
>> This does bring up an interesting point, I don't think there is a way
>> for a user to know whether the server is jit enabled or
tree. This does bring up an interesting point, I don't think there is a way
for a user to know whether the server is jit enabled or not (apart from
explaining a query with costs adjusted but that's not all that userfriendly).
Maybe we need a way to reliably tell if JIT is active or not.
--
Daniel Gustafsson
only moves
the assembly of newline to the different cases (replace vs. new) keeping the
rest of the code intact. Keeping it in one place gets sort of messy too since
it needs to use different values for a replacement and a new variable. Not
sure if there is a cleaner approach?
--
Daniel Gustafsson
v3-0001-Make-initdb-c-option-case-insensitive.patch
Description: Binary data
plain about duplicate entries, they just take the
> last setting.
Agreed, I think the patch as it stands now where it replaces case insensitive,
while keeping the original casing, is the best path forward. The issue exist
in 16 as well so I propose a backpatch to there.
--
Daniel Gustafsson
it makes sense to avoid wasting CI cycles on commits only changing
README files since we know it will be a no-op. A README documentation patch
going through N revisions will incur at least N full CI runs which are
resources we can spend on other things. So +1 for doing this both in CI and in
the buildfarm.
--
Daniel Gustafsson
don't think that a CF entry is necessary.
It isn't, I've now committed it backpatched down to 12.
--
Daniel Gustafsson
l.
The patch seems fine to me, the attached version is rebased, pgindented and has
a test case added.
--
Daniel Gustafsson
[0]
https://www.postgresql.org/message-id/flat/2844176.1674681919%40sss.pgh.pa.us
v2-0001-Make-initdb-c-option-case-insensitive.patch
Description: Binary data
at so I'll go ahead
and backpatch that down to v15.
--
Daniel Gustafsson
> On 16 Jan 2024, at 02:53, Kirk Wolak wrote:
>
> On Mon, Jan 15, 2024 at 9:03 AM Daniel Gustafsson <mailto:dan...@yesql.se>> wrote:
> > On 15 Jan 2024, at 07:24, Kirk Wolak > <mailto:wol...@gmail.com>> wrote:
>
> > You have a commit [1]
301 - 400 of 1358 matches
Mail list logo
