Re: Postgresql13_beta1 (could not rename temporary statistics file) Windows 64bits

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Postgresql13_beta1 (could not rename temporary statistics file) Windows 64bits
Date: 2020-06-15 13:03:56
Message-ID: CAEudQAqxZ7Pbs8A3ypfdDoOsEqLxhfO0LVwdqhPo50om1kXvDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em dom., 14 de jun. de 2020 às 23:53, Justin Pryzby <pryzby(at)telsasoft(dot)com>
escreveu:

> On Fri, Jun 12, 2020 at 03:15:52PM -0300, Ranier Vilela wrote:
> > Posgres13_beta1, is consistently writing to the logs, "could not rename
> > temporary statistics file".
> > When analyzing the source that writes the log, I simplified the part that
> > writes the logs a little.
>
> What windows version and compiler ?
>
Windows 10 (2004, msvc 2019 (64 bits)
None configuration, only git clone and build.bat

>
> Please show the full CSV log for this event, and not an excerpt.
> Preferably with several lines of "context" for the stats process PID, with
> log_min_messages=debug or debug2 and log_error_verbosity=verbose, so that
> you
> get the file location where it's erroring, if you don't already know that.
>
> https://wiki.postgresql.org/wiki/Guide_to_reporting_problems
>
> Ok, I will provide.

> > 1. I changed from if else if to if
> > 2. For the user, better to have more errors recorded, which can help in
> > discovering the problem
> > 3. Errors are independent of each other
> > 4. If I can't release tmpfile, there's no way to delete it (unlink)
> > 5. If I can rename, there is no need to delete it (unlink) tmpfile.
> >
> > Attached is the patch that proposes these changes.
> > Now, the problem has not been solved.
>
> It sounds like you haven't yet found the problem, right ? These are all
> unrelated changes which are confusing the problem report and discussion.
> And introducing behavior regressions, like renaming files with write
> errors on
> top of known good files.
>
It is certainly on pgstat.c
Yes, I have not yet discovered the real cause.
But, while checking the code, I thought I could improve error checking, and
to avoid creating a new thread about it, I took advantage of that thread.
It would certainly be better to separate, but this list is busy, I tried
not to create any more confusion.
If I can't record, I can't close and I can't rename, seeing this in the
logs, certainly, helps to solve the problem, not confuse.
In addition, the flow was cleaner, with fewer instructions and in this
specific case, it continues with the same expected behavior.
Only the rename message is showing, so the expected behavior is the same.

> I think you'll want to 1) identify where the problem is occuring, and
> attach a
> debugger there.
>
I will try.

>
> 2) figure out when the problem was introduced. If this problem doesn't
> happen
> under v12:
>
I don't think so, but v12 I'm using the official distributed version.

>
> git log --cherry-pick -p origin/REL_12_STABLE...origin/REL_13_STABLE --
> src/backend/postmaster/pgstat.c
> or just:
> git log -p origin/REL_12_STABLE.. src/backend/postmaster/pgstat.c
>
> You could try git-bisecting between v12..v13, but there's only 30 commits
> which
> touched pgstat.c (assuming that's where the ERROR is being thrown)

Thanks for the hit.

> .
>
> Do you have a special value of stats_temp_directory?
>
Not.

> Or a symlink or junction at pg_stat_tmp ?
>
Not. Only C driver (one volume)

You saw the patch regarding the flag, suggested.

> > 1. statfile, is it really closed or does it not exist in the directory?
> > There is no way to rename a file, which is open and in use.
> > 2. Why delete (pgstat_stat_filename), if permanent is true:
> > const char * statfile = permanent? PGSTAT_STAT_PERMANENT_FILENAME:
> > pgstat_stat_filename;
> > statfile is PGSTAT_STAT_PERMANENT_FILENAME and not pgstat_stat_filename
>
> You can find answers to a lot of questions in the git history. In this
> case,
> 70d756970 and 187492b6c.
>
Ok,.

Thanks for answer Justin.

regards,
Ranier Vilela

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Livre
de vírus. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-06-15 13:14:05 Failures with wal_consistency_checking and 13~
Previous Message Amit Kapila 2020-06-15 12:59:54 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions