Andrew - Supernews wrote:
On 2006-04-10, Alban Hertroys <[EMAIL PROTECTED]> wrote:
Notice the "INSERT" there. For a restore, you'd expect it to be "COPY",
_unless_ you used the -d option to pg_dump (this is a common mistake to
make, given that all the other utilities use -d to specify the databas
On 2006-04-10, Alban Hertroys <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>> Alban Hertroys <[EMAIL PROTECTED]> writes:
>>
>>>postgres 15092 0.0 0.3 43692 12924 ? D14:11 0:00 postgres:
>>>postgres vh3_live [local] INSERT
>>
>> This process is not blocked on a lock: it's waiting fo
Alban Hertroys wrote:
> > If your sysadmin wants to use 7.4.7 rather than 7.4., he
> > needs swift application of a cluestick. I'll grant that there
> > might be application-compatibility reasons to stay on 7.4.*, but
> > not to avoid being up to date in that release series. See
> > http://develo
Tom Lane wrote:
Alban Hertroys <[EMAIL PROTECTED]> writes:
postgres 15092 0.0 0.3 43692 12924 ? D14:11 0:00 postgres:
postgres vh3_live [local] INSERT
This process is not blocked on a lock: it's waiting for disk I/O.
Thoughts that come to mind include (1) it's going fine and y
Alban Hertroys <[EMAIL PROTECTED]> writes:
> postgres 15092 0.0 0.3 43692 12924 ? D14:11 0:00 postgres:
> postgres vh3_live [local] INSERT
This process is not blocked on a lock: it's waiting for disk I/O.
Thoughts that come to mind include (1) it's going fine and you're not
patient
Hi all,
I'm trying to restore one of our production databases on our development
system, but restore locks itself out.
The symptoms: restoring goes fine up to a certain point. Reaching that
point the database is idle, and apparently waiting on a lock. Server
load is minimal.
As this is a new
