On Fri, Dec 13, 2019 at 3:13 PM Justin Pryzby <pry...@telsasoft.com> wrote: > On Fri, Dec 13, 2019 at 03:03:47PM +1300, Thomas Munro wrote: > > On Fri, Dec 13, 2019 at 7:05 AM Justin Pryzby <pry...@telsasoft.com> wrote: > > > 2019-12-07 01:35:56 | 11025 | postgres | canceling statement due to > > > statement timeout | CLUSTER > > > pg_stat_database_snap USI > > > 2019-12-07 01:35:56 | 11025 | postgres | temporary file: path > > > "base/pgsql_tmp/pgsql_tmp11025.0.sharedfileset/2.0", size 5455872 | > > > CLUSTER pg_stat_database_snap USI > > > > Hmm. But then... maybe the two log lines you quoted should > > be the other way around for that. > > And, it's actually the other way around, when I order BY something better than > left(log_time::text,19).
Hah. Ok, so it looks like we shouldn't be relying on the same code path for 'happy' and 'error' cleanup. This could probably be fixed with a well placed explicit call to SharedFileSetDeleteAll() or a new function SharedFileSetDestroy(), and perhaps a flag in shmem to say it's been done so the callback doesn't do it again needlessly. I don't think this problem is specific to parallel index creation.
