Thread: ambuild parameters
Hi, I'm trying to implement my own access method. Now I've implemented
and compiled it but I've problems when I try to use it.
I got folowing AM function definitions:
CREATE OR REPLACE FUNCTION atomrtgettuple (INTERNAL ,INT4) RETURNS BOOL
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtgettuple'
LANGUAGE 'C';
CREATE OR REPLACE FUNCTION atomrtinsert (INTERNAL ,INTERNAL, INTERNAL, INTERNAL) RETURNS INTERNAL
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtinsert'
LANGUAGE 'C';
CREATE OR REPLACE FUNCTION atomrtbeginscan (INTERNAL ,INT4, INTERNAL) RETURNS INTERNAL
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtbeginscan'
LANGUAGE 'C';
CREATE OR REPLACE FUNCTION atomrtrescan (INTERNAL ,INTERNAL) RETURNS VOID
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtrescan'
LANGUAGE 'C';
CREATE OR REPLACE FUNCTION atomrtendscan (INTERNAL) RETURNS VOID
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtendscan'
LANGUAGE 'C';
CREATE OR REPLACE FUNCTION atomrtmarkpos (INTERNAL) RETURNS VOID
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtmarkpos'
LANGUAGE 'C';
CREATE OR REPLACE FUNCTION atomrtrestrpos (INTERNAL) RETURNS VOID
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtrestrpos'
LANGUAGE 'C';
CREATE OR REPLACE FUNCTION atomrtbuild (INTERNAL ,INTERNAL, INTERNAL) RETURNS VOID
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtbuild'
LANGUAGE 'C';
CREATE OR REPLACE FUNCTION atomrtbulkdelete (INTERNAL ,INTERNAL, INTERNAL) RETURNS INTERNAL
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtbulkdelete'
LANGUAGE 'C';
CREATE OR REPLACE FUNCTION atomrtcostestimate (INTERNAL, INTERNAL, INTERNAL, INTERNAL, INTERNAL, INTERNAL, INTERNAL,
INTERNAL)RETURNS VOID
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtcostestimate'
LANGUAGE 'C';
Then I insert record into pg_am:
insert into pg_am(
amname,
amowner,
amstrategies,
amsupport,
amorderstrategy,
amcanunique,
amcanmulticol,
amindexnulls,
amconcurrent,
amgettuple,
aminsert,
ambeginscan,
amrescan,
amendscan,
ammarkpos,
amrestrpos,
ambuild,
ambulkdelete,
amvacuumcleanup,
amcostestimate)
values (
'atomrtree',
(select usesysid from pg_shadow where usename = current_user),
1,
0,
0,
'f',
't',
't',
'f',
'atomrtgettuple',
'atomrtinsert',
'atomrtbeginscan',
'atomrtrescan',
'atomrtendscan',
'atomrtmarkpos',
'atomrtrestrpos',
'atomrtbuild',
'atomrtbulkdelete',
'-',
'atomrtcostestimate'
);
And when i try to set atomrtree index (create index idx_atom1 on test
using atomrtree(col1);), I get error telling me that I can't read on
address xxxx.
The problem is in the atomrtbuild function, which fails, when I try to
work with index_relation variable, which is parameter of that function. The
fucntion seems like:
Datum
atomrtbuild(PG_FUNCTION_ARGS)
{
Relation heap_rel = (Relation) PG_GETARG_POINTER(0);
Relation index_rel = (Relation) PG_GETARG_POINTER(1);
IndexInfo *indexInfo = (IndexInfo *) PG_GETARG_POINTER(2);
double reltuples;
AtomRTBuildState buildstate;
Buffer buffer;
BlockNumber block_num;
Page page;
AtomRTreePageOpaque page_opaque;
WriteToMyLog("Entering atomrtbuild");
/* no locking is needed */
WriteToMyLog("Before initAtomRTState");
initAtomRTState(&buildstate.atomrtstate, index_rel);
WriteToMyLog("After initAtomRTState");
if (index_rel == NULL)
WriteToMyLog("index_rel is null");
else
WriteToMyLog("index_rel is NOT null");
WriteToMyLog("Before RelationGetNumberOfBlocks(index_rel)");
if (RelationGetNumberOfBlocks(index_rel) != 0)
elog(ERROR, "index_rel \"%s\" already contains data",
RelationGetRelationName(index_rel));
And RelationGetNumberOfBlocks(index_rel) is the place, where it fails
(the index_rel variable is not null).
The same problem is, when I try to use heap_rel.
I really can't find, where's the problem. I use almost the same code
as btree or rtree does. Isn't the problem in the way I create the
functions? I mean if the parameter type INTERNAL in:
CREATE OR REPLACE FUNCTION atomrtbuild (INTERNAL ,INTERNAL, INTERNAL) RETURNS VOID
AS 'E:\\pgsource\\postgresql-8.0.7\\contrib\\atomrtree\\libatomrtree.dll', 'atomrtbuild'
LANGUAGE 'C';
is OK?
I spent whole afternoon trying to change the params for OPAQUE aso.,
but nothing works:(
Thanks,
David Hoksza
david.hoksza@seznam.cz writes:
> Hi, I'm trying to implement my own access method. Now I've implemented
> and compiled it but I've problems when I try to use it.
Wild guess: did you mark all your functions as V1 call convention?
The internal functions don't need to be marked, but dynamically loaded
ones do.
regards, tom lane
Thanks for answering, it was a good guess, I really didn't mark it,
but unfortunately it didn't solve my problem. It still falls down,
when I try to access the argument.
But it seems strange to me, that converting to Relation is OK:
Relation index_rel = (Relation) PG_GETARG_POINTER(1);
and also that comparing to NULL is OK:
if (index_rel == NULL).
Obviously the problem comes, when touching inside the structure in
RelationGetNumberOfBlocks.
I'm running it on Windows XP, but i guess that should be no problem in
this case?
Don't you have possibly any other ideas? I'm implementing a framework
for indexing into PG as my diploma work, so it's quite importatnt to
me...
Thanks,
David Hoksza
________________________________
19. března 2006, 22:43:48, napsal jste:
TL> david.hoksza@seznam.cz writes:
>> Hi, I'm trying to implement my own access method. Now I've implemented
>> and compiled it but I've problems when I try to use it.
TL> Wild guess: did you mark all your functions as V1 call convention?
TL> The internal functions don't need to be marked, but dynamically loaded
TL> ones do.
TL> regards, tom lane
david.hoksza@seznam.cz writes:
> Thanks for answering, it was a good guess, I really didn't mark it,
> but unfortunately it didn't solve my problem. It still falls down,
> when I try to access the argument.
> But it seems strange to me, that converting to Relation is OK:
> Relation index_rel = (Relation) PG_GETARG_POINTER(1);
> and also that comparing to NULL is OK:
> if (index_rel == NULL).
Neither of those prove a thing (except that you don't have a null
pointer). I'd still guess that you don't have the V1 parameter marking
correct, and so what the function thinks it's picking up is garbage
because the backend is not passing the parameters the way the function
expects.
You might try using gdb to see exactly what parameter values the
function thinks it's getting, or print them out to the log before you
use them.
regards, tom lane
I got problems when running gdb. In MINGW I run
"postgres -D ... dbname". Then I run gdb, but the problem is:
$ gdb
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) attach 4204
Attaching to process 4204
[Switching to thread 4204.0x1750]
(gdb) dll-symbols libatomrtree.dll
(gdb) break atomrtbuild
(gdb) Cannot access memory at address 0x65dc2110
Probably the reason is, that the dll is not loaded yet? But what's the
right way to set breakpoint into dll, which isn't loaded yet?
And about the V1 convention - I got in the .c file:
PG_FUNCTION_INFO_V1(atomrtbuild);
Datum
atomrtbuild(PG_FUNCTION_ARGS)
{
Relation heap_rel = (Relation) PG_GETARG_POINTER(0);
Relation index_rel = (Relation) PG_GETARG_POINTER(1);
IndexInfo *indexInfo = (IndexInfo *) PG_GETARG_POINTER(2);
Thanks,
David Hoksza
________________________________
20. března 2006, 23:20:12, napsal jste:
TL> david.hoksza@seznam.cz writes:
>> Thanks for answering, it was a good guess, I really didn't mark it,
>> but unfortunately it didn't solve my problem. It still falls down,
>> when I try to access the argument.
>> But it seems strange to me, that converting to Relation is OK:
>> Relation index_rel = (Relation) PG_GETARG_POINTER(1);
>> and also that comparing to NULL is OK:
>> if (index_rel == NULL).
TL> Neither of those prove a thing (except that you don't have a null
TL> pointer). I'd still guess that you don't have the V1 parameter marking
TL> correct, and so what the function thinks it's picking up is garbage
TL> because the backend is not passing the parameters the way the function
TL> expects.
TL> You might try using gdb to see exactly what parameter values the
TL> function thinks it's getting, or print them out to the log before you
TL> use them.
TL> regards, tom lane
TL> ---------------------------(end of
TL> broadcast)---------------------------
TL> TIP 2: Don't 'kill -9' the postmaster
david.hoksza@seznam.cz writes:
> Probably the reason is, that the dll is not loaded yet? But what's the
> right way to set breakpoint into dll, which isn't loaded yet?
Try forcing the .so to be loaded via the SQL "LOAD" command before you
attach to the process with gdb.
regards, tom lane
unsubscribe
Regards,
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org]On Behalf Of
david.hoksza@seznam.cz
Sent: Wednesday, March 22, 2006 5:49 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] ambuild parameters
I got problems when running gdb. In MINGW I run
"postgres -D ... dbname". Then I run gdb, but the problem is:
$ gdb
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
(gdb) attach 4204
Attaching to process 4204
[Switching to thread 4204.0x1750]
(gdb) dll-symbols libatomrtree.dll
(gdb) break atomrtbuild
(gdb) Cannot access memory at address 0x65dc2110
Probably the reason is, that the dll is not loaded yet? But what's the
right way to set breakpoint into dll, which isn't loaded yet?
And about the V1 convention - I got in the .c file:
PG_FUNCTION_INFO_V1(atomrtbuild);
Datum
atomrtbuild(PG_FUNCTION_ARGS)
{
Relation heap_rel = (Relation)
PG_GETARG_POINTER(0);
Relation index_rel = (Relation)
PG_GETARG_POINTER(1);
IndexInfo *indexInfo = (IndexInfo *)
PG_GETARG_POINTER(2);
Thanks,
David Hoksza
________________________________
20. března 2006, 23:20:12, napsal jste:
TL> david.hoksza@seznam.cz writes:
>> Thanks for answering, it was a good guess, I really didn't mark it,
>> but unfortunately it didn't solve my problem. It still falls down,
>> when I try to access the argument.
>> But it seems strange to me, that converting to Relation is OK:
>> Relation index_rel = (Relation) PG_GETARG_POINTER(1);
>> and also that comparing to NULL is OK:
>> if (index_rel == NULL).
TL> Neither of those prove a thing (except that you don't have a null
TL> pointer). I'd still guess that you don't have the V1 parameter marking
TL> correct, and so what the function thinks it's picking up is garbage
TL> because the backend is not passing the parameters the way the function
TL> expects.
TL> You might try using gdb to see exactly what parameter values the
TL> function thinks it's getting, or print them out to the log before you
TL> use them.
TL> regards, tom lane
TL> ---------------------------(end of
TL> broadcast)---------------------------
TL> TIP 2: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Yes, it came across my mind immediately atfter sending the mail yesterday , but didn't help:( (and it's dll - it's on win32). David Hoksza ________________________________ 22. března 2006, 4:26:07, napsal jste: TL> david.hoksza@seznam.cz writes: >> Probably the reason is, that the dll is not loaded yet? But what's the >> right way to set breakpoint into dll, which isn't loaded yet? TL> Try forcing the .so to be loaded via the SQL "LOAD" command before you TL> attach to the process with gdb. TL> regards, tom lane