RE: Snippets?

2019-05-24 Thread Ken Lacrosse
Thanks guys. VERY informative. I'll be looking at all 3 approaches: INHERITS, LIKE and Sqitch. Ken LaCrosse Senior IT InfoSec and Infrastructure Monitoring Specialist I.T. | American Recovery Service & Skipbusters Phone: (800)398-6480 x3758 Email: klacro...@pkwillis.com www.pkwillis.com *

Re: Snippets?

2019-05-24 Thread Adrian Klaver
On 5/24/19 12:24 PM, Ron wrote: On 5/24/19 1:27 PM, Adrian Klaver wrote: On 5/24/19 11:15 AM, Ken Lacrosse wrote: Is there any way in postgresql to have a "snippet" of SQL code which you could apply to all tables. Something you could add which would ensure that every table always has a

Re: Snippets?

2019-05-24 Thread Ron
On 5/24/19 1:27 PM, Adrian Klaver wrote: On 5/24/19 11:15 AM, Ken Lacrosse wrote: Is there any way in postgresql to have a "snippet" of SQL code which you could apply to all tables. Something you could add which would ensure that every table always has a Created, Changed and Deleted column for

Re: Snippets?

2019-05-24 Thread Adrian Klaver
On 5/24/19 11:15 AM, Ken Lacrosse wrote: Is there any way in postgresql to have a "snippet" of SQL code which you could apply to all tables.  Something you could add which would ensure that every table always has a Created, Changed and Deleted column for example.  Sort of like a C include I

Re: Snippets?

2019-05-24 Thread Ron
On 5/24/19 1:15 PM, Ken Lacrosse wrote: Is there any way in postgresql to have a "snippet" of SQL code which you could apply to all tables.  Something you could add which would ensure that every table always has a Created, Changed and Deleted column for example.  Sort of like a C include I

Snippets?

2019-05-24 Thread Ken Lacrosse
Is there any way in postgresql to have a "snippet" of SQL code which you could apply to all tables. Something you could add which would ensure that every table always has a Created, Changed and Deleted column for example. Sort of like a C include I suppose. Of course if I'm building a DB

Re: POSTGRES_FSM_RELATIONS CRITICAL: DB control fsm relations used: 79569 of 80000 (99%)

2019-05-24 Thread Adrian Klaver
On 5/24/19 10:16 AM, Julie Nishimura wrote: Adrian, this value was set in config file, and alerting comes from monitoring. Yes, but what is the monitoring actually doing to get that value? Would it be right query to count objects in each database (there are 75 dbs on this server totaling

Re: POSTGRES_FSM_RELATIONS CRITICAL: DB control fsm relations used: 79569 of 80000 (99%)

2019-05-24 Thread Julie Nishimura
Adrian, this value was set in config file, and alerting comes from monitoring. Would it be right query to count objects in each database (there are 75 dbs on this server totaling close to 20 tb): SELECT count(1) as object_count FROM pg_catalog.pg_class c WHERE c.relkind IN ('r','i') ? Thanks!

Questions about btree_gin vs btree_gist for low cardinality columns

2019-05-24 Thread Jeremy Finzel
I have been hoping for clearer direction from the community about specifically btree_gin indexes for low cardinality columns (as well as low cardinality multi-column indexes). In general there is very little discussion about this both online and in the docs. Rather, the emphasis for GIN indexes

Re: POSTGRES_FSM_RELATIONS CRITICAL: DB control fsm relations used: 79569 of 80000 (99%)

2019-05-24 Thread Adrian Klaver
On 5/23/19 11:57 PM, Julie Nishimura wrote: Hello, We have an issue with fsm_relations utilization reaching 99%, I was able How are you arriving at the above percentage? How many tables/indexes do you have in the database(s)? to vacuum a handful of tables, but it wasn't enough to make a

Re: pg_stat_user_tables.n_tup_ins empty for partitioned table

2019-05-24 Thread Luca Ferrari
On Fri, May 24, 2019 at 9:26 AM David Rowley wrote: > What does: select stats_Reset from pg_stat_database where datname = > current_database(); say? Good guess: # select stats_reset from pg_stat_database where datname = current_database(); stats_reset ---

Re: pg_stat_user_tables.n_tup_ins empty for partitioned table

2019-05-24 Thread David Rowley
On Fri, 24 May 2019 at 19:20, Luca Ferrari wrote: > > On Wed, May 22, 2019 at 7:55 PM Andres Freund wrote: > > That clearly seems wrong. Could you try build a small reproducer? > > Apparently not, I've tried to simulate the same but without any > success, that is n_tup_ins is always correctly

Re: pg_stat_user_tables.n_tup_ins empty for partitioned table

2019-05-24 Thread Luca Ferrari
On Wed, May 22, 2019 at 7:55 PM Andres Freund wrote: > That clearly seems wrong. Could you try build a small reproducer? Apparently not, I've tried to simulate the same but without any success, that is n_tup_ins is always correctly set. However, I've noted that this behavior applies up to

Re: POSTGRES_FSM_RELATIONS CRITICAL: DB control fsm relations used: 79569 of 80000 (99%)

2019-05-24 Thread Julie Nishimura
Correction about version: PostgreSQL 8.3.11 Thanks again!!! From: Julie Nishimura Sent: Thursday, May 23, 2019 11:57 PM To: pgsql-general@lists.postgresql.org; pgsql-general Subject: POSTGRES_FSM_RELATIONS CRITICAL: DB control fsm relations used: 79569 of

POSTGRES_FSM_RELATIONS CRITICAL: DB control fsm relations used: 79569 of 80000 (99%)

2019-05-24 Thread Julie Nishimura
Hello, We have an issue with fsm_relations utilization reaching 99%, I was able to vacuum a handful of tables, but it wasn't enough to make a noticeable difference. I think at this point we will need to increase the number of fsm_relations from 80,000 to 100,000 which will require a restart.

Re: terminating walsender process due to replication timeout

2019-05-24 Thread Kyotaro HORIGUCHI
Hello. At Fri, 17 May 2019 11:04:58 +0300, ayaho...@ibagroup.eu wrote in > Can frequent database operations cause getting a standby server behind? Is > there a way to avoid this situation? > I checked that walsender works well in my test if I set > wal_sender_timeout at least to 5 second.

Re: terminating walsender process due to replication timeout

2019-05-24 Thread Achilleas Mantzios
On 23/5/19 5:05 μ.μ., ayaho...@ibagroup.eu wrote: Hello Everyone! I can simplify and describe the issue I faced. I have 2 nodes in db cluster: master and standby. I create a simple table on master node by a command via psql: CREATE TABLE table1 (a INTEGER); After this I fill the table by COPY