t privs
from SHARED_DEPENDENCY_OWNER to SHARED_DEPENDENCY_INITACL, so that these can be
mopped up with a later DROP OWNED? Trying this in a POC patch it fails with
RemoveRoleFromInitPriv not removing the rows, shortcircuiting that for a test
seems to make it work but is it the right approach?
--
Daniel Gustafsson
rms like Github register the patch against the tree at the
time of submitting, and won't refresh unless the user does so. Github does
detect bitrot and show a "this cannot be merged" error message, but it doesn't
alter any state on the PR etc.
--
Daniel Gustafsson
onally there is a large developer meeting shortly which many are busy
preparing for. Excercise some patience, and I'm sure there will be follow-ups
to this once development of postgres v18 picks up.
--
Daniel Gustafsson
nother scan for SSL related patches in flight at the time.
--
Daniel Gustafsson
ace in time.
Magnus' commitmessage explains it well. The way I've used it (albeit
infrequently) is to point to a specific mail in the thread where a significant
change was proposed, like the patch changhing direction or something similar.
--
Daniel Gustafsson
> On 16 May 2024, at 19:47, Tom Lane wrote:
> Yeah, it's not worth working harder than this. I do see one typo
> in your comment: s/supported then/supported when/. LGTM otherwise.
Thanks for review, I've pushed this (with the fix from above) to 14 through 12.
--
Daniel Gustafsson
e CF
app does however provide that overview. This is essentially the TODO list
aspect, but sharing one's TODO isn't all bad, especially for maintainers.
--
Daniel Gustafsson
> On 17 May 2024, at 00:03, Peter Eisentraut wrote:
> I think, if we consider the core mission of the commitfest app, we need to be
> more protective of the Needs Review state.
IMHO this is a very very good summary of what we should focus on with this
work.
--
Daniel Gustafsson
ture detail could be if the system would send an
automated email to the thread summarizing the entry when it's marked as
"committed"?
--
Daniel Gustafsson
> On 17 May 2024, at 07:57, Peter Eisentraut wrote:
>
> On 16.05.24 23:27, Daniel Gustafsson wrote:
>>> On 16 May 2024, at 11:43, Peter Eisentraut wrote:
>>> You might want to run your patch through pgperltidy. The result doesn't
>>> look bad, but a bit
on the thread to measure "activity/hotness", but starting with the
simple boolean data we already have could be a good start.
--
Daniel Gustafsson
ses the file for each call. It might be nice if
> it could accept a list. Or you can just pass the whole block as one string,
> like it was done for pg_ident.conf before.
The attached v2 pass the whole block as a here-doc which seemed like the best
option to retain readability of the config.
--
> On 16 May 2024, at 13:56, Alvaro Herrera wrote:
> I think we should also take patch 0005 in pg17, which reduces the number
> of strings to translate.
Agreed, lessening the burden on translators is always a good idea.
--
Daniel Gustafsson
errmsg("WAL generated with \"full_page_writes=off\" was replayed "
I'm not a fan of this syntax, but I at the same time can't offer a better idea
so this isn't an objection but a hope that it can be made even better during
the v18 cycle.
--
Daniel Gustafsson
IMHO, from being CMF many times,
there is a fair bit of the latter, which excacerbates the problem. This is
harder to fix with more or better software though.
> I spent a good deal of time going through the CommitFest this week
And you deserve a big Thank You for that.
--
Daniel Gustafsson
> On 16 May 2024, at 15:54, Robert Haas wrote:
>
> On Wed, May 15, 2024 at 9:33 AM Heikki Linnakangas wrote:
>> Ok, yeah, I can see that now. Here's a new version to address that. I
>> merged ENC_SSL_NEGOTIATED_SSL and ENC_SSL_DIRECT_SSL to a single method,
>> ENC_SSL. The places that need to
not attached to
any other conditional. There is no change in functionality, it's mainly for
readability (PG_TEST_EXTRA is it's own concept, not tied to library presence).
0002 ports over editing configfiles to using append_conf() instead of opening
and writing to them directly.
--
Daniel
appealing since the code will be unreachable with this check anyways.
Thoughts?
--
Daniel Gustafsson
0001-Refuse-upgrades-from-pre-9.0-clusters.patch
Description: Binary data
> On 15 May 2024, at 20:46, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> While looking at pg_dump performance today I noticed that pg_dump fails to
>> clear query results in binary_upgrade_set_pg_class_oids during binary upgrade
>> mode. 9a974cbcba00 moved t
it not always
be executed. 353708e1fb2d fixed the leak of the query buffer but left the
PGresult leak. The attached fixes the PGresult leak which when upgrading large
schemas can be non-trivial.
This needs to be backpatched down to v15.
--
Daniel Gustafsson
0001-Fix-query-result-leak-during
next list item under COLUMNS. Unless objected to I will remove these
parenthesis.
--
Daniel Gustafsson
is was immmediately shot down as
something the community don't want to maintain.
> And we'd need to figure out which Markdown flavor to target.
Absolutely, and as I mentioned above, we need to pick based both the final
result (text and rendered) as well as the developer experience for maintaining
this.
--
Daniel Gustafsson
> On 14 May 2024, at 08:03, Michael Paquier wrote:
>
> On Mon, May 13, 2024 at 08:06:57PM +0200, Daniel Gustafsson wrote:
>>> Any chance we'll have these fixes in v17?
>>
>> Nice timing, I was actually rebasing them today to get them committed.
>
> Looks sen
> On 14 May 2024, at 07:12, Michael Paquier wrote:
> Hence, no objections to clean up that now. Thanks for asking.
Thanks for verifying, I've pushed this now.
--
Daniel Gustafsson
better
to link to the archive.org entry instead.
--
Daniel Gustafsson
> On 13 May 2024, at 20:05, Ranier Vilela wrote:
> Em qua., 10 de abr. de 2024 às 15:33, Daniel Gustafsson
> escreveu:
> Thanks, I'll have a look. I've left this for post-freeze on purpose to not
> cause unnecessary rebasing. Will take a look over the next few days
> On 13 May 2024, at 10:48, Peter Eisentraut wrote:
> Patches attached.
All patches look good.
> I think the first one is a bug fix.
Agreed.
--
Daniel Gustafsson
mat option for EXPLAIN?
Since json (and yaml/xml) is intended to be machine-readable I think we use a
single unit for all values, and document this fact.
--
Daniel Gustafsson
regress_partition_merge_alice;
+ERROR: role "regress_partition_merge_alice" already exists
--
Daniel Gustafsson
ter
implementation).
Any objections to fixing this in 17 by removing it? (cc:ing Michael from the
RMT)
--
Daniel Gustafsson
v2-0001-Remove-auth-options-support-from-initdb.patch
Description: Binary data
that for SNI.
* The documentation is not polished at all and will require a more work to make
it passable I think. There are also lot's more testing that can be done, so
far it's pretty basic.
* I've so far only tested with OpenSSL and haven't yet verified how LibreSSL
handles this.
--
Daniel
to repro and fix a bug
> from the section "live issues affecting stable branches". I will
> update this BHS patch by tonight and commit it once Tomas has a chance
> to +1.
+1
--
Daniel Gustafsson
noticed for 7 major versions. Plus, based on my
> admittedly limited testing, this is unlikely to provide significant
> improvements.
Agreed, this is a nice little improvement but it's unlikely to be enough of a
speedup to warrant changing the backbranches.
--
Daniel Gustafsson
> On 7 May 2024, at 01:31, Michael Paquier wrote:
>
> On Fri, May 03, 2024 at 10:39:15AM +0200, Daniel Gustafsson wrote:
>> They are no-ops when linking against v18, but writing an extension which
>> targets all supported versions of postgres along with their respective
> On 3 May 2024, at 21:21, Tom Lane wrote:
>
> Peter Eisentraut writes:
>> On 03.05.24 10:39, Daniel Gustafsson wrote:
>>> They are no-ops when linking against v18, but writing an extension which
>>> targets all supported versions of postgres along with their
> On 3 May 2024, at 13:48, Peter Eisentraut wrote:
> Maybe it's easier if we just replaced
>
>prototypes for functions in xxx.c
>
> with
>
>declarations for xxx.c
>
> throughout src/include/libpq/libpq.h.
+1
--
Daniel Gustafsson
enSSL versions make them still required, or am I missing something?
>ERR_clear_error();
> -
> #ifdef USE_RESOWNER_FOR_HMAC
>
> Some noise diff.
Will fix with a new rebase when once the tree has settled down from the
post-freeze fixups in this area.
--
Daniel Gustafsson
est added here aptly cover 04e72ed617be in terms its functionality?
--
Daniel Gustafsson
it was footgun prevention.
--
Daniel Gustafsson
ethods, like clientcert to cert for
example. If we fix it we should also document that it works IMHO.
--
Daniel Gustafsson
that function existed. I agree that it's an
improvement even at the increased query complexity.
> v3 attached also has a bit more work on code comments.
LGTM.
--
Daniel Gustafsson
rts
> of "regress_dump_test_role" or to privilege strings. That
> seems unlikely enough to live with, but I wonder if anybody has
> a better idea.
I think that will be bulletproof enough to keep it working in the buildfarm and
among 99% of hackers.
--
Daniel Gustafsson
> On 27 Apr 2024, at 20:32, Daniel Gustafsson wrote:
> That's a good point, there is potential for more code removal here. The
> attached 0001 takes a stab at it while it's fresh in mind, I'll revisit before
> the July CF to see if there is more that can be done.
> On 25 Apr 2024, at 05:49, Michael Paquier wrote:
>
> On Wed, Apr 24, 2024 at 01:31:12PM +0200, Daniel Gustafsson wrote:
>> Done. Attached are the two remaining patches, rebased over HEAD, for
>> removing
>> support for OpenSSL 1.0.2 in v18. Parking them in the c
> On 21 Apr 2024, at 23:08, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 6 Apr 2024, at 01:10, Tom Lane wrote:
>>> (So now I'm wondering why *only* copperhead has shown this so far.
>>> Are our other cross-version-upgrade testing animals AW
y server: %s",
app_name.data, err));
Messages like this should perhaps have translator comments to indicate what the
leading "%s" will contain?
--
Daniel Gustafsson
> On 25 Apr 2024, at 17:48, Robert Haas wrote:
>
> On Wed, Apr 24, 2024 at 3:20 PM Daniel Gustafsson wrote:
>> Patch LGTM.
>
> Thanks. Here's an updated version with fixes for the other issues you
> mentioned.
LGTM, only one small error in the commitmessage:
> On 25 Apr 2024, at 18:16, Robert Haas wrote:
>
> On Wed, Apr 24, 2024 at 3:08 PM Daniel Gustafsson wrote:
>> LGTM; only one small comment which you can ignore if you feel it's not worth
>> the extra words.
>>
>> +pg_combinebackup when the checksum statu
a. Maybe we should set an
xreflabel while at it for completeness sake?
--
Daniel Gustafsson
" -n, --dry-run don't actually do anything\n"));
printf(_(" -N, --no-sync do not wait for changes to be written
safely to disk\n"));
--
Daniel Gustafsson
> On 22 Apr 2024, at 20:52, Robert Haas wrote:
>
> On Thu, Apr 18, 2024 at 3:25 PM Daniel Gustafsson wrote:
>>> On 18 Apr 2024, at 20:11, Robert Haas wrote:
>>> 2. As (1), but make check_control_files() emit a warning message when
>>> the problem case i
> On 24 Apr 2024, at 00:20, Michael Paquier wrote:
>
> On Tue, Apr 23, 2024 at 10:08:13PM +0200, Daniel Gustafsson wrote:
>> Hearing no objections to this plan (and the posted v10), I'll go ahead with
>> 0001, 0003 and 0004 into v17 tomorrow.
>
> WFM, thanks.
FILE is close to two decades old so there might be extensions
using it (though the risk might be slim), perhaps using offering it as as well
as backwards-compatability is warranted should we introduce a new name?
--
Daniel Gustafsson
> let to go through a few months of beta testing.
>
> 0004 effectively just enhances an error message for LibreSSL; there is little
> reason to backpatch this.
Hearing no objections to this plan (and the posted v10), I'll go ahead with
0001, 0003 and 0004 into v17 tomorrow.
--
Daniel Gustafsson
> On 22 Apr 2024, at 18:04, Tom Lane wrote:
> Seems like a useful change
Agreed.
> ... about like this?
Patch LGTM.
--
Daniel Gustafsson
> On 21 Apr 2024, at 23:08, Tom Lane wrote:
> ... were you going to look at it? I can take a whack if it's too far down
> your priority list.
Yeah, I’m working on a patchset right now.
./daniel
> On 20 Apr 2024, at 01:23, Michael Paquier wrote:
>
> On Fri, Apr 19, 2024 at 10:12:14AM +0200, Daniel Gustafsson wrote:
>> Off the cuff that seems to make sense, it does make it easier to grep for
>> uses
>> of the control file.
>
> +1 for switching to the ma
w for new features opens again I am sure this patch will get reviews (I
have it on my personal TODO and hope to get to it).
--
Daniel Gustafsson
> On 19 Apr 2024, at 13:49, Daniel Gustafsson wrote:
>> On 19 Apr 2024, at 12:31, Aleksander Alekseev
>> wrote:
>> Here is the patch.
>
> Nice catch, and thanks for the patch. I'll apply it with a backpatch to when
> they were removed.
Done, thanks for the re
These
>> operators were removed by 2f70fdb0644c back in 2020.
>>
>> I will submit a patch for the documentation shortly. Thanks for reporting.
>
> Here is the patch.
Nice catch, and thanks for the patch. I'll apply it with a backpatch to when
they were removed.
--
Daniel Gustafsson
> On 16 Apr 2024, at 15:37, Nazir Bilal Yavuz wrote:
> I realized two small typos: 'sgmr' -> 'smgr'. You may want to include
> them in 0001.
Thanks, I incorporated these into 0001 before pushing. All the commits in this
patchset are now applied.
--
Daniel Gustafsson
> On 19 Apr 2024, at 05:50, Anton A. Melnikov wrote:
> May be better use this macro everywhere in C code?
Off the cuff that seems to make sense, it does make it easier to grep for uses
of the control file.
--
Daniel Gustafsson
ut a backpatch? Or perhaps
> you disagree?
If we want to 0001 can be baclpatched to v15, 0004 to v13 and 0003 all the way.
I don't have strong opinions either way.
--
Daniel Gustafsson
> On 18 Apr 2024, at 22:28, Nathan Bossart wrote:
>
> On Thu, Apr 18, 2024 at 10:23:01AM -0500, Nathan Bossart wrote:
>> On Thu, Apr 18, 2024 at 09:24:53AM +0200, Daniel Gustafsson wrote:
>>> That does indeed seem like a saner approach. Since we look up the relkind
&g
ing it
an empty no-op for all other cases. When we move past 1.1.0 due to a new API
requirement we can blow it all away.
> If everything is addressed, I agree that 0001, 0003, and 0004 can go into
> PG17, the rest later.
Agreed, 0002 and 0005 are clearly for the v18 cycle.
--
Daniel Gustafsson
on for doing
so.
> We could perhaps consider doing (2) for now and (5) for a future
> release, or something like that.
+1
--
Daniel Gustafsson
Oids, so I never benchmarked
it all that well.) The upside of that is that the magic Oid variables in the
backend can be removed, but it obviously adds slight overhead in others.
--
Daniel Gustafsson
keeps it to
functions in our API instead.
--
Daniel Gustafsson
> On 16 Apr 2024, at 01:03, Michael Paquier wrote:
>
> On Mon, Apr 15, 2024 at 11:07:05AM +0200, Daniel Gustafsson wrote:
>> On 15 Apr 2024, at 07:04, Michael Paquier wrote:
>>> On Fri, Apr 12, 2024 at 02:42:57PM +0200, Daniel Gustafsson wrote:
>>>> Is the
> On 14 Apr 2024, at 13:19, David Rowley wrote:
>
> On Sat, 13 Apr 2024 at 09:17, Daniel Gustafsson wrote:
>>
>>> On 12 Apr 2024, at 23:15, Heikki Linnakangas wrote:
>>> Here's a few more. I've accumulate these over the past couple of months,
>>>
m on the server. In a few places we use
"database server process" too when talking about backends.
In the case of pg_log_backend_memory_contexts(), the function comment states
the following:
"Signal a backend or an auxiliary process to log its memory contexts"
So in this case, "PostgreSQL server process" seems like the correct term.
--
Daniel Gustafsson
> On 15 Apr 2024, at 07:04, Michael Paquier wrote:
> On Fri, Apr 12, 2024 at 02:42:57PM +0200, Daniel Gustafsson wrote:
>> Is the attached split in line with how you were thinking about it?
>
> If I may, 0001 looks sensible here. The bits from 0003 and 0004 could
> b
> On 12 Apr 2024, at 23:15, Heikki Linnakangas wrote:
>
> On 11/04/2024 16:05, Daniel Gustafsson wrote:
>> Now that the tree has settled down a bit post-freeze I ran some tooling to
>> check spelling. I was primarily interested in docs and README* which were
>> mo
pg_strong_random_init() if it's no longer useful. I
> mean, if we leave it as is, and we are not removing any callers, then we are
> effectively continuing to support OpenSSL <1.1.1, right?
The attached removes pg_strong_random_init and instead calls it explicitly for
1.1.0 users by check
> On 11 Apr 2024, at 15:29, David Rowley wrote:
>
> On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, <mailto:dan...@yesql.se>> wrote:
>> Now that the tree has settled down a bit post-freeze I ran some tooling to
>> check spelling. I was primarily interested
-referenced
against ongoing reverts or any other fixup threads but will be before pushing
of course).
--
Daniel Gustafsson
v1-0001-Fix-typos.patch
Description: Binary data
> On 11 Apr 2024, at 13:16, Andrew Dunstan wrote:
> Thanks, I will include that in the cleanups I'm intending to push today.
+1, thanks!
--
Daniel Gustafsson
to overflow MAX_CHUNK bytes.
> */
>
> Shouldn't this be:
> /*
> * we expect to find the last lines of the manifest,...
> */
That sounds about right, and since it's a full sentence it should also start
with a capital 'W': "We expect to find the..".
--
Daniel Gustafsson
> On 10 Apr 2024, at 20:31, Ranier Vilela wrote:
>
> Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson <mailto:dan...@yesql.se>> escreveu:
>> > On 2 Apr 2024, at 20:13, Ranier Vilela > > <mailto:ranier...@gmail.com>> wrote:
>>
>> >
> On 4 Apr 2024, at 23:46, Daniel Gustafsson wrote:
>
>> On 4 Apr 2024, at 23:24, Tom Lane wrote:
>
>> A minimum fix that seems to make this work better is as attached,
>> but I feel like somebody ought to examine all the IPC::Run::timer
>> and IPC::Run:
> On 8 Apr 2024, at 22:30, Erik Wienhold wrote:
> On 2024-04-08 21:29 +0200, Daniel Gustafsson wrote:
> I've only peeked at a couple of those READMEs, but they look alright so
> far (at least on GitHub). Should we settle on a specific Markdown
> flavor[1]? Because I'm nev
> On 8 Apr 2024, at 01:04, Andres Freund wrote:
> What makes you think that's unrelated? To me that looks like the same issue?
Nvm, I misread the assert, ETOOLITTLESLEEP. Sorry for the noise.
--
Daniel Gustafsson
> On 8 Apr 2024, at 00:46, Michael Paquier wrote:
>
> On Sat, Apr 06, 2024 at 07:47:43PM +0200, Daniel Gustafsson wrote:
>> My apologies, I thought I did but clearly failed. My point was that this is
>> a
>> special/corner case where we try to find one
with that change, too.
Unrelated to that one, seems like turaco ran into another issue:
running bootstrap script ... TRAP: failed Assert("total_allocated ==
context->mem_allocated"), File: "bump.c", Line: 808, PID: 7809
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=turaco=2024-04-07%2022%3A42%3A54
--
Daniel Gustafsson
> On 7 Apr 2024, at 18:51, Daniel Gustafsson wrote:
>> On 7 Apr 2024, at 18:28, Andres Freund wrote:
>> I'm ok with printing path + some content or just the path.
>
> I think printing the last 512 bytes or so would be a good approach, I'll take
> care of it l
> On 7 Apr 2024, at 18:28, Andres Freund wrote:
>
> On 2024-04-07 16:52:05 +0200, Daniel Gustafsson wrote:
>>> On 7 Apr 2024, at 14:51, Andrew Dunstan wrote:
>>> On 2024-04-06 Sa 20:49, Andres Freund wrote:
>>
>>>> That's probably unnecessary o
nting
anything at all in this case but we should support negative offsets anyways, it
will fort sure come in handy.
--
Daniel Gustafsson
> On 7 Apr 2024, at 02:49, Andres Freund wrote:
> On 2024-04-07 00:19:35 +0200, Daniel Gustafsson wrote:
>>> On 6 Apr 2024, at 23:44, Andres Freund wrote:
>> The non-context aware fix would be to just print the last 1024 (or something)
>> bytes from the logfile:
>
# pg_ctl could have timed out, so check to see if there's a pid
file;
# otherwise our END block will fail to shut down the new
postmaster.
Would that be a reasonable fix?
--
Daniel Gustafsson
> On 6 Apr 2024, at 16:04, Tom Lane wrote:
> Daniel Gustafsson writes:
>>> On 6 Apr 2024, at 08:02, Peter Eisentraut wrote:
>>> Why do we need to check for the versions at all? We should just check for
>>> the functions we need. At least that'
ontrivial to know which animal does what.
> I doubt this is something we'll have fixed by Monday, so I will
> go add an open item for it.
+1. Having opened the can of worms I'll have a look at it next week.
--
Daniel Gustafsson
> On 6 Apr 2024, at 08:02, Peter Eisentraut wrote:
>
> On 05.04.24 23:48, Daniel Gustafsson wrote:
>> The reason to expand the check is to ensure that we have the version we want
>> for both OpenSSL and LibreSSL, and deprecating OpenSSL versions isn't all
>> that
> On 5 Apr 2024, at 22:55, Jacob Champion
> wrote:
>
> On Fri, Apr 5, 2024 at 9:59 AM Daniel Gustafsson wrote:
>> Attached is a WIP patch to get more eyes on it, the Meson test for 1.1.1
>> fails
>> on Windows in CI which I will investigate next.
The attached v
> On 5 Apr 2024, at 23:26, Peter Eisentraut wrote:
>
> On 05.04.24 18:59, Daniel Gustafsson wrote:
>> Attached is a WIP patch to get more eyes on it, the Meson test for 1.1.1
>> fails
>> on Windows in CI which I will investigate next.
>
> I'm not a
testing for earlier
> branches.)
We should draw the line on something we can reliably test, so 6.9 seems fine to
me (unless there is evidence of older versions being common in the wild).
OpenBSD themselves support 2 backbranches so 6.9 is still far beyond the EOL
mark upstream.
--
Daniel Gustafsson
fork safety
has been broken at least once in OpenSSL since 1.1.1:
https://github.com/openssl/openssl/issues/12377
That particular bug was thankfully caught before it shipped, but mitigating the
risk is this cheap enough that is seems reasonable to keep this in.
Attached is a WIP patch to get
4d75753
> broke it, but I've not dug deeply into the history.
AFAICT, in the previous coding the interactive_psql object would use a timer or
timeout based on what the caller provided, and check_completion used a timer so
the debug logging probably worked as written.
--
Daniel Gustafsson
they're just not hooked up to any
top-level commands. Running "make ssfiles-clean ssfiles" in src/test/ssl
regenerates all the files from the base config files that define their
contents.
--
Daniel Gustafsson
> On 4 Apr 2024, at 22:47, Tom Lane wrote:
>
> Robert Haas writes:
>> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
>>> I don't disagree, like I said that very email: it's non-trivial and I wish
>>> we
>>> could make it better somehow,
> On 4 Apr 2024, at 22:40, Robert Haas wrote:
>
> On Thu, Apr 4, 2024 at 4:25 PM Daniel Gustafsson wrote:
>> I don't disagree, like I said that very email: it's non-trivial and I wish we
>> could make it better somehow, but I don't hav an abundance of good ideas.
>
>
1 - 100 of 2184 matches
Mail list logo
