Am Dienstag, dem 08.07.2025 um 11:25 -0400 schrieb Tom Lane:
> Hannu Krosing writes:
> > On Mon, Jul 7, 2025 at 11:38 PM Tom Lane wrote:
> > > What do you think of instead specifying the limit as the maximum
> > > running-percentage to print, with a default of say 99.99%? That
> > > gives me res
Am Sonntag, dem 06.04.2025 um 15:43 -0400 schrieb Tom Lane:
> What this is on about is that portable use of isalpha() or isdigit()
> requires casting a "char" value to "unsigned char". I was about to
> make that simple change when I started to question if we actually
> want to be using here at al
rypt_itoa64 from unsigned char to char, since this
seems what strchr() expects (at least on my machine) and we don't deal
specifically elsewhere with that.
Thanks,
Bernd
From d9aa1524a8280bb3997998c2a3499b1f8cfdee6c Mon Sep 17 00:00:00 2001
From: Bernd Helmle
Date: Mon, 7 A
Am Sonntag, dem 06.04.2025 um 23:02 -0400 schrieb Andres Freund:
> Hi,
>
> On 2025-04-05 19:22:58 +0200, Alvaro Herrera wrote:
> > I have pushed this now, hoping it won't explode.
>
> I have a WIP patch that adds gcc specific allocator attributes for
> palloc et
> al. Just rebased that. It warns
Am Samstag, dem 05.04.2025 um 19:22 +0200 schrieb Alvaro Herrera:
> Hello,
>
> I have pushed this now, hoping it won't explode.
>
> Thanks!
Very cool, i keep my fingers crossed.
Thanks,
Bernd
ifferent according to the platform. Since it's
> limited by the macro definitions to no more than 9, we can
> make
> it an int32 instead. So we use strtoint() instead of strtoul() to
> parse
> the value, and remove the "l" suffixes from the macros that define
> the
> limits and default, which were bugging me a bit when used in the
> gen_list struct.
+1
--
Bernd Helmle
Blücherstrasse 17
41061 Mönchengladbach
Tel.: +49 172 726 99 66
Am Mittwoch, dem 02.04.2025 um 22:41 +0300 schrieb Heikki Linnakangas:
> * The stuff to save the FmgrInfo for gbt_enum_sortsupport() was
> broken.
> It saved the address of FmgrInfo struct that was allocated in a local
> variable, on the stack, in SortSupport->ssup-extra, and expected it
> to
> b
Hi,
Am Montag, dem 09.12.2024 um 18:10 +0100 schrieb Bernd Helmle:
> > I think we have two options:
> > 1. Just do not commit tests. We ran it manually, saw that paths are
> > taken, we are happy.
>
> So here's a version with the original, unchanged regression tests
word | openssl passwd -6 -stdin -salt 'abcdefghi%jklmno'
$6$abcdefghi%jklmno$LMN/V1pW97IoK0rWSDVqCo9EYd6zpqP0TdTX9.cxFAFqsdSMWQM
jehkmMtDzL36VBKeG6dg.kFAQKoFvZpK0G.
So the hashes we produce are identical, but with being more strict we
differ in the handling of the prov
Am Freitag, dem 24.01.2025 um 19:06 +0100 schrieb Alvaro Herrera:
> > So we behave exactly the same way as px_crypt_md5(): It stops after
> > the
> > first '$' after the magic byte preamble. For shacrypt, this could
> > be
> > the next '$' after the closing one of the non-mandatory 'rounds'
> > opt
Am Donnerstag, dem 23.01.2025 um 21:36 +0800 schrieb Japin Li:
Thanks for your review again. I am going to work on the other items,
but this one might need further discussion:
> 5.
> Does the following work as expected?
>
> postgres=# select crypt('hello',
> '$5$$6$rounds=1$/Zg436s2vmTwsoSz'
ed boundary.
So when passing a user defined salt string to crypt(), we do the same
now but i added a NOTICE to indicate that we changed the user submitted
parameter behind the scene. This also enables us to stress
px_crypt_shacrypt() with the same test cases as Drepper's code.
Thanks,
Am Mittwoch, dem 15.01.2025 um 19:24 +0100 schrieb Bernd Helmle:
> > Commit 630f9a43cece93cb4a5c243b30e34abce6a89514 created a conflict
> > with
> > this patch so that it doesn't apply anymore.
>
> Seems i broke something during rebase (see cfbot). I will look
Am Mittwoch, dem 15.01.2025 um 14:20 +0100 schrieb Bernd Helmle:
> Commit 630f9a43cece93cb4a5c243b30e34abce6a89514 created a conflict
> with
> this patch so that it doesn't apply anymore.
Seems i broke something during rebase (see cfbot). I will look at this
tomorrow.
Bernd
Am Montag, dem 09.12.2024 um 23:26 +0500 schrieb Andrey M. Borodin:
> > On 9 Dec 2024, at 22:10, Bernd Helmle wrote:
> >
> > So here's a version with the original, unchanged regression tests
> > and
> > injection point removed (i hope i forgot nothing t
Am Dienstag, dem 14.01.2025 um 11:47 +0100 schrieb Alvaro Herrera:
> > Oh, that's news to me. Is there a plan for it somewhere? I agree
> > that
> > pgcrypto is widley used and needs a proper replacement when we
> > decide
> > to deprecate it.
>
> I don't know about a plan, but
> https://www.youtu
Hi Alvaro,
Am Montag, dem 13.01.2025 um 17:06 +0100 schrieb Alvaro Herrera:
> Hello
>
> I was passing by and I noticed that this needs badly pgindent, and
> some
> comments are enumerations that would lose formatting once through it.
> For example, this would happen which is not good:
>
> /*
rely on the very first three
bytes when parsing the magic bytes of the salt string.
Please test again.
Bernd
From beb40e992b9bb78ce245cb00bff39d49ded40eab Mon Sep 17 00:00:00 2001
From: Bernd Helmle
Date: Tue, 7 Jan 2025 18:30:38 +0100
Subject: [PATCH] Add modern SHA-2 based password hashes to pgcrypto.
Am Freitag, dem 03.01.2025 um 23:57 +0800 schrieb Japin Li:
>
> Greate! I have some questions after using it.
>
> When I use the following query, it crashed!
>
> [local]:4012204 postgres=# select crypt('hello',
> '$5$$6$rounds=1$/Zg436s2vmTwsoSz');
> server closed the connection unexpectedl
Am Donnerstag, dem 02.01.2025 um 15:57 +0100 schrieb Daniel Gustafsson:
> > I adapted the code from the publicly available reference
> > implementation
> > at [1]. It's based on our existing OpenSSL infrastructure in
> > pgcrypto
> > and produces compatible password hashes with crypt() and "openssl
Am Dienstag, dem 31.12.2024 um 17:06 +0100 schrieb Bernd Helmle:
> I am going to add this patch to the upcoming january commitfest for
> initial review.
I see cfbot fails Debian Bookworm with autoconf and on macOS with
meson. I will look into it.
ommitfest for
initial review.
[1] https://www.akkadia.org/drepper/SHA-crypt.txt
--
Thanks,
Bernd
From 131b03729123967b93925d7f94bc04d5b5ab347c Mon Sep 17 00:00:00 2001
From: Bernd Helmle
Date: Tue, 31 Dec 2024 16:35:35 +0100
Subject: [PATCH] Add modern SHA-2 based password hashes to pgcry
1
From: Bernd Helmle
Date: Tue, 10 Dec 2024 11:17:06 +0100
Subject: [PATCH] Add support for sorted gist index builds to btree_gist
This enables sortsupport in the btree_gist extension for faster
builds of gist indexes. Additionally sortsupport is also added for range types
to the backend so that gist i
n also fixes cidr sortsupport (thanks again Andrey for
spotting this), where i accidently used inet instead of the correct
cidr datatype to pass down to the sortsupport function.
Thanks,
Bernd
From b38c1181d38526d0ccd948f3446ca31f6953815d Mon Sep 17 00:00:00 2001
From: Bernd Helmle
D
Hi Michael,
Am Freitag, dem 29.11.2024 um 13:42 +0900 schrieb Michael Paquier:
[...]
> Any module that requires the module injection_points to be installed
> can do a few things, none of them are done this way in this patch:
> - Add EXTRA_INSTALL=src/test/modules/injection_points.
> - You coul
Am Montag, dem 11.11.2024 um 23:03 +0500 schrieb Andrey M. Borodin:
> Some nitpicking:
> 0. postgres % git apply ~/Downloads/v7.3-Add-GIST-sortsupport-*
> /Users/x4mmm/Downloads/v7.3-Add-GIST-sortsupport-btree-gist.patch:19:
> space before tab in indent.
I obviously shouldn't do patches after a lo
Am Samstag, dem 26.10.2024 um 11:40 +0300 schrieb Andrey M. Borodin:
> First patch:
> 0. We have PG_FREE_IF_COPY(), does it suits your needs?
PG_FREE_IF_COPY() requires FunctionCallInfo (the macro uses
PG_GETARG_POINTER() to reference the pointer value to compare), which
is not usable in the conte
Hi,
Am Samstag, dem 18.05.2024 um 12:22 +0200 schrieb Tomas Vondra:
> > It was committed once [0], but then reverted, vardata opclasses
> > were
> > implemented wrong. Now it's on CF[1], Bernd is actively responding
> > in
> > the thread, but currently patch lacks tests.
> >
> > Thanks for raisin
Hi Andrey,
Am Freitag, dem 22.03.2024 um 18:27 +0500 schrieb Andrey M. Borodin:
> > Here is a rebased version of the patch.
>
> FWIW it would be nice at least port tests from commit that I
> referenced upthread.
> Nowadays we have injection points, so these tests can be much more
> stable.
Alrig
Hi,
Here is a rebased version of the patch. Since i don't have anything to
add at the moment and the numbers looks promising and to move on, i've
marked this patch "Ready For Committer".
Thanks,
Bernd
diff --git a/contrib/btree_gist/Makefile b/contrib/btree_gist/Makefile
index 7ac2
Am Montag, dem 12.02.2024 um 21:00 +0800 schrieb jian he:
> +
> + Per default btree_gist builts
> GiST indexe with
> + sortsupport in sorted
> mode. This usually results in a
> + much better index quality and smaller index sizes by much faster
> index built speed. It is still
> + possible to r
Am Mittwoch, dem 10.01.2024 um 22:18 +0800 schrieb jian he:
>
> I split the original author's patch into 2.
> 1. Add GiST sortsupport function for all the btree-gist module data
> types except anyrange data type (which actually does not in this
> module)
> 2. Add GiST sortsupport function for anyr
Am Freitag, dem 26.01.2024 um 18:31 +0530 schrieb vignesh C:
> CFBot shows that the patch does not apply anymore as in [1]:
> === Applying patches on top of PostgreSQL commit ID
I've started working on it and planning to submit a polished patch for
the upcoming CF.
Am Mittwoch, dem 10.01.2024 um 20:13 +0500 schrieb Andrey M. Borodin:
> I think GiST sortsupport comments are more relevant, so there's no
> need for this pfree()s.
>
> Also, please check other thread, maybe you will find some useful code
> there [0,1]. It was committed[2] once, but reverted. Plea
Am Mittwoch, dem 10.01.2024 um 08:00 +0800 schrieb jian he:
> you do `CREATE INDEX ON pgbench_accounts USING gist(aid);`
> but the original patch didn't change contrib/btree_gist/btree_int4.c
> So I doubt your benchmark is related to the original patch.
> or maybe I missed something.
>
The pat
Am Dienstag, dem 10.05.2022 um 15:00 +0100 schrieb Simon Riggs:
[...]
>
> > I think REINDEX DATABASE reindexing the current database is a good
> > usability improvement in itself. But skipping the shared catalogs
> > needs an explicity syntax. Not sure how feasible it is but
> > something
> > li
Am Freitag, dem 27.05.2022 um 19:08 + schrieb Cary Huang:
[...]
> The patch applies and tests fine and I think this patch has good
> intentions to prevent the default behavior of REINDEX DATABASE to
> cause a deadlock. However, I am not in favor of simply omitting the
> database name after D
Am Mittwoch, dem 11.05.2022 um 14:42 +0900 schrieb Michael Paquier:
> Agreed. Nobody is going to remember the difference. REINDEX's
> parsing grammar is designed to be extensible because we have the
> parenthesized flavor. Why don't you add an option there to skip the
> catalogs, like a SKIP_CAT
Hi,
Am Dienstag, dem 10.05.2022 um 10:13 +0100 schrieb Simon Riggs:
> A minor issue, and patch.
>
> REINDEX DATABASE currently requires you to write REINDEX DATABASE
> dbname, which makes this a little less usable than we might like.
>
> REINDEX on the catalog can cause deadlocks, which also mak
Am Montag, dem 14.02.2022 um 16:02 -0500 schrieb Andrew Dunstan:
> It occurred to me that this wasn't very well documented, so I created
> some docco:
> <
> https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Testing_Ad
> ditional_Software>
Thx Andrew, i wasn't aware of this, too! I'm goin
Am Mittwoch, dem 09.02.2022 um 08:01 -0500 schrieb Robert Haas:
> On Wed, Feb 9, 2022 at 3:14 AM Kyotaro Horiguchi
> wrote:
> > Thanks for pining. AFAICS, as you see, pg_rman doesn't talk
> > basebackup protocol (nor even pg_basebackup command) as it supports
> > inremental backup. So there's no
Am Dienstag, dem 01.06.2021 um 13:13 +0530 schrieb Bharath Rupireddy:
> I used MyProcPid which seems more random than MyBackendId (which is
> just a number like 1,2,3...). Even with this, someone could argue
> that
> they can look at the backend PID, use it in the materialized view
> names just to
Am Mittwoch, dem 19.05.2021 um 18:06 +0530 schrieb Bharath Rupireddy:
> > The corresponding Code is in `matview.c` in function
> > `refresh_by_match_merge`. With adding a prefix like `_pg_internal_`
> > we
> > could make collisions pretty unlikely, without intrusive changes.
> >
> > The appended p
Am Mittwoch, dem 24.03.2021 um 17:32 +0100 schrieb Bernd Helmle:
> > Yes, but it should be noted that the main reason that was mentioned
> > as
> > a reason to exclude partitions is to not cause table catalog bloat,
> > and I argue that this argument is not as
Am Mittwoch, dem 24.03.2021 um 13:23 +0100 schrieb Matthias van de
Meent:
> Yes, but it should be noted that the main reason that was mentioned
> as
> a reason to exclude partitions is to not cause table catalog bloat,
> and I argue that this argument is not as solid in the case of the
> explicitly
Am Donnerstag, dem 21.01.2021 um 15:56 +0100 schrieb Matthias van de
Meent:
> Hi,
>
> Recently I was trying to copy some of the data of one database to
> another through postgres_fdw, and found that it wouldn't import that
> partition through IMPORT FOREIGN SCHEMA, even when I explicitly
> specifi
Am Mittwoch, den 25.11.2020, 13:47 +0900 schrieb Michael Paquier:
> I can see the use case for IMMEDIATE, but I fail to see the use cases
> for WAIT and FORCE. CHECKPOINT_FORCE is internally implied for the
> end-of-recovery and shutdown checkpoints. WAIT could be a dangerous
> thing if disabled,
Am Montag, den 31.08.2020, 18:48 -0400 schrieb Bruce Momjian:
> > So confirmed.
>
>
> Patch applied through 13.
Thanks!
Hi,
protocol.sgml describes the protocol messages received by a BASE_BACKUP
streaming command, but doesn't tell anything about the additional
CopyResponse data message containing the contents of the backup
manifest (if requested) after having received the tar files. So i
propose the attached to gi
anks,
Bernd
From 15bd3a6457f59f3ba4bf72c645499132e90127cd Mon Sep 17 00:00:00 2001
From: Bernd Helmle
Date: Wed, 26 Feb 2020 16:49:03 +0100
Subject: [PATCH 1/2] Formerly pg_checksums recursively dived into pg_tblspc,
scanning any tablespace location found there without taking into account,
that tablespace l
On Fri, 2020-02-21 at 15:36 +0900, Michael Paquier wrote:
> We don't do that for the normal directory scan path, so it does not
> strike me as a good idea on consistency ground. As a whole, I don't
> see much point in having a separate routine which is just roughly a
> duplicate of scan_directory(
enced DBA has copied over the tablespace into pg_tblspc
directly.
> The issue with pg_internal.init.XX is quite different, so I think
> that
> it would be better to commit that separately first.
Agreed.
Thanks,
Bernd
From 4b6d369f731f111216f9ed6613ad1b41872fb0ea Mon Sep 17 00
Am Freitag, den 31.01.2020, 13:53 +0900 schrieb Michael Paquier:
> Indeed, with a bad timing and a crash in the middle of
> write_relcache_init_file(), it could be possible to have such a file
> left around in the data folder. Having a past tablespace version
> left
> around after an upgrade is a
Am Donnerstag, den 19.12.2019, 00:13 + schrieb Simon Riggs:
> So the consensus is for a more-specifically named facility.
>
> I was aiming for something that would allow general SELECTs to run
> with a
> snapshot that can see uncommitted xacts, so making it a SRF wouldn't
> really
> allow that
Am Mittwoch, den 21.08.2019, 13:26 +0300 schrieb Konstantin Knizhnik:
> Yes, it is possible to have physical replica withotu replication
> slot.
> But it is not safe, because there is always a risk that lag between
> master and replica becomes larger than size of WAL kept at master.
Sure, but tha
Am Mittwoch, den 21.08.2019, 12:20 +0300 schrieb Konstantin Knizhnik:
> I wonder if we can check that
>
> 1. wal_revel is "logical"
> 2. There are no physical replication slots
> 3. WAL archiving is disables
Not sure i get that correctly, i can still have a physical standby
without replication sl
Am Freitag, den 29.03.2019, 23:10 +0900 schrieb Michael Paquier:
>
> I can't really believe that many people set up shared_buffers at
> 128kB
> which would cause such a large number of page evictions, but I can
> believe that many users have shared_buffers set to its default value
> and that we ar
Am Dienstag, den 26.03.2019, 16:14 +0100 schrieb Christoph Berg:
> select 92551.0/97363;
> 0.9506
>
> So the cost is 5% in this very contrived case. In almost any other
> setting, the cost would be lower, I'd think.
Well, my machine (Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz, 32 GByte
RAM) tells
Am Montag, den 18.02.2019, 16:52 +0100 schrieb Michael Banck:
> > Surely we know at that point whether this first scan is needed, and
> we
> > can skip it if not?
>
> Yeah - new patch attached.
Maybe i'm wrong, but my thought is that this breaks the SIGUSR1
business, since there seems no code pat
Am Dienstag, den 08.01.2019, 16:17 +0100 schrieb Fabien COELHO:
> > > Adding a new state to ControlFileData which would prevent it from
> > > starting?
> >
> > But then you have to make sure the control flag gets cleared in any
> > case pg_verify_checksums crashes somehow or gets SIGKILL'ed ...
>
Am Dienstag, den 08.01.2019, 15:09 +0100 schrieb Fabien COELHO:
> > The question is how to reliably do this in an acceptable way? Just
> > faking a postmaster.pid sounds pretty hackish to me, do you have
> > any
> > suggestions here?
>
> Adding a new state to ControlFileData which would prevent it
Am Dienstag, den 28.08.2018, 11:21 +0200 schrieb Peter Eisentraut:
> This is reproducible with PG11 and PG12:
>
> initdb -k data
> postgres -D data
>
> make installcheck
> # shut down postgres with Ctrl-C
>
I tried to reproduce this and by accident i had a blocksize=4 in my
configure script, an
Am Dienstag, den 10.04.2018, 15:59 +0530 schrieb Pavan Deolasee:
> One of our 2ndQuadrant support customers recently reported a sudden
> rush of
> TOAST errors post a crash recovery, nearly causing an outage. Most
> errors
> read like this:
>
> ERROR: unexpected chunk number 0 (expected 1) for toa
Am Dienstag, den 16.01.2018, 08:25 + schrieb REIX, Tony:
> I've been able to compare PostgreSQL compiled with XLC vs GCC 7.1
> and, using times outputs provided by PostgreSQL tests, XLC seems to
> provide at least 8% more speed. We also plan to run professional
> performance tests in order to c
64 matches
Mail list logo
