Re: Restoring a database problem

On 9/30/20 7:11 PM, Bruce Momjian wrote: On Thu, Oct 1, 2020 at 01:00:21PM +1300, Glen Eustace wrote: I have had to do this so rarely and it has almost always been in a bit of a panic so may well be missing something really obvious. What I want to know is how to quiese a database to that I

Re: Restoring a database problem

> On Sep 30, 2020, at 6:11 PM, Bruce Momjian wrote: > > On Thu, Oct 1, 2020 at 01:00:21PM +1300, Glen Eustace wrote: >> I have had to do this so rarely and it has almost always been in a bit of a >> panic so may well be missing something really obvious. >> >> What I want to know is how to

Re: Restoring a database problem

On Thu, Oct 1, 2020 at 01:00:21PM +1300, Glen Eustace wrote: > I have had to do this so rarely and it has almost always been in a bit of a > panic so may well be missing something really obvious. > > What I want to know is how to quiese a database to that I can restore it. > > I need to close

Restoring a database problem

I have had to do this so rarely and it has almost always been in a bit of a panic so may well be missing something really obvious. What I want to know is how to quiese a database to that I can restore it. I need to close all existing connections and the prevent people/processes from connecting

Re: Database logins taking longer and longer, showing up as "authentication" in ps(1)

On Wed, Sep 30, 2020 at 3:41 PM Adrian Klaver wrote: > On 9/30/20 2:30 PM, Adam Sjøgren wrote: > > Adrian writes: > > > >> I don't have an answer. Not even sure if this is relevant to the > >> problem, but how are the jobs getting into the queue? > > > > Plain INSERTs - often a lot at the same

Re: Database logins taking longer and longer, showing up as "authentication" in ps(1)

On 9/30/20 2:30 PM, Adam Sjøgren wrote: Adrian writes: I don't have an answer. Not even sure if this is relevant to the problem, but how are the jobs getting into the queue? Plain INSERTs - often a lot at the same time. I inserted 400K jobs to clean up after a bug earlier today, for

Re: Database logins taking longer and longer, showing up as "authentication" in ps(1)

Adrian writes: > I don't have an answer. Not even sure if this is relevant to the > problem, but how are the jobs getting into the queue? Plain INSERTs - often a lot at the same time. I inserted 400K jobs to clean up after a bug earlier today, for instance. What were you suspecting? Best

Re: Database logins taking longer and longer, showing up as "authentication" in ps(1)

On 9/30/20 1:22 PM, Adam Sjøgren wrote: Tom writes: =?utf-8?Q?Adam_Sj=C3=B8gren?= writes: Tom writes: ... which implies that the problem is unexpectedly high contention for the ProcArrayLock. One thing I should have mentioned, but forgot, is that the database is configured to do logical

Re: Database logins taking longer and longer, showing up as "authentication" in ps(1)

Tom writes: > =?utf-8?Q?Adam_Sj=C3=B8gren?= writes: >> Tom writes: >>> ... which implies that the problem is unexpectedly high contention for the >>> ProcArrayLock. > >> One thing I should have mentioned, but forgot, is that the database is >> configured to do logical replication to another

Re: Procedure to install and configure pgadmin4 in desktop mode in Red Hat Linux 8 and other Linux distributions

Hi Maria! Add the repo: sudo rpm -i https://ftp.postgresql.org/pub/pgadmin/pgadmin4/yum/pgadmin4-redhat-repo-1-1.noarch.rpm # Install for desktop mode only. sudo yum install pgadmin4-desktop Final config sudo /usr/pgadmin4/bin/setup-web.sh Here are the instructions:

Re: Problem close curser after rollback

On Wed, Sep 30, 2020 at 09:06:13PM +0200, Matthias Apitz wrote: > Btw: In all of the other DBS (Informix, Sybase, Oracle) we could define that > point with START TRANSACTION. You can always use SET SAVEPOINT. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

Re: Problem close curser after rollback

On Wednesday, 30 September 2020 20:37:23 CEST, Tom Lane wrote: Matthias Apitz writes: El día miércoles, septiembre 30, 2020 a las 05:26:39p. m. +0200, Laurenz Albe escribió: On Wed, 2020-09-30 at 13:32 +, Wiltsch,Sigrid wrote: What can I do so that the cursor is retained despite

Procedure to install and configure pgadmin4 in desktop mode in Red Hat Linux 8 and other Linux distributions

Hello, I'm looking for a procedure to install and configure pgadmin4 in desktop mode in Red Hat Linux 8 and other Linux distributions. Thanks in advance Regards

Re: Problem close curser after rollback

Matthias Apitz writes: > El día miércoles, septiembre 30, 2020 a las 05:26:39p. m. +0200, Laurenz Albe > escribió: >> On Wed, 2020-09-30 at 13:32 +, Wiltsch,Sigrid wrote: >>> What can I do so that the cursor is retained despite rollback? >> You cannot start a transaction while you are

Re: Problem close curser after rollback

El día miércoles, septiembre 30, 2020 a las 05:26:39p. m. +0200, Laurenz Albe escribió: > On Wed, 2020-09-30 at 13:32 +, Wiltsch,Sigrid wrote: > > we use the following statements in our applications, as described on the > > site: > > > >

Re: Yum repository RPM behind release

> That happens when you modify the config file Thank you, that makes sense of course — and I had to change the config file to set `enabled=1` to enable the testing repo when we first installed.

Re: Problem close curser after rollback

On Wed, 2020-09-30 at 13:32 +, Wiltsch,Sigrid wrote: > we use the following statements in our applications, as described on the > site: > > https://www.postgresql.org/docs/11/ecpg-commands.html#ECPG-TRANSACTIONS > > EXEC SQL PREPARE stmt1 FROM "SELECT oid,datname FROM pg_database WHERE oid

