Re: BUG #8397: pg_basebackup -x from new standby server sometimes causes Segmentation fault
| От | TAKATSUKA Haruka |
|---|---|
| Тема | Re: BUG #8397: pg_basebackup -x from new standby server sometimes causes Segmentation fault |
| Дата | |
| Msg-id | 20130825160549.8cbe1bfd.harukat@sraoss.co.jp обсуждение исходный текст |
| Ответ на | Re: BUG #8397: pg_basebackup -x from new standby server sometimes causes Segmentation fault (Magnus Hagander <magnus@hagander.net>) |
| Ответы |
Re: BUG #8397: pg_basebackup -x from new standby server
sometimes causes Segmentation fault
|
| Список | pgsql-bugs |
Thanks for the response. On Sat, 24 Aug 2013 17:04:21 +0200 Magnus Hagander <magnus@hagander.net> wrote: > > (1) create new standby server dir by pg_basebackup without -x > > (2) start new standby server > > (3) pg_basebackup from new standby server with -x > > (!) when new standby has no WAL files in pg_xlog, > > new standby's wal sender crash (snip) > > Though pg_basebackup does not have to work in this rare case, > > we should insert something like "if (nWalFiles <= 0) ereport(...);". > > Yes, we definitely need better error checking there - a crash is never > the right answer. > > Does this happen only when you take a backup "really quickly" after > setting up the new standby, It's just this first case. Therefore, we recognize that it is the problem of how to use. regards, > or is there some scenario further in it's > lifetime when it can happen? In the first case, throwing a hard error > seems quite reasonable, but if it's repeatable, perhaps there is > something better we can do? > > Also, while we definitely need a sanity check at this point, might it > be worth it to put a second check earlier in the process as well - > since AFAICT this error gets thrown only after all the data has been > sent arlready. > > -- > Magnus Hagander > Me: http://www.hagander.net/ > Work: http://www.redpill-linpro.com/ ______________________________________________________ harukat@sraoss.co.jp (SRA OSS, Inc. http://www.sraoss.co.jp)
В списке pgsql-bugs по дате отправления: