Re: [BUGS] BUG #5883: Error when mixing SPI_returntuple with returning regular HeapTuple
The updated example is pasted in below.
The given example will cause an error. You may (for example) change the code in
the stwitch statement like this, and it will work like a charm:
from:
case 1:
SRF_RETURN_NEXT(funcctx, get_data_alternative_b());
//get_data_alternative_a(ret, isnull);
to:
case 1:
//SRF_RETURN_NEXT(funcctx, get_data_alternative_b());
get_data_alternative_a(ret, isnull);
VG
#include
#include
#include
#include
#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif
/*
* CREATE TABLE test (a int, b int);
* INSERT INTO test VALUES (1, 2);
* CREATE FUNCTION run_test() RETURNS SETOF test AS 'SOMEWHERE/something.so',
'run_test' LANGUAGE C VOLATILE;
*
* SELECT * FROM run_test();
*
* ERROR: rows returned by function are not all of the same row type
*
*/
static const char * query = "SELECT a, b FROM test";
static void get_data_alternative_a(Datum * data_out, bool * isnull)
{
SPI_connect();
SPI_execute(query, true, 1);
data_out[0] = SPI_getbinval(* SPI_tuptable->vals,
SPI_tuptable->tupdesc, 1, & isnull[0]);
data_out[1] = SPI_getbinval(* SPI_tuptable->vals,
SPI_tuptable->tupdesc, 2, & isnull[1]);
SPI_finish();
}
static Datum get_data_alternative_b()
{
SPI_connect();
SPI_execute(query, true, 1);
HeapTupleHeader ret = SPI_returntuple(* SPI_tuptable->vals,
SPI_tuptable->tupdesc);
Datum d = PointerGetDatum(ret);
SPI_finish();
return d;
}
PG_FUNCTION_INFO_V1(run_test);
Datum run_test(PG_FUNCTION_ARGS)
{
FuncCallContext * funcctx;
int * return_count = NULL;
if ( SRF_IS_FIRSTCALL() )
{
funcctx = SRF_FIRSTCALL_INIT();
//SPI_connect();
MemoryContext oldcontext =
MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
TupleDesc tupdesc;
if (get_call_result_type(fcinfo, NULL, &tupdesc) !=
TYPEFUNC_COMPOSITE)
ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg(
"function returning record called in
context "
"that cannot accept type
record")));
funcctx->tuple_desc = BlessTupleDesc(tupdesc);
return_count = (int *) palloc(sizeof(int));
MemoryContextSwitchTo(oldcontext);
* return_count = 0;
funcctx->user_fctx = (void*) return_count;
}
funcctx = SRF_PERCALL_SETUP();
return_count = (int *) funcctx->user_fctx;
Datum ret[2];
bool isnull[2];
switch ( (* return_count) ++ )
{
case 0:
//SRF_RETURN_NEXT(funcctx, get_data_alternative_b());
get_data_alternative_a(ret, isnull);
break;
case 1:
SRF_RETURN_NEXT(funcctx, get_data_alternative_b());
//get_data_alternative_a(ret, isnull);
break;
default:
SRF_RETURN_DONE(funcctx);
}
HeapTuple heap_tuple = heap_form_tuple(funcctx->tuple_desc, ret,
isnull);
Datum packed_ret = HeapTupleGetDatum(heap_tuple);
SRF_RETURN_NEXT(funcctx, packed_ret);
}
- Original Message -
Fra: "Robert Haas"
Til: "Vegard Bønes"
Kopi: "Tom Lane" , pgsql-bugs@postgresql.org
Sendt: 17. februar 2011 02:41:47
Emne: Re: [BUGS] BUG #5883: Error when mixing SPI_returntuple with returning
regular HeapTuple
On Tue, Feb 15, 2011 at 2:43 AM, Vegard Bønes wrote:
> Ok, I tried to modify the example functions get_data_alternative_a() and
> get_data_alternative_b(), so that they start with SPI_connect, and end with
> SPI_finish. Also I removed SPI_connect and SPI_finish from the main function.
> As I understand you, that should have solved the problem. The result,
> however, is exactly the same as before.
You may get further if you post the modified code, instead of simply
asserting that some code we can't see doesn't work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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] timestamp issue
On 17.02.2011 08:06, Sachin Srivastava wrote:
postgres=# SELECT now() + '7 days' AS week_ahead;
week_ahead
--
2011-02-24 10:39:29.951931+05:30
(1 row)
postgres=# SELECT now() - '7 days' AS week_behind;
ERROR: invalid input syntax for type timestamp with time zone: "7 days"
LINE 1: SELECT now() - '7 days' AS week_behind;
^
Now, if '+' operator works with '7 days', why dint the '-' operator? Is this
intentional or a bug?
Intentional, or at least coincidental.
postgres=# SELECT oprname, oprleft::regtype, oprright::regtype FROM
pg_operator WHERE oprleft ='timestamptz'::regtype AND oprname IN('+', '-');
oprname | oprleft | oprright
-+--+--
+ | timestamp with time zone | interval
- | timestamp with time zone | timestamp with time zone
- | timestamp with time zone | interval
(3 rows)
With '-', it's getting interpreted as timestamptz-timestamptz.
--
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
[BUGS] timestamp issue
Hello all, I am running PostgreSQL 9.0.2 on Mac (10.6.6) This is what I get in the psql terminal: postgres=# SELECT version(); version PostgreSQL 9.0.2 on x86_64-apple-darwin, compiled by GCC i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664), 64-bit (1 row) postgres=# SELECT now() + interval '7 days' AS week_ahead; week_ahead -- 2011-02-24 10:39:07.071655+05:30 (1 row) postgres=# SELECT now() - interval '7 days' AS week_behind; week_behind -- 2011-02-10 10:39:21.848049+05:30 (1 row) postgres=# SELECT now() + '7 days' AS week_ahead; week_ahead -- 2011-02-24 10:39:29.951931+05:30 (1 row) postgres=# SELECT now() - '7 days' AS week_behind; ERROR: invalid input syntax for type timestamp with time zone: "7 days" LINE 1: SELECT now() - '7 days' AS week_behind; ^ Now, if '+' operator works with '7 days', why dint the '-' operator? Is this intentional or a bug? -- Regards, Sachin Srivastava EnterpriseDB, the Enterprise PostgreSQL company.
Re: [BUGS] 64-bit windows installer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Swiderek, Sunny wrote: > Hi, > > We are a current user of Postgres on a 32-bit Windows 2003 server. We > need to run this application on a 64-bit Windows 2008 server… I read > there is a 64-bit installer available (9.0.3) but have yet to find it > on the Postgres site. Can you point me to this download if it’s available? This link should help :- http://www.postgresql.org/download/windows -- regards, tushar Lead QA Engineer EnterpriseDB Corporation The Enterprise PostgreSQL Company Phone: +91-99227433-47 This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFNXLhTfQNodY2PIRoRAszTAJ9mgkPZXtauy3YEn09Sfph+1I5FHACbBEkt zcLvr0LVZcOnB1kc5UEjXWA= =gIvD -END PGP SIGNATURE- -- 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] Bidirectional replication for postgres 9
On ons, 2011-02-16 at 17:15 +, Khadtare, Sharad wrote: > I want to configure Bidirectional replication in postgres 9 ( streaming ). > > any one knows solution for Bidirectional replication in postgres. This is not a bug, and is hence inappropriate for this forum. But what you are looking for doesn't exist. If you want bidirectional replication, consider Bucardo. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] 64-bit windows installer
Hi, We are a current user of Postgres on a 32-bit Windows 2003 server. We need to run this application on a 64-bit Windows 2008 server... I read there is a 64-bit installer available (9.0.3) but have yet to find it on the Postgres site. Can you point me to this download if it's available? Thanks, Sunny Bentley Indesign, LLC
[BUGS] can't build contrib/uuid-ossp
Dear PostgreSQL bug-squasher-team, I was trying to build postgresql-9.0.2 with the following ./configure: $ ./configure --enable-cassert --enable-debug --with-python --with-ossp-uuid and got the following message: checking uuid.h presence... yes configure: WARNING: uuid.h: present but cannot be compiled configure: WARNING: uuid.h: check for missing prerequisite headers? configure: WARNING: uuid.h: see the Autoconf documentation configure: WARNING: uuid.h: section "Present But Cannot Be Compiled" configure: WARNING: uuid.h: proceeding with the preprocessor's result configure: WARNING: uuid.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ## configure: WARNING: ## ## checking for uuid.h... yes I've downloaded and installed the requisite ossp-uuid library: ftp ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz which builds fine (I didn't use the ./configure --with-pgsql option for installing uuid-1.6.2 as it throws an error too). Sadly, I got this to install yesterday, but in a ridiculously stupid brain lapse, I didn't document it. I'm nor trying to recreate the postgresql-9.0.2 install from scratch and get stuck here. Help? Respectfully, Jeff. Jeff Hamann, PhD PO Box 1421 Corvallis, Oregon 97339-1421 541-754-2457 jeff.hamann[at]forestinformatics[dot]com http://www.forestinformatics.com http://forufus.blogspot.com/
[BUGS] Bidirectional replication for postgres 9
I want to configure Bidirectional replication in postgres 9 ( streaming ). any one knows solution for Bidirectional replication in postgres. Regards, Sharad K
Re: [BUGS] BUG #5883: Error when mixing SPI_returntuple with returning regular HeapTuple
On Tue, Feb 15, 2011 at 2:43 AM, Vegard Bønes wrote: > Ok, I tried to modify the example functions get_data_alternative_a() and > get_data_alternative_b(), so that they start with SPI_connect, and end with > SPI_finish. Also I removed SPI_connect and SPI_finish from the main function. > As I understand you, that should have solved the problem. The result, > however, is exactly the same as before. You may get further if you post the modified code, instead of simply asserting that some code we can't see doesn't work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5890: malloc error
"Emmanuel" writes: > Operating system: Mac OSX 10.6.6 > When I type a select query and then push the 'tab' key for table name > completion (without) schema name, if there more than one table starting with > the same prefix, I get this error: > legiobiblio=# select pmid from pub > psql(41402) malloc: *** error for object 0x4: pointer being freed was not > allocated This is a known and oft-reported bug in OS X's libedit --- it stomps on memory that doesn't belong to it anytime the number of possible completions is exactly 9 + 10*N, for any N>=0. Complain to Apple: the fix was applied upstream quite some time ago, and they are being derelict by not adopting it. In the meantime, you might consider building psql with readline instead of libedit. (Note you need real GNU readline, as /usr/lib/libreadline.dylib is just a link to libedit.) 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 #5890: malloc error
The following bug has been logged online: Bug reference: 5890 Logged by: Emmanuel Email address: t...@pasteur.fr PostgreSQL version: 8.4.1 Operating system: Mac OSX 10.6.6 Description:malloc error Details: When I type a select query and then push the 'tab' key for table name completion (without) schema name, if there more than one table starting with the same prefix, I get this error: legiobiblio=# select pmid from pub psql(41402) malloc: *** error for object 0x4: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap I have more than one table starting with 'pub...' - publications - pub_genes - pub_org - pub_auths However if I precise the schema name like 'public.pub..' and press 'tab' key, then I get list of table matching the beginning of my table name: legiobiblio=# select pmid from public.pub public.pub_auths public.pub_genes public.pub_org public.publications legiobiblio=# select pmid from public.pub hope my message is clear enough. Cheers -- 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 #5889: "Intersects" for polygons broken
2011/2/16 Tom Lane : > "Konrad Garus" writes: >> && operator seems to be broken for polygons whose bounding boxes intersect: > >> select polygon'((0,0), (1,2), (0,2))' && polygon'((0.5, 0), (1,0), (1,1))'; >> ?column? >> -- >> t >> (1 row) > > This is fixed as of 9.0; see the release notes at > http://www.postgresql.org/docs/9.0/static/release-9-0.html > which say > > Correct calculations of "overlaps" and "contains" operations for > polygons (Teodor Sigaev) > > The polygon && (overlaps) operator formerly just checked to see > if the two polygons' bounding boxes overlapped. It now does a > more correct check. The polygon @> and <@ (contains/contained > by) operators formerly checked to see if one polygon's vertexes > were all contained in the other; this can wrongly report "true" > for some non-convex polygons. Now they check that all line > segments of one polygon are contained in the other. Thank you. How about the point of more informative docs that would explain supported types, automatic conversions and all such caveats (also for 8.3 and 8.4)? -- Konrad Garus -- 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 #5889: "Intersects" for polygons broken
"Konrad Garus" writes: > && operator seems to be broken for polygons whose bounding boxes intersect: > select polygon'((0,0), (1,2), (0,2))' && polygon'((0.5, 0), (1,0), (1,1))'; > ?column? > -- > t > (1 row) This is fixed as of 9.0; see the release notes at http://www.postgresql.org/docs/9.0/static/release-9-0.html which say Correct calculations of "overlaps" and "contains" operations for polygons (Teodor Sigaev) The polygon && (overlaps) operator formerly just checked to see if the two polygons' bounding boxes overlapped. It now does a more correct check. The polygon @> and <@ (contains/contained by) operators formerly checked to see if one polygon's vertexes were all contained in the other; this can wrongly report "true" for some non-convex polygons. Now they check that all line segments of one polygon are contained in the other. 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] possible bug: orphaned files left after immediate shutdown during DDL
Jeff Davis wrote: > On Wed, 2011-02-09 at 22:58 -0500, Tom Lane wrote: > > It's intentional ... not that other people haven't complained about it > > before. Remember that what you have done is forced a crash, and > > recovery from it is crash recovery. If we proactively removed such > > files we would very possibly be destroying evidence of forensic value. > > I thought that might be the case, but I wasn't able to find any previous > discussions. > > It might be a good idea to issue a warning during recovery, however, > like "possible orphaned file ...". I'm not sure if it's worth the > bookkeeping effort though. I thought we had a TODO item about removing orphaned files, but I don't see it now, perhaps because I thought we had fixed that. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- 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 #5889: "Intersects" for polygons broken
The following bug has been logged online: Bug reference: 5889 Logged by: Konrad Garus Email address: konrad.ga...@gmail.com PostgreSQL version: 8.4 Operating system: Linux Description:"Intersects" for polygons broken Details: && operator seems to be broken for polygons whose bounding boxes intersect: select polygon'((0,0), (1,2), (0,2))' && polygon'((0.5, 0), (1,0), (1,1))'; ?column? -- t (1 row) It reportedly is different in 9.0 (http://stackoverflow.com/q/5015233/277683) Docs could do better job explaining what types each of the geometry operator supports, and whether intersecting polygons support nonconvex polygons as well, or only uses bounding box as criteria. -- 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 #5885: Strange rows estimation for left join
On Wed, Feb 16, 2011 at 6:18 AM, Tom Lane wrote: > Maxim Boguk writes: > > Test case look like: > > > create table "references" ( attr_id integer, reference integer, > > object_id integer ); > > insert into "references" select *100**(random()), > > *10**(random()^*10*), *100**(random()) from > > generate_series(*1*,*1000*); > > create index xif01references on "references" ( reference, attr_id ); > > create index xif02references on "references" ( object_id, attr_id, > reference ); > > > analyze "references"; > > > explain select * from "references" rs left join "references" vm on > > vm.reference = rs.reference and vm.attr_id = *10* where rs.object_id = > > *1000*; > > I don't believe there's actually anything very wrong here. The > large-looking estimate for the join size is not out of line: if you try > different values for object_id you will find that some produce more rows > than that and some produce less. If we had cross-column stats we could > maybe derive a better estimate, but as-is you're getting an estimate > that is probably about right on the average, depending on whether the > particular object_id matches to more common or less common reference > values. > > The thing that looks funny is that the inner indexscan rowcount estimate > is so small, which is because that's being done on the assumption that > the passed-in rs.reference value is random. It's not really --- it's > more likely to be one of the more common reference values --- which is > something that's correctly accounted for in the join size estimate but > not in the inner indexscan estimate. > >regards, tom lane > Thank you very much for answer. Are I correct in my assumption: estimated row counts in both sides of the join isn't related to estimated resulting row count of the join because they are calculated independently? If that assumption correct than which values used to select between nested loop and merge/hash joins (estimated resulting join rows or estimated row counts on each sides of the join)? I asking because in some cases these two values can lead to different plans. PS: I just calculated how many questions I had in mail lists about postgresql planner. Look like it's time to me dust off my memory about C and start read planner code by myself. :) Kind Regards, Maxim
