On Mon, May 18, 2015 at 1:00 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Mon, May 18, 2015 at 12:39 PM, Tom Lane wrote:
>
>> >> Uh, doesn't that change the translated strings? Is that a problem?
>> >
>> > Better an untranslated message than a translated one that lacks critical
>> > info
Robert Haas wrote:
> On Mon, May 18, 2015 at 12:39 PM, Tom Lane wrote:
> >> Uh, doesn't that change the translated strings? Is that a problem?
> >
> > Better an untranslated message than a translated one that lacks critical
> > info. But anyway, there are likely other instances of that same str
Robert Haas writes:
> On Mon, May 18, 2015 at 12:39 PM, Tom Lane wrote:
>> Better an untranslated message than a translated one that lacks critical
>> info. But anyway, there are likely other instances of that same string
>> *with* %m ...
> Probably not, because of the way the message is worded
On Mon, May 18, 2015 at 12:39 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Mon, May 18, 2015 at 12:15:03PM -0400, Tom Lane wrote:
>>> It's a trivial enough change that I wouldn't see a problem with doing it
>>> now. But if you do, please get it in by say 2PM EDT.
>
>> Uh, doesn't that chang
Bruce Momjian writes:
> On Mon, May 18, 2015 at 12:15:03PM -0400, Tom Lane wrote:
>> It's a trivial enough change that I wouldn't see a problem with doing it
>> now. But if you do, please get it in by say 2PM EDT.
> Uh, doesn't that change the translated strings? Is that a problem?
Better an u
On Mon, May 18, 2015 at 12:15:03PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 18, 2015 at 11:04 AM, Tom Lane wrote:
> >> Huh? All the ones that are reporting kernel call failures certainly
> >> have %m.
>
> > Oops, you're right. I was looking at the wrong code. Yeah, that
>
Robert Haas writes:
> On Mon, May 18, 2015 at 11:04 AM, Tom Lane wrote:
>> Huh? All the ones that are reporting kernel call failures certainly
>> have %m.
> Oops, you're right. I was looking at the wrong code. Yeah, that
> should probably be fixed. I'm not sure it's a good idea to do that
>
On Mon, May 18, 2015 at 11:04 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 17, 2015 at 9:44 PM, Peter Eisentraut wrote:
>>> If there a reason why in pre_sync_fname(), the error message does not
>>> contain a %m?
>
>> For consistency with the rest of the file, I suppose. Not sure why
Robert Haas writes:
> On Sun, May 17, 2015 at 9:44 PM, Peter Eisentraut wrote:
>> If there a reason why in pre_sync_fname(), the error message does not
>> contain a %m?
> For consistency with the rest of the file, I suppose. Not sure why
> it's like that, but all the functions in the file do it
On Sun, May 17, 2015 at 9:44 PM, Peter Eisentraut wrote:
> On 5/4/15 2:23 PM, Robert Haas wrote:
>> Recursively fsync() the data directory after a crash.
>>
>> Otherwise, if there's another crash, some writes from after the first
>> crash might make it to disk while writes from before the crash fa
On 5/4/15 2:23 PM, Robert Haas wrote:
> Recursively fsync() the data directory after a crash.
>
> Otherwise, if there's another crash, some writes from after the first
> crash might make it to disk while writes from before the crash fail
> to make it to disk. This could lead to data corruption.
On Mon, May 4, 2015 at 11:37 PM, Andrew Dunstan wrote:
> On 05/04/2015 02:23 PM, Robert Haas wrote:
>> Recursively fsync() the data directory after a crash.
>>
>> Otherwise, if there's another crash, some writes from after the first
>> crash might make it to disk while writes from before the crash
On 05/04/2015 02:23 PM, Robert Haas wrote:
Recursively fsync() the data directory after a crash.
Otherwise, if there's another crash, some writes from after the first
crash might make it to disk while writes from before the crash fail
to make it to disk. This could lead to data corruption.
Ba
Recursively fsync() the data directory after a crash.
Otherwise, if there's another crash, some writes from after the first
crash might make it to disk while writes from before the crash fail
to make it to disk. This could lead to data corruption.
Back-patch to all supported versions.
Abhijit M
Recursively fsync() the data directory after a crash.
Otherwise, if there's another crash, some writes from after the first
crash might make it to disk while writes from before the crash fail
to make it to disk. This could lead to data corruption.
Back-patch to all supported versions.
Abhijit M
Recursively fsync() the data directory after a crash.
Otherwise, if there's another crash, some writes from after the first
crash might make it to disk while writes from before the crash fail
to make it to disk. This could lead to data corruption.
Back-patch to all supported versions.
Abhijit M
Recursively fsync() the data directory after a crash.
Otherwise, if there's another crash, some writes from after the first
crash might make it to disk while writes from before the crash fail
to make it to disk. This could lead to data corruption.
Back-patch to all supported versions.
Abhijit M
Recursively fsync() the data directory after a crash.
Otherwise, if there's another crash, some writes from after the first
crash might make it to disk while writes from before the crash fail
to make it to disk. This could lead to data corruption.
Back-patch to all supported versions.
Abhijit M
Recursively fsync() the data directory after a crash.
Otherwise, if there's another crash, some writes from after the first
crash might make it to disk while writes from before the crash fail
to make it to disk. This could lead to data corruption.
Back-patch to all supported versions.
Abhijit M
19 matches
Mail list logo
