Re: 7 hrs for a pg_restore?
От | Gregory Stark |
---|---|
Тема | Re: 7 hrs for a pg_restore? |
Дата | |
Msg-id | 87zltvurve.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: 7 hrs for a pg_restore? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 7 hrs for a pg_restore?
|
Список | pgsql-performance |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Erik Jones <erik@myemma.com> writes: >> On Feb 20, 2008, at 8:14 AM, Gregory Stark wrote: >>> I would suggest leaving out the && which only obfuscate what's >>> going on here. >>> >>> PGOPTIONS=... pg_restore ... >>> >>> would work just as well and be clearer about what's going on. > >> Right, that's just an unnecessary habit of mine. > > Isn't that habit outright wrong? ISTM that with the && in there, > what you're doing is equivalent to > > PGOPTIONS=whatever > pg_restore ... > > This syntax will set PGOPTIONS for the remainder of the shell session, > causing it to also affect (say) a subsequent psql invocation. Which is > exactly not what is wanted. When I said "obfuscating" I meant it. I'm pretty familiar with sh scripting and I'm not even sure what the && behaviour would do. On at least some shells I think the && will introduce a subshell. In that case the variable would not continue. In bash I think it would because bash avoids a lot of subshells that would otherwise be necessary. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
В списке pgsql-performance по дате отправления: