Re: Acclerating INSERT/UPDATE using UPS - Mailing list pgsql-hackers

Christopher,

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
read warnings

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
be used.
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
am sorry.

Regards,

-- Hideyuki

Christopher Browne wrote:
> kawasima@cs.tsukuba.ac.jp (Hideyuki Kawashima) wrote:
>
>> Joshua,
>>
>> 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...
>