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

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: Postgresql13_beta1 (could not rename temporary statistics file)Windows 64bits
Дата
Msg-id CAEudQAqxZ7Pbs8A3ypfdDoOsEqLxhfO0LVwdqhPo50om1kXvDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Postgresql13_beta1 (could not rename temporary statistics file)Windows 64bits  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Postgresql13_beta1 (could not rename temporary statistics file)Windows 64bits  (Ranier Vilela <ranier.vf@gmail.com>)
Список pgsql-hackers
Em dom., 14 de jun. de 2020 às 23:53, Justin Pryzby <pryzby@telsasoft.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

Livre de vírus. www.avast.com.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Следующее
От: Michael Paquier
Дата:
Сообщение: Failures with wal_consistency_checking and 13~