Re: Re: Hot Standby query cancellation and Streaming Replication integration

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Re: Hot Standby query cancellation and Streaming Replication integration
Дата
Msg-id 4B8D70D4.7010004@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Re: Hot Standby query cancellation and Streaming Replication integration  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Re: Hot Standby query cancellation and Streaming Replication integration  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Bruce Momjian wrote:<br /><blockquote cite="mid:201003021834.o22IYX529089@momjian.us" type="cite"><blockquote
type="cite"><prewrap="">Right now you can't choose "master bloat", but you can choose the other
 
two.  I think that is acceptable for 9.0, assuming the other two don't
have the problems that Tom foresees.   </pre></blockquote><pre wrap="">
I was wrong.  You can choose "master bloat" with
vacuum_defer_cleanup_age, but only crudely because it is measured in
xids and the master defers no matter what queries are running on the
slave...</pre></blockquote><br /> OK with you finding the situation acceptable, so long as it's an informed decision. 
Fromhow you're writing about this, I'm comfortable you (and everybody else still involved here) have absorbed the
issuesenough that we're all talking about the same thing now.  Since there are a couple of ugly user-space hacks
possiblefor prioritizing "master bloat", and nobody is stepping up to work on resolving this via my suggestion
involvingbetter SR integration, seems to me heated discussion of code changes has come to a resolution of sorts I (and
Simon,just checked) can live with.  Sounds like we have three action paths here:<br /><br /> -Tom already said he was
planninga tour through the HS/SR code, I wanted that to happen with him aware of this issue.<br /> -Josh will continue
doinghis testing, also better informed about this particular soft spot.<br /> -I'll continue test-case construction for
theproblems here there are still concerns about (pathologic max_standby_delay and b-tree split issues being the top two
onthat list), and keep sharing particularly interesting ones here to help everyone else's testing.  <br /><br /> If it
turnsout any of those paths leads to a must-fix problem that doesn't have an acceptable solution, at least the idea of
thisas a "plan B" is both documented and more widely understood then when I started ringing this particular bell.<br
/><br/> I just updated the Open Items list:  <a class="moz-txt-link-freetext"
href="http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items">http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items</a>
toofficially put myself on the hook for the following HS related documentation items that have come up recently, aiming
toget them all wrapped up in time before or during early beta:<br /><br /> -Update Hot Standby documentation: clearly
explainrelationships between the 3 major setup trade-offs, "buffer cleanup lock", notes on which queries are killed
oncemax_standby_delay is reached, measuring XID churn on master for setting vacuum_defer_cleanup_age<br /> -Clean up
archive_commanddocs related to recent "/bin/true" addition.  Given that's where I expect people who run into the
pg_stop_backupwarning message recently added will end up at, noting its value for escaping from that particular case
mightbe useful too.<br /><br /> To finish airing my personal 9.0 TODO list now that I've gone this far, I'm also still
workingon completing the following patches that initial versions have been submitted of, was close to finishing both
beforegetting side-tracked onto this larger issue:<br /><br /> -pgbench > 4000 scale bug fix:  <a
class="moz-txt-link-freetext"
href="http://archives.postgresql.org/message-id/4B621BA3.7090306@2ndquadrant.com">http://archives.postgresql.org/message-id/4B621BA3.7090306@2ndquadrant.com</a><br
/>-Improving the logging/error reporting/no timestamp issues in pg_standby re-raised recently by Selena:  <a
class="moz-txt-link-freetext"
href="http://archives.postgresql.org/message-id/2b5e566d1001250945oae17be8n6317f827e3bd7492@mail.gmail.com">http://archives.postgresql.org/message-id/2b5e566d1001250945oae17be8n6317f827e3bd7492@mail.gmail.com</a><br
/><br/> If nobody else claims them as something they're working on before, I suspect I'll then move onto building some
ofthe archiver UI improvements discussed most recently as part of the "pg_stop_backup does not complete" thread,
despiteHeikki having crushed my dreams of a simple solution to those by pointing out the shared memory memory
limitationinvolved.<br /><br /><pre class="moz-signature" cols="72">-- 
 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
<a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a>   <a
class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>
 

</pre>

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Re: Hot Standby query cancellation and Streaming Replication integration
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Re: Hot Standby query cancellation and Streaming Replication integration