> On Sep 17, 2019, at 8:43 AM, Shital A wrote:
>
> Hello,
>
> We are working on a payments systems which uses postgreSql 9.6 as backend DB
> and blockchain technology. The database is setup in HA in master-standby mode
> using pacemaker on Linux 7.6.
>
> We are new to postgres and need help
> On Jan 4, 2019, at 9:32 AM, MichaelDBA wrote:
>
> The 3rd one is separate binary locations for each PG cluster instance
> running on the same host.
Don’t need separate binaries for each cluster; only separate binaries for each
version needed; i.e. 9.6.1, 9.6.2, etc.
>
> Look, you either trust your DBAs or you don't. If you don't trust them, why
> are they your DBA? This is like writing unit tests for unit tests or having
> even higher levels of privilege than a superuser. It's turtles all the way
> down.
>
> ~Ben
>
>
> On Aug 6, 2018, at 10:45 AM, Bear Giles wrote:
>
> then it's reasonable to ask if storing the information in a relational
> database is the best approach.
Why? Just because its encrypted doesn’t mean it shouldn’t be stored in the
database. What about PITR, how would that be handled? You b
Correct, and there is no need to create an index on a unique constraint or
primary key as they are already implemented via indexes. I can’t count how
many duplicate indexes I’ve dropped in the past. I use this view help find
duplicates in a given system. Duplicate indexes just use up space an
How large are the given tables and is the databases in heavy use at the time?
It sounds like either blocking is occurring or you’re dealing with large tables
and the validation is take a long time; which, in both case is normal.
Try creating the foreign key without validation, i.e. use the “not
There are many different solutions; but I would recommend and use a least a
three node cluster using synchronous replication where one of the nodes is
acting as the witness — at a minimum (actual have more replicas). The witness
node need not be a full Postgres instance; it can also be achieved
