Re: SR fails to send existing WAL file after off-line copy
В списке pgsql-hackers по дате отправления:
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: SR fails to send existing WAL file after off-line copy |
| Дата | |
| Msg-id | 4CCE5E10.7060403@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: SR fails to send existing WAL file after off-line copy (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
On 01.11.2010 05:21, Robert Haas wrote: > There seem to be two cases in the code that can generate that error. > One, attempting to open the file returns ENOENT. Two, after the data > has been read, the last-removed position returned by > XLogGetLastRemoved precedes the data we think we just read, implying > that it was overwritten while we were in the process of reading it. > Does your installation have debugging symbols? Can you figure out > which case is triggering (inside XLogRead) and what the values of log, > seg, lastRemovedLog, and lastRemovedSeg are? An easy way to find out which ereport() it is is to "set log_error_verbosity='verbose'" and re-run the test. You then get the file and line number of the ereport in the log. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера