On Wed, Feb 13, 2013 at 8:59 PM, Stuart Bishop <stuart@xxxxxxxxxxxxxxxx> wrote: > Something that might be interesting that I neglected to mention, the > DETAIL of the error message is random; on production my failures end > up with one of these three: > > DETAIL: User query might have needed to see row versions that must be removed. > DETAIL: User was holding a relation lock for too long. > DETAIL: User was holding shared buffer pin for too long. I think it can only be solved by increasing max_standby_streaming_delay or by setting it to -1. What about VACUUM from your test case. Probably it is not the matter of it, but the matter of what is happening in the connection. Try replace the VACUUM with SELECT pg_sleep(<some long period>) or may be start a transaction without/with query inside, or something else. Try to simulate different stuff from the activity that happens on your server to find out what causes which DETAILs. >> Personally I recommend to do pg_dump on master at least on <=9.2. > > Anything in particular in 9.2? I've been seeing a lot of replication > related fixes in 9.1 patch releases and had been planning on sticking > with 9.1 for the next 18 months. Nothing significant AFAIK. > I'm still unsure if this is supposed to work, and this is a bug in > PostgreSQL or Ubuntu, or if I'm just misreading the documentation. I would not say it is a bug. I think it just was not supposed to be a functionality of standby servers. -- Sergey Konoplev Database and Software Architect http://www.linkedin.com/in/grayhemp Phones: USA +1 415 867 9984 Russia, Moscow +7 901 903 0499 Russia, Krasnodar +7 988 888 1979 Skype: gray-hemp Jabber: gray.ru@xxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
