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
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*
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,
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
>
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
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
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
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
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
on, 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
module.
MIME-Version: 1.0
Content-T
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 Dec 2023 15:55:39 +0100
Subject: [PATCH v4] Add optional expone
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.
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...
> >
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
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
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
>
> >
> > +
> > + It is optionally possible to let auth_delay wait
> > longer
> > + for each successive authentication failure from a particular remote
> > host, if
> > + the configuration parameter auth_delay.exp_backoff is
> > + active. On
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
>
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
a 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 r
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
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
at
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
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
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
d version 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
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 wh
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)'
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
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
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-
> > >
> > >
> > >
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
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
Hi,
On Sat, Jun 17, 2023 at 07:10:23PM -0400, James Cloos wrote:
> Has anyone recently tried updating a streaming replication cluster using
> debian’s pg_upgradecluster(1) on each node?
Note that the word "cluster" in upgradecluster refers to a single
Postgres instance, a.k.a a cluster of
Hi,
On Thu, Feb 02, 2023 at 12:56:47PM -0800, Nikolay Samokhvalov wrote:
> On Thu, Feb 2, 2023 at 12:43 PM Peter Geoghegan wrote:
> > I think that that problem should be solved at a higher level, in the
> > program that runs amcheck. Note that pg_amcheck will already do this
> > for B-Tree
Hi,
On Tue, Nov 29, 2022 at 02:57:08PM +, Jelte Fennema wrote:
> Attached is a new version with the tests cleaned up a bit (more
> comments mostly).
>
> @Michael, did you have a chance to look at the last version? Because I
> feel that the patch is pretty much ready for a committer to look
Hi,
On Wed, Sep 21, 2022 at 09:12:04PM -0400, Tom Lane wrote:
> In any case I agree with the point that --create-slot seems
> rather obsolete. If you are trying to resume in a previous
> replication stream (which seems like the point of persistent
> slots) then the slot had better already exist.
Hi,
On Mon, Sep 12, 2022 at 02:16:56PM +, Jelte Fennema wrote:
> Attached is an updated patch with the following changes:
> 1. rebased (including solved merge conflict)
> 2. fixed failing tests in CI
> 3. changed the commit message a little bit
> 4. addressed the two remarks from Micheal
> 5.
Hi,
On Wed, Sep 14, 2022 at 05:53:48PM +0300, Maxim Orlov wrote:
> > Also, IMO, the solution must have a fallback mechanism if the
> > standby/chosen host isn't reachable.
>
> Yeah, I think it should. I'm not insisting on a particular name of options
> here, but in my view, the overall idea may
Hi,
the patch no longer applies cleanly, please rebase (it's trivial).
I don't like the provided commit message very much, I think the
discussion about pgJDBC having had load balancing for a while belongs
elsewhere.
On Wed, Jun 22, 2022 at 07:54:19AM +, Jelte Fennema wrote:
> I tried to
Hi,
On Tue, Aug 30, 2022 at 03:58:48PM -0400, Jonathan S. Katz wrote:
> ### Other Notable Changes
>
> PostgreSQL server-level statistics are now collected in shared memory,
> eliminating the statistics collector process and writing these stats to disk.
> PostgreSQL 15 also revokes the `CREATE`
handling of personal data is subject to:
https://www.credativ.de/en/contact/privacy/
>From 00b1b245f74a0496a4d60cfafff92735dbe73d22 Mon Sep 17 00:00:00 2001
From: Michael Banck
Date: Mon, 22 Aug 2022 16:20:14 +0200
Subject: [PATCH] Allow usage of archive .backup files as backup_label.
This l
Hi,
On Thu, Apr 21, 2022 at 10:18:56AM -0400, Tom Lane wrote:
> And as for the version, if you want that you can get it from "initdb
> --version".
I assumed the point in stamping the version in the output was that
people might want to pipe it to some logfile and then later on, when
they found
Hi,
Am Donnerstag, dem 10.03.2022 um 15:28 +0100 schrieb Gunnar "Nick"
Bluth:
> Am 10.03.22 um 14:43 schrieb Michael Banck:
> > some minor comments, I didn't look at the added test and I did not
> > test the patch at all, but (as part of the Debian/Ubuntu packaging
>
hope v16-0001 and v16-0002 are small enough (I didn't do the above)
that they can just be attached normally?
Michael
--
Michael Banck
Team Lead PostgreSQL
Project Manager
Tel.: +49 2166 9901-171
Mail: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566
ta directory */
> appendPQExpBufferStr(postgres_cmd, " --single -F -D ");
> appendShellString(postgres_cmd, datadir_target);
> + if (config_file != NULL)
> + {
> + appendPQExpBufferStr(postgres_cmd, " --config_file=");
> +
it) ?
https://github.com/prometheus-community/postgres_exporter (1.6k GH stars) ?
Something else?
Michael
--
Michael Banck
Teamleiter PostgreSQL-Team
Projektleiter
Tel.: +49 2166 9901-171
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
On Mon, Feb 07, 2022 at 04:44:24PM +0100, Peter Eisentraut wrote:
> On 07.02.22 11:29, Julien Rouhaud wrote:
> > - that's not really something new with this patch, but should we output the
> >collation version info or mismatch info in \l / \dO?
>
> It's a possibility. Perhaps there is a
On Fri, Feb 04, 2022 at 04:35:07PM -0500, Tom Lane wrote:
> Michael Banck writes:
> > On Fri, Feb 04, 2022 at 02:58:59PM -0500, Tom Lane wrote:
> >> + If this seems to have affected a table, REINDEX
> >> + should repair the damage.
>
> > I don't thin
y
> + reindexing again.
> +
> +
Same, but at least here the admin can cut it down to only those indexes
which were added concurrently.
Michael
--
Michael Banck
Teamleiter PostgreSQL-Team
Projektleiter
Tel.: +49 2166 9901-171
Email: michael.ba...@credativ.de
cred
ich I
> > think means there isn't enough interest in this feature to advance it.
>
> This confuses me. Clearly there’s plenty of interest, but asking on hackers
> in a deep old sub thread isn’t a terribly good way to judge that. Yet even
> when there is an active positive response, you
Hi,
Am Montag, dem 31.01.2022 um 09:18 -0800 schrieb Mark Dilger:
> On Jan 31, 2022, at 12:43 AM, Michael Banck <
> michael.ba...@credativ.de> wrote:
> Ok, sure. I think this topic is hugely important and as I read the
> patch anyway, I added some comments, but yeah, we
Hi,
Am Sonntag, dem 30.01.2022 um 17:11 -0800 schrieb Mark Dilger:
> > On Jan 30, 2022, at 2:38 PM, Michael Banck <
> > michael.ba...@credativ.de> wrote:
> > > The attached WIP patch attempts to solve most of the CREATEROLE
>
> I'm mostly looking for whether
word => 't', admvaliduntil => 't',
> rolconnlimit => '-1',
>rolpassword => '_null_', rolvaliduntil => '_null_' },
Those sure are a couple of new columns in pg_authid, but oh well...
> diff --git a/src/include/catalog/pg_authid.h b/src/include/catalog/pg_authid.h
> in
| {}
postgres=> ALTER ROLE test SET log_statement='all';
ALTER ROLE
postgres=> \drds
List of settings
Role | Database | Settings
--+--+---
test | | log_statement=all
(1 row)
I am not sure if there is anything
ems to me we only distinguish between LOG
and PANIC for server-facing events; maybe we need one or more
additional levels here in order to make it easier for admins to see the
really bad things that are happening?
Michael
--
Michael Banck
Teamleiter PostgreSQL-Team
Projektleiter
Tel.: +4
t; question.
Michael
--
Michael Banck
Team Lead PostgreSQL
Project Manager
Tel.: +49 2166 9901-171
Mail: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Management: Dr. Michael Meskes, Geoff Richardson, Pete
onvinced it should be the default.
To put another option on the table: maybe a compromise could be to log
xlog checkpoints unconditionally, and the (checkpoint_timeout) time ones
only if log_checkpoints are set (maybe with some exponential backoff to
avoid log spam)?
Michael
--
Michael Banck
Team L
UMN ... TYPE is without it. So I
would suggest separating the two and make the general case (table and
indexe rewrites are not needed if the type is binary coercible without
having USING in the same sentence.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fa
2fce/blob/master/db2fce.sql#L588
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäfts
meetings or
so and have the advantage that, modulo timezone problems, every
(invited) developer could attend.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID
Hi,
Am Mittwoch, den 14.07.2021, 21:29 +0530 schrieb vignesh C:
> On Wed, Apr 7, 2021 at 5:23 PM Michael Banck
> wrote:
> > Hi,
> >
> > Am Dienstag, den 06.04.2021, 15:37 +0200 schrieb Michael Banck:
> > > Am Montag, den 05.04.2021, 14:33 -0400 schrieb S
T08:32:55.527975+00:00 |
| 5 | 84017040 | no recovery target specified |
2021-06-19T12:05:40.495982+00:00 |
| 6 | 84019264 | no recovery target specified |
2021-06-19T15:51:49.983987+00:00 |
| 7 | 84135720 | no recovery target specified |
2021-06-20T03:46:22.775851+00:00 |
--
Michael Banck
Projektlei
assume the point of cross-linking patches to the commitfest is to get
them into Postgres after all.
Also, I'd have expected that any meaningful patch surfacing on -general
would be cross-posted to -hackers anyway (less/not so for -bugs and
-docs).
Michael
--
Michael Banck
Projektleiter / Se
Just saying, I've proposed something very similar, albeit for a narrower
scope (mostly the Reporting and Logging category) here:
https://www.postgresql.org/message-id/flat/c2ee39152957af339ae6f3e851aef09930dd2faf.ca...@credativ.de
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 216
rsed by
> pgBadger."
>
> I think we should simply document that %Q is not compatible with
> log_statements.
What about log_statement_sample_rate ? Does compute_query_id have the
same problem with that?
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fa
Hi,
Am Dienstag, den 06.04.2021, 15:37 +0200 schrieb Michael Banck:
> Am Montag, den 05.04.2021, 14:33 -0400 schrieb Stephen Frost:
> > Should drop the 'DEFAULT_' to match the others since the rename to
> > 'predefined' roles went in.
>
> Right, will send a rebased patch AS
an administrator may wish to set BYPASSRLS on roles
> + which this role is GRANTed to.
> +
Shouldn't those "SELECT", "INSERT" etc. be wrapped in tags?
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166
Hi,
Am Montag, den 05.04.2021, 14:33 -0400 schrieb Stephen Frost:
> * Michael Banck (michael.ba...@credativ.de) wrote:
> > Am Montag, den 08.03.2021, 20:54 +0500 schrieb Ibrar Ahmed:
> > > On Thu, Dec 31, 2020 at 6:16 PM Michael Banck
> > > wrote:
> > >
from a technical POV it's useful as it closes a gap between
pg_dumpall -g and pg_dump -Fc $DATABASE in my opinion, without having to
potentially schema-dump and filter out a large number of database
objects.
Anybody else have some opinions on what to call this best? Maybe just a
short option and some expl
Hi,
Am Montag, den 08.03.2021, 20:54 +0500 schrieb Ibrar Ahmed:
> On Thu, Dec 31, 2020 at 6:16 PM Michael Banck
> wrote:
> > in today's world, some DBAs have no superuser rights, but we can
> > delegate them additional powers like CREATEDB or the pg_monitor default
>
On Sat, Mar 06, 2021 at 06:12:50PM +0100, Magnus Hagander wrote:
> On Tue, Feb 23, 2021 at 7:19 AM Robert Treat wrote:
> > On Thu, Dec 31, 2020 at 10:05 AM Michael Banck
> > wrote:
> > > Am Montag, den 28.12.2020, 20:41 +0900 schrieb Masahiko Sawada:
> > >
gzilla.redhat.com/show_bug.cgi?id=1925296
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäfts
test
SELECT pg_catalog.set_config('search_path', '', false);
GRANT CONNECT ON DATABASE test TO test;
postgres@kohn:~$
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
ute?
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, J
st across tablespaces.
Right. I thought about this a while ago, but didn't have time to work on
it so far.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Num
function) and some
> function comments which were missing.
0002 (now 0001 I guess) needs a rebase due to a3ed4d1e.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach
postgresql.org and/or Github), so that it can be picked up by
distributions and/or individual users in need.
That is Assuming it does not need assorted server changes to go with; I
did not read the thread in detail but I was under the assumption it is a
client program?
Michael
--
Michael Banck
Proje
ter
hand, we're just returning early from print_aligned_vertical() right now
and never get to the part where we usually print the title if there are
zero results.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.ba...@credat
Hi,
On Thu, Jan 07, 2021 at 03:05:44PM +0100, Daniel Gustafsson wrote:
> > On 5 Jan 2021, at 18:19, Michael Banck wrote:
> >> +
> >> + Data pages are not checksum protected by default, but this can
> >> optionally be
> >> + enabled for a clust
e it is
1GB for the smallest possible one and 32GB for a production instance.
It's 1GB for the small Google Cloud SQL Postgres and 2GB for the small
RDS test instance. It is user-changeable everywhere (at least to some
degree).
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166
Am Mittwoch, den 06.01.2021, 13:08 -0800 schrieb Peter Geoghegan:
> On Wed, Jan 6, 2021 at 1:04 PM Michael Banck
> wrote:
> > At least data_checksums=on for Azure Managed Postgres, Amazon RDS and
> > Google Cloud SQL Postgres. It might not be on for all types (I just
> &g
uring
> initdb?
At least data_checksums=on for Azure Managed Postgres, Amazon RDS and
Google Cloud SQL Postgres. It might not be on for all types (I just
checked the basic one each earlier today), but I guess it is.
Michael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166
Am Mittwoch, den 06.01.2021, 19:07 +0100 schrieb Michael Banck:
> Am Mittwoch, den 06.01.2021, 09:58 -0800 schrieb Andres Freund:
> > It still requires running a binary locally on the DB server, no? Which
> > means it'll not be an option on most cloud providers...
>
> At lea
around handily right now to check.
Micael
--
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax: +49 2166 9901-100
Email: michael.ba...@credativ.de
credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführu
1 - 100 of 294 matches
Mail list logo
