On Wed, Feb 13, 2013 at 8:59 PM, Stuart Bishop <stuart@stuartbishop.net> 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@gmail.com
