Re: symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: PQsetErrorContextVisibility

Hi Tom ; Thank you for your detailed email. rob stan writes: > I have a problem with connecting database via psql;/usr/lib/9.6/bin/psql: > symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: > PQsetErrorContextVisibility Apparently psql is linking to a pre-9.6 copy of libpq.so. You c

Re: symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: PQsetErrorContextVisibility

On Fri, Jun 4, 2021 at 06:21:02PM -0400, rob stan wrote: > Hello all, > I have a problem with connecting database via psql;/usr/lib/9.6/bin/psql: > symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: > PQsetErrorContextVisibility > > OS :Debian GNU/Linux 9 > > I tried setting it didn't

Re: symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: PQsetErrorContextVisibility

rob stan writes: > I have a problem with connecting database via psql;/usr/lib/9.6/bin/psql: > symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: > PQsetErrorContextVisibility Apparently psql is linking to a pre-9.6 copy of libpq.so. You could confirm that with ldd /usr/lib/9.

Re: symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: PQsetErrorContextVisibility

On 6/4/21 5:21 PM, rob stan wrote: Hello all, I have a problem with connecting database via psql;|/usr/lib/9.6/bin/psql: symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: PQsetErrorContextVisibility||| || |OS :||Debian GNU/Linux 9| || |I tried setting it didn't help;export LD_

symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: PQsetErrorContextVisibility

Hello all, I have a problem with connecting database via psql;/usr/lib/9.6/bin/psql: symbol lookup error: /usr/lib/9.6/bin/psql: undefined symbol: PQsetErrorContextVisibility OS :Debian GNU/Linux 9 I tried setting it didn't help; export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/postgresql/9.6/lib

Re: strange behavior of WAL files

it gets cleaned up for me. turn archiving on, simulate success using /bin/true turn archiving off, simulate success using /bin/false generate wals by some DMLS. postgres@go:~/pgsql/data/pg_wal$ grep wal_size ../postgresql.conf max_wal_size = 100MB min_wal_size = 80MB postgres@go:~/pgsql/data/pg_

Re: Struggling with EXCLUDE USING gist

On 6/4/21 11:21 AM, Adrian Klaver wrote: On 6/4/21 10:37 AM, Laura Smith wrote: Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 4 June 2021 18:11, Julien Rouhaud wrote: On Sat, Jun 5, 2021 at 12:48 AM Laura Smith n5d9xq3ti233xiyif...@protonmail.ch wrote: A

Re: Struggling with EXCLUDE USING gist

