Re: [BUGS] BUG #6425: Bus error in slot_deform_tuple
On 6 Feb 2012, at 20:48, Tom Lane wrote: > bug reports. Please see if you can break REL9_0_STABLE branch tip Just to let you know that I built this yesterday and I'm giving it a good battering in our Solaris 10 Sparc test environment. D -- 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 #6439: problems with streaming replication
The following bug has been logged on the website: Bug reference: 6439 Logged by: vipin v Email address: vipinass...@gmail.com PostgreSQL version: 9.0.0 Operating system: windows xp Description: hi I tried to configure replication in windows xp with postgresql 9.0 standard edition, 1. Edit postgresql.conf on the master to turn on streaming replication. Change these settings: listen_address = '*' wal_level = hot_standby max_wal_senders = 3 2. Edit pg_hba.conf on the master in order to let the standby connect. host replication all 192.168.0.2/32 trust In stadby server 1. First, in postgresql.conf, change this line: hot_standby = on 2.Edited recovery.conf on the standby. standby_mode = 'on' primary_conninfo = 'host=192.168.0.1' After putting the recovery.confg in data folder,I cant start the postgresql service. -- 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 #6440: Window function in WHERE evaluated after agregate
The following bug has been logged on the website: Bug reference: 6440 Logged by: Matyas Novak Email address: lo...@centrum.cz PostgreSQL version: 9.1.1 Operating system: Linux Description: Window function in WHERE clause - as all other functions used in where - should be evaluated before agregating takes place. But it seems that postgresql try evaluate its after agregating, as it'd be in HAVING clause. E.g. in folowing example I'l try to sum the best results of given persons from all dispciplines - so I agregate over persons and best result in each discipline wann get using window function. (I'm aware that it can be done by various subselects, or that there may be better to use different window function or nested agregates, but it's simplified example from a bit complex example.) Test example: create table results ( id serial not null primary key, person integer, discipline integer, result integer ); select person, sum(result) from results where row_number() over (partition by person, discipline order by result desc) = 1 group by person Error: ERROR: column "results.result" must appear in the GROUP BY clause or be used in an aggregate function LINE 19: ...() over (partition by person, discipline order by result des... -- 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 #6440: Window function in WHERE evaluated after agregate
lo...@centrum.cz writes: > Window function in WHERE clause - as all other functions used in where - > should be evaluated before agregating takes place. Hmm? WHERE clauses are necessarily evaluated before aggregating; that's one of the main reasons why there's a difference between WHERE and HAVING in the first place. Read the SQL standard, or any book about SQL. > select person, sum(result) from > results > where > row_number() over (partition by person, discipline order by result desc) = > 1 > group by > person > Error: > ERROR: column "results.result" must appear in the GROUP BY clause or be > used in an aggregate function > LINE 19: ...() over (partition by person, discipline order by result des... The real reason this query isn't allowed can be found in SQL:2008 section 4.15.3 "Window functions": Window functions may only appear in the of a or , or the simply contained in a that is a simple table query. I agree that the error message could be improved --- it'd be better if it complained that you can't put a window function call there. You would eventually get "window functions not allowed in WHERE clause", but the other check is being made first. As far as fixing your problem goes, maybe you should put the aggregate, GROUP BY, and row_number() calls into a sub-select and put the WHERE in the upper level. Or consider using LIMIT, which is going to be a lot more efficient than this row_number() = 1 locution anyway. 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
[BUGS] BUG #6445: PreparedStatement.setObject(1,java.util.String)
The following bug has been logged on the website:
Bug reference: 6445
Logged by: Rajesh
Email address: rajesh...@tcs.com
PostgreSQL version: 8.4.3
Operating system: Windows XP
Description:
I have a table in PostgreSQL database
CREATE TABLE newtest
(
id numeric(6),
name character varying(120),
email character varying(120)
)
I am using PreparedStatement so that i can insert data into newtest table
INSERT INTO NewTest (ID,NAME,EMAIL ) values (?,?,? )
Actual query fired -INSERT INTO NewTest (ID,NAME,EMAIL ) values ('1','Rajesh
','rajesh...@abs.com' )
code for prepared statement
try{
pstatement=conn.prepareStatement(insertQuery);
for(int k=1;khttp://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6444: Postgresql crash
The following bug has been logged on the website: Bug reference: 6444 Logged by: Petr Jediný Email address: petr.jed...@gmail.com PostgreSQL version: 8.4.10 Operating system: Debian 6 Squeeze, 64bit Description: Postgresql-8.4.9 (from debian squeeze repositories) works ok, after latest debian update to 8.4.10 keeps crashing (oom kill) while working with large tables/long running queries. I can reliably reproduce the crash, I have aprox 30M row table dump (2GiB SQL file) that I'm trying to import to postgresql test system causing the crash... 8.4.9 works with no problems. System has 6GiB RAM available, there are only postgres and ssh running. --- dmesg --- [ 2379.741939] postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0 [ 2379.741943] postgres cpuset=/ mems_allowed=0 [ 2379.741945] Pid: 1969, comm: postgres Not tainted 2.6.32-5-amd64 #1 [ 2379.741947] Call Trace: [ 2379.741953] [] ? oom_kill_process+0x7f/0x23f [ 2379.741956] [] ? __out_of_memory+0x12a/0x141 [ 2379.741958] [] ? out_of_memory+0x140/0x172 [ 2379.741961] [] ? __alloc_pages_nodemask+0x4ec/0x5fc [ 2379.741966] [] ? io_schedule+0x93/0xb7 [ 2379.741969] [] ? __do_page_cache_readahead+0x9b/0x1b4 [ 2379.741972] [] ? wake_bit_function+0x0/0x23 [ 2379.741975] [] ? ra_submit+0x1c/0x20 [ 2379.741978] [] ? filemap_fault+0x17d/0x2f6 [ 2379.741982] [] ? __do_fault+0x54/0x3c3 [ 2379.741985] [] ? handle_mm_fault+0x3b8/0x80f [ 2379.741989] [] ? do_page_fault+0x2e0/0x2fc [ 2379.741992] [] ? page_fault+0x25/0x30 [ 2379.741993] Mem-Info: [ 2379.741994] Node 0 DMA per-cpu: [ 2379.741996] CPU0: hi:0, btch: 1 usd: 0 [ 2379.741997] Node 0 DMA32 per-cpu: [ 2379.741999] CPU0: hi: 186, btch: 31 usd: 61 [ 2379.742000] Node 0 Normal per-cpu: [ 2379.742002] CPU0: hi: 186, btch: 31 usd: 57 [ 2379.742006] active_anon:1205594 inactive_anon:301380 isolated_anon:0 [ 2379.742007] active_file:6 inactive_file:0 isolated_file:0 [ 2379.742008] unevictable:0 dirty:0 writeback:823 unstable:0 [ 2379.742008] free:9451 slab_reclaimable:800 slab_unreclaimable:1607 [ 2379.742009] mapped:916 shmem:959 pagetables:6399 bounce:0 [ 2379.742011] Node 0 DMA free:15840kB min:24kB low:28kB high:36kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15280kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:4kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes [ 2379.742019] lowmem_reserve[]: 0 3000 6030 6030 [ 2379.742021] Node 0 DMA32 free:16984kB min:4936kB low:6168kB high:7404kB active_anon:2355684kB inactive_anon:588744kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3072160kB mlocked:0kB dirty:0kB writeback:1400kB mapped:1476kB shmem:1548kB slab_reclaimable:256kB slab_unreclaimable:24kB kernel_stack:8kB pagetables:8356kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:50 all_unreclaimable? yes [ 2379.742030] lowmem_reserve[]: 0 0 3030 3030 [ 2379.742032] Node 0 Normal free:4980kB min:4988kB low:6232kB high:7480kB active_anon:2466692kB inactive_anon:616776kB active_file:24kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3102720kB mlocked:0kB dirty:0kB writeback:1892kB mapped:2188kB shmem:2288kB slab_reclaimable:2944kB slab_unreclaimable:6400kB kernel_stack:584kB pagetables:17240kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:79 all_unreclaimable? yes [ 2379.742041] lowmem_reserve[]: 0 0 0 0 [ 2379.742043] Node 0 DMA: 2*4kB 3*8kB 2*16kB 3*32kB 3*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15840kB [ 2379.742049] Node 0 DMA32: 216*4kB 179*8kB 104*16kB 49*32kB 27*64kB 18*128kB 9*256kB 2*512kB 0*1024kB 0*2048kB 1*4096kB = 16984kB [ 2379.742055] Node 0 Normal: 717*4kB 2*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 4980kB [ 2379.742061] 4505 total pagecache pages [ 2379.742062] 3518 pages in swap cache [ 2379.742064] Swap cache stats: add 1372955, delete 1369437, find 1539/1943 [ 2379.742065] Free swap = 0kB [ 2379.742066] Total swap = 5476344kB [ 2379.756825] 1572848 pages RAM [ 2379.756826] 39908 pages reserved [ 2379.756827] 1566 pages shared [ 2379.756828] 1522287 pages non-shared [ 2379.756831] Out of memory: kill process 1731 (postgres) score 1557674 or a child [ 2379.756974] Killed process 1733 (postgres) --- -- 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 #6445: PreparedStatement.setObject(1,java.util.String)
On Wed, 8 Feb 2012, rajesh...@tcs.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6445
> PostgreSQL version: 8.4.3
>
>
> I have a table in PostgreSQL database
>
> CREATE TABLE newtest
> (
> id numeric(6),
> name character varying(120),
> email character varying(120)
> )
>
> I am using PreparedStatement so that i can insert data into newtest table
>
> INSERT INTO NewTest (ID,NAME,EMAIL ) values (?,?,? )
>
> Actual query fired -INSERT INTO NewTest (ID,NAME,EMAIL ) values ('1','Rajesh
> ','rajesh...@abs.com' )
>
> Please note I am reading data from an excel sheet and
> datacell[eachCell].getContents() is of type String..prepareStatement
> setObject is complaining that I am sending String datatype which cannot be
> casted to bigint or numeric,but that is the job of setObject right to decide
> the target datatype and cast accordingly..please reply any
> solution..Parameter to setObject(can be anything) so I cannot cast the data
> to appropriate format before sending the data
>
It is not the job of setObject to determine the correct conversion to the
column type. The setObject javadoc says, "The JDBC specification
specifies a standard mapping from Java Object types to SQL types. The
given argument will be converted to the corresponding SQL type before
being sent to the database." So it is solely looking at the Java type of
the object passed to it and converting that to a SQL type. So you pass it
a String and it converts it to a varchar which is appropriate. If you
want setObject to do a conversion to a different type, that is the reason
for the additional setObject variant which takes a target sql type to
convert to, but that doesn't help your situation where you don't know what
the target type is.
The Postgresql JDBC driver offers three possible workarounds.
1) Use getParameterMetaData to try and determine the target types.
2) Use setObject(int, Object, Types.OTHER) to indicate that you don't know
that the Java type you are passing is correct.
3) Use the stringtype=unspecified URL parameter to indicate that all
String bindings may not really be strings.
Kris Jurka
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
