Re: [BUGS] ecpg mapping struct members for indicators incorrectly?
On Thu, Feb 19, 2004 at 11:57:33AM -0800, Shelby Cain wrote: > I'm coming from a Pro*C background so I'm not entirely > certain whether what I am attempting is simply not > allowed in ecpg or not. Well it should be. :-) Thanks for reporting the bug. I just committed a fix to HEAD and REL7_4_STABLE so it should be in 7.4.2. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] whitespaces and upper()
"Flavio Casadei D. C." <[EMAIL PROTECTED]> writes: > create table foo ( > id integer not null primary key, > name char(6) not null, > value varchar(255) > ); > insert into foo values (1,'FLAVIO','hi!'); > insert into foo values (2,'FLA ' ,'hi!'); > insert into foo values (3,' ','hi!'); > insert into foo values (4,' d ','hi!'); > test=> SELECT * from foo ; > id | name | value > ++--- >1 | FLAVIO | hi! >2 | FLA| hi! >3 || hi! >4 |d | hi! > (4 righe) > test=> SELECT * from foo where upper(name) like '% '; > id | name | value > +--+--- > (0 righe) This is because upper() takes a text argument, and as of 7.4 char(N) to text conversion discards trailing spaces. I believe this behavior is correct on balance: if you think that trailing spaces are significant data, you ought to be storing the column as varchar or text, not char. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1161: User permissions are kept, even if user is dropped
The following bug has been logged online: Bug reference: 1161 Logged by: Martin Email address: [EMAIL PROTECTED] PostgreSQL version: 7.4 Operating system: Linux Description:User permissions are kept, even if user is dropped Details: Hi, dropping and creating a user will keep the *old* permission on objects: The following statements will grant access to the user foe: create user friend; create table secret (passwd char(30)); grant all on secret to friend; \dp secret; drop user friend; -- The permissions are still existing -- (on a numeric user-id) \dp secret; create user foe; -- The user foe "inherits" the old permissions \dp secret; This is not what I would have expected. If this behaviour is valid, there should be a warning in the documentation, that creating a user may inherit some "dangling" permissions. Best regards, Martin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] BUG #1083: Insert query reordering interacts badly with NEXTVAL()/CURRVAL()
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> /* this statement will reverse the order of CURRVAL()/NEXTVAL() to match the
> column order of the table */
> INSERT INTO testing (col_b, col_a) VALUES (NEXTVAL('seq'), CURRVAL('seq'));
This is not a bug. The order of evaluation of select-lists and
values-lists is not defined anywhere in the SQL standard, nor promised
anywhere in the Postgres documentation. In fact, we specifically say
here:
http://www.postgresql.org/docs/7.4/static/sql-expressions.html#SYNTAX-EXPRESS-EVAL
that "The order of evaluation of subexpressions is not defined." To do
otherwise would put horrible crimps in our ability to optimize query plans.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] A memory leak. Postgres 7.4. Mac OS. X Server
Hi, this is just a me too message. We have 7.4.2 running which was build from fink (I guess same compiler settings). My investigation so far is that: - the system will eat more and more memory and will start swapping to hard disk - no performance hits so far (I haven't noticed any) - the system will crash when the partition where the swap files reside is full - stopping the connections will free up the virtual memory reported in top - stopping postmaster will free up the disk space used for swapping and will bring back everything to "normal" - top will report nothing unusual (no large VSIZE, RSIZE, RSHRD values per process), just a large total of virtual memory Settings: shared_buffers = 12500 # 12500*8.2kB + 1 MB = shmem ~=100MB /etc/rc sysctl -w kern.sysv.shmmax=268435456 sysctl -w kern.sysv.shmmin=1 sysctl -w kern.sysv.shmmni=32 sysctl -w kern.sysv.shmseg=8 sysctl -w kern.sysv.shmall=65536 We've got about 50 concurrent connections (WebApp, via JDBC...) OSX Server 10.3.4, on XServe G5 2x2Ghz Another thing is that we have a C trigger that will do replication on update/insert/delete. The whole setup was fine when running on 10.2.x and 7.3.4. Anyway, I don't know if this is a postgres problem or an OSX 10.3.4 problem. If you have any hints or places or tools that I could use to analyze the problem more throughly, I'd be very glad (right now we're down to rebooting the system every week). The DB has one large table with around 1.6 million rows. Thanks Christian On May 21, 2004, at 10:15 PM, [EMAIL PROTECTED] wrote: Hi, we have a postgresql 7.4 database server on an X Server with Mac OS 10.3.3, 7F45 The server possess two CPU's, 4 Gb in memory, and an adequate space on disk. The service run fine in the majority of time. But, we see the memory go down, bit by bit. (A memory leak). No errors are produced, but the memory is missing, and then we need to restart the service (pg_ctl restart) to clean the busy memory. Before the reload, the postgres run slow (by the lack of memory, I think!). Postgres was compiled with gcc 3.3, with fink on stable (read line, open ssl), and with CFLAGS= -03-mtune=970 -funroll-loops The parameters used was: /configure --with-includes=/sw/include --with-libraries=/sw/lib --prefix=/sw --with-rendevouz Regards Pablo Avilés Cisneros Area Manager Software Research and Development Area Development and Research, ITS San José,Costa Rica email: [EMAIL PROTECTED] phone: (506) 2110319 cel: (506) 8444312
Re: [BUGS] BUG #1083: Insert query reordering interacts badly with NEXTVAL()/CURRVAL()
"Martin Langhoff (Catalyst IT)" <[EMAIL PROTECTED]> writes:
> Thanks for the clarification. I am curious, however: I can't find a
> means to achieve the same effect in a deterministic manner. Any pointers?
How about
SELECT nextval('seq'); -- ignore result
INSERT INTO ... VALUES (currval('seq'), currval('seq'));
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [BUGS] Fwd: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf
Hi again! On 2004-05-25 15:13 -0400, Tom Lane wrote: > I said: > > I would suggest adding more paranoia along these lines: > > Actually the correct patch is as per attached. Even without a core > dump, the original code would not print the token that was really > causing the problem :-(. Please apply this patch and then tell us > what you see with winbind. The submitter of this bug eventually reported back (there was a problem with his email address) and tested the updated package (with your patch); unfortunately it seems that the patch did not improve the output very much :-( He wrote: Started by /etc/init.d/postgresql: 2004-06-07 14:24:59 [6455] LOG: authentication file token too long, skipping: "(garbage)" I piped the garbage through xxd and got: 986e 0241 9131 f840 I ran it again from the command line, as user postgres and got, instead: 98e3 ed40 9101 e340 These garbage strings are repeatable. In either case, I did get the seg fault. Does that say anything to anybody? Thanks and have a nice day! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
Re: [BUGS] A memory leak. Postgres 7.4. Mac OS. X Server
Christian van der leeden <[EMAIL PROTECTED]> writes: > this is just a me too message. Neither one of you has provided any information that would let anyone else even guess where to look for the problem :-( For starters, which process or processes is eating memory? (see top(1)) regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Fwd: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf
Martin Pitt <[EMAIL PROTECTED]> writes: > The submitter of this bug eventually reported back (there was a > problem with his email address) and tested the updated package (with > your patch); unfortunately it seems that the patch did not improve the > output very much :-( He wrote: I didn't expect the failure to go away, only the consequent core dump. We still need to learn why winbind is returning bad data. To that end, could we *see* the "garbage" error report? I don't know that it will tell anything, but certainly I have zero to go on at the moment. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] Known issue with Reindex-based corruption?
Folks, Is there any known issues with index file corruption in the event of a power-out during REINDEX with 7.2.4? I *think* the problem is this client's peculiar hardware, but wanted to eliminate any potential known issues. -- -Josh Berkus __AGLIO DATABASE SOLUTIONS___ Josh Berkus Complete information technology [EMAIL PROTECTED] and data management solutions (415) 565-7293 for law firms, small businesses fax 651-9224 and non-profit organizations. San Francisco ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
