On Fri, 22 Jun 2007, Tom Lane wrote:
What's wrong with synchronous_commit? It's accurate and simple.
It's kind of a big word that not a lot of people understand the subtleties
of, and I'd be concerned it will sow confusion with the terminology used
for WAL synchronous writes.
When I expla
Richard Huxton wrote:
Bruce Momjian wrote:
Tom Lane wrote:
What's wrong with synchronous_commit? It's accurate and simple.
That is fine too.
My concern would be that it can be read two ways:
1. When you commit, sync (something or other - unspecified)
2. Synchronise commits (to each other?
Richard Huxton <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> What's wrong with synchronous_commit? It's accurate and simple.
> My concern would be that it can be read two ways:
> 1. When you commit, sync (something or other - unspecified)
> 2. Synchronise commits (to each other? to something
Bruce Momjian wrote:
Tom Lane wrote:
What's wrong with synchronous_commit? It's accurate and simple.
That is fine too.
My concern would be that it can be read two ways:
1. When you commit, sync (something or other - unspecified)
2. Synchronise commits (to each other? to something else?)*
I
On Jun 22, 2007, at 9:23 , Richard Huxton wrote:
Or perhaps "sync_on_commit = off"?
Or switch it around...
sink_on_commit = on
(sorry for the noise)
Michael Glaesemann
grzm seespotcode net
---(end of broadcast)---
TIP 5: don't forget to in
PFC wrote:
On Fri, 22 Jun 2007 16:43:00 +0200, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> untrustworthy disk hardware, for instance. I'd much rather
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Joshua D. Drake wrote:
> Hm, another possibility: "synchronous_commit = off"
>
> Ooo, I like that. Any other takers?
>
> >>> Yea, I like that too but I am now realizing that we are not really
> >>> deferring or delaying the
On Fri, 2007-06-22 at 10:52 -0400, Bruce Momjian wrote:
> commit_stability? reliable_commit?
commit_durability?
That then relates it directly to the D in ACID.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)--
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Joshua D. Drake wrote:
Hm, another possibility: "synchronous_commit = off"
Ooo, I like that. Any other takers?
>>> Yea, I like that too but I am now realizing that we are not really
>>> deferring or delaying the "COMMIT" command but rather the
On Fri, 22 Jun 2007 16:43:00 +0200, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
> > Tom Lane wrote:
> >
> >> untrustworthy disk hardware, for instance. I'd much rather use
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Simon Riggs wrote:
> >> On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> >>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >>>
> Tom Lane wrote:
>
> > untrustworthy disk hardware, for instance. I'd much rather use names
> >
Bruce Momjian wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
untrustworthy disk hardware, for instance. I'd much rather use names
derived from "deferred commit" or "delayed commit" or some such
Simon Riggs wrote:
> On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >
> > > Tom Lane wrote:
> > >
> > >> untrustworthy disk hardware, for instance. I'd much rather use names
> > >> derived from "deferred commit" or "delayed commit" or s
So now we're poking a hole in that but we certainly have to ensure that
any
transactions that do see the results of our deferred commit themselves
don't
record any visible effects until both their commit and ours hit WAL. The
essential point in Simon's approach that guarantees that is that w
Joshua D. Drake wrote:
I like "synchronous_commit = off", it even has a little girlfriend
getting spin while being accurate :)
In my experience, *_commit = off rarely gets you a girlfriend ...
cheers
andrew
---(end of broadcast)---
TIP 7:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Hm, another possibility: "synchronous_commit = off"
> Ooo, I like that. Any other takers?
OK with me
regards, tom lane
Joshua D. Drake wrote:
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
untrustworthy disk hardware, for instance. I'd much rather use names
derived from "deferred commit" or "delayed commit" or some su
Simon Riggs wrote:
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
untrustworthy disk hardware, for instance. I'd much rather use names
derived from "deferred commit" or "delayed commit" or some such.
Honestly, I prefer
On Fri, 2007-06-22 at 14:29 +0100, Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
> > Tom Lane wrote:
> >
> >> untrustworthy disk hardware, for instance. I'd much rather use names
> >> derived from "deferred commit" or "delayed commit" or some such.
> >
> > Honestly, I pre
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
>> untrustworthy disk hardware, for instance. I'd much rather use names
>> derived from "deferred commit" or "delayed commit" or some such.
>
> Honestly, I prefer these names as well as it seems directly related versus
> transactio
Tom Lane wrote:
I've been reflecting a bit about whether the notion of deferred fsync
for transaction commits is really safe. The proposed patch tries to
ensure that no consequences of a committed transaction can reach disk
before the commit WAL record is fsync'd, but ISTM there are potential
ho
"Tom Lane" <[EMAIL PROTECTED]> writes:
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I've been reflecting a bit about whether the notion of deferred fsync
> for transaction commits is really safe. The proposed patch tries to
> ensure that no consequences of a committed transaction can reach disk
> be
On Thu, 2007-06-21 at 18:15 -0400, Tom Lane wrote:
> I've been reflecting a bit about whether the notion of deferred fsync
> for transaction commits is really safe. The proposed patch tries to
> ensure that no consequences of a committed transaction can reach disk
> before the commit WAL record is
On Thu, 2007-06-21 at 18:15 -0400, Tom Lane wrote:
> BTW: I really dislike the name "transaction guarantee" for the
> feature; it sounds like marketing-speak, not to mention overpromising
> what we can deliver.
There is no marketing speak there, nor any overpromising of what is
delivered. I real
I've been reflecting a bit about whether the notion of deferred fsync
for transaction commits is really safe. The proposed patch tries to
ensure that no consequences of a committed transaction can reach disk
before the commit WAL record is fsync'd, but ISTM there are potential
holes in what it's d
25 matches
Mail list logo
