Has this been addressed?
---
Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of vie oct 29 13:23:39 -0300 2010:
> > On Tue, Oct 12, 2010 at 2:25 PM, Alvaro Herrera
> > wrote:
> > > Excerpts from Richard Evans's
Teodor, would you please comment on this bug after reading the entire
thread which includes comments from other developers?
http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php
Thanks.
---
Andreas Karlsso
Solved.
Changing the field datatype from TIMESTAMP to TIMESTAMPTZ fixed it. Now I
can use now() as the default value.
Strange that it just cropped up recently, but you're right we should be
including time zone with that timestamp anyways.
My deep gratitude for your time and help!
JB
-Ori
Hi,
Do you still have the WAL files?
what do you mean exactly? We don't have full history of WAL files from
creation of hot streaming standby. They are recycled. We have set of WAL
files from the point we discovered the corrupted index and stopped the
cluster. But it was probably days after
On Fri, Feb 25, 2011 at 9:48 AM, Merlin Moncure wrote:
> On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera
> wrote:
>> Excerpts from Merlin Moncure's message of vie feb 25 12:28:25 -0300 2011:
>>
>>> no I wouldn't, and the pg_dump extra_float_digits setting addresses my
>>> primary concern. The cl
"Jonathan Brinkman" wrote:
> ## I COULDN'T MAKE IT BREAK USING PSQL.
That's pretty solid evidence that the problem isn't in the
PostgreSQL server.
> This didn't always happen, it just started happening on various of
> my tables a maybe couple weeks or so ago. I think it is related to
> an up
Excerpts from Ross Barrett's message of jue feb 24 13:36:34 -0300 2011:
>
> The following bug has been logged online:
>
> Bug reference: 5899
> Logged by: Ross Barrett
> Email address: ross_barr...@rapid7.com
> PostgreSQL version: 9.0.3
> Operating system: Ubuntu 9.10
> Descr
Excerpts from Jakub Ouhrabka's message of vie feb 25 08:20:33 -0300 2011:
> For details about corrupted index see below. The table and index in
> question are mostly read-only (several queries per second) writes happen
> only few times a day.
>
> We've backed up whole cluster and recreated it.
On Fri, Feb 25, 2011 at 9:40 AM, Alvaro Herrera
wrote:
> Excerpts from Merlin Moncure's message of vie feb 25 12:28:25 -0300 2011:
>
>> no I wouldn't, and the pg_dump extra_float_digits setting addresses my
>> primary concern. The client has a similar issue though -- suppose it
>> fetches a value
Excerpts from Merlin Moncure's message of vie feb 25 12:28:25 -0300 2011:
> no I wouldn't, and the pg_dump extra_float_digits setting addresses my
> primary concern. The client has a similar issue though -- suppose it
> fetches a value from the server and updates it back -- which record
> gets th
"Sergey Aleynikov" writes:
> PostgreSQL version: 8.4.1
> Yesterday i've got a non-repeatable database server crash with following
> messages in server log:
> [ crash is within auto_explain according to backtrace ]
I think most likely you got bit by this known bug:
commit 85a646aee39b97b68bd7095
On Fri, Feb 25, 2011 at 9:21 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> right -- in understand how floating point works -- but are you are
>> saying that you are ok with the fact that (for example) a table with a
>> floating point unique key could dump and not restore? more
>> specifically,
Merlin Moncure writes:
> right -- in understand how floating point works -- but are you are
> saying that you are ok with the fact that (for example) a table with a
> floating point unique key could dump and not restore? more
> specifically, a binary dump would restore but a text dump would not.
On Thu, Feb 24, 2011 at 8:03 PM, Greg Stark wrote:
> On Thu, Feb 24, 2011 at 7:31 PM, Merlin Moncure wrote:
>> the root issue I think here is that the string version of the double
>> precision math is approximated:
>
> No, it's simpler than that, all double precision math is approximated.
> The r
The following bug has been logged online:
Bug reference: 5900
Logged by: Sergey Aleynikov
Email address: sergey.aleyni...@gmail.com
PostgreSQL version: 8.4.1
Operating system: FreeBSD 7.3-STABLE amd64
Description:Coredump on executing query
Details:
I've a setup wit
Hi,
we've found that we have corrupted index on 9.0.3 streaming hot standby.
Master works ok. There is one more non-streaming standby which is ok as
well. Platform is 64bit Linux.
Database cluster and this database were created on 9.0.2 and than
upgraded to 9.0.3. We are not aware of any cra
16 matches
Mail list logo