Re: Fail to create PK or index for large table in Windows

From: Pavel <ospavelmail(at)gmail(dot)com>
To: thomas(dot)munro(at)enterprisedb(dot)com
Cc: PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Fail to create PK or index for large table in Windows
Date: 2018-11-13 09:21:55
Message-ID: CAHDGBJMX_MjnrDzf1R4wafpzpHyVsisoSy+bPsr4uW92goJdUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thank you for your work!

You can log contents of directory before rmdir.
If it empty then the reason should be in multiworkers: looks like
Windows disallow to delete directory if it (or files in it) used by
somebody else (like other workers) and maybe some workers didn't
release it before rmdir. Linux allows as I know.

Best regards,
Pavel Oskin

вт, 13 нояб. 2018 г. в 12:01, Thomas Munro:
>
> On Tue, Nov 13, 2018 at 10:22 AM Pavel wrote:
> > PostgreSQL 11.0, 11.1
> > OS: Windows 7 x64
> > RAM: 16GB
>
> Thanks for the report. This is the same issue as reported in bug #15460:
>
> https://www.postgresql.org/message-id/flat/15460-b6db80de822fa0ad%40postgresql.org
>
> We are still trying to figure out what causes this, and there have
> been no similar reports on Unix. For a workaround, you can disable
> parallel index building with SET max_parallel_maintenance_workers = 0.
>
> > 2018-11-12 21:31:05.182 MSK [6672] ERROR: could not determine size of
> > temporary file "0"
> > 2018-11-12 21:31:05.182 MSK [6672] STATEMENT: alter table sc.address
> > add primary key (id_address);
>
> This is the thing we haven't understood yet.
>
> > 2018-11-12 21:31:05.889 MSK [7008] LOG: could not rmdir directory
> > "base/pgsql_tmp/pgsql_tmp6672.0.sharedfileset": Directory not empty
> >
> > After error the directory
> > "base/pgsql_tmp/pgsql_tmp6672.0.sharedfileset" is empty.
>
> For the later "could not rmdir directory" error, I am fairly sure I
> understand what's happening there (see the other bug thread) but
> that's only a LOG message and an empty directory left behind after an
> error is raised, it's not the root cause.
>
> --
> Thomas Munro
> http://www.enterprisedb.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Eisentraut 2018-11-13 09:45:36 Re: BUG #15356: Inconsistent documentation about CREATE TYPE
Previous Message Thomas Munro 2018-11-13 09:13:37 Re: BUG #15460: Error while creating index or constraint