Re: BUG #15460: Error while creating index or constraint

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: paul(dot)vanderlinden(at)mapcreator(dot)eu, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: BUG #15460: Error while creating index or constraint
Date: 2018-10-29 17:11:57
Message-ID: CAH2-WzkrO994qdNP9Ai8G16eRNa_UQswzg4=7PdqYEPeJKYruA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Oct 29, 2018 at 4:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> "performsort of -1"? Seems a bit suspicious.
>
> > This just refers to the leader Tuplesortstate. It isn't suspicious.
> > We follow the convention that worker -1 is the leader within
> > tuplesort.c.
>
> Hmm. But the sort of "0" has already completed, according to the first
> couple of log lines I quoted. Why is something still trying to access
> it? Why is a worker trying to do anything at all with the leader's
> Tuplesortstate?

This is almost certainly because the parallel infrastructure generally
doesn't guarantee that log output will be in order. Even if something
bizarre took place with the temporary files, there is no way that the
worker number in trace_sort would change within a worker. It's an
immutable field within Tuplesortstate, initialized once.

> > trace_sort is a developer option, so this seems fine to me.
>
> That's a poor excuse for ignoring the message style guidelines.
> There are many reasons why even experts could get confused trying
> to follow badly-written messages.

I'll change the trace_sort messages to refer to "worker n" -- that
should bring the trace_sort output in line with our style guidelines.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2018-10-29 18:39:51 Re: BUG #15460: Error while creating index or constraint
Previous Message Ádám Maracska 2018-10-29 16:51:14 Exception is thrown with message: SSL SYSCALL error: No error (0x00000000/0) in case of connection lost