The following bug has been logged online:
Bug reference: 5324
Logged by: sourabh bansal
Email address: sourabh.k.ban...@gmail.com
PostgreSQL version: 8.4
Operating system: windows XP SP2
Description:Server not starting
Details:
While Starting Server the Error messag
On Thu, Feb 11, 2010 at 10:47 PM, Robert Haas wrote:
> On Thu, Feb 11, 2010 at 3:12 PM, Alexey Klyukin
> wrote:
>>> I think this might be the same problem previously discussed here:
>>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00224.php
>>
>> Seems to be the same problem. Backtrace I
On Thu, Feb 11, 2010 at 3:12 PM, Alexey Klyukin wrote:
>> I think this might be the same problem previously discussed here:
>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00224.php
>
> Seems to be the same problem. Backtrace I'm getting on 8.4 is almost
> identical to the one at the end
In addition, in the fix, I'm thinking I should add at least the
following check mechanism;
1. Check XNOOP record size to match the original WAL record.
2. Restore WAL segment at the time of pg_compress, compare restored
WAL with the original and check it is safe to use in the restoration,
both eac
Thank you very much for the advice. Yes I think it should go to
announce. I will post a message.
--
Koichi Suzuki
2010/2/12 Karl Denninger :
> Joshua D. Drake wrote:
>
> On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote:
>
>
> Dear Folks;
>
> A very serious bug was reported on p
Robert Haas a écrit :
On Thu, Feb 11, 2010 at 11:25 AM, Robert Haas wrote:
I can see VACUUM making VACUUM FULL faster. I don't think VACUUM FULL
should make VACUUM FULL ANALYZE faster.
Err, let me correct myself. A second VACUUM FULL should be faster
than the first one. But the two togethe
On Feb 11, 2010, at 10:02 PM, Robert Haas wrote:
> On Thu, Feb 11, 2010 at 1:44 PM, Dave Olszewski wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: 5323
>> Logged by: Dave Olszewski
>> Email address: cx...@pobox.com
>> PostgreSQL version: 8.3.9
>>
On Thu, Feb 11, 2010 at 1:44 PM, Dave Olszewski wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5323
> Logged by: Dave Olszewski
> Email address: cx...@pobox.com
> PostgreSQL version: 8.3.9
> Operating system: Linux
> Description: plperl and plpe
Robert Haas writes:
> 2010/2/10 Oleg Serov :
>> Somebody will fix this bug or not?
> I'm not sure whether this is a bug.
Yeah, I think it is. The problem is that exec_move_row is taking too
many shortcuts with nulls. If the input record is short of fields it
is willing to pass this data to exe
The following bug has been logged online:
Bug reference: 5323
Logged by: Dave Olszewski
Email address: cx...@pobox.com
PostgreSQL version: 8.3.9
Operating system: Linux
Description:plperl and plperlu interaction segfaults
Details:
Creating the following functions re
2010/2/10 Oleg Serov :
> Somebody will fix this bug or not?
I'm not sure whether this is a bug. This is an explicit cast:
SELECT '(1,)'::bug_level_one;
But I think this is an implicit cast:
SELECT bug_procedure('(1,)');
I'm not totally sure of the details, but implicit, assignment, and
explic
Dear Folks;
A very serious bug was reported on pg_lesslog. So far, I found it's
a bug in pg_compresslog. Please do not use pg_compresslog and
pg_decompresslog until improved version is uploaded.
I strongly advise to take base backup of your database.
I apologize for inconvenience. I'll upl
Joshua D. Drake wrote:
> On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote:
>
>> Dear Folks;
>>
>> A very serious bug was reported on pg_lesslog. So far, I found it's
>> a bug in pg_compresslog. Please do not use pg_compresslog and
>> pg_decompresslog until improved version is uploaded.
On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote:
> Dear Folks;
>
> A very serious bug was reported on pg_lesslog. So far, I found it's
> a bug in pg_compresslog. Please do not use pg_compresslog and
> pg_decompresslog until improved version is uploaded.
>
> I strongly advise to take ba
On Wed, Feb 10, 2010 at 8:56 AM, Eric Pailleau wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5322
> Logged by: Eric Pailleau
> Email address: e...@numlog.fr
> PostgreSQL version: 8.2.3
> Operating system: linux debian
> Description: Time to per
On Thu, Feb 11, 2010 at 11:25 AM, Robert Haas wrote:
> I can see VACUUM making VACUUM FULL faster. I don't think VACUUM FULL
> should make VACUUM FULL ANALYZE faster.
Err, let me correct myself. A second VACUUM FULL should be faster
than the first one. But the two together I wouldn't expect to
Dear Folks;
A very serious bug was reported on pg_lesslog. So far, I found it's
a bug in pg_compresslog. Please do not use pg_compresslog and
pg_decompresslog until improved version is uploaded.
I strongly advise to take base backup of your database.
I apologize for inconvenience. I'll upl
17 matches
Mail list logo
