Re: Problem with a "complex" upsert
От | Peter Geoghegan |
---|---|
Тема | Re: Problem with a "complex" upsert |
Дата | |
Msg-id | CAH2-Wz=Qv+orFotg9EASYu8vbNLFjuBywS_pj0mi+pz3fsaXeQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Fwd: Problem with a "complex" upsert (Mario De Frutos Dieguez <mariodefrutos@gmail.com>) |
Список | pgsql-bugs |
On Thu, Jun 21, 2018 at 7:11 AM, Mario De Frutos Dieguez <mariodefrutos@gmail.com> wrote: > I've tried using the source insert table data but the server crashes: > > INSERT INTO "acs2014_5yr"."b01003" (geoid, b01003001) > SELECT (left(acs.geoid, 7) || bi.blockid) geoid, (b01003001 * > (percentage*100.0))::float b01003001 > FROM "tiger2015".blocks_interpolation bi > INNER JOIN "acs2014_5yr"."b01003" acs ON bi.blockgroupid = > substr(acs.geoid,8) > WHERE acs.geoid = '15000US020200001013' AND char_length(substr(acs.geoid, > 8)) = 12 > ON CONFLICT (geoid) DO UPDATE SET (b01003001) = > ROW("acs2014_5yr"."b01003".b01003001); > > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > > Any clues? Could be a bug? I see something similar here It would be very helpful if you could get a stack trace of the crashing backend: https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Getting_a_trace_from_a_randomly_crashing_backend -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: