[BUGS] Bug on pg_lesslog
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 upload the new version ASAP. Warmest Regards; -- Koichi Suzuki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5322: Time to perform vacuums
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 be faster than doing it all in one shot. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5322: Time to perform vacuums
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 perform vacuums > Details: > > Hello, > I really don't know if it can be a bug or not, > but when I do a 'VACCUM FULL ANALYZE VERBOSE', > it can take a very long time (expecially on large tables), while doing this > sequence of 3 commands is > quite quicker (on my system at least). > > VACCUM VERBOSE > then > VACCUM FULL VERBOSE > then > VACCUM FULL ANALYZE VERBOSE > > I mean adding the 'three commands' times is less than the time for the > direct 'VACCUM FULL ANALYZE VERBOSE'. > > Does the fact of doing a 'simple' VACUUM first, make > other VACCUM more quick ? Does it finally does the same ? Is it only > coincidence due to system load ? > > Thanks for your comments about this... I can see VACUUM making VACUUM FULL faster. I don't think VACUUM FULL should make VACUUM FULL ANALYZE faster. It's a known problem that VACUUM FULL is really slow. CLUSTER is usually a better alternative; and in the next major release of PostgreSQL VACUUM FULL will switch over to using approximately the same method that CLUSTER now does. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] Bug on pg_lesslog
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 base backup of your database. > > I apologize for inconvenience. I'll upload the new version ASAP. Should this go out on announce? > > Warmest Regards; > > -- > Koichi Suzuki > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] [HACKERS] Bug on pg_lesslog
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. >> >> I strongly advise to take base backup of your database. >> >> I apologize for inconvenience. I'll upload the new version ASAP. >> > > Should this go out on announce? > I certainly think so. Anyone who gets caught "by surprise" on this could quite possibly lose all their data! I (fortunately) caught it during TESTING of my archives - before I needed them. -- Karl Denninger <> -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Bug on pg_lesslog
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 upload the new version ASAP. Warmest Regards; -- Koichi Suzuki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5314: Error in nested composite types in plpgsql.
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
explicit casts are documented to have different semantics:
http://www.postgresql.org/docs/current/static/sql-createcast.html
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5323: plperl and plperlu interaction segfaults
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 reliably segfaults Postgres for me: CREATE LANGUAGE 'plperl'; CREATE LANGUAGE 'plperlu'; CREATE OR REPLACE FUNCTION test_one() RETURNS TRIGGER AS $$ $$ language 'plperlu'; CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language 'plperl'; CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language 'plperl'; A possibly interesting note is that if I create "two, one, two two" it will not crash, but just 'one, two two" will. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5314: Error in nested composite types in plpgsql.
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 exec_assign_value: value = (Datum) 0; isnull = true; valtype = InvalidOid; The invalid datatype value doesn't matter in the scalar case, but if the target is a sub-row it fails the type_is_rowtype() sanity check in exec_assign_value. The cleanest fix would probably be to use the target variable's datatype here instead of InvalidOid. Alternatively, we could change exec_assign_value to not apply the sanity check unless the input is non-null. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5323: plperl and plperlu interaction segfaults
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 plperlu interaction segfaults > Details: > > Creating the following functions reliably segfaults Postgres for me: > > CREATE LANGUAGE 'plperl'; > CREATE LANGUAGE 'plperlu'; > CREATE OR REPLACE FUNCTION test_one() RETURNS TRIGGER AS $$ $$ language > 'plperlu'; > CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language > 'plperl'; > CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language > 'plperl'; > > A possibly interesting note is that if I create "two, one, two two" it will > not crash, but just 'one, two two" will. I think this might be the same problem previously discussed here: http://archives.postgresql.org/pgsql-bugs/2010-01/msg00224.php Does that patch fix it? ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5323: plperl and plperlu interaction segfaults
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 >> Operating system: Linux >> Description:plperl and plperlu interaction segfaults >> Details: >> >> Creating the following functions reliably segfaults Postgres for me: >> >> CREATE LANGUAGE 'plperl'; >> CREATE LANGUAGE 'plperlu'; >> CREATE OR REPLACE FUNCTION test_one() RETURNS TRIGGER AS $$ $$ language >> 'plperlu'; >> CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language >> 'plperl'; >> CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$ language >> 'plperl'; >> >> A possibly interesting note is that if I create "two, one, two two" it will >> not crash, but just 'one, two two" will. > > 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 of this post: http://archives.postgresql.org/pgsql-bugs/2010-01/msg00144.php > > Does that patch fix it? > The problem doesn't appear on 9.0 alpha with that patch committed. -- Alexey Klyukin http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5322: Time to perform vacuums
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 together I wouldn't expect to be faster than doing it all in one shot. ...Robert Thank you Robert for your comments. What seems to be a bug, could be a feature ? May be performing a simple VACUUM first before a real VACUUM FULL can be a solution to increase VACUUM FULL performances ? (I mean VACUUM FULL could be done in 2 sequences , first a simple VACUUM then a real VACUUM FULL). The time difference is sometime 1 for 10 ! But it should be confirmed on other platforms and OS ... Thanks anyway, I will stay with my three commands sequence, waiting for the new CLUSTER command... Postgreqlement . -- Salutations - Best regards - mit freundlichen Grüssen -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] [HACKERS] Bug on pg_lesslog
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 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 upload the new version ASAP. > > > Should this go out on announce? > > > I certainly think so. Anyone who gets caught "by surprise" on this could > quite possibly lose all their data! > > I (fortunately) caught it during TESTING of my archives - before I needed > them. > > -- Karl Denninger > > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [GENERAL] [HACKERS] Bug on pg_lesslog
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 each WAL record and whole WAL segment. -- Koichi Suzuki 2010/2/12 Koichi Suzuki : > 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 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 upload the new version ASAP. >> >> >> Should this go out on announce? >> >> >> I certainly think so. Anyone who gets caught "by surprise" on this could >> quite possibly lose all their data! >> >> I (fortunately) caught it during TESTING of my archives - before I needed >> them. >> >> -- Karl Denninger >> >> > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5323: plperl and plperlu interaction segfaults
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 of this post: > http://archives.postgresql.org/pgsql-bugs/2010-01/msg00144.php > >> Does that patch fix it? > The problem doesn't appear on 9.0 alpha with that patch committed. It looks like the plperl.c change applies cleanly back to 8.2, though I haven't yet verified that it actually fixes the problem on all those branches. 8.1 does nothing at all instead of decrementing the reference count: - /* need we delete old entry? */ + hash_search(plperl_proc_hash, internal_proname, + HASH_REMOVE, NULL); + if (prodesc->reference) + SvREFCNT_dec(prodesc->reference); + free(prodesc->proname); + free(prodesc); I am not inclined to apply the additional regression tests, even on HEAD. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5323: plperl and plperlu interaction segfaults
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'm getting on 8.4 is almost
>> identical to the one at the end of this post:
>> http://archives.postgresql.org/pgsql-bugs/2010-01/msg00144.php
>>
>>> Does that patch fix it?
>> The problem doesn't appear on 9.0 alpha with that patch committed.
>
> It looks like the plperl.c change applies cleanly back to 8.2, though
> I haven't yet verified that it actually fixes the problem on all those
> branches.
Ah. Well. So it turns out that this patch causes any branch other
than CVS HEAD to not compile, because select_perl_context() was only
added to the tree on January 26th. And on CVS HEAD, the OP's test
case doesn't crash.
CREATE LANGUAGE 'plperl';
CREATE LANGUAGE 'plperlu';
CREATE OR REPLACE FUNCTION test_one() RETURNS TRIGGER AS $$ $$
language 'plperlu';
CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$
language 'plperl';
CREATE OR REPLACE FUNCTION test_two() RETURNS TRIGGER AS $$ $$
language 'plperl';
Not sure where to go from here. The prerequisite patch ("Various
small improvements and cleanups for PL/Perl") is not suitable for
backpatching, so I think someone needs to prepare a cut-down patch
that addresses this issue in a more surgical fashion. Also, would
like to understand why the test case fails to fail on CVS HEAD.
...Robert
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5324: Server not starting
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 message is coming like "The service name is invalid net helpmsg 2185" I have installed the through One click installation and done successfully... Please reply ... I have tried by reinstalling also... By checking post connectivity and host Address also.. But no result Pls provide solution -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
