Tom and all,
I apologize destroying the thread information with this topic.
Unfortunately my basic smtp server does not work now and I am writing
all the responses via gmail tonight...
Thanks for teaching me about the development assumption of PostgreSQL.
The assumption and my direction are different since the assumption
considers only disk drive as persistent device while my assumption is
Honestly speaking, I am not sure whether there is a person who accepts
my assumption (i.e. battery-supplied memory as persistent device) or
not. And I am not sure whether my approach can be integrated into
PostgreSQL since some accept and some reject. So, anyway I will write
a patch and submit. Then I leave to this community the decision of
accept/reject. If someone has interest on Sigres, please download it
from http://sourceforge.jp/projects/sigres/ and try it. I will
continue to accelerate Sigres more anyway under my assumption. Since I
believe "time always wins in transaction processing" as Jim Gray told
last June in ACM SIGMOD 2006 keynote talk, I wish UPS will be reliable
or nice non volatile memories such as MRAM will appear in the near
Finally, this discussion was really beneficial for me. I would like to
say thank you for everyone who gave me great information. Thank you
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I'd like to see a clear explanation of what assumptions are being made
and why they represent a useful case.
Absolutely agreed there.
Just to be clear: I believe our current assumptions can be stated as
"Postgres will not lose data if the kernel and disk drive do not lose
data that they have acknowledged as being successfully fsync'd."
This is independent of any questions about Postgres bugs or measures
that we take to limit the impact of our bugs --- it's about what our
extent of responsibility is. I think that Hideyuki-san is proposing
a different contract for data integrity, and I want to understand what
that contract is and why someone would want it.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not