Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Not having looked at md.c (I confess...) but don't we have a problem in
>> case we have closed the file without fsyncing it, and then change the
>> fsync parameter?
>
> Well, we don't promise to retroactively fsync stuff we didn't be
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Not having looked at md.c (I confess...) but don't we have a problem in
> case we have closed the file without fsyncing it, and then change the
> fsync parameter?
Well, we don't promise to retroactively fsync stuff we didn't before;
and I wouldn't expe
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Or are you talking about changing the variable "fsync"? If so, doesn't
>> "fsync=off" also change the behavior of other parts of the code, so it's
>> not just WAL, which means it'd be pretty unsafe *anyway* unless you
>> actually "syn
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Or are you talking about changing the variable "fsync"? If so, doesn't
> "fsync=off" also change the behavior of other parts of the code, so it's
> not just WAL, which means it'd be pretty unsafe *anyway* unless you
> actually "sync" the disks, and not
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Hmm ... or at least more or less fixed. Seems like there's no provision
>>> to close and reopen the file if enableFsync changes. Not sure if that's
>>> worth worrying about.
>
>> We didn't have that before eithe
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmm ... or at least more or less fixed. Seems like there's no provision
>> to close and reopen the file if enableFsync changes. Not sure if that's
>> worth worrying about.
> We didn't have that before either, did we?
No, so I thin
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> No, my point was that there are three possible states of sync_bit and
>>> your patch only accounted for transitions between two of 'em.
>
>> Did this every get addressed? I don't see a commit for it.
>
> I thought
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> No, my point was that there are three possible states of sync_bit and
>> your patch only accounted for transitions between two of 'em.
> Did this every get addressed? I don't see a commit for it.
I thought it got fixed here:
2008-05
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > Right, but I still need the other part of the check, right? This one
> > still fails the same check as my patch, no? Because I assume the hole
> > you found there was that get_sync_bit() will return 0 for two different
> > sync metho
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Right, but I still need the other part of the check, right? This one
> still fails the same check as my patch, no? Because I assume the hole
> you found there was that get_sync_bit() will return 0 for two different
> sync methods as long as none of them
Tom Lane wrote:
> I wrote:
> > Okay, but you failed to correctly reproduce the conditions for
> > closing the old file.
>
> A more bulletproof solution might involve passing sync_method to
> get_sync_bit as an explicit parameter, and then the assign hook
> could do
> if (get_sync_bit(sync_me
I wrote:
> Okay, but you failed to correctly reproduce the conditions for closing
> the old file.
A more bulletproof solution might involve passing sync_method to
get_sync_bit as an explicit parameter, and then the assign hook
could do
if (get_sync_bit(sync_method) != get_sync_bit(new_sync
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Since it didn't really sound like a nice option, here's a third one I
> came up with later. Basically, this one splits things apart so we only
> use one variable, which is sync_method. Instead of using a macro to get
> the open sync bit, it uses a fu
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
I still think going with the older method would be the safest, though,
for the other reasons. You agree?
Seems reasonable to me.
Since it didn't really sound like a nice option, here's a third one I
came up with later. Basically, t
Magnus Hagander <[EMAIL PROTECTED]> writes:
> I still think going with the older method would be the safest, though,
> for the other reasons. You agree?
Seems reasonable to me.
> (I assume you mean GUC enum here, that seems fairly obvious)
Sorry, was writing in too much of a hurry.
> In these,
Tom Lane wrote:
> I see that assign_xlog_sync_method() is still assigning to
> sync_method. This is 100% wrong: an assign hook is chartered to set
> derived values, but not to set the GUC variable itself. This will
> for example result in set_config_option() stacking the wrong value
> (the already
I see that assign_xlog_sync_method() is still assigning to sync_method.
This is 100% wrong: an assign hook is chartered to set derived values,
but not to set the GUC variable itself. This will for example result
in set_config_option() stacking the wrong value (the already-updated
one) as the value
17 matches
Mail list logo
