Re: Vacuum very big table - how the full vacuum works in background/internally?

2019-11-06 Thread Durumdara
Hello! We solved it. The VACUUM full finished fast on pg_largeobject, because we deleted 98% of big largeobject (ours) before. And it worked as zip deletion - it created a new file and copied only living records, which was fast (3 GB vs. 80 GB). Thanks dd Luca Ferrari ezt írta (időpont: 2019.

Upgrade PGSQL main version without backup/restore all databases?

2019-11-06 Thread Durumdara
Dear Members! We have PGSQL 9.6.xxx on a Linux server which heavily used. More than 100 databases, and more than 300 active users, and it is a master of a cluster (the data replicated on a slave). Somewhere we have read that 9.6 will become unsupported shortly. We need to prepare upgrade. In Wi

Re: Upgrade PGSQL main version without backup/restore all databases?

2019-11-06 Thread Thomas Kellerer
Durumdara schrieb am 06.11.2019 um 14:09: > We have PGSQL 9.6.xxx on a Linux server which heavily used. > More than 100 databases, and more than 300 active users, and it is a master > of a cluster (the data replicated on a slave). > > Somewhere we have read that 9.6 will become unsupported shortl

Re: Hunspell as filtering dictionary

2019-11-06 Thread Hugh Ranalli
On Tue, 5 Nov 2019 at 09:42, Bibi Mansione wrote: > Hi, > I am trying to create a ts_vector from a French text. Here are the > operations that seem logical to perform in that order: > > 1. remove stopwords > 2. use hunspell to find words roots > 3. unaccent > I can't speak to French, but we use

Re: Upgrade PGSQL main version without backup/restore all databases?

2019-11-06 Thread Ravi Krishna
-k option is kept precisely for this.  The upgrades are pretty fast, but still with some downtime. may be 30-45 min tops.

Locked out of schema public

2019-11-06 Thread Peter
This is FreeBSD 11.3, with postgres installed from ports as 10.10. There is included a daily utility doing pg_dump: : ${daily_pgsql_pgdump_args:="-U ${daily_pgsql_user} -p ${daily_pgsql_port} -bF c"} pg_dump ${daily_pgsql_pgdump_args} -f ${file} ${db} Recently I did a restore of some database

Re: Locked out of schema public

2019-11-06 Thread Adrian Klaver
On 11/6/19 11:11 AM, Peter wrote: This is FreeBSD 11.3, with postgres installed from ports as 10.10. There is included a daily utility doing pg_dump: : ${daily_pgsql_pgdump_args:="-U ${daily_pgsql_user} -p ${daily_pgsql_port} -bF c"} pg_dump ${daily_pgsql_pgdump_args} -f ${file} ${db} What

How to convert return values from JSON Path functions to text

2019-11-06 Thread Thomas Kellerer
The new JSON path functions in Postgres 12 are really convenient, however I cannot figure out how to properly convert their return values to a text value. E.g. select jsonb_path_query_first('{"a": "foo"}', '$.a') returns a JSONB value. Casting it to text, still yields "foo" (with quotes), rather

Re: Locked out of schema public (pg_dump lacks backup of the grant)

2019-11-06 Thread Peter
Long story short: pg_dump just forgets to backup the grant on schema public. :( Long story: After searching for half an hour to get some comprehensive listing of permissions (which was in vain) I tried with pgadmin3 (which is indeed a life-saver and still somehow works on 10.10 - and that's t

Re: Locked out of schema public (pg_dump lacks backup of the grant)

2019-11-06 Thread Tom Lane
Peter writes: > If you do only "pg_restore -c -d ", the sessions can stay open, > but then it will do > DROP SCHEMA public; > CREATE SCHEMA public; > and it will NOT restore the grant because it is not in the backup. We improved that situation in v11, I believe. What I see for this case these da

Re: Locked out of schema public

2019-11-06 Thread Peter
Hi Adrian, okay, lets check these out: > What is ${daily_pgsql_user} equal to? postgres. The owner of the installation. > I am not seeing -U postgres. > Are you sure there is not something else specifying the user e.g. env > PGUSER? I'm sure. The log shows the nightly backup connections as po

Re: Locked out of schema public (pg_dump lacks backup of the grant)

2019-11-06 Thread Peter
Hello Tom, thank You very much. > We improved that situation in v11, I believe. What I see for this > case these days is per commit 5955d9341: > [...] Ah, well. I don't fully understand that, but as the iessue appears to be known, then that is fine with me. This thing is just bad if one neve