Re: temp table same name real table

Michael Lewis writes: > IMO, you are asking for strange behavior when you overload a table name. > I expect that one of the people who work down deep down in the code will > say it is a caching thing that saves system table lookups. Yeah, I think that on the second call, plpgsql caches a query

Re: Yum repository RPM behind release

Hi, On Wed, 2020-09-30 at 15:12 +0100, Jack Douglas wrote: > I had 42.0-14 installed but I had to manually uninstall and re- > install to get the stable repo in the list in /etc/yum.repos.d/pgdg- > redhat-all.repo That happens when you modify the config file. The updated repo rpm willl create

Re: temp table same name real table

On Wed, Sep 30, 2020, 7:27 AM v.br...@joinsnc.com wrote: > > Hi all, > I have this strange behavior when I use temp table with same name of a > permanent table in a function. > IMO, you are asking for strange behavior when you overload a table name. I expect that one of the people who work

Re: Problem close curser after rollback

El día miércoles, septiembre 30, 2020 a las 01:32:41p. m. +, Wiltsch,Sigrid escribió: >   > Hi,  > > we use the following statements in our applications, as described on the > site: >   > https://www.postgresql.org/docs/11/ecpg-commands.html#ECPG-TRANSACTIONS >   > EXEC SQL PREPARE stmt1

Re: Yum repository RPM behind release

Thanks very much Devrim, that got me on the right track. > Please update the repo RPM to the *latest* version first (42.0-13 or > above). rc packages were in the testing repo. v13 packages went to the > stable repo, which I added in 42.0-13. I had 42.0-14 installed but I had to manually

Re: Table sizes

Hello On 2020-09-30 15:54, luis.robe...@siscobra.com.br wrote: De: "Charles Clavadetscher" Para: "luis.roberto" Cc: "pgsql-general" Enviadas: Quarta-feira, 30 de setembro de 2020 10:46:39 Assunto: Re: Table sizes Hello On 2020-09-30 14:11, luis.robe...@siscobra.com.br wrote: Hi! I'm

Re: Table sizes

On 9/30/20 6:54 AM, luis.robe...@siscobra.com.br wrote: Thanks, this worked. I wonder though, why calling pg_relation_size('users') work (I don't need to specify the schema). Because it is in the search_path. In psql

Re: Table sizes

De: "Charles Clavadetscher" Para: "luis.roberto" Cc: "pgsql-general" Enviadas: Quarta-feira, 30 de setembro de 2020 10:46:39 Assunto: Re: Table sizes Hello On 2020-09-30 14:11, luis.robe...@siscobra.com.br wrote: > Hi! > > I'm trying to use this query to get table sizes, however

Re: Table sizes

Hello On 2020-09-30 14:11, luis.robe...@siscobra.com.br wrote: Hi! I'm trying to use this query to get table sizes, however I'm getting a strange error: select tablename,pg_relation_size(tablename::text) from pg_tables; In PG 13: SQL Error [42P01]: ERROR: relation

Re: Table sizes

W dniu 2020-09-30 o 14:11, luis.robe...@siscobra.com.br pisze: Hi! I'm trying to use this query to get table sizes, however I'm getting a strange error: select tablename,pg_relation_size(tablename::text)   from pg_tables; In PG 13: SQL Error [42P01]: ERROR: relation

Problem close curser after rollback

  Hi,  we use the following statements in our applications, as described on the site:   https://www.postgresql.org/docs/11/ecpg-commands.html#ECPG-TRANSACTIONS   EXEC SQL PREPARE stmt1 FROM "SELECT oid,datname FROM pg_database WHERE oid > ?"; EXEC SQL DECLARE foo_bar CURSOR FOR stmt1;   /* when

temp table same name real table

Hi all, I have this strange behavior when I use temp table with same name of a permanent table in a function. Postgres version is: PostgreSQL 11.3 (Debian 11.3-1.pgdg90+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit I use a query panel from pgAdmin

Table sizes

Hi! I'm trying to use this query to get table sizes, however I'm getting a strange error: select tablename,pg_relation_size(tablename::text) from pg_tables; In PG 13: SQL Error [42P01]: ERROR: relation "sql_implementation_info" does not exist In PG 12: SQL Error [42P01]: ERROR:

Re: Dependency problem using community repo on Redhat 7

Hi, On Thu, 2020-09-03 at 18:31 +, Lawrence Layhee wrote: > We are having a dependency problem when using the community repo on > redhat 7 > When we install postgresql12-devel-12.4-1PGDG.rhel7.x86_64 we get the > issue below. > Redhat doesn't support the dependencies. Any ideas? We are

Re: Yum repository RPM behind release

Hi, On Sat, 2020-09-26 at 08:17 +0100, Jack Douglas wrote: > > Postgres 13 is out and the yum repos for the release exist, eg: > https://yum.postgresql.org/13/redhat/rhel-8-x86_64/ gresql.org/13/redhat/rhel-8-x86_64/>. However the repository RPM > suggested at

Re: Postgres going very slow

st 30. 9. 2020 v 10:06 odesílatel Olivier Leprêtre napsal: > Hi, > > > > > > We have a database which is getting very slow. Pgadmin 3 is alos very > slow, requiring more than 2 minutes to refresh the list of schemas > > Machine is a windows server 2016 with Intel Xeon 2,4Ghz, 24 Go Ram. >

Postgres going very slow

Hi, We have a database which is getting very slow. Pgadmin 3 is alos very slow, requiring more than 2 minutes to refresh the list of schemas Machine is a windows server 2016 with Intel Xeon 2,4Ghz, 24 Go Ram. Postgres 9.6/32 bits Database contains 4000 schemas, each having 164 tables, 48