Re: Manual failover cluster

Hi Saul, Hope you are doing well. My apology for no response for a longer time. Pgbackrest helps build a streaming replication. While performing role reversal(switchover), it is mandatory to set recover_target_timeline to latest in recovery.conf(in data directory). Steps to perform switchover is

Re: lower() and unaccent() not leakproof

Peter Eisentraut writes: > I think the complexity of the implementation of upper() and lower() is > on the same order as bttextcmp() and similar, so it wouldn't be totally > out of scope. True. But you'll recall that the decision to mark bttextcmp() and cohorts as leakproof was not made withou

Re: Can we get rid of repeated queries from pg_dump?

On Thu, Aug 26, 2021 at 10:20:29AM -0400, Tom Lane wrote: > Well, you could move it forward by doing the legwork to identify which > queries are worth merging. Is it really sane to do a global "select > format_type() from pg_type" query and save all the results on the client > side? I wonder whet

Re: lower() and unaccent() not leakproof

> On 26 Aug 2021, at 16:59, Peter Eisentraut > wrote: > On 26.08.21 10:40, Daniel Gustafsson wrote: >> Wouldn’t the difference in possible error messages in upper/lower be able to >> leak whether the input is ascii or wide chars, and/or the collation? > > Yeah, but there aren't any error messag

Re: lower() and unaccent() not leakproof

On 26.08.21 16:00, Tom Lane wrote: Generally speaking, we've been resistant to marking anything leakproof unless it has a very small code footprint that can be easily audited. In particular, anything that shares a lot of infrastructure with not-leakproof functions seems quite hazardous. Even if

Re: lower() and unaccent() not leakproof

On 26.08.21 10:40, Daniel Gustafsson wrote: On 26 Aug 2021, at 09:58, Peter Eisentraut wrote: On 26.08.21 06:52, David G. Johnston wrote: On Wednesday, August 25, 2021, Christophe Pettus mailto:x...@thebuild.com>> wrote: lower() and unaccent() (and most string functions) are not marked as

Re: Can we get rid of repeated queries from pg_dump?

On Thu, Aug 26, 2021 at 07:46:46AM -0700, Adrian Klaver wrote: > On 8/26/21 7:35 AM, hubert depesz lubaczewski wrote: > > On Thu, Aug 26, 2021 at 07:34:26AM -0700, Adrian Klaver wrote: > > > On 8/26/21 1:44 AM, hubert depesz lubaczewski wrote: > > > > Hi, > > > > I have following case: local pg_dum

Re: Can we get rid of repeated queries from pg_dump?

On 8/26/21 7:35 AM, hubert depesz lubaczewski wrote: On Thu, Aug 26, 2021 at 07:34:26AM -0700, Adrian Klaver wrote: On 8/26/21 1:44 AM, hubert depesz lubaczewski wrote: Hi, I have following case: local pg_dump (v15) connecting to remote PostgreSQL (v12). So you are using a dev version of pg_du

Re: Can we get rid of repeated queries from pg_dump?

On Thu, Aug 26, 2021 at 07:34:26AM -0700, Adrian Klaver wrote: > On 8/26/21 1:44 AM, hubert depesz lubaczewski wrote: > > Hi, > > I have following case: local pg_dump (v15) connecting to remote > > PostgreSQL (v12). > So you are using a dev version of pg_dump or is that a typo? Yes. I'm running pg

Re: Can we get rid of repeated queries from pg_dump?

On 8/26/21 1:44 AM, hubert depesz lubaczewski wrote: Hi, I have following case: local pg_dump (v15) connecting to remote PostgreSQL (v12). So you are using a dev version of pg_dump or is that a typo? It's been 15 minutes, and pg_dump (called: pg_dump -v -s -f schema.dump, with env variables

Re: Can we get rid of repeated queries from pg_dump?

On Thu, Aug 26, 2021 at 10:20:29AM -0400, Tom Lane wrote: > hubert depesz lubaczewski writes: > > On Thu, Aug 26, 2021 at 10:02:07AM -0400, Tom Lane wrote: > >> hubert depesz lubaczewski writes: > >>> Wouldn't it be possible to get all type formats at once, and cache them > >>> in pg_dump? Or at

Re: Can we get rid of repeated queries from pg_dump?

hubert depesz lubaczewski writes: > On Thu, Aug 26, 2021 at 10:02:07AM -0400, Tom Lane wrote: >> hubert depesz lubaczewski writes: >>> Wouldn't it be possible to get all type formats at once, and cache them >>> in pg_dump? Or at the very least reuse already received information? >> Send a patch

Re: Can we get rid of repeated queries from pg_dump?

On Thu, Aug 26, 2021 at 10:02:07AM -0400, Tom Lane wrote: > hubert depesz lubaczewski writes: > > It seems that for every function, pg_dump is getting it's data, and then > > runs format_type on each parameter/output type? I'm mostly guessing > > here, as I didn't read the code. > > Wouldn't it be

Re: Can we get rid of repeated queries from pg_dump?

hubert depesz lubaczewski writes: > It seems that for every function, pg_dump is getting it's data, and then > runs format_type on each parameter/output type? I'm mostly guessing > here, as I didn't read the code. > Wouldn't it be possible to get all type formats at once, and cache them > in pg_du

Re: lower() and unaccent() not leakproof

Peter Eisentraut writes: > On 26.08.21 06:52, David G. Johnston wrote: >> On Wednesday, August 25, 2021, Christophe Pettus > > wrote: >>> lower() and unaccent() (and most string functions) are not marked as >>> leakproof.  Is this due to possible locale / character encodi

Can we get rid of repeated queries from pg_dump?

Hi, I have following case: local pg_dump (v15) connecting to remote PostgreSQL (v12). I'm trying to get just schema (pg_dump -s). It's taking very long, which is kinda OK given that there is long distance and latency, but I got curious and checked queries that the pg_dump was running (select * fro

Re: lower() and unaccent() not leakproof

> On 26 Aug 2021, at 09:58, Peter Eisentraut > wrote: > > On 26.08.21 06:52, David G. Johnston wrote: >> On Wednesday, August 25, 2021, Christophe Pettus > > wrote: >>lower() and unaccent() (and most string functions) are not marked as >>leakproof. Is this due

Re: lower() and unaccent() not leakproof

On 26.08.21 06:52, David G. Johnston wrote: On Wednesday, August 25, 2021, Christophe Pettus > wrote: lower() and unaccent() (and most string functions) are not marked as leakproof.  Is this due to possible locale / character encoding errors they might encou