2009/6/22 Tom Lane :
> William Temperley writes:
>> I'm wondering if I happened as I'd started the same query twice.
>> The first had work_mem = 1MB so I tried to kill it and started another
>> with work_mem = 1000MB, but both were attempting to insert the same id
>> into a PK:
>> "insert into wor
William Temperley writes:
> I'm wondering if I happened as I'd started the same query twice.
> The first had work_mem = 1MB so I tried to kill it and started another
> with work_mem = 1000MB, but both were attempting to insert the same id
> into a PK:
> "insert into world (geom, id) select st_unio
2009/6/22 Tom Lane :
> William Temperley writes:
>> I've got two transactions I tried to kill 3 days ago using "select
>> pg_cancel_backend()", then SIGTERM, and have since then been
>> using 100% of a cpu core each. They were supposed to insert the
>> results of large unions with PostGIS and appe
William Temperley writes:
> I've got two transactions I tried to kill 3 days ago using "select
> pg_cancel_backend()", then SIGTERM, and have since then been
> using 100% of a cpu core each. They were supposed to insert the
> results of large unions with PostGIS and appear to have failed.
> Could
Hi All,
I've got two transactions I tried to kill 3 days ago using "select
pg_cancel_backend()", then SIGTERM, and have since then been
using 100% of a cpu core each. They were supposed to insert the
results of large unions with PostGIS and appear to have failed.
Could someone tell me what's the l
