I'm using CentOS 5.2 64-bits with postgres 8.1.11 + java 6u16, and
Windows Vista 32-bits with postgres 8.4.1 + java 6u13.
Here is a small code snippet that shows the problem, where the user id
value is 0:
public void update(EntityVO vo) {
StringBuilder sql = new StringBuil
The following bug has been logged online:
Bug reference: 5117
Logged by: cf of
Email address: ccooff...@hotmail.com
PostgreSQL version: 8.4 (maybe all)
Operating system: Linux
Description:Table type Function Bug when column dropped
Details:
create table test_table
The following bug has been logged online:
Bug reference: 5118
Logged by: Gerhard Leykam
Email address: gel...@sealsystems.de
PostgreSQL version: 8.4.0
Operating system: linux
Description:start-status-insert-fatal
Details:
Hi!
I am using a start script to set up my
Sean Hsien wrote:
> 2009/10/15 Kevin Grittner :
>> what are the OS and Java versions on the client side?
> I'm using CentOS 5.2 64-bits with postgres 8.1.11 + java 6u16, and
> Windows Vista 32-bits with postgres 8.4.1 + java 6u13.
So the Java code is running on the same machine as the databa
cf of wrote:
>alter table test_table drop column key3;
>
>select * from test_function();
>ERROR: wrong record type supplied in RETURN NEXT
>DETAIL: Number of returned columns (2) does not match expected column
> count (3).
Known problem, fixed in HEAD (8.5-to-be). Not sure how
"Gerhard Leykam" wrote:
> I am using a start script to set up my PostgreSQL database: it runs
> initdb, if not done yet, starts the instance with pg_ctl start and
> checks everything is fine by pg_ctl status.
>
> If there is another PostgreSQL database on the same machine
> listening to the sa
"Kevin Grittner" writes:
> "Gerhard Leykam" wrote:
>> I am using a start script to set up my PostgreSQL database: it runs
>> initdb, if not done yet, starts the instance with pg_ctl start and
>> checks everything is fine by pg_ctl status.
>>
>> If there is another PostgreSQL database on the sam
Tom Lane wrote:
> Well, it's arguably a start-script bug
OK.
> While mulling that it occurred to me that some additional output
> from the postmaster would help to solve another thing that's an
> acknowledged shortcoming of pg_ctl, namely that it can't parse
> postgresql.conf to find out whe
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Suppose that after the postmaster is fully up, it writes a file
>> $PGDATA/postmaster.ports, with contents along the lines of
>>
>> 5432
>> /tmp/.s.PGSQL.5432
> The listen_addresses setting would need to figure in, too.
Yeah, I'm not entirely sure
Kevin Grittner wrote:
> This seems likely to overlap the review I was soon going to do of the
> differences between pg_ctl behavior and what is required for LSB
> conformance. I'll make sure to test this behavior along with others.
> One of my current complaints is that pg_ctl doesn't wait until
The following bug has been logged online:
Bug reference: 5120
Logged by: Steven McLellan
Email address: smclel...@mintel.com
PostgreSQL version: 8.3.x
Operating system: FreeBSD 6.2
Description:Performance difference between running a query with
named cursor and straig
"Kevin Grittner" wrote:
> I neglected that point in my recently proposed LSB conforming script
Hmmm... On review, I see that I assumed that the -w switch on pg_ctl
start would cover this. I see that the problem is that this uses psql
to connect to the specified port. Besides the problems To
"Kevin Grittner" writes:
> Hmmm... On review, I see that I assumed that the -w switch on pg_ctl
> start would cover this. I see that the problem is that this uses psql
> to connect to the specified port. Besides the problems Tom mentioned
> with its heuristics to find the right port number for
Tom Lane wrote:
> I would rather see us implement the hypothetical pg_ping protocol
> and remember to include the postmaster's PID in the response. One
> of the worst misfeatures of pg_ctl is the need to be able to
> authenticate itself to the postmaster, and having it rely on being
> able to a
"Steven McLellan" writes:
> I've found what appears to be a bug seriously affecting performance running
> a particular query using a named cursor versus running it as a simple
> SELECT.
You haven't shown us a plan for the cursor case, but I'm thinking the
issue here is that Postgres prefers fast-
I wrote:
> "Kevin Grittner" writes:
>> ... This would allow pg_ctl or a script to
>> connect to a port and see if it is the expected postmaster process.
> I would rather see us implement the hypothetical pg_ping protocol
> and remember to include the postmaster's PID in the response.
Although on
Tom Lane wrote:
> [ thinks... ] Maybe we could have the postmaster generate a random
> number at start and include that in both the postmaster.ports file
> and its pg_ping responses. That would have a substantially lower
> collision probability than PID, if the number generation process
> were
"Kevin Grittner" writes:
> Sounds good to me, other than it stalls pg_ctl revamp until pg_ping is
> done. I don't remember a clear design of what pg_ping should look
> like. Does anyone have a clear plan in their head?
I don't think anyone's written down a full spec, but it seems like a
relativ
Richard Neill writes:
> The good news is that the patch has now been in place for 5 days, and,
> despite some very high loading, it has survived without a single crash.
> I'd venture to say that this issue is now fixed.
Great, thanks for the followup.
regards, tom lane
"Kevin Grittner" writes:
> Tom Lane wrote:
>> [ thinks... ] Maybe we could have the postmaster generate a random
>> number at start and include that in both the postmaster.ports file
>> and its pg_ping responses.
> Unless two postmasters could open the same server socket within a
> microsecond
Tom Lane wrote:
> I'm not sure whether we'd want to provide a function within libpq
> for this, or just code it in pg_ctl.
I'm inclined to think there would be value to a pg_ping utility to
support automated monitoring by unprivileged users on other boxes.
That both suggests libpq as the locat
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I'm not sure whether we'd want to provide a function within libpq
>> for this, or just code it in pg_ctl.
> I'm inclined to think there would be value to a pg_ping utility to
> support automated monitoring by unprivileged users on other boxes.
True
>"Steven McLellan" writes:
>> I've found what appears to be a bug seriously affecting performance
running
>> a particular query using a named cursor versus running it as a simple
>> SELECT.
> You haven't shown us a plan for the cursor case, but I'm thinking the
> issue here is that Postgres prefe
Dear Tom,
Thanks for this, and sorry for not replying earlier. We finally obtained
a window to deploy this patch on the real (rather busy!) production
system as of last Saturday evening.
The good news is that the patch has now been in place for 5 days, and,
despite some very high loading, it
Steve McLellan writes:
> Thanks! Installing 8.4 and setting cursor_tuple_fraction to 1.0 does seem to
> force it to execute in the same time as not using the cursor, and we'll
> probably go with this solution (the only reason we're using cursors is to
> avoid retrieving vast result sets through ps
The following bug has been logged online:
Bug reference: 5121
Logged by: Ryan Douglas
Email address: rdoug...@arbinet.com
PostgreSQL version: 8.4.1
Operating system: Fedora 11
Description:Segmentation Fault when using pam w/ krb5
Details:
Whenever I use psql to remo
>Steve McLellan writes:
>> Thanks! Installing 8.4 and setting cursor_tuple_fraction to 1.0 does seem
to
>> force it to execute in the same time as not using the cursor, and we'll
>> probably go with this solution (the only reason we're using cursors is to
>> avoid retrieving vast result sets throu
"Ryan Douglas" writes:
> Whenever I use psql to remotely connect to the database the server crashes
> (see log below). If I use psql with the '-W' option then it's fine.
What this looks like at first glance is a bug in the PAM module you're
using, since Postgres really has no idea which PAM conf
Ryan Douglas wrote:
> The following bug has been logged online:
>
> Bug reference: 5121
> Logged by: Ryan Douglas
> Email address: rdoug...@arbinet.com
> PostgreSQL version: 8.4.1
> Operating system: Fedora 11
> Description:Segmentation Fault when using pam w/ krb5
> D
Steve McLellan writes:
> Sorry, I should've tried that. The two explains are below; without cursor
> then with cursor. I don't know enough to reliably say whether there's
> anything wrong with either (we use default_statistics_target=100 although
> the estimates don't look right for some of the qu
>Since that's on the outside of a nestloop, the 169x rowcount error
>translates directly to a 169x error in the total runtime estimate ---
>and it looks like that's not very far at all from the real ratio,
>so the other estimates are pretty good.
You're correct - the query's exercising a very smal
"Douglas, Ryan" writes:
> (gdb) bt
> #0 0x00559624 in pam_passwd_conv_proc ()
> #1 0x7f738dfeedd8 in _pam_krb5_conv_call (pamh=,
> messages=0xb51780, n_prompts=0, responses=0x7fff2e356668) at conv.c:99
> #2 0x7f738dfefb38 in _pam_krb5_generic_prompter (context= optimized out>,
Tom Lane wrote:
This could be addressed by having the postmaster report its $PGDATA
value in the pg_ping response, but I would be against that on security
grounds. We don't let nonprivileged users know where PGDATA is, why
would we make the information available without any authentication at
al
On Sep 18, 7:31 pm, jmor...@coverity.com ("Jesse Morris") wrote:
> The following bug has been logged online:
>
> Bug reference: 5065
> Logged by: Jesse Morris
> Email address: jmor...@coverity.com
> PostgreSQL version: 8.3.7, 8.4.1
> Operating system: Windows Server 2003 R2
> D
Tom/ Heikki ,
This is a custom build. I used "./configure --with-pam --with-perl
--with-python --enable-thread-safety --with-openssl --with-krb5".
Gdb output below...
Core was generated by `postgres: rdouglas tacacs 10.0'.
When I initially ran gdb I got the following
.
.
Program terminated with signal 11, Segmentation fault.
#0 0x00559624 in pam_passwd_conv_proc ()
Missing separate debuginfos, use: debuginfo-install
audit-libs-1.7.13-1.fc11.x86_64 e2fsprogs-libs-1.41.4-12.fc11.x86_64
glibc-2.10.1-5.x86_
Found the bug...was my fault, of course.
Sorry for the mistake.
Sean
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
37 matches
Mail list logo
