On Wed, Feb 10, 2010 at 12:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Tom Lane wrote:
>>> The code is only trying to substitute for something you can't have
>>> in parallel restore, ie --single-transaction.
>
>> Exactly. IIRC that's why --single-transaction was introduced in the
>> first place.
>
> To me, --single-transaction is mostly there for people who want to be
> sure they have all-or-nothing restore behavior. Optimizations are
> secondary.
>
>> Takahiro-san is suggesting there is a case for doing the optimisation in
>> non-parallel mode. But if we do that, is there still a case for
>> --single-transaction?
>
> Yeah, per above. The main problem I have with doing it in non-parallel
> restore mode is that we couldn't safely do it when outputting to a
> script (since we don't know if the user will try to put begin/end
> around the script), and I really do not want to allow any differences
> between script output and direct-to-database output. Once that camel's
> nose gets under the tent, debuggability will go down the tubes...
Is this a fatal defect or is there a way to salvage this idea?
Another possible issue is that this changes the behavior. Suppose the
table wasn't empty before we truncated it...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company