On Mon, Aug 22, 2016 at 1:31 PM, John R Pierce wrote:
> On 8/21/2016 9:13 PM, Tatsuki Kadomoto wrote:
>>
>> Can we point out a specific bug that can lead to this?
>
>
> 9.2.6 fixed several data corruption bugs,
> https://www.postgresql.org/docs/current/static/release-9-2-6.html
>
> 9.2.9 fixed a G
On 8/21/2016 9:13 PM, Tatsuki Kadomoto wrote:
Can we point out a specific bug that can lead to this?
9.2.6 fixed several data corruption bugs,
https://www.postgresql.org/docs/current/static/release-9-2-6.html
9.2.9 fixed a GiST index corruption problem...
https://www.postgresql.org/docs/cur
John, Michael,
Thanks. The server is Dell PowerEdge R720.
The checksum error only was reported only once so I guess it was automatically
fixed immediately.
The log was output only one time while the box was running very long time (> 1
year.).
I have hundreds of the machines with same confi
On 8/21/2016 8:37 PM, Michael Paquier wrote:
PosgreSQL version is 9.2.4.
You are missing a couple of years worth of bug fixes here..
3+ years, to be more specific, 9.2.4 was released in april 2013.
indeed, and several of the bug fixes involved data corruption. current
is 9.2.18
--
john r
On Mon, Aug 22, 2016 at 12:27 PM, Tatsuki Kadomoto
wrote:
> I see incorrect checksum detected on "global/pg_filenode.map" when "VACUUM
> FULL" is executed.
>
> The error message didn't repeat. It showed up only once.
>
> Is this expected? Can someone give me a plausible scenario why this
> happene
On 8/21/2016 8:27 PM, Tatsuki Kadomoto wrote:
I see incorrect checksum detected on "global/pg_filenode.map" when
"VACUUM FULL" is executed.
The error message didn't repeat. It showed up only once.
Is this expected? Can someone give me a plausible scenario why this
happened?
Aug 16 20:51
Hello,
I see incorrect checksum detected on "global/pg_filenode.map" when "VACUUM
FULL" is executed.
The error message didn't repeat. It showed up only once.
Is this expected? Can someone give me a plausible scenario why this happened?
Aug 16 20:51:19 postgres[22329]: [2-1] FATAL: relation
On Sun, Aug 21, 2016 at 14:24:16 -0400,
Tom Lane wrote:
Unfortunately, these particular characters are U+2013 and U+2014 so you
lose.
Thanks for saving me some time, as it would have taken me quite a while
to figure that out.
I'll adjust the constraint so that good strings aren't rejected
Bruno Wolff III writes:
> However I am wondering about my use of [[:graph:]] to match characters
> that have glyphs. I was not expecting there to be characters that have
> glyphs to not be in the graph class. In the short term I might want to
> change the way I am testing that.
[ looks into co
On Sun, Aug 21, 2016 at 12:30:21 -0500,
Bruno Wolff III wrote:
I should also try the equivalent test in perl to see if it is more
likely tied to the unicode implementation on my system or if it
appears to be Postgres specific.
It looks like my locale may not be being set the way I expect.
On Sun, Aug 21, 2016 at 08:12:23 +1000,
rob stone wrote:
You can't use — (emdash) or – (endash)?
Or their hex equivalents. See the Unicode chart.
By the way, those aren't the correct codes. That only works if your
code treats iso-5589-1 code points as windows 1252 code points. That
may hap
On Sun, Aug 21, 2016 at 08:12:23 +1000,
rob stone wrote:
You can't use — (emdash) or – (endash)?
Or their hex equivalents. See the Unicode chart.
I am not the source of the data, but I can special case them one way
or the other.
However I am wondering about my use of [[:graph:]] to match
12 matches
Mail list logo