> On Jun 4, 2021, at 11:55 AM, Laura Smith > wrote: > > That seems to have done the trick. Thanks again Mark Glad to hear it. Good luck. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: Struggling with EXCLUDE USING gist

Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 4 June 2021 18:45, Mark Dilger wrote: > > On Jun 4, 2021, at 9:47 AM, Laura Smith n5d9xq3ti233xiyif...@protonmail.ch > > wrote: > > CREATE TABLE test ( > > t_val text not null, > > t_version text unique not null

Re: Struggling with EXCLUDE USING gist

Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 4 June 2021 18:45, Mark Dilger wrote: > > On Jun 4, 2021, at 9:47 AM, Laura Smith n5d9xq3ti233xiyif...@protonmail.ch > > wrote: > > CREATE TABLE test ( > > t_val text not null, > > t_version text unique not null

Re: Struggling with EXCLUDE USING gist

On 6/4/21 1:32 PM, Laura Smith wrote: What is the solution then ? I need to keep historical versions but at the same time I need a "current" version. If I am not able to use "infinity" as bounds for "current" version then clearly I'm wasting my time trying to use EXCLUDE AS for version tracking

Re: Struggling with EXCLUDE USING gist

On 6/4/21 10:37 AM, Laura Smith wrote: Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 4 June 2021 18:11, Julien Rouhaud wrote: On Sat, Jun 5, 2021 at 12:48 AM Laura Smith n5d9xq3ti233xiyif...@protonmail.ch wrote: All the examples I've seen around the inter

Re: Struggling with EXCLUDE USING gist

On 6/4/21 10:37 AM, Laura Smith wrote: Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 4 June 2021 18:11, Julien Rouhaud wrote: On Sat, Jun 5, 2021 at 12:48 AM Laura Smith n5d9xq3ti233xiyif...@protonmail.ch wrote: All the examples I've seen around the inter

Re: Struggling with EXCLUDE USING gist

> On Jun 4, 2021, at 9:47 AM, Laura Smith > wrote: > > CREATE TABLE test ( > t_val text not null, > t_version text unique not null default gen_random_uuid() , > t_range tstzrange not null default tstzrange('-infinity','infinity'), > EXCLUDE USING gist (t_val WITH=, t_range WITH &&) DEFERRABLE

Re: Struggling with EXCLUDE USING gist

Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 4 June 2021 18:11, Julien Rouhaud wrote: > On Sat, Jun 5, 2021 at 12:48 AM Laura Smith > n5d9xq3ti233xiyif...@protonmail.ch wrote: > > > All the examples I've seen around the internet make this sound so easy. > >

Re: Struggling with EXCLUDE USING gist

‐‐‐ Original Message ‐‐‐ On Friday, 4 June 2021 18:07, Adrian Klaver wrote: > On 6/4/21 9:47 AM, Laura Smith wrote: > > > All the examples I've seen around the internet make this sound so easy. > > But I seem to be missing some important step because all I'm getting are > > messages su

RE: BUG #17046: Upgrade postgres 11 to 13 version

Dear Adrian, Currently I am using postgres 11 version and I want to upgrade postgres 13 and I am doing this activity , first we take pgbase_backup from from Postgres 11 and restore this backup on postgres 13 (new server). I am not using pg_dump . I have done this activity on test server and it

Re: Struggling with EXCLUDE USING gist

On Sat, Jun 5, 2021 at 12:48 AM Laura Smith wrote: > > All the examples I've seen around the internet make this sound so easy. > > But I seem to be missing some important step because all I'm getting are > messages such as "DETAIL: Key (t_val, t_version)=(def, [-infinity,infinity)) > conflicts

Re: Struggling with EXCLUDE USING gist

On 6/4/21 9:47 AM, Laura Smith wrote: All the examples I've seen around the internet make this sound so easy. But I seem to be missing some important step because all I'm getting are messages such as "DETAIL: Key (t_val, t_version)=(def, [-infinity,infinity)) conflicts with existing key (t_va

Struggling with EXCLUDE USING gist

All the examples I've seen around the internet make this sound so easy. But I seem to be missing some important step because all I'm getting are messages such as "DETAIL: Key (t_val, t_version)=(def, [-infinity,infinity)) conflicts with existing key (t_val, t_version)=(def, [-infinity,"2021-06-

Re: possible license violations

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Thu, Jun 3, 2021 at 06:08:42PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > On Thu, Jun 3, 2021 at 09:31:15PM +, tom.beacon wrote: > > >> What is the best contact with whom to discuss possible violations of the > > >> pgsq

Re: strange behavior of WAL files

hi Tom, Please check my findings below older -rw--- 1 enterprisedb enterprisedb 16777216 Jun 2 02:47 000136CF00A4 -rw--- 1 enterprisedb enterprisedb 16777216 Jun 2 02:45 000136CF00A3 -rw--- 1 enterprisedb enterprisedb 16777216 Jun 2 02:44 000136CF000

Re: AW: [Extern] Re: autovacuum on pg_catalog tables

On Fri, 2021-06-04 at 15:43 +, Zwettler Markus (OIZ) wrote: > I have a lot of LO manipulation and want a more aggressive autovacuum on some > pg_catalog tables therefore. > > I do not see any reason why this should not work or be at risk? It is not a risk per se. The biggest problem is that

Re: AW: [Extern] Re: autovacuum on pg_catalog tables

"Zwettler Markus (OIZ)" writes: > I do not see any reason why this should not work or be at risk? I think the only problem you'd be likely to run into is that pg_dump/pg_upgrade won't propagate those settings for you. autovacuum doesn't really treat catalogs differently from user tables, AFAIR.

Re: [Extern] Re: autovacuum on pg_catalog tables

Why not change the defaults? How many tables would hit this new threshold and you would NOT want autovacuum to process them? >

AW: [Extern] Re: autovacuum on pg_catalog tables

Thanks for the info. I have a lot of LO manipulation and want a more aggressive autovacuum on some pg_catalog tables therefore. I do not see any reason why this should not work or be at risk? Markus Von: Vijaykumar Jain Gesendet: Freitag, 4. Juni 2021 17:37 An: Zwettler Markus (OIZ) Cc: pg

Re: autovacuum on pg_catalog tables

ok, what i am sharing, *DO NOT DO IT.* it is just to answer why it is not working :) PostgreSQL: Documentation: 13: 19.17. Developer Options postgres=# alter table pg_catalog.pg_largeobject_metadata set (AUTOVACUUM_VACUUM_CO

Re: EXCLUDE USING and tstzrange

Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 4 June 2021 16:20, Joe Conway wrote: > On 6/4/21 10:58 AM, Laura Smith wrote: > > > One other question, what's the syntax for manipulating only the upper > > bound of a range. > > Say I have a Postgres function th

Re: EXCLUDE USING and tstzrange

On 6/4/21 10:58 AM, Laura Smith wrote: One other question, what's the syntax for manipulating only the upper bound of a range. Say I have a Postgres function that does a "SELECT INTO" for an existing tsrange. Is there an easy way to change the variable's upper bound whilst leaving the "old" low

Re: strange behavior of WAL files

Hi Jehan, Just to add little more info about this issue is : We have set value 4000 for parameter wal_keep_segments. So is there any chance that after a certain number of WAL files, postgres will start recycling the WAL with same name ? Please share your valuable suggestion. Regards. Atul

Re: EXCLUDE USING and tstzrange

Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 4 June 2021 15:44, Adrian Klaver wrote: > On 6/4/21 7:32 AM, Laura Smith wrote: > > > Hi, > > I'm having difficulty finding the right part of the docs for this one. > > Could someone kindly clarify: > > create tab

Re: EXCLUDE USING and tstzrange

On 6/4/21 7:32 AM, Laura Smith wrote: Hi, I'm having difficulty finding the right part of the docs for this one. Could someone kindly clarify: create table test ( test_id text, test_range tstzrange); Will "EXCLUDE USING gist (test_id WITH =, test_range WITH && )" work as expected or do I need

autovacuum on pg_catalog tables

I would like to start a more aggressive autovacuum on pg_catalog tables like pg_largeobject. So I tried as a superuser: # alter table pg_catalog.pg_largeobject_metadata set (autovacuum_vacuum_scale_factor = 0, autovacuum_vacuum_threshold = 5000); ERROR: permission denied: "pg_largeobject_metad

EXCLUDE USING and tstzrange

Hi, I'm having difficulty finding the right part of the docs for this one. Could someone kindly clarify: create table test ( test_id text, test_range tstzrange); Will "EXCLUDE USING gist (test_id WITH =, test_range WITH && )" work as expected or do I need to use "EXCLUDE USING gist (test_id WI

Re: BUG #17046: Upgrade postgres 11 to 13 version

On 6/4/21 4:46 AM, Ram Pratap Maurya wrote: Dear Adrian, Please do not top post. It is the convention on this list to post inline or bottom post. Currently I am using postgres 11 version and I want to upgrade postgres 13 and I am doing this activity , first we take pgbase_backup from fr

Re: EXPLAIN (ANALYZE, BUFFERS) - puzzling numbers for a simple query.

> Laurenz Albe writes: > > "generate_series" has a support function from v12 on: > True, but I don't think it can do anything with non-constant inputs, > as we have in the OP's case. As confirmed by this: https://dbfiddle.uk/?rdbms=postgres_12&fiddle=d0b70717faca3b094be8b4a096758b94 Plan: =

Re: strange behavior of WAL files

Atul Kumar writes: > once old WAL files of pg_xlog directory are archived in > '/nfslogs/wal/' directory then these WAL files are getting generated > with the same name in pg_xlog directory. Are you sure you are describing the behavior accurately? What I would expect to happen, once an old WAL f

Re: EXPLAIN (ANALYZE, BUFFERS) - puzzling numbers for a simple query.

Laurenz Albe writes: > On Sat, 2021-06-05 at 00:12 +1200, David Rowley wrote: >> As for the call to generate_series, you're not likely to ever get any >> great estimation from that. > "generate_series" has a support function from v12 on: True, but I don't think it can do anything with non-consta

Re: strange behavior of WAL files

I will try to simulate this and see if i can reproduce it, currently in between difficult interviews where i have little hope :) PostgreSQL WAL Retention and Clean Up: pg_archivecleanup - Percona Database Performance Blog

Re: EXPLAIN (ANALYZE, BUFFERS) - puzzling numbers for a simple query.

On Sat, 5 Jun 2021 at 00:55, Laurenz Albe wrote: > > On Sat, 2021-06-05 at 00:12 +1200, David Rowley wrote: > > As for the call to generate_series, you're not likely to ever get any > > great estimation from that. The number of rows returned by a call to > > that particular function are just what

Re: strange behavior of WAL files

I have not seen this, so cannot comment, but when I am trying to simulate i do not see issues. One thing to note, It seems your wal is on nfs mount , can you rule out any nfs errors if it is nfs. On Fri, Jun 4, 2021, 6:24 PM Atul Kumar wrote: > Hi, > > > archive_command is 'cp %p /nfslogs/wal/%

Re: EXPLAIN (ANALYZE, BUFFERS) - puzzling numbers for a simple query.

On Sat, 2021-06-05 at 00:12 +1200, David Rowley wrote: > As for the call to generate_series, you're not likely to ever get any > great estimation from that. The number of rows returned by a call to > that particular function are just whatever is set in pg_proc.prorows, > in this case, 1000. The o

Re: strange behavior of WAL files

Hi, archive_command is 'cp %p /nfslogs/wal/%f' and no, we are not removing anything from pg_xlog directory. once old WAL files of pg_xlog directory are archived in '/nfslogs/wal/' directory then these WAL files are getting generated with the same name in pg_xlog directory. my query is Why is t

Re: EXPLAIN (ANALYZE, BUFFERS) - puzzling numbers for a simple query.

On Fri, 4 Jun 2021 at 22:59, Pól Ua Laoínecháin wrote: > Now, we've gone from 1,160,000 to 39,830 rows (progress? :-) ) and a > cost of ~ 1M (compared with 168k for the first query). The estimates are not that meaningful due to a lack of table statistics on the "test" table. If you run ANALYZE o

Re: EXPLAIN (ANALYZE, BUFFERS) - puzzling numbers for a simple query.

how is cost calculated? postgres/costsize.c at master · postgres/postgres (github.com) row estimation PostgreSQL: Documentation: 13: 70.1. Row Estimation Examples

EXPLAIN (ANALYZE, BUFFERS) - puzzling numbers for a simple query.

Hi all, Noticed this today - relatively simple query - table with 7 records (all code is shown at the bottom of this post and on the fiddle here): https://dbfiddle.uk/?rdbms=postgres_12&fiddle=efe73a37d29af43f33d2bc79de2b6c97 Sample (2 of 7 records); == INSERT INTO test VALU

Re: strange behavior of WAL files

On Fri, 4 Jun 2021 15:39:30 +0530 Atul Kumar wrote: > HI, > > We have a centos 6 enviornment where postgres 9.6 is running on it. > > We have strange behavior of WAL files of pg_xlog directory > > As we have set archive_command to archive WAL files at different > location and the archive_comma

strange behavior of WAL files

HI, We have a centos 6 enviornment where postgres 9.6 is running on it. We have strange behavior of WAL files of pg_xlog directory As we have set archive_command to archive WAL files at different location and the archive_command is working fine. So strange behavior is : We have a WAL file say