On Wed, Jul 27, 2016 at 09:17:58AM +0200, Chris Travers wrote: > The replication section made me wonder though if they were using the right > replication solution for the job. If you don't want an on-disk copy, don't use > physical replication. This being said there is one serious issue here that is > worth mentioning, which is that since autovacuum on the master has no knowledge > of autovacuum on the slave, it is easy to have longer-running queries on a > slave that have rows they need to see removed by autovacuum and replication. Uh, see hot_standby_feedback: #hot_standby_feedback = off # send info from standby to prevent # query conflicts > All of the above being said, there are solutions to all the major problems. > But you have to know about them, where to look, and what to do. And with > higher scale, one very important aspect is that attention to detail starts to > matter a whole lot. I agree that there are some good points raised but I > wonder what the solutions are. There is room for some improvement in the > backend (it would really be nice to instrument and measure toasting/detoasting > overhead in explain analyze) but for a lot of these I wonder if that is > secondary. PostgreSQL is very well optimized for a certain series of tasks, > and one can build well optimized solutions well outside that. At a certain > point (including a certain scale) therewill be no substitute for a teamof > people who really know the db backend inside and out who can design around > limitations and I think that is true for all databases I have worked with. Watching the video was helpful: https://vimeo.com/145842299 You can see the failover happened because of various user errors. That doesn't excuse our bug, but I am not sure exactly how much they understood of Postgres behavior. His talk near the end about the replication infrastucture being exposed to them was also interesting. -- Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general