Re: parallel restore vs. windows

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: parallel restore vs. windows
Дата
Msg-id 493EF0E3.5010905@hagander.net
обсуждение исходный текст
Ответ на Re: parallel restore vs. windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: parallel restore vs. windows  (Andrew Chernow <ac@esilo.com>)
Список pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Andrew Dunstan wrote:
>>> I'll try. It's unfortunately not as simple as it sounds, because of the
>>> way the abstractions are arranged. I can't count the number of times I
>>> have had to stop and try to clear my head while working on this code.
> 
>> That's what killed me when I tried to review that stuff and figure it out.
> 
>> Does that indicate that the abstractions are bad and should be changed,
>> or just that there's no reasonably way to make the abstractions both
>> make sense for the internal API itself *and* for being threadsafe?
> 
> I think pretty much everybody except Philip Warner has found the stuff
> around the TOC data structure and the "archiver" API to be confusing.
> I'm not immediately sure about a better design though, at least not if
> you don't want to duplicate a lot of code between the plain pg_dump and
> the pg_dump/pg_restore cases.
> 
> I don't see that this has much of anything to do with thread safety,
> however --- it's just a matter of too many layers of indirection IMHO.

It doesn't - but it makes it harder to find the issue I think :-( If it
was reasonably easy, an API redesign might help that. But I haven't
looked at all at the possibility of doing so, so I won't comment on if
it's likely to be doable.

//Magnus



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

Предыдущее
От: Oleg Bartunov
Дата:
Сообщение: Re: syntax for reaching into records, specifically ts_stat results
Следующее
От: Andreas 'ads' Scherbaum
Дата:
Сообщение: FOSDEM 2009 Call for Papers - deadline