Where is the tsrange() function documented?

On Monday, October 18, 2021, Bryn Llewellyn wrote: > > I can't find anything, neither on the page in question here on Range Types > nor in the doc on the overlaps operator, about the semantics for when a > duration collapses to an instant. Am I missing this too? > > Same page: https://www.postgr

Re: Where is the tsrange() function documented?

> Adrian wrote: > >> Bryn wrote: >> >> I found my way to this by guesswork and good luck. (I happen to be using PG >> Version 13.5. But I don't suppose that this matters.)… But I can't formulate >> a search that finds it using the doc site's intrinsic search. > > Where exactly did you search?

Re: Where is the tsrange() function documented?

> David Johnston wrote: > >> Bryn wrote: >> >> Where is it? > > TOC - Data Types - Range Types: > > https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-BUILTIN > Thanks for the instant response, David.

Re: JSON query

> On Oct 18, 2021, at 10:02 PM, David G. Johnston > wrote: > > (jsonb - text[]) = ‘{}’::jsonb …? Aha, thank you!

Re: Where is the tsrange() function documented?

On 10/18/21 20:44, Bryn Llewellyn wrote: I found my way to this by guesswork and good luck. (I happen to be using PG Version 13.5. But I don't suppose that this matters.) But I can't formulate a search that finds it using the doc site's intrinsic search. Where exactly did you search? When

Re: JSON query

On Monday, October 18, 2021, Scott Ribe wrote: > > "containing only keys from this list of keys" > > (jsonb - text[]) = ‘{}’::jsonb …? Combine with (jsonb ?& text[]) if all tested keys need to be present as well. David J.

Re: Force re-compression with lz4

On Mon, Oct 18, 2021 at 08:01:04AM -0700, Adrian Klaver wrote: > Not sure how much this applies to the Postgres usage of lz4. As I understand > it, this is only used internally for table compression. When using pg_dump > compression gzip is used. Unless you pipe plain text output through some > oth

Re: Where is the tsrange() function documented?

On Monday, October 18, 2021, Bryn Llewellyn wrote: > > > Where is it? > TOC - Data Types - Range Types: https://www.postgresql.org/docs/current/rangetypes.html#RANGETYPES-BUILTIN David J.

Re: Unsynchronized parallel dumps from 13.3 replica produced by pg_dump

Chris Williams writes: > Thanks Tom. It's a strange one for sure. Hopefully AWS support will shed > some light on it. I will clarify too that this is the regular RDS Postgres > version and not their other Aurora Postgres service. I suspect the Aurora > Postgres probably differs from the communi

JSON query

What's a good way to query jsonb column for "no keys other than those in this list of keys" in other words "containing only keys from this list of keys" -- Scott Ribe scott_r...@elevated-dev.com https://www.linkedin.com/in/scottribe/

Where is the tsrange() function documented?

I found my way to this by guesswork and good luck. (I happen to be using PG Version 13.5. But I don't suppose that this matters.) Doing "\df tsrange()" gives this: Schema | Name | Result data type | Argument data types | Type +

Re: Unsynchronized parallel dumps from 13.3 replica produced by pg_dump

Thanks Tom. It's a strange one for sure. Hopefully AWS support will shed some light on it. I will clarify too that this is the regular RDS Postgres version and not their other Aurora Postgres service. I suspect the Aurora Postgres probably differs from the community version by quite a bit, but I

Re: Unsynchronized parallel dumps from 13.3 replica produced by pg_dump

Chris Williams writes: > We have a script that runs a pg_dump off of an RDS PG13.3 replica several > times per day. We then load this dump using pg_restore into another > postgres RDS db in another AWS account, scrub some of the data, and then > take a snapshot of it. Hmm ... I'm fairly sure that

Unsynchronized parallel dumps from 13.3 replica produced by pg_dump

Hi, We have a script that runs a pg_dump off of an RDS PG13.3 replica several times per day. We then load this dump using pg_restore into another postgres RDS db in another AWS account, scrub some of the data, and then take a snapshot of it. We then use these snapshots for testing and staging serv

Re: Force re-compression with lz4

On 10/18/21 06:41, Mladen Gogala wrote: On 10/18/21 01:07, Michael Paquier wrote: CPU-speaking, LZ4 is*much*  faster than pglz when it comes to compression or decompression with its default options.  The compression ratio is comparable between both, still LZ4 compresses in average less than PGL

Debug PostgreSQL logical apply process

Hello, We have configured "pglogical" in AWS Aurora. But the "subscription" process keeps going down frequently. We don't get enough log in database error log to know exactly what's causing the problem (we have tried setting the "log_min_messages" and "pglogical.conflict_log_level" upto "debug5") .

Re: PostgreSQL 14: pg_dump / pg_restore error: could not write to the communication channel: Broken pipe

"Nick Renders" writes: > Thank you for all the feedback and suggestions. > It seems that the "-h localhost" parameter is triggering the issue. If I > leave it out, pg_restore works without problems with multiple jobs. I > have also tried specifying the IP number instead of "localhost", but > th

Re: Force re-compression with lz4

On 10/18/21 01:07, Michael Paquier wrote: CPU-speaking, LZ4 is*much* faster than pglz when it comes to compression or decompression with its default options. The compression ratio is comparable between both, still LZ4 compresses in average less than PGLZ. -- Michael LZ4 works much better wi

Re: PostgreSQL 14: pg_dump / pg_restore error: could not write to the communication channel: Broken pipe

Thank you for all the feedback and suggestions. It seems that the "-h localhost" parameter is triggering the issue. If I leave it out, pg_restore works without problems with multiple jobs. I have also tried specifying the IP number instead of "localhost", but that results in the same error.

Re: Force re-compression with lz4

On Mon, Oct 18, 2021 at 7:18 AM Michael Paquier wrote: > On Sun, Oct 17, 2021 at 10:13:48PM +0300, Florents Tselai wrote: > > I did look into VACUUM(full) for it’s PROCESS_TOAST option which > > makes sense, but the thing is I already had a cron-ed VACUUM (full) > > which I ended up disabling a w

Re: Force re-compression with lz4

On Mon, Oct 18, 2021 at 09:57:11AM +0300, Florents Tselai wrote: > Oh, that’s good to know then. So besides ALTER COMPRESSION for > future inserts there’s not much one can do for pre-existing values The posting style of the mailing list is to not top-post, so if you could avoid breaking the logic