From: | Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, hlinnaka <hlinnaka(at)iki(dot)fi> |
Subject: | Re: Race condition in recovery? |
Date: | 2021-05-28 03:18:35 |
Message-ID: | e00f625f-b1e1-933c-7915-3acd9250d63b@nttcom.co.jp_1 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Horiguchi-san,
In a project I helped with, I encountered an issue where
the archive command kept failing. I thought this issue was
related to the problem in this thread, so I'm sharing it here.
If I should create a new thread, please let me know.
* Problem
- The archive_command is failed always.
* Conditions under which the problem occurs (parameters)
- archive_mode=always
- Using the test command in archive_command
* Probable cause
- I guess that is because the .history file already exists,
and the test command fails.
(but if we use archive_mode=on, archive_command is successful).
* How to reproduce
- Attached is a script to reproduce the problem.
Note: the script will remove $PGDATA when it started
The test command is listed as an example of the use of archive_command
in postgresql.conf, and the project faced this problem because it used
the example as is. If this behavior is a specification, it would be
better not to write the test command as a usage example.
Or maybe there should be a note that the test command should not be used
when archive_mode=always. Maybe, I'm missing something, sorry.
Regards,
Tatsuro Yamada
Attachment | Content-Type | Size |
---|---|---|
always.sh | text/plain | 1.2 KB |
always.log | text/plain | 18.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-05-28 03:23:57 | Re: Parallel Inserts in CREATE TABLE AS |
Previous Message | Greg Nancarrow | 2021-05-28 01:01:31 | Re: Consider parallel for lateral subqueries with limit |