Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster)
В списке pgsql-hackers по дате отправления:
| От | Alfred Perlstein |
|---|---|
| Тема | Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster) |
| Дата | |
| Msg-id | 20000122230510.I26520@fw.wintelcom.net обсуждение |
| Ответ на | Re: pg_dump possible fix, need testers. (was: Re: [HACKERS] pg_dump disaster) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
* Tom Lane <tgl@sss.pgh.pa.us> [000122 22:17] wrote: > Alfred Perlstein <bright@wintelcom.net> writes: > > I really hope the originator of the problem report will get back to > > us to make sure it's settled. > > > *poking Patrick Welche* > > Um, I didn't have any trouble at all reproducing Patrick's complaint. > pg_dump any moderately large table (I used tenk1 from the regress > database) and try to load the script with psql. Kaboom. Can you try it on sources from before my initial patches were applied, and from before the initial non-blocking connections patches from Ewan Mellor were applied? >From my point of view none of my code should be affecting those that don't explicitly use PQsetnonblocking(), which is nothing besides the application i'm developing in-house. I'm currently investigating that possibility. thanks, -Alfred
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера