Hi,
On Tue, Jul 01, 2025 at 12:41:50PM -0400, Tom Lane wrote:
> Michael Banck writes:
> > please find attached the current patches required to get master built
> > and the testsuites run on Debian's hurd-i386 port. I have not had the
> > time to test the hurd-amd64 por
:00 2001
From: Michael Banck
Date: Tue, 10 Jun 2025 12:23:17 +0200
Subject: [PATCH 1/2] Make safeguard against incorrect fd flags for fsync more
portable.
The current code assumed that O_RDONLY is defined as 0, but this is not
universally the case. To fix this, mask the flags with O_ACCMODE an
Hi,
On Wed, Jun 25, 2025 at 08:36:01AM +0900, Michael Paquier wrote:
> On Tue, Jun 24, 2025 at 07:51:08AM +0200, Michael Banck wrote:
> > I got it working, I had to rebuild gnumach with --enable-apic in order
> > to get HPET. With that, the regular build-farm checks (check/
>
Hi,
another update:
On Wed, Jun 11, 2025 at 09:24:24PM +0200, Michael Banck wrote:
> So it seems the low-resolution timer is the only functional issue right
> now. I upgraded my VM to current Debian unstable, but unfortunately that
> did not increase the timer resolution is hoped, m
On Tue, Jun 10, 2025 at 09:09:35PM -0400, Tom Lane wrote:
> Still, I'd like to be closer to having a working Hurd buildfarm member
> before we take a portability risk that would only benefit Hurd.
I've spent some more time on this, here's the status beyond make check:
1. The pg_stat_statements en
Hi,
one more thing:
On Tue, Jun 10, 2025 at 12:26:48PM +0200, Michael Banck wrote:
> The better way might be to mask the flags with O_ACCMODE and then just
> check what you want, like in the attached.
I forgot to mention it in the patch, but Samuel Thibault reviewed the
patch and sug
Hi,
On Tue, Jun 10, 2025 at 12:59:16PM +0200, Michael Banck wrote:
> On Tue, Jun 10, 2025 at 09:05:03AM +1200, Thomas Munro wrote:
> > https://savannah.gnu.org/task/?7050
>
> 3. make check nowadays succeeds the subscription test that it failed in
> the log mentioned in the
Hi,
On Tue, Jun 10, 2025 at 09:05:03AM +1200, Thomas Munro wrote:
> On Tue, Jun 10, 2025 at 2:25 AM Andres Freund wrote:
> > On 2025-06-09 15:25:22 +0200, Michael Banck wrote:
> > > Postgres built fine up and until v15 on the Hurd, so this is a build
> > > regression,
with
O_ACCMODE and then just check what you want, like in the attached.
Thoughts?
Michael
[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/bits/fcntl.h;hb=HEAD#l39
>From 16431e7b1aac9600fac285e77f39bb628a0dea14 Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Tue, 1
Hi,
On Mon, Jun 09, 2025 at 10:25:23AM -0400, Andres Freund wrote:
> I think our policy basically is that if it doesn't exist on the BF, it's
> unsupported. Also note that Hurd is not listed as a supported OS:
> https://www.postgresql.org/docs/devel/supported-platforms.html
>
> We can't design fo
Hi Thomas,
On Thu, Aug 11, 2022 at 10:02:29PM +1200, Thomas Munro wrote:
> Remove configure probe for sys/uio.h.
Removing the configure probe is fine, but the patch also changes
behavior in the sense that IOV_MAX is now considered defined everywhere
but on Windows. However, in the good-old GNU "w
Hi,
On Tue, Jun 03, 2025 at 05:25:40PM +0900, Shinya Kato wrote:
> On Tue, Jun 3, 2025 at 4:42 PM Michael Banck wrote:
> > On Tue, Jun 03, 2025 at 03:35:20PM +0900, Shinya Kato wrote:
> > > I am proposing the introduction of two new GUC parameters,
> > > log
Hi,
On Tue, Jun 03, 2025 at 03:35:20PM +0900, Shinya Kato wrote:
> I am proposing the introduction of two new GUC parameters,
> log_autovacuum_{vacuum|analyze}_min_duration, to replace the existing
> log_autovacuum_min_duration.
How about adding log_autoanalyze_min_duration instead? That would st
Hi,
On Wed, Apr 16, 2025 at 10:24:48AM +0500, Andrey Borodin wrote:
> I think I can provide some reasons why it cannot be neither extension,
> nor any part running within postmaster reign.
>
> 1. When joining cluster, there’s not PGDATA to run postmaster on top
> of it.
>
> 2. After failover, ol
Hi,
On Tue, Apr 01, 2025 at 08:01:32AM +, Hayato Kuroda (Fujitsu) wrote:
> Attached patch implements it. Since -f/-F option has already been used, -O was
> chosen for the short-version. Better idea is very welcomed.
Maybe we don't need a short option at all for this, at least initially?
Mic
Hi,
On Wed, Mar 19, 2025 at 09:53:37AM +0100, Christophe Pettus wrote:
> We're tracking down an issue that we've seen in two separate
> installations so far, which is that, at the very end of a vacuum, the
> vacuum operation starts using *very* high levels of CPU and
> (sometimes) I/O, often to th
Hi,
On Fri, Mar 07, 2025 at 09:17:46AM -0500, Robert Haas wrote:
> Why wouldn't the cloud provider just change add 'trusted = true' to
> the relevant control files instead of doing this?
That would be possible, but maybe the cloud provider is using
distribution packages and does not want to muck
Hi,
On Fri, Jan 17, 2025 at 10:03:17AM +0100, Laurenz Albe wrote:
> On Thu, 2024-10-31 at 22:47 +0100, Michael Banck wrote:
> > Even though there has not been a lot of discussion on this, here is a
> > rebased patch. I have also added it to the upcoming commitfest.
>
> I ha
Hi,
On Mon, Jan 13, 2025 at 02:48:31PM +0100, Antonin Houska wrote:
> Alvaro Herrera wrote:
> > On 2025-Jan-09, Antonin Houska wrote:
> > > It seems you accidentally fixed another problem :-) I was referring to the
> > > 'lockmode' argument of make_new_heap(). I can try to write a patch for
> >
Hi,
On Thu, Jan 16, 2025 at 04:09:44PM +0900, Shinya Kato wrote:
> On Thu, Jan 16, 2025 at 3:31 PM Michael Banck wrote:
> > I do think having a whitelist of allowed-to-be-installed extensions
> > (similar/like https://github.com/dimitri/pgextwlist) makes sense
> > ad
Hi,
On Wed, Jan 15, 2025 at 09:12:17AM +, Andy Fan wrote:
> I can understand that "the file space has really been allocated", but
> why do we care about this?
>
> One reason I can think of is it has something with "out-of-disk-space"
> sistuation, even though what's the benefit of it since we
Hi,
On Sat, Jan 11, 2025 at 09:01:54AM -0500, Andrew Dunstan wrote:
> On 2025-01-09 Th 8:35 AM, Alvaro Herrera wrote:
> > Maybe we should have a new toplevel command. Some ideas that have been
> > thrown around:
> >
> > - RETABLE (it's like REINDEX, but for tables)
> > - ALTER TABLE SQUEEZE
> >
Hi,
On Fri, Jan 10, 2025 at 01:04:14PM +0100, Magnus Hagander wrote:
> In an effort to make at least a couple of more people realize they have to
> run ALTER EXTENSION UPDATE after they've upgraded an extension, as well as
> make it a bit easier to realize when you have to do it, I propose we add
Hi,
first, sorry for the late reply :-/
On Mon, Nov 18, 2024 at 11:26:40AM +0500, Kirill Reshke wrote:
> On Fri, 1 Nov 2024 at 02:47, Michael Banck wrote:
> > Even though there has not been a lot of discussion on this, here is a
> > rebased patch. I have also added it
Hi,
On Wed, Dec 18, 2024 at 03:17:36PM +0900, Michael Paquier wrote:
> On Tue, Dec 17, 2024 at 09:42:36AM +0100, Michael Banck wrote:
> > Done.
> >
> > V3 attached.
>
> Done.
Thanks!
Michael
Hi,
On Tue, Dec 17, 2024 at 04:43:21PM +0900, Michael Paquier wrote:
> On Mon, Dec 16, 2024 at 10:57:49PM +0100, Michael Banck wrote:
> > Thanks, I have added the documentation now in v2.
>
> The doc additions seem fine to me. I've just grabbed three tiny nits,
> nothin
Hi Michael,
On Tue, Dec 10, 2024 at 04:38:24PM +0900, Michael Paquier wrote:
> On Thu, Nov 28, 2024 at 09:17:23PM +0100, Michael Banck wrote:
> > On Tue, Nov 19, 2024 at 07:47:58PM -0500, Greg Sabino Mullane wrote:
> > > Compiled and tested: works fine, so +1 from me. Honestl
ery to check for an end-of-WAL condition at that spot.
Michael
>From 015a9bfb2bd57f37f7c9601e9014d7560b76c21d Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Sat, 30 Nov 2024 11:51:34 +0100
Subject: [PATCH v1] Re-introduce less scary message for possible end-of-WAL
invalid record.
A lot of
Hi,
On Tue, Nov 19, 2024 at 07:47:58PM -0500, Greg Sabino Mullane wrote:
> Compiled and tested: works fine, so +1 from me. Honestly, I was surprised
> %s was still available. :)
Thanks. Was that full review? You kept the commitfest item in "Needs
Review" state.
Michael
Hi,
On Tue, Nov 12, 2024 at 03:56:11PM +0100, Benoit Lobréau wrote:
> On 11/12/24 15:05, Michael Banck wrote:
> > I was wondering about the weird new column name workers_to_launch when I
> > read the commit message - AFAICT this has been an internal term so far,
> > and this
Hi,
On Fri, Oct 11, 2024 at 09:33:48AM +0200, Guillaume Lelarge wrote:
> FWIW, with the recent commits of the pg_stat_statements patch, you need a
> slight change in the patch I sent on this thread. You'll find a patch
> attached to do that. You need to apply it after a rebase to master.
>
> -
Hi,
Even though there has not been a lot of discussion on this, here is a
rebased patch. I have also added it to the upcoming commitfest.
On Sat, Jan 13, 2024 at 09:20:40AM +0100, Michael Banck wrote:
> On Fri, Jan 12, 2024 at 04:13:27PM +0100, Jelte Fennema-Nio wrote:
> > But I'm
o me during a recent customer training.
I chose the '%s' tag for it. I had to add the service to PGConn as
PQservice (first patch) to libpq and then use it in psql in the second
patch.
Michael
>From f876195acb797a5ac58c17409fdd75d18581c292 Mon Sep 17 00:00:00 2001
From: Michael Banck
Hi,
So I am a bit confused about the status of the tar format support, and
after re-reading the thread (or at least grepping it for ' tar '), this
wasn't really much discussed here either.
On Wed, Jun 14, 2023 at 02:46:48PM -0400, Robert Haas wrote:
> - We only know how to operate on directories,
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 polish (the docs for
> sure do) but it's at least a start.
Just a nitpick, but we call it data_ch
Hi,
On Tue, Oct 24, 2023 at 11:42:15AM -0400, Tom Lane wrote:
> Christoph Berg writes:
> > Anyway, if this doesn't raise any "oh we didn't think of this"
> > concerns, we'll just remove the old operators in pgsphere.
>
> Well, the idea was exactly to forbid that sort of setup.
> However, if we g
On Fri, Sep 20, 2024 at 03:20:16PM -0500, Nathan Bossart wrote:
> On Fri, Sep 20, 2024 at 01:56:16PM -0500, Nathan Bossart wrote:
> > On Fri, Sep 20, 2024 at 07:20:15PM +0200, Michael Banck wrote:
> >> I noticed two headers are not in alphabetical order in pg_checkums.c,
&
Hi,
I noticed two headers are not in alphabetical order in pg_checkums.c,
patch attached.
Michael
>From e4d6d6503b4c14685424c6a04c5eb2ae29024bf6 Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Fri, 20 Sep 2024 19:17:43 +0200
Subject: [PATCH] Reorder headers in pg_checkums.c in alphabeti
Hi,
On Tue, Sep 10, 2024 at 10:16:34AM +1200, David Rowley wrote:
> On Tue, 10 Sept 2024 at 09:39, Shayon Mukherjee wrote:
> > Adding and removing indexes is a common operation in PostgreSQL. On
> > larger databases, however, these operations can be
> > resource-intensive. When evaluating the per
On Thu, Sep 05, 2024 at 09:51:25PM -0400, Bruce Momjian wrote:
> On Tue, Sep 3, 2024 at 10:44:01AM -0500, Nathan Bossart wrote:
> > While freely acknowledging that I am biased because I wrote it, I am a bit
> > surprised to see the DSM registry left out of the release notes (commit
> > 8b2bcf3, do
Hi,
On Thu, Sep 05, 2024 at 09:12:07PM +1200, Thomas Munro wrote:
> On Thu, Sep 5, 2024 at 6:45 PM Mats Kindahl wrote:
> > Making the ReadStream API non-opaque (that is, moving the definition
> > to the header file) would at least solve our problem (unless I am
> > mistaken). However, I am ignora
Hi,
On Tue, Aug 27, 2024 at 03:11:15PM -0400, Robert Haas wrote:
> Third, I think there's simply a lack of critical mass in terms of our
> planner hooks. While the ability to add hypothetical indexes has some
> use, the ability to remove indexes from consideration is probably
> significantly more
On Thu, Aug 15, 2024 at 09:49:04AM +0200, Jakub Wartak wrote:
> On Wed, Aug 7, 2024 at 4:18 PM Greg Sabino Mullane wrote:
> >
> > On Wed, Aug 7, 2024 at 4:43 AM Michael Banck wrote:
> >>
> >> I think the last time we dicussed this the consensus was that
> &g
Hi,
On Wed, Aug 14, 2024 at 06:05:19PM -0700, Jeff Davis wrote:
> That looks good to me. Does anyone have a different opinion? If not,
> I'll go ahead and commit (but not backport) this change.
What is the rationale not to backpatch this? The error message changes,
but we do not translate configu
Hi,
adding Jeff to CC as he changed the way ICU configure detection was done
in fcb21b3.
On Fri, Aug 09, 2024 at 11:59:12AM +0300, Heikki Linnakangas wrote:
> On 09/08/2024 11:16, Michael Banck wrote:
> > Hi,
> >
> > Holger Jacobs complained in pgsql-admin that in v17
Meh, forgot the attachment. Also, this should be backpatched to v17 if
accepted.
Michael
>From b696949180437a3c7307ac0509cba54828b44259 Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Fri, 9 Aug 2024 10:13:27 +0200
Subject: [PATCH] Improve configure error for ICU libraries if pkg-config
Hi,
Holger Jacobs complained in pgsql-admin that in v17, if you have the ICU
development libraries installed but not pkg-config, you get a somewhat
unhelpful error message about ICU not being present:
|checking for pkg-config... no
|checking whether to build with ICU support... yes
|checking for
On Thu, Aug 08, 2024 at 12:11:38PM +0200, Peter Eisentraut wrote:
> So I think we need to think through the upgrade experience a bit more.
> Unfortunately, pg_checksums hasn't gotten to the point that we were perhaps
> once hoping for that you could enable checksums on a live system. I'm
> thinkin
Hi,
On Tue, Aug 06, 2024 at 06:46:52PM -0400, Greg Sabino Mullane wrote:
> Please find attached a patch to enable data checksums by default.
>
> Currently, initdb only enables data checksums if passed the
> --data-checksums or -k argument. There was some hesitation years ago when
> this feature w
Hi,
On Mon, Jul 22, 2024 at 08:39:23AM -0400, Robert Haas wrote:
> What the extensions that are out there seem to do is, as I understand
> it, an online table rewrite with concurrent change capture, and then
> you apply the changes to the output table afterward. That has the
> problem that if the
On Mon, Jul 22, 2024 at 01:23:03PM +0500, Kirill Reshke wrote:
> Also, should we create a cf entry for this thread already?
I was wondering about this as well, but there is one for the upcoming
commitfest already:
https://commitfest.postgresql.org/49/5117/
Michael
Hi,
this patch is still on the table, though for v18 now.
Nathan mentioned up-thread that he was hesitant to commit this without
further discussion. Laurenz, Stephen and I are +1 on this, but when it
comes to committers having chimed in only Tom did so far and was -1.
Are there any others who h
Hi,
On Fri, Apr 07, 2023 at 01:32:22PM -0400, Tom Lane wrote:
> "wangw.f...@fujitsu.com" writes:
> > On Tues, Apr 4, 2023 at 23:48 PM Tom Lane wrote:
> >> I like the "per eligible process" wording, at least for guc_tables.c;
> >> or maybe it could be "per server process"? That would be more
> >
Hi,
On Fri, Apr 26, 2024 at 10:18:00AM +0200, Laurenz Albe wrote:
> On Fri, 2024-04-26 at 09:35 +0200, Frédéric Yhuel wrote:
> > Le 26/04/2024 à 04:24, Laurenz Albe a écrit :
> > > On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> > > > I believe that the underlying problem here can be summa
Hi,
On Fri, Apr 26, 2024 at 04:24:45AM +0200, Laurenz Albe wrote:
> On Thu, 2024-04-25 at 14:33 -0400, Robert Haas wrote:
> > Another reason, at least in existing releases, is that at some
> > point index vacuuming hits a wall because we run out of space for dead
> > tuples. We *most definitely* w
Hi,
On Wed, Mar 20, 2024 at 11:22:12PM +0100, Daniel Gustafsson wrote:
> > On 20 Mar 2024, at 22:21, Jacob Champion
> > wrote:
> >
> > On Wed, Mar 20, 2024 at 2:15 PM Jacob Champion
> > wrote:
> >> I think solutions for case 1 and case 2 are necessarily at odds under
> >> the current design, i
Hi,
On Sun, Mar 31, 2024 at 01:05:40PM -0400, Joe Conway wrote:
> But it has always bothered me how many patches get applied to the upstream
> tarballs by the OS package builders. Some of them, e.g. glibc on RHEL 7,
> include more than 1000 patches that you would have to manually vet if you
> care
On Sat, Mar 30, 2024 at 09:52:47PM -0400, Bruce Momjian wrote:
> On Sat, Mar 30, 2024 at 07:54:00PM -0400, Joe Conway wrote:
> > Virtually every RPM source, including ours, contains out of tree patches
> > that get applied on top of the release tarball. At least for the PGDG
> > packages, it would
Hi,
On Wed, Mar 27, 2024 at 10:53:51AM +0100, Laurenz Albe wrote:
> On Wed, 2024-03-27 at 10:20 +0100, Michael Banck wrote:
> > Also, is there a chance this is going to be back-patched? I guess it
> > would be enough if the ugprade target is v17 so it is less of a concern,
>
Hi,
On Sat, Mar 16, 2024 at 06:46:15PM -0400, Tom Lane wrote:
> Laurenz Albe writes:
> > On Fri, 2024-03-15 at 19:18 -0400, Tom Lane wrote:
> >> This patch seems to have stalled out again. In hopes of getting it
> >> over the finish line, I've done a bit more work to address the two
> >> loose e
Hi,
On Wed, Mar 20, 2024 at 08:11:32PM +0100, Magnus Hagander wrote:
> (And FWIW also already solved on debian-based platforms for example,
> which but the main config files in /etc with postgres only having read
> permissions on them
JFTR - Debian/Ubuntu keep postgresql.conf under /etc/postgres
Hi,
On Tue, Mar 19, 2024 at 10:51:50AM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Perhaps we could make that even better with a GUC though. I propose a
> > GUC called 'configuration_managed_externally = true / false". If you set
> > it to true, we prevent ALTER SYSTEM and make the
On Fri, Mar 15, 2024 at 11:17:53AM +0100, Daniel Gustafsson wrote:
> > On 14 Mar 2024, at 16:48, Peter Eisentraut wrote:
> > One could instead, for example, describe those as "maintenance releases":
>
> That might indeed be a better name for what we provide.
+1
Hi,
On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
> > On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> > > https://www.postgresql.org/support/versioning/
> > >
> > > This web page should correct t
Hi,
On Sun, Mar 10, 2024 at 09:58:25AM -0400, Robert Treat wrote:
> On Fri, Mar 8, 2024 at 10:47 AM Michael Banck wrote:
> > On Fri, Jan 12, 2024 at 10:14:38PM +, Cary Huang wrote:
> > > I think it is good to warn the user about the increased allocation of
> > > me
Hi,
On Fri, Jan 12, 2024 at 10:14:38PM +, Cary Huang wrote:
> I think it is good to warn the user about the increased allocation of
> memory for certain parameters so that they do not abuse it by setting
> it to a huge number without knowing the consequences.
Right, and I think it might be u
Hi,
On Wed, Mar 06, 2024 at 09:34:37PM +0100, Tomas Vondra wrote:
> On 3/6/24 19:24, Jacob Champion wrote:
> > On Wed, Mar 6, 2024 at 8:10 AM Nathan Bossart
> > wrote:
> >> Assuming you are referring to the case where we run out of free slots in
> >> acr_array, I'm not sure I see that as desirab
than a real policy decision, so
let's do away with it.
V5 attached.
Michael
>From 3563d77061480b7e022255b968a39086b0cc8814 Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Wed, 27 Dec 2023 15:55:39 +0100
Subject: [PATCH v5] Add optional exponential backoff to auth_delay contrib
modul
er confusing.)
Right, I added a log line for that. However, I made it LOG instead of
WARNING as I don't think the client would ever see it, would he?
Attached is v4 with the above changes.
Cheers,
Michael
>From 6520fb1e768bb8bc26cafad014d08d7e9ac7f12a Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Wed, 27 De
Hi,
On Thu, Feb 29, 2024 at 12:57:31AM -0800, Andres Freund wrote:
> On 2024-02-29 09:13:04 +0100, Michael Banck wrote:
> > The commit message says there is not a lot of user demand and that might
> > be right, but contrary to other fringe OSes that got removed like HPPA
> &g
Hi,
On Sat, Feb 24, 2024 at 01:29:36PM -0800, Andres Freund wrote:
> Let's just drop AIX. This isn't the only alignment issue we've found and the
> solution for those isn't so much a fix as forcing everyone to carefully only
> look into one direction and not notice the cliffs to either side.
Whil
Hi,
On Wed, Jan 24, 2024 at 02:50:52PM -0500, Kirk Wolak wrote:
> On Mon, Jan 22, 2024 at 1:30 AM Kirk Wolak wrote:
> > On Fri, Jan 19, 2024 at 7:03 PM Daniel Gustafsson wrote:
> >> > On 19 Jan 2024, at 23:09, Kirk Wolak wrote:
> > Thank you, that made it possible to build and run...
> > UNFORT
Hi,
On Thu, Jan 25, 2024 at 08:56:52AM -0400, David Steele wrote:
> I would still advocate for a back patch here. It is frustrating to get logs
> from users that just say:
>
> LOG: invalid checkpoint record
> PANIC: could not locate a valid checkpoint record
>
> It would be very helpful to kno
Hi,
On Thu, Jan 11, 2024 at 03:24:55PM +0100, Michael Banck wrote:
> On Thu, Dec 21, 2023 at 02:29:05PM +0100, Laurenz Albe wrote:
> > Here is a patch to implement this.
> > Being stuck behind a lock for more than a second is almost
> > always a problem, so it is reasonab
On Fri, Jan 19, 2024 at 03:08:36PM +0100, Michael Banck wrote:
> I went through your comments (a lot of which pertained to the original
> larger patch I took code from), attached is a reworked version 2.
Oops, we are supposed to be at version 3, attached.
Michael
doc/src/sgml/auth-delay.sgml
> > +++ b/doc/src/sgml/auth-delay.sgml
> > @@ -16,6 +16,17 @@
> >connection slots.
> >
> >
> > +
> > + It is optionally possible to let auth_delay wait
> > longer
> > + for each successive authentication fa
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 not (apart
> from explaining a query with costs adjusted but that's not all that
> userfriendly).
Hi,
On Fri, Jan 12, 2024 at 04:13:27PM +0100, Jelte Fennema-Nio wrote:
> But I'm not sure that such a pg_manage_extensions role would have any
> fewer permissions than superuser in practice.
Note that just being able to create an extension does not give blanket
permission to use it. I did a few
WIP patch for this.
Thoughts?
Michael
>From 59497e825184f0de30a18573ffd7d331be3b233d Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Fri, 12 Jan 2024 13:56:59 +0100
Subject: [PATCH] Add new pg_manage_extensions predefined role.
This allows any role that is granted this new predefined role
Hi,
On Fri, Jan 12, 2024 at 01:35:24PM +0100, Pavel Stehule wrote:
> pá 12. 1. 2024 v 11:54 odesílatel Michael Banck napsal:
> > Which version of Postgres is this and on which platform/distribution?
>
> It was tested on master branch (pg 17) on Fedora 39
>
> > Did you
Hi,
On Fri, Jan 12, 2024 at 11:02:14AM +0100, Pavel Stehule wrote:
> pá 12. 1. 2024 v 10:27 odesílatel Pavel Stehule
> napsal:
>
> > Hi
> >
> > I have reported very memory expensive pattern:
[...]
> > takes lot of megabytes of memory too.
>
> The megabytes leaks are related to JIT. With JIT o
Hi,
On Thu, Dec 21, 2023 at 02:29:05PM +0100, Laurenz Albe wrote:
> Here is a patch to implement this.
> Being stuck behind a lock for more than a second is almost
> always a problem, so it is reasonable to turn this on by default.
I also think that this should be set to on.
I had a look at the
Hi,
On Wed, Dec 27, 2023 at 05:19:54PM +0100, Michael Banck wrote:
> This patch adds exponential backoff so that one can choose a small
> initial value which gets doubled for each failed authentication attempt
> until a maximum wait time (which is 10s by default, but can be disable
extending auth_delay by 成之焕 from a year ago:
https://postgr.es/m/ahwaxacqiwivoehs5yejpqog.1.1668569845751.hmail.zhch...@ceresdata.com
Michael
>From 4c964c866010bbdbeee9f0b2a755d97c91c5c091 Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Wed, 27 Dec 2023 15:55:39 +0100
Subject: [PATCH v1]
Hi,
On Tue, Dec 12, 2023 at 11:18:59AM +0100, Daniel Gustafsson wrote:
> > On 12 Dec 2023, at 01:09, Tristan Partin wrote:
> >
> > Not sold on the name, but --check is a combination of --silent-diff
> > and --show-diff. I envision --check mostly being used in CI
> > environments. I recently came
Hi,
On Fri, Nov 24, 2023 at 12:17:56PM +0100, Magnus Hagander wrote:
> On Fri, Nov 24, 2023 at 11:21 AM Michael Banck wrote:
> > On Wed, Nov 22, 2023 at 11:23:34PM -0500, Bruce Momjian wrote:
> > > + Non-zero values of
> > > + vacuum_cost_delay will delay s
Hi,
On Wed, Nov 22, 2023 at 11:23:34PM -0500, Bruce Momjian wrote:
> + Non-zero values of
> + vacuum_cost_delay will delay statistics generation.
Now I wonder wheter vacuumdb maybe should have an option to explicitly
force vacuum_cost_delay to 0 (I don't think it has?)?
Michael
Hi,
On Tue, Nov 07, 2023 at 05:30:20PM -0500, Bruce Momjian wrote:
> On Mon, Nov 6, 2023 at 09:53:50PM +0100, Laurenz Albe wrote:
> > +
> > + There is no way to change the default privileges for objects created by
> > + arbitrary roles. You have run ALTER DEFAULT
> > PRIVILEGES
>
> I fin
Hi,
On Sat, Nov 04, 2023 at 09:14:01PM -0400, Bruce Momjian wrote:
> + There is no way to change the default privileges for objects created by
> + any role. You have run ALTER DEFAULT PRIVILEGES for
> all
> + roles that can create objects whose default privileges should be modified.
That
ersion of this patch.
Michael
>From bc9eb46a49ee514236aabe42d9689a7c35b5bcd7 Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Thu, 19 Oct 2023 11:37:11 +0200
Subject: [PATCH v3] pg_basebackup: Mention that spread checkpoints are the
default in --help
---
src/bin/pg_basebackup/pg_base
Hi,
On Fri, Oct 27, 2023 at 05:49:42PM +0200, Laurenz Albe wrote:
> On Fri, 2023-10-27 at 11:34 +0200, Michael Banck wrote:
> > On Fri, Oct 27, 2023 at 09:03:04AM +0200, Laurenz Albe wrote:
> > > On Fri, 2022-11-04 at 10:49 +0100, Laurenz Albe wrote:
> > > > On
Hi,
On Fri, Oct 27, 2023 at 09:03:04AM +0200, Laurenz Albe wrote:
> On Fri, 2022-11-04 at 10:49 +0100, Laurenz Albe wrote:
> > On Thu, 2022-11-03 at 11:32 +0100, Laurenz Albe wrote:
> > > On Wed, 2022-11-02 at 19:29 +, David Burns wrote:
> > >
> > > > Some additional clarity in the versions 1
Hi,
On Wed, Oct 25, 2023 at 04:36:41PM +0200, Peter Eisentraut wrote:
> On 19.10.23 11:39, Michael Banck wrote:
> > Hi,
> >
> > I believed that spread (not fast) checkpoints are the default in
> > pg_basebackup, but noticed that --help does not specify which is
Hi,
On Sun, Oct 22, 2023 at 11:00:07AM +0200, André Verwijs wrote:
> missing dependencies PostgreSQL 16 OpenSUSE Tumbleweed (SLES 15.5
> packages)
>
> ---
>
> YaST2 conflicts list - generated 2023-10-22 10:30:07
>
> there is no package providing 'libldap_r-2.4.so.2())(64bit)' requ
Hi,
On Thu, Oct 19, 2023 at 04:21:19PM +0300, Aleksander Alekseev wrote:
> > I believed that spread (not fast) checkpoints are the default in
> > pg_basebackup, but noticed that --help does not specify which is which -
> > contrary to the reference documentation.
> >
> > So I propose the small att
1bd Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Thu, 19 Oct 2023 11:37:11 +0200
Subject: [PATCH] pg_basebackup: Mention that spread checkpoints are the
default in --help
---
src/bin/pg_basebackup/pg_basebackup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/
On Mon, Oct 16, 2023 at 11:15:53AM -0400, David Steele wrote:
> On 10/16/23 10:19, Robert Haas wrote:
> > We got rid of exclusive backup mode. We replaced pg_start_backup
> > with pg_backup_start.
>
> I do think this was an improvement. For example it allows us to do
> [1], which I believe is a be
Hi,
On Mon, Jul 10, 2023 at 02:37:24PM -0700, Nikolay Samokhvalov wrote:
> On Mon, Jul 10, 2023 at 2:02 PM Michael Banck wrote:
> > > +++ b/doc/src/sgml/ref/pgupgrade.sgml
> > > @@ -380,22 +380,28 @@ NET STOP postgresql-&majorversion;
> > >
>
Hi,
On Mon, Jul 10, 2023 at 01:36:39PM -0700, Nikolay Samokhvalov wrote:
> On Fri, Jul 7, 2023 at 6:31 AM Stephen Frost wrote:
> > * Nikolay Samokhvalov (n...@postgres.ai) wrote:
> > > But this can happen with anyone who follows the procedure from the docs
> > as
> > > is and doesn't do any addit
Hi,
On Sat, Jun 24, 2023 at 01:54:53PM -0400, Tom Lane wrote:
> I don't know whether raising the default would be enough to fix that
> in a nice way, and I certainly don't pretend to have a specific value
> to offer. But it's undeniable that we have a serious problem here,
> to the point where JI
1 - 100 of 349 matches
Mail list logo
