Thanks for your comments and I am sorry for my bad response because of
my business. In the first place, criticisms are welcome since without
criticisms and discussions, I cannot improve my idea.
Christopher, thanks to your comments, I understood why this community
does not incline to accept Sigres approach.
Reason 1: Sigres method may make PostgreSQL less robust.
Reason 2: There is a not-inconsiderable risk that people will fail to
Let me write my opinions for the above.
Opinion for Reason 1:
Right. Apparently Sigres method makes PostgreSQL less robust. Thus I
propose to use Sigres method as an option like fsync=off. In my
understanding, fsync=off option is ambiguous. I think unfortunately it
is unclear when exactly the option should be used. Even if one uses
UPS, the option is dangerous because the final issue_xlog_sync called
by XLogWrite called by CreateCheckPoint called by ShutdownXLOG called
by bgWriter process at postgres shutdown is not executed. (Sorry for
the exact but wired descriptions). Without using UPS, the option never
On the other hand, *IF* UPS is reliable, Sigres assures
synchronization of wal records to a disk because Sigres executes
issue_xlog_fsync at each XLogFileClose() and at shutdown. That is, the
question would be expressed as "Can an administrator have a reliable
UPS system ?" If an administrator is confident on his/her UPS system,
the administrator may select Sigres method. In summary, fsync=off is
ambiguous option, and Sigres can be used *IF* an administrator is
confident on his/her UPS system.
Opinion for Reason 2:
Right. I think it is easy to avoid the risk. Sigres should not be used
in default such as fsync=off. If my opinion lacks in common sense, I
Christopher Browne wrote:
[EMAIL PROTECTED] (Hideyuki Kawashima) wrote:
I appreciate your quick & informative reply. And, I also really
appreciate your kind comments. Since I have joined this ML 3 hours
ago, I tried to be polite and slightly nervous. But I was relieved
by your message.
Your idea sounds interesting; there is likely to be a considerable
resistance to mechanisms, however, that would be likely to make
PostgreSQL less robust.
Be aware, also, that in a public forum like this, people are sometimes
less gentle than Joshua.
The fundamental trouble with this mechanism is that a power outage can
instantly turn a database into crud.
One may try to mitigate that problem by supporting the memory device
with multiple power supplies *and* multiple UPSes.
But there is a not-inconsiderable risk that people will fail to read
warnings, deploy databases in a way that leaves them exposed to total
loss, and then lay blame at this community's feet. I'm sure you can
understand why the community might resist that...
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at