From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Andrew Chernow <ac(at)esilo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallel restore vs. windows |
Date: | 2008-12-09 20:02:31 |
Message-ID: | 20149.1228852951@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2008-12-09 20:04:26 | Re: syntax for reaching into records, specifically ts_stat results |
Previous Message | Tom Lane | 2008-12-09 19:52:52 | Re: SSL BIO wrappers |