Hello,
We're using streaming replication. Our technique for spinning up a db
slave is this:
rsync from master (gross copy)
pg_start_backup() on server
rsync from master (correct copy)
pg_stop_backup()
drop in recovery.conf into slave directory
enable hot_standby in slave conf
start slave
After s
Hi, there.
First, my particulars:
* Ubuntu Trusty build and runtime environment
* PostgreSQL 9.3.10 Ubuntu source code
* Using a FIPS enabled version of OpenSSL (i.e. 1.0.1p version of the
library and 2.0.9 of the FIPS canister source code)
* I think this is pr
Hello Adrian, thanks for the response.
master data also located on SAN
Yes, each replica is it own VM with its own virtual disk/volume as served
up from the same SAN
Raw disk mappings are a way for ESX to present a SAN volume directly to a
VM instead of creating a virtual disk.
no unexpected me
Rodney Lott writes:
> So, my question is this: In FIPS mode, what would cause the random
> number generation to not initialize?
I remember that Red Hat's version of "FIPS mode" involved crypto features
(including RNGs) just refusing to work in modes deemed inadequately
secure. So my guess is tha
> > So, my question is this: In FIPS mode, what would cause the random
> > number generation to not initialize?
>
> I remember that Red Hat's version of "FIPS mode" involved crypto
> features (including RNGs) just refusing to work in modes deemed
> inadequately secure. So my guess is that psql is
On Tue, Mar 29, 2016 at 12:38 PM, Pavel Stehule wrote:
> The coalesce is one few functions implemented by special rule in
> PostgreSQL parser.
In the SQL standard the COALESCE feature is not listed as a
function; it is listed as one of the short forms of CASE
expression. While it has function-l
It seems that it was the Postgres bug on replica, after upgrading minor
version to 9.1.21 on replica1, the corruption goes away.
Thanks everyone for the help
On Tue, Apr 5, 2016 at 1:32 AM, Soni M wrote:
> Hello Adrian, thanks for the response.
>
> master data also located on SAN
>
> Yes, each
Hi there.
I'm currently using postgres 9.2.
As you can see below, my "template1" database was being accessed:
[image: Inline images 2]
That server is a 4-day-old backup DB - does a gzip of pg_dump, excluding
some tables; also 4-day old replication using WAL-archive with 345600s
delay; also file
On 4/4/2016 9:04 PM, drum.lu...@gmail.com wrote:
I'm currently using postgres 9.2.
As you can see below, my "template1" database was being accessed:
500m is 1/2 access per whatever interval that graph is using. typically,
template1 is accessed when you do a create database if you don't specif
On Sun, Apr 3, 2016 at 2:50 PM, David Caldwell wrote:
> Hello,
>
> We're using streaming replication. Our technique for spinning up a db
> slave is this:
>
> rsync from master (gross copy)
> pg_start_backup() on server
> rsync from master (correct copy)
> pg_stop_backup()
> drop in recovery.conf i
(sorry, back to the list)
On Tue, Apr 5, 2016 at 6:11 AM, John R Pierce wrote:
> its also possible some management software might use it as a default place
> to connect so they can get a list of databases or whatever .
This is probably the most common case for continuos access to template1.
Lu
11 matches
Mail list logo
