[HACKERS] logical replication read-only slave

Hello, I played around a bit with the logical replication in 10.0 beta 1. My first question was: is it possible to set the "slave" server to run in (almost) read-only mode? The current setup is the following: There is a Rails application running on multiple servers Two PostgreSQL servers, strea

Re: [HACKERS] Google Cloud Compute + FreeBSD + PostgreSQL = timecounter issue

On 23.11.16 20:43, Maeldron T. wrote: pg_test_timing doesn’t show the problem, or I read the output wrong. Or it does. I checked another output than the one I attached at the end. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

[HACKERS] Google Cloud Compute + FreeBSD + PostgreSQL = timecounter issue

In short: The available timecounters on Google Compute Instances seem to be random. The setting in the official FreeBSD image is wrong (not available on any of my test instances). FreeBSD will pick up a timecounter at random. When either the TSC or the TSC-low counter is used, explain analyze

[HACKERS] PostgreSQL super HA (High Availability) conception for 9.5+

Hello, Foreword: Unfortunately, I have no time to read the mailing lists and attend events like PostgreSQL and NoSQL. Some of the ideas came from MongoDB and Cassandra. The inspiration was the pg_rewind. There is little new here, it’s a wish-list put together, considering what could be possible

Re: [HACKERS] Failback to old master

2014-11-13 9:05 GMT+01:00 Heikki Linnakangas : > > Right. You have to be careful to make sure the standby really did fully > catch up with the master, though. If it happens that the replication > connection is momentarily down when you shut down the master, for example, > then the master won't wai

Re: [HACKERS] Failback to old master

On 16/11/14 13:13, didier wrote: I think you have to add recovery_target_timeline = '2' in recovery.conf with '2' being the new primary timeline . cf http://www.postgresql.org/docs/9.4/static/recovery-target-settings.html Thank you. Based on the link I have added: recovery_target_timeline = '

Re: [HACKERS] Failback to old master

On 12/11/14 14:28, Ants Aasma wrote: On Tue, Nov 11, 2014 at 11:52 PM, Maeldron T. wrote: As far as I remember (I can’t test it right now but I am 99% sure) promoting the slave makes it impossible to connect the old master to the new one without making a base_backup. The reason is the

Re: [HACKERS] Failback to old master

Hi, 2014-10-29 17:46 GMT+01:00 Robert Haas >: Yes, but after the restart, the slave will also rewind to the most recent restart-point to begin replay, and some of the sanity checks that recovery.conf enforces will be lost during that replay. A safe wa

Re: [HACKERS] Failback to old master

9, 2014 at 6:21 AM, Maeldron T. wrote: > > I swear I have read a couple of old threads. Yet I am not sure if it > safe to > > failback to the old master in case of async replication without base > backup. > > > > Considering: > > I have the latest 9.3 server >

[HACKERS] Failback to old master

Hello, I swear I have read a couple of old threads. Yet I am not sure if it safe to failback to the old master in case of async replication without base backup. Considering: I have the latest 9.3 server A: master B: slave B is actively connected to A I shut down A manually with -m fast (it's the