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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: paul.vanderlinden@mapcreator.eu, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2018-10-29T16:51:03Z
Lists: pgsql-bugs
Peter Geoghegan <pg@bowt.ie> writes:
> On Mon, Oct 29, 2018 at 3:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> LOG:  performsort of 0 done: CPU: user: 250.03 s, system: 42.66 s, elapsed: 294.35 s
>>> LOG:  parallel external sort of 0 ended, 462886 disk blocks used: CPU: user: 250.03 s, system: 42.66 s, elapsed: 298.95 s
>>> LOG:  begin index sort: unique = f, workMem = 2096128, randomAccess = f
>>> LOG:  performsort of -1 starting: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
>>> LOG:  could not rmdir directory "base/pgsql_tmp/pgsql_tmp5088.0.sharedfileset": Directory not empty
>>> ERROR:  could not determine size of temporary file "0"

>> "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?

> 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.

			regards, tom lane


Commits

  1. Have BufFileSize() ereport() on FileSize() failure.

  2. Use 64 bit type for BufFileSize().

  3. Adjust trace_sort log messages.

  4. Fix some sloppiness in the new BufFileSize() and BufFileAppend() functions.