Re: [BUGS] BUG #5393: Installer sets superuser password if passwords don't match
[Removing Rens] On Thu, Apr 8, 2010 at 10:19 PM, Robert Haas wrote: > It would certainly be nice if we could just have all bugs reported > here and sort it out ourselves, but in practice that doesn't seem to > work. When installer or pgadmin bugs are reported here, they > typically don't get a response. That's because typically before anyone can even draw a breath someone has jumped on the user and they've re-posted into the more appropriate forum. In the case of both installers and pgAdmin though, I can say with absolute certainty that there are at least 3 developers from each that read this list daily - we just happen to all be East-pondians so don't always respond in the timeframe that you might. > Or to put it another way, if someone had written back any time in the > 13 days between when this email was posted and today and said "thanks > for the report - will look into it", I wouldn't have replied. No idea what happened to the original message in this thread - the first I saw was your response. In any case - I stand by my comments. For projects that are closely affiliated with PostgreSQL we should not be chastising users for reporting bugs here, we should make it easy, not difficult, embarrassing and annoying for users to give feedback. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- 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] bugs that have not been replied-to on list
On Thu, Apr 8, 2010 at 10:23 PM, Robert Haas wrote: > BUG #5287: ispell dict erroneously returns lexeme on all prefix+suffix > cross products > BUG #5300: Bug on Mac OS X 10.6 and Postgres 8.4 > BUG #5316: not handled error in inherit queries > BUG #5335: GUC value lost on exception > BUG #4785: Installation fails I responded to that one: http://archives.postgresql.org/pgsql-bugs/2009-05/msg2.php > BUG #5337: PostgreSQL install fails with 1603 error That's a PG 8.2/MSI issue, which is why none of the EDB guys responded. My own excuse is that I'm not the only guy that worked on the MSI installer, and I simply don't have time to respond to every problem reported. > BUG #4806: Bug with GiST index and empty integer array? > BUG #4769: xmlconcat produces invalid xml values -> data corruption > BUG #5379: Adding hunspell-ko dictionary for full-text search doesn't work > BUG #5405: Consol and utf8 This basically indicates that we need an issue tracker. There, look - now see what you made me do :-( -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- 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 #5411: \copy do not work with dot "." in query
The following bug has been logged online: Bug reference: 5411 Logged by: Vitalii Tymchyshyn Email address: tiv...@gmail.com PostgreSQL version: 8.4.3 Operating system: OpenSuse 11.2: Linux tivv 2.6.31.12-0.1-default #1 SMP 2010-01-27 08:20:11 +0100 x86_64 x86_64 x86_64 GNU/Linux Description:\copy do not work with dot "." in query Details: dict=> \copy (select 1.0) to test.tst ERROR: syntax error at or near "." LINE 1: COPY ( select 1 . 0 ) TO STDOUT ^ \copy: ERROR: syntax error at or near "." LINE 1: COPY ( select 1 . 0 ) TO STDOUT ^ Workaround: \copy (select 1::float8) to test.tst works OK. -- 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] bugs that have not been replied-to on list
On Fri, Apr 9, 2010 at 4:43 AM, Dave Page wrote: > On Thu, Apr 8, 2010 at 10:23 PM, Robert Haas wrote: > >> BUG #5287: ispell dict erroneously returns lexeme on all prefix+suffix >> cross products >> BUG #5300: Bug on Mac OS X 10.6 and Postgres 8.4 >> BUG #5316: not handled error in inherit queries >> BUG #5335: GUC value lost on exception >> BUG #4785: Installation fails > > I responded to that one: > http://archives.postgresql.org/pgsql-bugs/2009-05/msg2.php ! I never got that email message. Something is wrong with this mailing list. In the case of the email that started this discussion, you never saw the original email message, and in this case, I never saw your reply. That's bad. >> BUG #5337: PostgreSQL install fails with 1603 error > > That's a PG 8.2/MSI issue, which is why none of the EDB guys > responded. My own excuse is that I'm not the only guy that worked on > the MSI installer, and I simply don't have time to respond to every > problem reported. > >> BUG #4806: Bug with GiST index and empty integer array? >> BUG #4769: xmlconcat produces invalid xml values -> data corruption >> BUG #5379: Adding hunspell-ko dictionary for full-text search doesn't work >> BUG #5405: Consol and utf8 > > This basically indicates that we need an issue tracker. There, look - > now see what you made me do :-( You know, I never really thought we did before, but I had the same thought last night. One of the problems with "don't worry about what product it is, just post here" is that it only works if people from all of those products regularly monitor this list, which in turn requires them to skip over the issues with all the other products that they don't know or care about. An actual bug-tracking system would let us classify bugs by product, which would in theory help with this problem. Even consider ecpg. It's part of core PostgreSQL, so undeniably on topic for this list, but it's asking a lot for Michael Meskes to read everything that goes by on this list just to catch the 2 or 3 ecpg problems that get reported each year. Of course, if the people working on those projects don't monitor the bug-tracking system, then we'll have the same problem with non-response that we do today - maybe worse, since at least now we can refer people who don't get an answer to another forum. Another problem is that any solution we picked would have to be acceptable to the people who do actively monitor this list. It would be bad if changing to a different system resulted in bugs getting less attention. But practically speaking, I'd guess there's less than 20 people who respond to most of the traffic on -bugs, so if we find a solution that those people like, we'd be better off. We'd also have fewer problems with things slipping through the cracks. Things might still get ignored, but at least the system would be keeping track of that instead of Bruce and I. Momjzilla/Haaszilla has a catchy ring to it but it's not a very efficient way to run a project. ...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 #5412: Crash in production SIGSEGV, equalTupleDescs (tupdesc1=0x7f7f7f7f, tupdesc2=0x966508c4) at tupdesc.c
The following bug has been logged online:
Bug reference: 5412
Logged by: Rusty Conover
Email address: rcono...@infogears.com
PostgreSQL version: 8.4.3
Operating system: Fedora Core 10, 2.6.27.30-170.2.82.fc10.i686.PAE
Description:Crash in production SIGSEGV, equalTupleDescs
(tupdesc1=0x7f7f7f7f, tupdesc2=0x966508c4) at tupdesc.c
Details:
Hi,
8.4.3 is crashing for me under load, below is the stack trace:
#0 equalTupleDescs (tupdesc1=0x7f7f7f7f, tupdesc2=0x966508c4) at
tupdesc.c:311
#1 0x0832451b in RelationClearRelation (relation=0x96654178, rebuild=) at relcache.c:1901
#2 0x08324b9f in RelationFlushRelation () at relcache.c:1991
#3 RelationCacheInvalidateEntry (relationId=322615) at relcache.c:2042
#4 0x0831dd89 in LocalExecuteInvalidationMessage (msg=0xa218b54) at
inval.c:510
#5 0x0831d341 in ProcessInvalidationMessages (hdr=0xa2010c4, func=0x831dc50
) at inval.c:397
#6 0x0831d3dc in CommandEndInvalidationMessages () at inval.c:1006
#7 0x080c9035 in AtCommit_LocalCache () at xact.c:1009
#8 CommandCounterIncrement () at xact.c:634
#9 0x0826dcc9 in finish_xact_command () at postgres.c:2363
#10 0x0826ed4d in exec_simple_query (
query_string=0xa1e88d4 "insert into product_refer_urls (item_id,
destination_url) select product_info.oid, product_info_static.affiliate_url
from real_products, product_parts, product_info left join
product_info_static on ("...) at postgres.c:1022
#11 0x0827042c in PostgresMain (argc=4, argv=0xa17c5d0, username=0xa17c590
"gb") at postgres.c:3614
#12 0x0823a4d3 in BackendRun () at postmaster.c:3449
#13 BackendStartup () at postmaster.c:3063
#14 ServerLoop () at postmaster.c:1387
#15 0x0823b503 in PostmasterMain (argc=4, argv=0xa179678) at
postmaster.c:1040
#16 0x081dc0a6 in main (argc=4, argv=0xa179678) at main.c:188
The bug is reproducible, I'm not sure how to proceed. Here is the output
from the log:
LOG: server process (PID 8886) was terminated by signal 11: Segmentation
fault
LOG: terminating any other active server processes
WARNING: terminating connection because of crash of another server process
I have been seeing these messages:
LOG: autovacuum: found orphan temp table "pg_temp_7"."found_sizes" in
database "gb_render_footwear_db"
LOG: autovacuum: found orphan temp table "pg_temp_7"."classification_tree"
in database "gb_render_footwear_db"
Could they be the result of previous crashes? Any help is greatly
appreciated.
All of this code ran perfectly under 8.3.
Thanks,
Rusty
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] About “context-switching issue on Xeon” te st case ？
Hi， Anybody have the test of “context-switching issue on Xeon” from Tm lane ？ Best regards, Ray Huang
[BUGS] initdb stores default client_encoding from environment-variable
initdb stores default client_encoding from environment-variable Postgres Version: 8.4.3 and 8.3.6 Operating System: Sun Solaris 5.10 and SuseEnterprise 9 When a database is initialized with the initdb-command, the default client_enconding, which will be stored in the DB, depends on the value of the environment-variable PGCLIENTENCODING at the time of running initdb. This behaviour is not documented. Furthermore I didn't find a command to change this default client_encoding in the database later. The default client_encoding does not depend on the database encoding! This is a small shell-script to show this behaviour. #!/bin/bash -x # PGHOST="localhost" PGPORT=7654 PGDATABASE=postgres PGUSER=postgres export PGHOST PGPORT PGDATABASE PGUSER export LD_LIBRARY_PATH=/usr/local/pgsql/lib binpath=/usr/local/pgsql/bin dir=/data/DB-2 $binpath/pg_ctl stop -D $dir/pg-base -m fast -o '-p 7654' # # remove Database # rm -r $dir/pg-base 2> /dev/null sleep 1 mkdir $dir/pg-base 2> /dev/null PGCLIENTENCODING="WIN1250" export PGCLIENTENCODING $binpath/initdb --encoding=UTF8 -D $dir/pg-base $binpath/pg_ctl start -D $dir/pg-base -l $dir/pg-server.log -o '-p 7654' sleep 5 unset PGCLIENTENCODING # IMPORTANT !! $binpath/psql -c "select version();" $binpath/psql -c "show client_encoding;" -- 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] bugs that have not been replied-to on list
On Apr 9, 2010, at 5:08 AM, Robert Haas wrote: > Something is wrong with this > mailing list. In the week and a half that I've been subscribed to this mailing list, there have been several times that I received a reply to a message without receiving the original message. In most cases, I received the original message a few minutes to a few hours later. I haven't watched other people's issues closely enough to tell if I'm missing any messages completely. But I can see why people need to use such long Cc: lists on their posts. -- 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] bugs that have not been replied-to on list
Andy Balholm wrote: > On Apr 9, 2010, at 5:08 AM, Robert Haas wrote: > >> Something is wrong with this mailing list. > > In the week and a half that I've been subscribed to this mailing > list, there have been several times that I received a reply to a > message without receiving the original message. In most cases, I > received the original message a few minutes to a few hours later. I've seen that sometimes, too. It's usually preceded by an eerie "calm" without many (or any) messages. I don't know whether the bottleneck is on our end (the emails go through many anti-spam filters before they reach me, and I know they sometimes fall behind). The other issue which has caused me to see replies to messages I missed is that some of the posters here are going through SMTP servers on networks segments which have been blacklisted as sources of spam. Since I have things configured to not send me duplicates when the post is to me and a list (or to multiple lists), if a blacklisted user copies me directly I don't get anything. When I identify such a user I let them know and get them whitelisted on my end, but that's hit or miss. -Kevin -- 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 #5412: Crash in production SIGSEGV, equalTupleDescs (tupdesc1=0x7f7f7f7f, tupdesc2=0x966508c4) at tupdesc.c
Rusty Conover wrote: > The bug is reproducible, I'm not sure how to proceed. How do you reproduce it? Can you make a self-contained test case? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- 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] pgadmin supports on SLES10.3
Please keep the list copied, so others can contribute, know the status, and future users with problems can find the resolution of the issue. manohar cr wrote: > i have SuSe Linux Enterprise Server(SLES) 10 SP 3 > > my question is.. does pgadmin works on this version??. I was going to try it out to see, but there's no package for it showing in YAST, and I don't really know how you're attempting to install or what version. I would expect it to work, though. > if yess.. i will try to fix the error which is showing.. Sure, go for it. If it still doesn't work, please re-post with the details of where you got the software, what version it is, exactly how you're trying to apply it, and what the error message is. (Without any of that, it's hard to know what to suggest.) -Kevin -- 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 #5411: \copy do not work with dot "." in query
"Vitalii Tymchyshyn" writes: > dict=> \copy (select 1.0) to test.tst > ERROR: syntax error at or near "." > LINE 1: COPY ( select 1 . 0 ) TO STDOUT > ^ This case works as expected in CVS HEAD, apparently because of this fix: http://archives.postgresql.org/pgsql-committers/2009-09/msg00184.php I doubt we'd risk backpatching the whole change, but maybe it would be sensible to backpatch just the changes in the COPY (SELECT) part (lines 119-137 in HEAD). Not sure that it's worth taking any risk for, though, given the lack of previous complaints. 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
