t similar functions it's clear they don't use the pg_postgres_ prefix,
like for example pg_conf_load_time. Should this if so be pg_start_time?
--
Daniel Gustafsson
> On 1 Nov 2024, at 01:36, Bruce Momjian wrote:
> On Fri, Oct 25, 2024 at 01:55:57PM +0200, Daniel Gustafsson wrote:
>> In the meantime, the OP has a good point that it's a tad silly that
>> pg_upgrade
>> fails hard on invalid databases instead of detecting an
> On 5 Nov 2024, at 22:08, Daniel Gustafsson wrote:
>
>> On 5 Nov 2024, at 17:40, Fujii Masao wrote:
>>
>> On 2024/09/24 21:31, Daniel Gustafsson wrote:
>>>> On 24 Sep 2024, at 10:32, btnakamurakoukil
>>>> wrote:
>>>&g
> On 5 Nov 2024, at 17:40, Fujii Masao wrote:
>
> On 2024/09/24 21:31, Daniel Gustafsson wrote:
>>> On 24 Sep 2024, at 10:32, btnakamurakoukil
>>> wrote:
>>> I noticed unnecessary variable "low" in index_delete_sort()
>>> (/postgres/src
> On 5 Nov 2024, at 10:33, Alvaro Herrera wrote:
> Therefore I +1 Daniel's original proposal with thanks, and BTW I'm not
> sorry for changing my name to use the hard-won ' accent on it :-)
Done.
--
Daniel Gustafsson
> On 4 Nov 2024, at 21:00, Bruce Momjian wrote:
> Proposed patch attached.
LGTM.
--
Daniel Gustafsson
, I think it would be a good change.
> But I also think that
> "SQL" in front of the command name is unnecessary because the man page
> uses the "FOOBAR command" form throughout
Agreed.
>--inserts
>Dump data as INSERT commands [...]
>
> Also, it doesn't really matter whether COMMENT is standard SQL.
AFAIK some flavor of COMMENT is present in MySQL, PostgreSQL and Oracle which
already makes it more "standardized" than many parts of the SQL standard =)
--
Daniel Gustafsson
+1 on your patch, reading through I can't see anything it misses. Maybe a
comment above the change with a note on why dbname is tested for NULL there
would be good?
--
Daniel Gustafsson
e common pattern for
erroring out like this.
--
Daniel Gustafsson
> On 1 Nov 2024, at 13:53, Peter Eisentraut wrote:
>
> On 01.11.24 12:53, Alvaro Herrera wrote:
>> On 2024-Oct-31, Daniel Gustafsson wrote:
>>> When looking at our Git tree for a recent conference presentation I
>>> happened to
>>> notice that we h
> On 28 Oct 2024, at 11:56, Heikki Linnakangas wrote:
>
> On 09/04/2024 20:10, Daniel Gustafsson wrote:
>> Turning the timeout into a timer and returning undef along with logging a
>> test
>> failure in case of expiration seems a bit saner (maybe Andrew can suggest a
> On 31 Oct 2024, at 10:24, vignesh C wrote:
> I noticed a couple of typos in code. "the the" should have been "the",
> attached patch has the changes for the same.
Fixed, thanks.
--
Daniel Gustafsson
committer entry.
--
Daniel Gustafsson
mailmap.diff
Description: Binary data
h it would probably
help readers.
--
Daniel Gustafsson
> On 29 Oct 2024, at 17:40, Jacob Champion
> wrote:
>
> On Tue, Oct 29, 2024 at 3:52 AM Daniel Gustafsson wrote:
>> Currently we don't support any conditional compilation which only affects
>> backend or frontend, all --without-XXX flags turn it off for both.
>
> On 29 Oct 2024, at 13:53, Joe Conway wrote:
>
> On 10/29/24 05:57, Daniel Gustafsson wrote:
>>> On 26 Oct 2024, at 20:10, Joe Conway wrote:
>>> Rather than depend on figuring out if we are in FIPS_mode in a portable
>>> way, I think the GUC is simpler and
unction
-pg_event_trigger_table_rewrite_reason().
+pg_event_trigger_table_rewrite_oid() To discover the
reason(s)
+for the rewrite, use the function
pg_event_trigger_table_rewrite_reason()
+(see ).
--
Daniel Gustafsson
> On 28 Oct 2024, at 17:09, Jacob Champion
> wrote:
> On Mon, Oct 28, 2024 at 6:24 AM Daniel Gustafsson wrote:
>> Looking more at the patchset I think we need to apply conditional compilation
>> of the backend for oauth like how we do with other opt-in schemes in
>
their own extension.
--
Daniel Gustafsson
s a hot mess =/
Looking more at the patchset I think we need to apply conditional compilation
of the backend for oauth like how we do with other opt-in schemes in configure
and meson. The attached .txt has a diff for making --with-oauth a requirement
for compiling support into backend libpq.
refer to output this to the log only and not the TAP output, to avoid
the risk of not seeing the test output for all the log output on the screen.
--
Daniel Gustafsson
ed patch to make these changes.
+1 for applying backpatched to at least 17 but possibly further down judging by
the linked threads.
--
Daniel Gustafsson
needed.
--
Daniel Gustafsson
v13-0001-Add-notBefore-and-notAfter-to-SSL-cert-info-disp.patch
Description: Binary data
a tad silly that pg_upgrade
fails hard on invalid databases instead of detecting and reporting like how
other errors are handled. The attached adds this check and expands the report
wording to cover it.
--
Daniel Gustafsson
0001-Find-invalid-databases-during-upgrade-check-stage.patch
Description: Binary data
This has now been committed via the TLS 1.3 ciphersuite patchset.
--
Daniel Gustafsson
/LibreSSL requirement, I
will reach out to BF animal owners for upgrades.
--
Daniel Gustafsson
pg_group are now views on pg_authid.
I'm no native speaker but I don't interpret "publicly accessible" as readable
by the public role, rather that they are accessible via a user interface (in
this case SQL).
--
Daniel Gustafsson
d feed to the binary the values from the header. The
> patch attached does that.
I haven't studied the patch in detail (yet), nothing stood out from a quick
skim, but +1 on the concept.
--
Daniel Gustafsson
> On 17 Oct 2024, at 04:45, Bruce Momjian wrote:
> I looked at this and decided the GUC section was illogical, so I just
> moved the variables up into the be-secure.c section. Patch attached.
No objections.
--
Daniel Gustafsson
easonable use-case, so +1.
--
Daniel Gustafsson
> On 15 Oct 2024, at 22:48, Peter Eisentraut wrote:
>
> On 09.10.24 20:30, Daniel Gustafsson wrote:
>>> On 9 Oct 2024, at 19:15, Nathan Bossart wrote:
>>> Another problem is that "deprecated" may or may not imply that the feature
>>> will be removed
features we've marked as
deprecated and sometimes they are kept.
--
Daniel Gustafsson
> On 14 Oct 2024, at 15:08, Peter Eisentraut wrote:
>
> On 26.09.24 11:01, Daniel Gustafsson wrote:
>> Attached is a v7 which address a test failure in the CI. It turns out that
>> the
>> test_misc module gather GUC names using the :alpha: character class which
&
> On 3 Oct 2024, at 01:20, Jacob Champion
> wrote:
>
> On Wed, Oct 2, 2024 at 11:33 AM Daniel Gustafsson wrote:
>>> If I migrate a server to a different machine that doesn't support my
>>> groups, I don't know that this would give me enough information t
> On 5 Sep 2024, at 00:10, Daniel Gustafsson wrote:
> Thanks for reviewing, I plan on going ahead with this patch shortly.
That ended up not being shortly, but having spent a fair bit of time reading
the diff over and testing on multiple versions of OpenSSL and LibreSSL I've now
push
> On 7 Oct 2024, at 22:04, Nathan Bossart wrote:
>
> On Mon, Oct 07, 2024 at 03:37:35PM -0400, Bruce Momjian wrote:
>> On Tue, Oct 1, 2024 at 09:28:54AM +0200, Daniel Gustafsson wrote:
>>> Correct, sorry for being unclear. The consistency argument would be to
>
d point in time for when MD5 goes away with
notices in all release notes up until that point.
--
Daniel Gustafsson
> On 10 Oct 2024, at 02:01, Michael Paquier wrote:
>
> On Wed, Oct 09, 2024 at 04:24:27PM +0200, Daniel Gustafsson wrote:
>> Fixed.
>
> -doublesleep = 2;
> +doublesleep = pset.watch_interval;
>
> This forces the use of seconds a
ing the code I agree that
we must check previous_words_count here so +1 on this patch.
--
Daniel Gustafsson
use
unintended side effects when executed by copy/paste.
What separates nbsp is that it may affect the rendering in an un-intuitive way
by forcing two words to not break even if the viewport is too narrow to fit.
Catching such characters seems wortwhile since it's also quite doable with a
tr
I think we should separate
between discouraged and deprecated.
--
Daniel Gustafsson
> On 9 Oct 2024, at 18:33, Nathan Bossart wrote:
>
> On Wed, Oct 09, 2024 at 10:08:31AM +0200, Daniel Gustafsson wrote:
>> The -H option to oid2name was deprecated in v12, and with v12 going out of
>> support it seems about time to remove it for v18. Not the most
>>
equal to* 0". Or maybe "cannot be negative". -0 is also accepted,
> though.
I changed to "must be at least XX" to keep the message short.
> set -> sets
>
> beetween -> between
Fixed.
--
Daniel Gustafsson
v2-0001-Make-default-watch-interval-configurable.patch
Description: Binary data
e attached adds a new variable, WATCH_INTERVAL, which is used as the default
value in case no value is defined when executing the command. The defualt of
this remains at 2 seconds as it is now. The count and min_rows values are not
affected by this as those seem less meaningful to set defaults on.
The -H option to oid2name was deprecated in v12, and with v12 going out of
support it seems about time to remove it for v18. Not the most groundbreaking
cleanup, but also no point in carrying it around for 5 more years.
--
Daniel Gustafsson
v1-0001-Remove-depracated-H-option-for-host.patch
> On 8 Oct 2024, at 22:56, Daniel Gustafsson wrote:
>
>> On 8 Oct 2024, at 22:24, Andrew Dunstan wrote:
>> The patch looks fine, and should be backpatched. Looks like this is a 12
>> year old thinko. AFAICT File::Spec doesn't export anything.
>
> Thanks for
> On 8 Oct 2024, at 22:24, Andrew Dunstan wrote:
>
> On 2024-10-08 Tu 5:26 AM, Daniel Gustafsson wrote:
>>> On 8 Oct 2024, at 03:50, Erik Wienhold wrote:
>>>> Calling the import method of an unknown package produces a warning
>>>> [...]
>>>
h_ptr
> and foreach_oid macros instead of plain foreach.
Fair point, done in the v4 attached upthread.
--
Daniel Gustafsson
.00 which was released just a hair over 2 decades ago so I think we can safely
assume any File::Spec we use to have it.
--
Daniel Gustafsson
o objection, I will commit this to
> master branch.
No objections, LGTM.
--
Daniel Gustafsson
> On 7 Oct 2024, at 09:47, Michael Paquier wrote:
> The commit fest 2024-09 should have ended one week ago, so I have been
> taking one step ahead and I have begun cleaning up things.
Thanks for doing this, much appreciated!
--
Daniel Gustafsson
, but I think this should be an xref like how we link to --no-locale in
the -E docs: instead.
LGTM otherwise.
--
Daniel Gustafsson
> On 10 Sep 2024, at 10:44, Daniel Gustafsson wrote:
> This change will be committed together with the TLSv1.3 cipher suite pathcset,
> just wanted to bring it up here and not hide it in another thread.
In the TLSv1.3 cipher suite thread it was brought up that this bump in minimum
vers
there was a reachable segfault on a null pointer deref I have a
feeling we'd heard about it by now so some extra care seems warranted to ensure
it's not a static analyzer false positive.
--
Daniel Gustafsson
> On 2 Oct 2024, at 19:16, Jacob Champion
> wrote:
>
> On Wed, Sep 25, 2024 at 6:39 AM Daniel Gustafsson wrote:
>> I can't recall specific bounds for supporting LibreSSL even being discussed,
>> the support is also not documented as an official thing. Requiring T
> On 1 Oct 2024, at 16:53, Jelte Fennema-Nio wrote:
> On Tue, 1 Oct 2024 at 15:52, Daniel Gustafsson wrote:
>>> Apart from this, I don't changing the placeholders like to < foo >.
>>> In some cases, this really decreases readability. Maybe we should look
> On 1 Oct 2024, at 00:43, Michael Banck wrote:
>
> Hi,
>
> On Mon, Sep 30, 2024 at 11:21:30PM +0200, Daniel Gustafsson wrote:
>>> Yeah, I think a view like pg_stat_progress_checksums would work.
>>
>> Added in the attached version. It probably needs some
> On 1 Oct 2024, at 00:20, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 30 Sep 2024, at 16:55, Tom Lane wrote:
>>> TBH I'm not finding anything very much wrong with the current
>>> behavior... this has to be a rare situation, do we need to add
> On 1 Oct 2024, at 02:35, Thomas Krennwallner wrote:
>
> On 30/09/2024 17.29, Daniel Gustafsson wrote:
>>> On 30 Sep 2024, at 16:55, Tom Lane wrote:
>>> TBH I'm not finding anything very much wrong with the current
>>> behavior... this has
> On 30 Sep 2024, at 17:43, Tom Lane wrote:
>
> Nathan Bossart writes:
>> On Mon, Sep 30, 2024 at 04:13:55PM +0200, Daniel Gustafsson wrote:
>>> I'm not a native speaker so I'm not sure which is right, but grepping for
>>> other
>>> li
enerally tries
to report all the offending entries to help the user when fixing the source
database. Not sure if it's a strong enough argument for carrying code which
really shouldn't see much use though.
--
Daniel Gustafsson
> On 30 Sep 2024, at 12:38, Yugo Nagata wrote:
>
> On Mon, 30 Sep 2024 11:40:29 +0200
> Daniel Gustafsson wrote:
>
>> - * MATERIALIZED VIEW, and REINDEX on all relations.
>> + * MATERIALIZED VIEW, REINDEX and LOCK TABLE on all relations.
>
> Should we put a c
doing so made me realize we don't have an equivalent meson target).
--
Daniel Gustafsson
check_nbsp.diff
Description: Binary data
INDEX on all relations.
>> */
>
> Therefore, shouldn't LOCK TABLE be added to the comment?
That's correct, for the list to be complete LOCK TABLE should be added as per
the attached.
--
Daniel Gustafsson
acl_maintain_comment.diff
Description: Binary data
allows all
alphanumeric characters. This is not directly related to this patch, it just
happened to be exposed by it.
--
Daniel Gustafsson
v7-0001-Handle-alphanumeric-characters-in-matching-GUC-na.patch
Description: Binary data
v7-0002-Raise-the-minimum-supported-OpenSSL-version-to-1..patch
> On 18 Sep 2024, at 22:48, Jacob Champion
> wrote:
> On Mon, Sep 9, 2024 at 5:00 AM Daniel Gustafsson wrote:
>> The attached version also has a new 0001 which bumps the minimum required
>> OpenSSL version to 1.1.1 (from 1.1.0) since this patchset requires API's on
en used since it
was committed in d168b666823. The question is if it's a left-over from
development which can be removed, or if it should be set and we're missing an
optimization. Having not read the referenced paper I can't tell so adding
Peter Geoghegan who wrote this for clarification.
--
Daniel Gustafsson
> On 23 Sep 2024, at 19:17, Tom Lane wrote:
> Daniel Gustafsson writes:
>
>> There is an ERRCODE_INTERNAL_ERROR in xml_out_internal() which seems a tad
>> odd
>> given that any error would be known to be parsing related and b) are caused
>> by
>> libxm
> On 17 Sep 2024, at 21:22, Nathan Bossart wrote:
>
> Here are a few miscellaneous cleanup patches for pg_upgrade. I don't think
> there's anything controversial here.
No objections to any of these changes, LGTM.
--
Daniel Gustafsson
not internally. Not sure if it's worth bothering with but with the
other ones improved it stood out.
--
Daniel Gustafsson
e last sentence, but it mentions the env var in the
> first paragraph. Here's a patch to make the key word equally prominent.
Fair point, that seems like a good change, will apply.
--
Daniel Gustafsson
albeit in a limited fashion.
PostgreSQL still support OpenSSL 1.1.1 where engines aren't deprecated, and I
expect we will for some time.
--
Daniel Gustafsson
> On 10 Sep 2024, at 17:37, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Since there doesn't seem to be much interest in going all the way to
>> Markdown,
>> the attached 0001 is just the formatting changes for achieving (to some
>> degree)
>>
> On 9 Sep 2024, at 23:21, Daniel Gustafsson wrote:
>
>> On 9 Sep 2024, at 20:41, Jacob Champion
>> wrote:
>>
>> On Mon, Sep 9, 2024 at 11:30 AM Daniel Gustafsson wrote:
>>> Just to make sure I understand, this is for guarding against overreads in
>&
rated.
The attached v3 is a rebase to handle executor changes done since v2, with the
above mentioned fix as well. If there are no objections I think we should
apply this version.
--
Daniel Gustafsson
v3-0001-Replace-EEOP_DONE-with-special-steps-for-return-n.patch
Description: Binary data
v
> On 10 Sep 2024, at 00:53, Michael Paquier wrote:
>
> On Mon, Sep 09, 2024 at 11:29:09PM +0200, Daniel Gustafsson wrote:
>> Agreed. OpenSSL 1.1.1 is very different story and I suspect we'll be stuck
>> on
>> that level for some time, but 1.1.0 is gone from
, but given that
we regularly test LibreSSL and fix breakage in our support I think we should.
--
Daniel Gustafsson
> On 9 Sep 2024, at 16:48, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> The patchset in https://commitfest.postgresql.org/49/5025/ which adds support
>> for configuring cipher suites in TLS 1.3 handshakes require an API available
>> in
>> OpenSSL 1.1.1 and
> On 9 Sep 2024, at 20:41, Jacob Champion
> wrote:
>
> On Mon, Sep 9, 2024 at 11:30 AM Daniel Gustafsson wrote:
>> Just to make sure I understand, this is for guarding against overreads in
>> validation of strings containing torn MB characters?
>
> Right. Our
> On 9 Sep 2024, at 21:17, Nathan Bossart wrote:
>
> On Thu, Sep 05, 2024 at 01:32:34PM +0200, Daniel Gustafsson wrote:
>> I've read and tested through the latest version of this patchset and I think
>> it's ready to go in.
>
> Thanks for reviewing. I'
ion of strings containing torn MB characters? Assuming I didn't
misunderstand you this patch seems correct to me.
--
Daniel Gustafsson
d patchset for illustration.
The removal should happen when pushing the rest of the patchset.
Does anyone see any reason not to go to 1.1.1 as the minimum?
--
Daniel Gustafsson
v5-0001-Raise-the-minimum-supported-OpenSSL-version-to-1..patch
Description: Binary data
> On 22 Jul 2024, at 19:14, Jacob Champion
> wrote:
>
> On Fri, Jul 12, 2024 at 1:03 PM Daniel Gustafsson wrote:
>> The original author added the string parsing in order to provide a good error
>> message in case of an error in the list, and since that seemed like a ni
^~
> compilation terminated.
That implies OPENSSL_NO_ENGINE isn't defined while the engine header is
missing, which isn't really a workable combination. Which version of OpenSSL
is this?
--
Daniel Gustafsson
> On 4 Sep 2024, at 17:34, David Rowley wrote:
>
> On Wed, 4 Sept 2024 at 20:24, Daniel Gustafsson wrote:
>> Not mandatory at all, but since you were prepping a typo backpatch anyways I
>> figured these could join to put a small dent in reducing risks for future
>> b
> On 4 Sep 2024, at 20:35, Daniel Gustafsson wrote:
>> On 4 Sep 2024, at 19:30, Nathan Bossart wrote:
>> On Wed, Sep 04, 2024 at 02:10:28PM -0300, Ranier Vilela wrote:
>>> patch attached.
>>
>> Yeah, that looks like a problem to me. I've cc'd Da
ocess. This is primarily intended for the inital step
in
s/inital/initial/
--
Daniel Gustafsson
> On 4 Sep 2024, at 23:19, David Benjamin wrote:
>
> On Wed, Sep 4, 2024 at 9:22 AM Daniel Gustafsson <mailto:dan...@yesql.se>> wrote:
>> > On 3 Sep 2024, at 14:18, Daniel Gustafsson > > <mailto:dan...@yesql.se>> wrote:
>>
>> > Atta
ah, that looks like a problem to me. I've cc'd Daniel here.
Thanks for the report, it does seem genuine to me too. I'll get that handled
later today.
--
Daniel Gustafsson
> On 3 Sep 2024, at 14:18, Daniel Gustafsson wrote:
> Attached is a v4 rebase over the recent OpenSSL 1.0.2 removal which made this
> patch no longer apply. I've just started to dig into it so have no comments
> on
> it right now, but wanted to get a cleaned up version in
> On 4 Sep 2024, at 03:25, Michael Paquier wrote:
>
> On Tue, Sep 03, 2024 at 12:00:13PM +0200, Daniel Gustafsson wrote:
>> I see your v17 typo fixes, and raise you a few more. Commit 31a98934d169
>> from
>> just now contains 2 (out of 3) sets of typos intro
> On 17 May 2024, at 09:58, Daniel Gustafsson wrote:
>
>> 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 yo
> On 19 May 2024, at 22:32, Daniel Gustafsson wrote:
>
>> On 19 May 2024, at 22:21, Peter Eisentraut wrote:
>
>> Whoever commits these should be sure to coordinate this.
>
> Thanks for the reminder. I have this patchset, the OCSP stapling patchset and
> the mul
before the release.
I see your v17 typo fixes, and raise you a few more. Commit 31a98934d169 from
just now contains 2 (out of 3) sets of typos introduced in v17 so they should
follow along when you push the ones mentioned here.
--
Daniel Gustafsson
ve that one as the filename
spelled out.
- "the \".old\" suffix from %s/global/pg_control.old.\n"
+ "the \".old\" suffix from %s/%s.old.\n"
Same with that change, not sure I think that makes reading the errormessage
code any easier.
--
Daniel Gustafsson
oken my crystal ball is this
> time. The timing is awful for this patchset in particular.
It is indeed, if it ends up deprecated server-side among the big providers then
support for it risks being very hard to use. Not sure what is the best course
of action here is.
--
Daniel Gustafsson
> On 2 Sep 2024, at 10:03, Daniel Gustafsson wrote:
>
>> On 23 Aug 2024, at 01:56, Michael Paquier wrote:
>>
>> On Thu, Aug 22, 2024 at 11:13:15PM +0200, Daniel Gustafsson wrote:
>>> On 22 Aug 2024, at 02:31, Michael Paquier wrote:
>>>> Just do it
te list can be found in the post
>> below, I'll refrain from copying everything here.
>>
>> https://www.crunchydata.com/blog/understanding-the-postgres-hackers-mailing-list
>
> Nice write-up!
+1
> Might it also be worth linking to the acronyms and
> glossary sec
> On 5 Jun 2024, at 04:39, Nathan Bossart wrote:
>
> On Wed, May 15, 2024 at 03:21:36PM -0500, Nathan Bossart wrote:
>> Nice! I'll plan on taking a closer look at this one.
>
> LGTM. I've marked the commitfest entry as ready-for-committer.
Thanks for review, committed.
--
Daniel Gustafsson
> On 23 Aug 2024, at 01:56, Michael Paquier wrote:
>
> On Thu, Aug 22, 2024 at 11:13:15PM +0200, Daniel Gustafsson wrote:
>> On 22 Aug 2024, at 02:31, Michael Paquier wrote:
>>> Just do it :)
>>
>> That's my plan, I wanted to wait a bit to see
1 - 100 of 1268 matches
Mail list logo
