Re: [GENERAL] Error: column "host" does not exist

[Reg Me Please]

IS there any name clash with a function argument?

--
Fahrbahn ist ein graues Band
weisse Streifen, grüner Rand

On Thursday 08 January 2009 08:30:07 Mayuresh Nirhali wrote:
> Hello,
>
> I am working with 8.1.4 pgsql as my database backend. I have a function
> written in plpgsql language, that queries a particular table as below,
>
> select host from table_host where ip_address = ip_array[i] and port =
> port_array[i];
>
> The query is running in a for loop. I see ip_array and port_array
> getting populated with correct values during the execution.
> The error I see is,
>
> ERROR:  column "host" does not exist
> CONTEXT:  SQL statement "SELECT host"
> PL/pgSQL function "sp_get_ip_data" line 286 at raise
>
> throu psql, I can select the table_host fine.
> column "host" is a primary key here.
>
> I dont understand why I see the "column does not exist" error; any idea ?
>
> cheers
> Mayuresh



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Fail of a return query from plpgsql function for a specific table

[A. Kretschmer]

In response to c k :
> Hi all,
> I have a table accgroups and many others. I have written a test function as
> follows.
> CREATE OR REPLACE FUNCTION uf_testfunction()
>   RETURNS SETOF associates AS
> $BODY$
> begin 
> return query select * from associates;
> return;
> end;
> $BODY$
>   LANGUAGE 'plpgsql' VOLATILE;
> This works fine for above table but not works at all for accgroups table. As I
> searched for this over web, it is identified as a bug for tables whose columns
> are changed(deleted and added). Is it true? 
> How to solve this issue?
> Thanks
> CPK

I can't reproduce your problem:

test=# create table foo (a int, b int);
CREATE TABLE
test=# create or replace function get_foo() returns setof foo as $$begin return 
query select * from foo; return; end; $$ LANGUAGE 'plpgsql' VOLATILE;
CREATE FUNCTION
test=# select * from get_foo();
 a | b
---+---
(0 rows)

test=# alter table foo add column c int;
ALTER TABLE
test=# select * from get_foo();
 a | b | c
---+---+---
(0 rows)


(only if i drop a column):
test=# alter table foo drop column c;
ALTER TABLE
test=# select * from get_foo();
ERROR:  structure of query does not match function result type
CONTEXT:  PL/pgSQL function "get_foo" line 1 at RETURN QUERY



Please, provide us an example including the error you got.


Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Error: column "host" does not exist

[Mayuresh Nirhali]

Hello,

I am working with 8.1.4 pgsql as my database backend. I have a function 
written in plpgsql language, that queries a particular table as below,


select host from table_host where ip_address = ip_array[i] and port = 
port_array[i];


The query is running in a for loop. I see ip_array and port_array 
getting populated with correct values during the execution.

The error I see is,

ERROR:  column "host" does not exist
CONTEXT:  SQL statement "SELECT host"
   PL/pgSQL function "sp_get_ip_data" line 286 at raise

throu psql, I can select the table_host fine.
column "host" is a primary key here.

I dont understand why I see the "column does not exist" error; any idea ?

cheers
Mayuresh


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Need help! To build geos-3.0.x lib using Sun Studio 12 compiler [conflict in file ConvexHull.cpp]

[SATYAJIT TRIPATHI]

Hi there,

We are trying to build the PostGIS (1.3.5) extension to PostgreSQL (8.3) on
Solaris 10 Update 5 on an amd64 platform (Sun Fire X4100).

We are unable to build the geos (3.0.3) library on the same using Sun Studio
12 compiler. We have included the patches as mentioned in
http://trac.osgeo.org/geos/changeset/2131?format=diff&new=2131 to fix the
name space issue. However the following issue still persists :

--
CC: Warning: Option -Wall passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -ansi passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -pedantic passed to ld, if ld is invoked, ignored
otherwise
CC: Warning: Option -Wno-long-long passed to ld, if ld is invoked, ignored
otherwise
"../../source/headers/geos/platform.h", line 59: Warning: #warning "Could
not find 64bit integer definition!".
"../../source/headers/geos/geom/Coordinate.inl", line 140: Warning: Shift
count is too large.
"ConvexHull.cpp", line 122: Warning: inputPts hides
geos::algorithm::ConvexHull::inputPts.
"ConvexHull.cpp", line 161: Warning: inputPts hides
geos::algorithm::ConvexHull::inputPts.
"ConvexHull.cpp", line 210: Error: Could not find a match for
std::vector::assign(__rwstd::__rb_tree, geos::geom::CoordinateLessThen,
std::allocator>::const_iterator,
__rwstd::__rb_tree, geos::geom::CoordinateLessThen,
std::allocator>::const_iterator) needed in
geos::algorithm::ConvexHull::reduce(std::vector&).
1 Error(s) and 4 Warning(s) detected.
*** Error code 1
make: Fatal error: Command failed for target `ConvexHull.lo'
--


Any suggestion enabling us to build it successfully would be very helpful.

Thank you and warm regards
--Satya

Re: [GENERAL] Per-user schemas with inherited skeleton.

[Scott Marlowe]

On Wed, Jan 7, 2009 at 11:39 PM, Craig Ringer
 wrote:
> Scott Marlowe wrote:
>
 Is there a way to let PostgreSQL to allow inherited tables to be owned
 by different roles?
>>>
>>> Not that I know of, and given the security implications I'd be a bit
>>> nervous
>>> about it unless it was done via an explicitly GRANTed right.
>>
>> I hope here you're meaning to have tables that are inheritable by
>> various non-role members.  It works as long as everyone's in the same
>> group role with the right permissions.  Since you'd have to change
>> ownership to the group role for the parent table, everyone would, in
>> effect, own it now.  But if you wanna do it...
>
> That's right - I refer to inheritance by a user that's not a member of the
> role that owns the table.
>
> If the inheriting users *are* a member of the owning role of the parent
> table, then they can select and update the shared-structure part of OTHER
> users' records via the parent table, as well as their own. IIRC they can
> delete other users records via the parent table, too. Not ideal if the
> various users are supposed to be blind to each others' data, as appears to
> be the case here.

Also alter table gets locked by the child tables.  If stan, a member
of sharing, tries to change the inherited table top, which user ted
has inherited, he gets an error saying he has to have alter perms on
ted's table.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Per-user schemas with inherited skeleton.

[Scott Marlowe]

On Wed, Jan 7, 2009 at 11:39 PM, Craig Ringer
 wrote:
> Scott Marlowe wrote:
>
 Is there a way to let PostgreSQL to allow inherited tables to be owned
 by different roles?
>>>
>>> Not that I know of, and given the security implications I'd be a bit
>>> nervous
>>> about it unless it was done via an explicitly GRANTed right.
>>
>> I hope here you're meaning to have tables that are inheritable by
>> various non-role members.  It works as long as everyone's in the same
>> group role with the right permissions.  Since you'd have to change
>> ownership to the group role for the parent table, everyone would, in
>> effect, own it now.  But if you wanna do it...
>
> That's right - I refer to inheritance by a user that's not a member of the
> role that owns the table.
>
> If the inheriting users *are* a member of the owning role of the parent
> table, then they can select and update the shared-structure part of OTHER
> users' records via the parent table, as well as their own. IIRC they can
> delete other users records via the parent table, too. Not ideal if the
> various users are supposed to be blind to each others' data, as appears to
> be the case here.

No, it doesn't work that way.  Perms on the parent table are just
that, perms on the parent table.  I just tested it.  Given a role
called sharing, and two members stan and ted, and a parent table owned
by sharing, the users have to grant select on their tables to the
other users or the role they belong to or the other users can't see it
or change it.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Per-user schemas with inherited skeleton.

[Craig Ringer]

Scott Marlowe wrote:


Is there a way to let PostgreSQL to allow inherited tables to be owned
by different roles?

Not that I know of, and given the security implications I'd be a bit nervous
about it unless it was done via an explicitly GRANTed right.


I hope here you're meaning to have tables that are inheritable by
various non-role members.  It works as long as everyone's in the same
group role with the right permissions.  Since you'd have to change
ownership to the group role for the parent table, everyone would, in
effect, own it now.  But if you wanna do it...


That's right - I refer to inheritance by a user that's not a member of 
the role that owns the table.


If the inheriting users *are* a member of the owning role of the parent 
table, then they can select and update the shared-structure part of 
OTHER users' records via the parent table, as well as their own. IIRC 
they can delete other users records via the parent table, too. Not ideal 
if the various users are supposed to be blind to each others' data, as 
appears to be the case here.


--
Craig Ringer

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Per-user schemas with inherited skeleton.

[Scott Marlowe]

On Sun, Jan 4, 2009 at 9:05 PM, Craig Ringer
 wrote:
> alvar...@alvarezp.ods.org wrote:
>
>> (2) per-user schemas
>> with "CREATE TABLE (LIKE parent_table)", as getting the data from all
>> users at once would also be difficult and modifying the column
>> definition on the user tables would be pretty much error-prone.

If you are just replacing a couple of tables, and they don't need most
of the tables but can use the public schema this might be worthwhile
for some projects.  Everyone uses the public schema as the common one.

I agree with everything you posted after this, and a nice example of doing it.

>> Is there a way to let PostgreSQL to allow inherited tables to be owned
>> by different roles?
>
> Not that I know of, and given the security implications I'd be a bit nervous
> about it unless it was done via an explicitly GRANTed right.

I hope here you're meaning to have tables that are inheritable by
various non-role members.  It works as long as everyone's in the same
group role with the right permissions.  Since you'd have to change
ownership to the group role for the parent table, everyone would, in
effect, own it now.  But if you wanna do it...

The admin creates a group called sharing, all users are granted
sharing, so when they create a table they can share it or not.  If
they share it in the public schema then any user in the group can
inherit it, and search_path can make it the "default" table so to
speak.

The child tables are automatically created with the role of the user
not the group, so your user would have to remember to grant select to
the sharing role when they created a table.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Per-user schemas with inherited skeleton.

[Octavio Alvarez]

On Mon, 2009-01-05 at 13:05 +0900, Craig Ringer wrote:
> alvar...@alvarezp.ods.org wrote:
> 
> > On user account creation, the schema gets created and the interface
> > tries to do a "CREATE TABLE my_relation () INHERITS
> > (_skel.my_relation);" as the new role, but PostgreSQL returns the error
> > "must be owner of relation my_relations". I am assuming it refers to
> > _skel.my_relation.
> 
> > The following questions arose during the preparation of this test:
> > 
> > Why is ownership needed on the parent table?
> 
> I don't know for sure, but I'd say it's a security issue. Granting a 
> user ownership of a table that inherits another table gives them, as the 
> owner of the child table, the ability to (via the child table) INSERT 
> into the parent table, as well as DELETE/UPDATE/SELECT rows they've 
> previously inserted themselves.

I see. So, in other words, inserting a record in a table they don't have
INSERT privileges from would be just a matter of inheriting that table.

For the tables given in the _skel schema from this model, this is be the
way to go. The _skel tables are empty, and have foreign keys to other
secured-tables that prevent two users from having the same value in the
primary keys.

It is also possible to list the records from all users with a simple
SELECT directly from the the parent table in the _skel schema.

> You can also have the owner of the parent table CREATE the child
> table 
> with the inheritance relationship, then ALTER TABLE ... OWNER TO  to 
> give ownership of the child table away. You can wrap this within a 
> SECURITY DEFINER  Pl/PgSQL function if you want the eventual owning user 
> to be able to do it. eg, assuming for the sake of the example that 
> you're on a machine with `trust' authentication set to the db:

This is what bewildered me. So if parent and child tables CAN have
different owners, this is perfect for the model. Users can extend their
use of the database with an app of their own connecting with their own
role and permissions, it is still secure (or so it looks), and
administration is relatively simple.

> \c - super
> CREATE SCHEMA super;
> CREATE TABLE super.parent (x integer);
> 
> -- insert a dummy row, too. No end user should ever be able to see it,
> -- and it's just here to demonstrate that one user shouldn't be able 
> << snipped rest of SQL demonstration >>

Thank you for this detailed example. It proves to be secure enough.

CHECK constraints or FOREIGN keys to secured tables are present so the
users don't fill up the tables with dummy rows to perform a DoS. This
can or can not be ultimately desired, though.

> I guess it might be handy for a new right might be created called say 
> 'INHERIT'. This would let a table owner delegate the right to inherit 
> from the table to other users. Such a right does not presently exist. 
> There might be good reasons for it that I don't know about, or it might 
> simply be that nobody has wanted it - or at least, wanted it enough to 
> bother implementing it.
> 
> Do you? To me, it seems pretty easy to just create the table with the 
> same ownership as the parent then ALTER TABLE ... OWNER TO it away.

What *would* be even nicer is for PostgreSQL to expose the owner of the
row as a special column (say, "__owner_user") in a SELECT statement to
the parent table.

An INHERITS privilege is a very nice proposal for extension, though
through the use of SECURITY DEFINER we can achieve the same result and
it is good enough for this model. SECURITY DEFINER is comparable to
having a SUID-root program in a Unix system, with everything it implies.

Also, if this privilege would exist, PostgreSQL would need to provide
the owner of the parent table a way to use the before-mentioned special
__owner_user column as part of primary and unique keys.

This would be a good on the way of having a native way of setting up
row-level security based on user ownership (a la virtual private
database with some shared data).

Octavio.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] pg_bulkload

[Adrian Klaver]

On Wednesday 07 January 2009 4:10:34 pm John Randall wrote:
> Does anyone know if this utility can generate a log file of records that
> for some reason do not load to a PostgreSQL database? I’m looking for
> something like Oracle’s SQLLDR where an error is generated when a record
> fails to load. If not pg_bulkload, perhaps there is some other like
> utility. Thanks in advance

I don't know about pg_bulkload, but pgloader does:
http://pgfoundry.org/projects/pgloader/

-- 
Adrian Klaver
akla...@comcast.net

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] pg_bulkload

[John Randall]

Does anyone know if this utility can generate a log file of records that for 
some reason do not load to a PostgreSQL database? I’m looking for something 
like Oracle’s SQLLDR where an error is generated when a record fails to load. 
If not pg_bulkload, perhaps there is some other like utility. Thanks in advance


  

[GENERAL] Fail of a return query from plpgsql function for a specific table

[c k]

Hi all,I have a table accgroups and many others. I have written a test
function as follows.
CREATE OR REPLACE FUNCTION uf_testfunction()
  RETURNS SETOF associates AS
$BODY$
begin
return query select * from associates;
return;
end;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE;
This works fine for above table but not works at all for accgroups table. As
I searched for this over web, it is identified as a bug for tables whose
columns are changed(deleted and added). Is it true?
How to solve this issue?
Thanks
CPK

Re: [GENERAL] stable function called for every row?

[Tom Lane]

Gerhard Heift  writes:
> The function is called for every row in the table if it is stable or
> volatile and only once if it is immutable?

Yes, possibly.

> I thought it had to be called only once, if it is stable.

No.  Stable means that it is *okay* to call it only once per query,
not that that is *guaranteed* to happen.  (What it really does is give
the planner license to use an indexscan on a condition involving the
function --- an indexscan's comparison value is evaluated just once,
so it would give the wrong answers for a non-stable function.)

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] SPI_ERROR_CONNECT in plperl function

[Tom Lane]

I wrote:
> =?ISO-8859-1?Q?Christian_Schr=F6der?=  writes:
>> When I try to call the function I get the following error message:

>> test=# select * from testfunc();
>> ERROR:  error from Perl function: SPI_connect failed: SPI_ERROR_CONNECT 
>> at line 2.

> Hmph ... looks like plperl is shy a few SPI_push/SPI_pop calls.

I've applied a patch for this --- it'll be in the next set of update
releases.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] stable function called for every row?

[Pavel Stehule]

Hello,

stable, volatile, immutable flag doesn't necessary means caching or
not caching.

if you need really only one call, use srf function

postgres=# create table foo(a int);
CREATE TABLE
postgres=# insert into foo values(10),(20);
INSERT 0 2
postgres=# create function foof(bool) returns setof int as $$begin
raise notice 'foof call'; if $1 then return next 1; else return next
0; end if; return; end;$$ language plpgsql;
CREATE FUNCTION
postgres=# select * from foof(true);
NOTICE:  foof call
 foof
--
1
(1 row)


postgres=# select * from foo,foof(true);
NOTICE:  foof call
 a  | foof
+--
 10 |1
 20 |1
(2 rows)

regards
Pavel Stehule

2009/1/7 Gerhard Heift :
> I isolated my problem a little bit:
>
> CREATE FUNCTION get_array() RETURNS integer[] AS
> $BODY$
> BEGIN
>  RAISE INFO 'get_array';
>  RETURN ARRAY[1, 2];
> END
> $BODY$ LANGUAGE 'plpgsql' STABLE;
>
> And now
>
> SELECT * FROM generate_series(1,3) a(b) where array[b] <@ core.get_array();
>
> gives me:
>
> INFO:  get_array
> INFO:  get_array
> INFO:  get_array
>  b
> ---
>  1
>  2
> (2 rows)
>
> Why?? Wlli functions which returns an array not be cached?
>
> Regards,
>  Gerhard
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJZQ2Ea8fhU24j2fkRAlChAKCDTbhPdKxschTqScfhqRb5olvQ5wCcCcgl
> iMUlTPHTmX0jX/G84Pk82iA=
> =b/pY
> -END PGP SIGNATURE-
>
>

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] FreeBSD and large shared_buffers a no-go?

[Kirk Strauser]

On Jan 7, 2009, at 12:30 PM, Tom Lane wrote:


Kirk Strauser  writes:
First, shmget is asking for a lot less than shmmax - why is it  
failing?


Check to see if things work as expected when you have shmmax and  
shmall

set to a shade less than 2GB and fail when they are a shade more.  If
so, it would seem there's a signed-integer-overflow bug somewhere in  
the

kernel's handling of shmem requests ... which would be a reportable
kernel bug.


BTW, that's at http://www.freebsd.org/cgi/query-pr.cgi?pr=130274 for  
anyone who wants to follow along.

--
Kirk Strauser

Re: [GENERAL] stable function called for every row?

[Gerhard Heift]

I isolated my problem a little bit:

CREATE FUNCTION get_array() RETURNS integer[] AS
$BODY$
BEGIN
  RAISE INFO 'get_array';
  RETURN ARRAY[1, 2];
END
$BODY$ LANGUAGE 'plpgsql' STABLE;

And now

SELECT * FROM generate_series(1,3) a(b) where array[b] <@ core.get_array();

gives me:

INFO:  get_array
INFO:  get_array
INFO:  get_array
 b 
---
 1
 2
(2 rows)

Why?? Wlli functions which returns an array not be cached?

Regards,
  Gerhard


signature.asc
Description: Digital signature

Re: [GENERAL] encoding of PostgreSQL messages

[Karsten Hilbert]

Bruce, et al,

given the thread partially quoted below would this warrant a
TODO item "improve communication of encoding between client
and server regarding early startup messages" ?

A very usable band-aid for 8.4 - short of a proper fix -
would be the minimal-invasive sending of messages in 7-bit
English until server_encoding can be retrieved by the client
by current means.

Thanks,
Karsten

On Thu, Jan 01, 2009 at 08:33:56PM +0200, Peter Eisentraut wrote:
> Subject: Re: [GENERAL] encoding of PostgreSQL messages
> User-Agent: KMail/1.9.9
> 
> On Wednesday 31 December 2008 20:23:47 Tom Lane wrote:
> > > The proper fix is probably to include the client encoding in the
> > > connection startup message.
> >
> > What of errors occurring before such an option could be applied?
> 
> Connection errors are handled by the client, which knows the client encoding. 
>  
> If the setting of the client encoding would be one of the first things to be 
> done on the server side, you would only have a handful of possible error 
> conditions left (e.g., setlocale failed, out of memory).  You could choose to 
> report those in plain ASCII or send a special error code that the client can 
> resolve.  Although I guess no one could fault us if "could not set language" 
> is reported not translated. ;-)
> 
> > I think that ultimately it's necessary to accept that there will be some
> > window during connection startup where sending plain ASCII (English)
> > messages is the best recourse.
> 
> Ultimately yes.  But we currently handle the client encoding quite late in 
> the 
> startup sequence so that many connection startup failure messages that are of 
> interest to normal users would likely be affected.  So moving the client 
> encoding handling to the earliest possible phase would still be desirable.
> 
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] to_tsquery, plainto_... avoiding bad input, injections. Is there a builtin function for this ? Escaping?

[Mohamed]

Hi, I am wondering whether or not there exists any built in function for
making sure a query/textinput is not harmful or one that escapes them. If
not, what kind of things should I watch out for ?
As of now, I get errors on the quote ( ' ) if it is entered in an input and
in to_tsquery also on space. What other tokens should I be careful about?
How should I handle these ? How do I escape them ?

When fulltext indexing my text, is there any risk that the text being
indexed could be harmful if it contains certain characters ?

/ Moe

Re: [GENERAL] FreeBSD and large shared_buffers a no-go?

[Kirk Strauser]

On Jan 7, 2009, at 12:30 PM, Tom Lane wrote:


Kirk Strauser  writes:
First, shmget is asking for a lot less than shmmax - why is it  
failing?


Check to see if things work as expected when you have shmmax and  
shmall

set to a shade less than 2GB and fail when they are a shade more.  If
so, it would seem there's a signed-integer-overflow bug somewhere in  
the

kernel's handling of shmem requests ... which would be a reportable
kernel bug.



Actually, it seems that if shmget is trying to get more than 2GB, it  
will fail regardless of shmmax.  When I backed shared_buffers down to  
1980MB, PostgreSQL was able to start as long as shmmax is >= 2GB  
(which I verified with 2GB+1MB, 3GB, and 8GB).  I'm off to file a  
report now.

--
Kirk Strauser

[GENERAL] stable function called for every row?

[Gerhard Heift]

Hello,

I have a query like this:

SELECT * FROM table WHERE has_permission('permission_name');

and the function

CREATE FUNCTION has_permission(IN pname text, OUT is_ok boolean) RETURNING 
boolean AS
$BODY$
BEGIN
  SELECT has_perm INTO is_ok FROM permission WHERE title = pname;

  RAISE INFO 'function called';

  IF is_ok IS FALSE THEN
-- this function is VOLATILE
PERFORM log.exception('permission denied');
  END IF;

  RETURN;
END
$BODY$ LANGUAGE 'plpgsql' STABLE SECURITY DEFINER;

The function is called for every row in the table if it is stable or
volatile and only once if it is immutable?

I thought it had to be called only once, if it is stable.

(PostgreSQL 8.3.5)

Regards,
 Gerhard


signature.asc
Description: Digital signature

Re: [GENERAL] FreeBSD and large shared_buffers a no-go?

[Tom Lane]

Kirk Strauser  writes:
> First, shmget is asking for a lot less than shmmax - why is it failing?

Check to see if things work as expected when you have shmmax and shmall
set to a shade less than 2GB and fail when they are a shade more.  If
so, it would seem there's a signed-integer-overflow bug somewhere in the
kernel's handling of shmem requests ... which would be a reportable
kernel bug.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] FreeBSD and large shared_buffers a no-go?

[Kirk Strauser]

I'm running PostgreSQL 8.3.5 on a FreeBSD 7.1/amd64 system with 8GB of  
RAM and two quad-core Xeon CPUs.  The data filesystem is on a battery- 
backed RAID-10 system.  This is a dedicated server so I want to commit  
all resources to PostgreSQL alone.  The database will get hit with a  
lot of small, quick queries with a few complex 10-second ones thrown  
in, and gets hourly bulk uploads to the tune of a few million rows.


This is actually an upgrade from older hardware that handled the load  
just fine, so I know this system will perform well.  My biggest  
concern is getting the best performance for my boss's money.


I'm using the default postgresql.conf with the following additions:

max_connections = 400
listen_addresses = '*'
shared_buffers = 2GB
temp_buffers = 32MB
work_mem = 64MB
maintenance_work_mem = 256MB
max_stack_depth = 500MB
max_fsm_pages = 204800
full_page_writes = off
wal_buffers = 1MB
commit_delay = 10
checkpoint_segments = 32
random_page_cost = 2.0
effective_cache_size = 4GB
default_statistics_target = 100
log_connections = on
log_disconnections = on
log_min_duration_statement = 5000
log_statement = 'ddl'

Now, what's confusing me is that I've set shmmax to 3GB and shmall to  
3GB/4096 (the page size):


$ sysctl kern.ipc.shmmax
kern.ipc.shmmax: 3221225472
$ sysctl kern.ipc.shmall
kern.ipc.shmall: 786432
$ sysctl hw.pagesize
hw.pagesize: 4096

However, when shared_buffers is 2GB (one fourth of 8GB of RAM),  
PostgreSQL's startup fails with a call to allocated shared memory:


Jan  7 11:39:24 db1 postgres[60872]: [1-1] FATAL:  could not create  
shared memory segment: Cannot allocate memory
Jan  7 11:39:24 db1 postgres[60872]: [1-2] DETAIL:  Failed system call  
was shmget(key=5432001, size=2209497088, 03600).
Jan  7 11:39:24 db1 postgres[60872]: [1-3] HINT:  This error usually  
means that PostgreSQL's request for a shared memory segment exceeded  
available memory or swap space.
Jan  7 11:39:24 db1 postgres[60872]: [1-4]  To reduce the request size  
(currently 2209497088 bytes), reduce PostgreSQL's shared_buffers  
parameter (currently 262144) and/or
Jan  7 11:39:24 db1 postgres[60872]: [1-5]  its max_connections  
parameter (currently 403).
Jan  7 11:39:24 db1 postgres[60872]: [1-6] 	The PostgreSQL  
documentation contains more information about shared memory  
configuration.


First, shmget is asking for a lot less than shmmax - why is it failing?

Second, does the "one fourth of RAM" rule of thumb still apply on  
systems with decent amounts of memory?


Third, is there anything else I can be doing to take advantage of this  
RAM and 8 CPU cores?


Thanks!
--
Kirk Strauser

Re: [GENERAL] The length of a tsvector (lexemes + positions) must be less than 1 megabyte

[Tom Lane]

Mohamed  writes:
> http://www.postgresql.org/docs/8.3/interactive/textsearch-limitations.html
> The length of a tsvector (lexemes + positions) must be less than 1 megabyte
>> 

> What does this mean ? Is that per column and row or for the whole index ?

It's for a single tsvector value, which means one table entry.

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Slow Vacuum was: vacuum output question

[Scott Marlowe]

On Wed, Jan 7, 2009 at 10:26 AM, Dan Armbrust
 wrote:
> I'm no closer to a solution, but here are some additional data points
> - all taken on Fedora Core 6.

So, what does vmstat 10 say when you're running the "long" vacuum on
each system?

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Slow Vacuum was: vacuum output question

[Dan Armbrust]

I'm no closer to a solution, but here are some additional data points
- all taken on Fedora Core 6.

Postgres 8.1 built from source.  Auto vacuum disabled.

Create Empty Database.
Run our load on the system for 2 hours to  populate and exercise the database.
Run Vacuum.  Takes more than a minute.
Run Vacuum immediately again.  Takes more than a minute.
Reindex the database.  Takes 10 seconds.
Run Vacuum again.  Takes 2 seconds.
Allow load to run on the system for 30 minutes.
Run Vacuum again.  Takes more than a minute.


Postgres 8.3 built from source.  Auto vacuum disabled.

Create Empty Database.
Run our load on the system for 2 hours to  populate and exercise the database.
Run Vacuum.  Takes more than a minute.
Run Vacuum immediately again.  Takes 15 seconds.
Run Vacuum immediately again.  Takes 15 seconds.
Reindex the database.  Takes 10 seconds.
Run Vacuum again.  Takes 2 seconds.

So, PostgreSQL 8.3 shows better behaviour, but it is still showing
some sort of performance issue which a reindex fixes.
And then of course, the kicker is that we can't recreate any of these
issues when running the same exact test, on the same exact hardware -
but using a different underlying OS.  When we were running under a
modern Ubuntu, the vacuum never takes more than 2 seconds.  We will be
checking other OSs soon.  I guess if we can't figure out what is
causing it, we can at least isolate the distros that we need to tell
our customers not to use (or to schedule a reindex if they insist on
not upgrading their OS)

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] The length of a tsvector (lexemes + positions) must be less than 1 megabyte

[Mohamed]

http://www.postgresql.org/docs/8.3/interactive/textsearch-limitations.html

The length of a tsvector (lexemes + positions) must be less than 1 megabyte
>

What does this mean ? Is that per column and row or for the whole index ?

Re: [GENERAL] explain

[Jaime Casanova]

On Wed, Jan 7, 2009 at 10:53 AM, hubert depesz lubaczewski
 wrote:
>
> p.s. as you can clearly see from another mails from this list - the list
> uses english language. please use it, or if you'd like to use spanish
> (i'm not sure if your language if spanish, i don't know it) - you can
> use list pgsql-es-ayuda
> (http://archives.postgresql.org/pgsql-es-ayuda/).
>

oops! i answered in spanish too! i never saw the list it was sent to...


-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] explain

[Jaime Casanova]

2009/1/7 Gustavo Rosso :
> Es 1.213ms un valor correcto para realizar un insert en una tabla obtenido
> por explain analyze.

eso es un poco mas de un milisegundo, no parece mucho... en todo caso
el tiempo que demore un INSERT dependera en parte de la cantidad de
indices, FK y triggers que tenga una tabla


-- 
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] explain

[hubert depesz lubaczewski]

On Wed, Jan 07, 2009 at 01:30:54PM -0300, Gustavo Rosso wrote:
> Es 1.213ms un valor correcto para realizar un insert en una tabla  
> obtenido por explain analyze.

trochę długo, ale to zależy od sprzętu. dodatkowo - może masz tam
triggery? klucze obce? ciężko powiedzieć. pokaż schemat tabeli i tego
inserta to coś więcej będziemy mogli powiedzieć.

depesz

p.s. as you can clearly see from another mails from this list - the list
uses english language. please use it, or if you'd like to use spanish
(i'm not sure if your language if spanish, i don't know it) - you can
use list pgsql-es-ayuda
(http://archives.postgresql.org/pgsql-es-ayuda/).

-- 
Linkedin: http://www.linkedin.com/in/depesz  /  blog: http://www.depesz.com/
jid/gtalk: dep...@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] explain

[Gustavo Rosso]

Es 1.213ms un valor correcto para realizar un insert en una tabla 
obtenido por explain analyze.

Gustavo

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] RCA for MemoryContextAlloc: invalid request size(Known Issue)

[David Fetter]

On Wed, Jan 07, 2009 at 06:07:02AM -0800, yogvinder wrote:
> 
> Hi All,
> 
> I am having multiple postgresql 7.3(pretty old version now) on rhel4
> servers.

Not just "pretty old," but past any community support.  You'll need to
build and implement an upgrade strategy along with doing your upgrade.

> I am getting the error MemoryContextAlloc: invalid request size on
> many of these servers from time to time.
> 
> On crawling through net, I have found that its because of some bad
> word value in a variable length field which implies database
> corruption. A possible solution to recover database is by deleting
> the corrupted row and then continuing till all the bad rows are
> deleted.
> 
> My Queries: 1) What is the root cause? Why database is getting
> corrupted. 

The root cause is that whoever was responsible for this cluster failed
to upgrade to a supported version.  Don't Do That Again :)

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] RCA for MemoryContextAlloc: invalid request size(Known Issue)

[Richard Huxton]

yogvinder wrote:
> Hi All,
> 
> I am having multiple postgresql 7.3(pretty old version now) on rhel4
> servers.

Which 7.3? Are you aware the community doesn't even officially support
them now?

> I am getting the error MemoryContextAlloc: invalid request size on many of
> these servers from time to time.
> 
> On crawling through net, I have found that its because of some bad word
> value in a variable length field which implies database corruption. A
> possible solution to recover database is by deleting the corrupted row and
> then continuing till all the bad rows are deleted.
> 
> My Queries:
> 1) What is the root cause? Why database is getting corrupted. 

Hardware problems or a bug in the code. If it's happening on a regular
basis it might well be hardware.

> 2) Is any newer version or patch can take care of this issue.

The last download for 7.3 is 7.3.21

http://www.postgresql.org/ftp/source/OLD/

> 3) Any other solution for the same that can update the corrupted data.

If you're using RHEL check with RedHat and see what the latest RPM they
offer is.

-- 
  Richard Huxton
  Archonet Ltd

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] RCA for MemoryContextAlloc: invalid request size(Known Issue)

[yogvinder]

Hi All,

I am having multiple postgresql 7.3(pretty old version now) on rhel4
servers.

I am getting the error MemoryContextAlloc: invalid request size on many of
these servers from time to time.

On crawling through net, I have found that its because of some bad word
value in a variable length field which implies database corruption. A
possible solution to recover database is by deleting the corrupted row and
then continuing till all the bad rows are deleted.

My Queries:
1) What is the root cause? Why database is getting corrupted. 

2) Is any newer version or patch can take care of this issue.

3) Any other solution for the same that can update the corrupted data.


Regards,
Yogvinder Singh



-- 
View this message in context: 
http://www.nabble.com/RCA-for-MemoryContextAlloc%3A-invalid-request-size%28Known-Issue%29-tp21331952p21331952.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] How do I 'include' a stored procedure in a SQL script file

[A. Kretschmer]

In response to Donna Rudd :
> Hi,
> All I want to do is 'include' a stored procedure (contained in another
> script file) into my main PostgreSQL database creation script file so that
> it can get defined/declared before I define my triggers to call it. It seems
> such a simple thing but I don't seem to be able to find any examples or
> documentation. Please help!

Your main script file is executed with psql? You can use \i 
within your main-file.


Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID:   0x3FFF606C, privat 0x7F4584DA   http://wwwkeys.de.pgp.net

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] How do I 'include' a stored procedure in a SQL script file

[Serge Fonville]

An .sql file is just a list of sql you can just as well enter when running
psql.If you had the psql prompt open, what would you type to execute the
commands in an .sql file, limited to 'true' sql and not psql specific
commands

If you know that you know which lines to add to the .sql file

Hope this helps

Regards,

Serge fonville

On Wed, Jan 7, 2009 at 12:41 PM, Donna Rudd  wrote:

> Hi,
> All I want to do is 'include' a stored procedure (contained in another
> script file) into my main PostgreSQL database creation script file so that
> it can get defined/declared before I define my triggers to call it. It
> seems
> such a simple thing but I don't seem to be able to find any examples or
> documentation. Please help!
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

[GENERAL] How do I 'include' a stored procedure in a SQL script file

[Donna Rudd]

Hi,
All I want to do is 'include' a stored procedure (contained in another
script file) into my main PostgreSQL database creation script file so that
it can get defined/declared before I define my triggers to call it. It seems
such a simple thing but I don't seem to be able to find any examples or
documentation. Please help!


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Running exe problem

[Dave Page]

On Wed, Jan 7, 2009 at 9:40 AM, Shahbaz A. Tyagi
 wrote:
> We have not installed the Postgre but we are trying to use the binaries
> directly.

Did you read the README?

postgresql-8.3.5-1-binaries-no-installer.zip is a zip of the PostgreSQL
installation directory. It does not include any of the bundled apps or
drivers and is intended for expert users only! This bundle requires the
Microsoft Visual C++ 8.0 runtimes to be installed on your system. A
seperate installer can be downloaded from:

http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Running exe problem

[Shahbaz A. Tyagi]

Yeah, thanks guys, we were able to run it in one machine but not in our main
server, hence the confusion came. Than we installed other version of
runtimes but now we installed the correct one as suggested, hence worked.



Thanks,
 
Shahbaz A. Tyagi
Sphere Networks


-Original Message-
From: Dave Page [mailto:dp...@pgadmin.org] 
Sent: Wednesday, January 07, 2009 1:51 PM
To: Shahbaz A. Tyagi
Cc: Ashesh Vashi; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Running exe problem

On Wed, Jan 7, 2009 at 9:40 AM, Shahbaz A. Tyagi
 wrote:
> We have not installed the Postgre but we are trying to use the binaries
> directly.

Did you read the README?

postgresql-8.3.5-1-binaries-no-installer.zip is a zip of the PostgreSQL
installation directory. It does not include any of the bundled apps or
drivers and is intended for expert users only! This bundle requires the
Microsoft Visual C++ 8.0 runtimes to be installed on your system. A
seperate installer can be downloaded from:

http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-
984d-389c36f85647&DisplayLang=en


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Running exe problem

[Shahbaz A. Tyagi]

We have not installed the Postgre but we are trying to use the binaries
directly.

 

Thanks,

 

 

 

Shahbaz

 

 

 

 

 

 

 

 

 

  _  

From: Ashesh Vashi [mailto:ashesh.va...@enterprisedb.com] 
Sent: Wednesday, January 07, 2009 1:38 PM
To: Shahbaz A. Tyagi
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Running exe problem

 

How did you install PostgreSQL on your system?
Microsoft Visual Studio redistribution binaries are missing on your system.

Download it from the following link and install it.
http://www.microsoft.com/downloads/details.aspx?familyid=200b2fd9-ae1a-4a14-
984d-389c36f85647
 &displaylang=en

After installing it, postgresql should run properly.

-- 

Regards,
Ashesh Vashi
(Software Engineer)

EnterpriseDB INDIA: http://www.enterprisedb.com 


Shahbaz A. Tyagi wrote: 

Hi,

 

While trying to run "pg_ctl.exe" with valid parameters, using command prompt
in windows XP sp2 machine, it's not getting executed.

 

In event viewer we are getting following events,

 


__

 

Event Type: Error

Event Source:  SideBySide

Event Category:  None

Event ID: 32

Date:   1/6/2009

Time:5:30:42 PM

User:N/A

Computer:   BOB

Description:

Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was
The referenced assembly is not installed on your system.

 

 

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

 

 

 



-

 

 

 

Event Type: Error

Event Source:  SideBySide

Event Category:  None

Event ID: 59

Date:   1/7/2009

Time:12:25:27 PM

User:N/A

Computer:   BOB

Description:

Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error
message: The referenced assembly is not installed on your system.

.

 

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

 


__

 

 

Please suggest,

 

 

Thanks,

 

Shahbaz

Re: [GENERAL] Running exe problem

[Grzegorz Jaśkiewicz]

On Wed, Jan 7, 2009 at 9:15 AM, Shahbaz A. Tyagi
 wrote:
> Hi,
>
>
>
> While trying to run "pg_ctl.exe" with valid parameters, using command prompt
> in windows XP sp2 machine, it's not getting executed.

> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.

ol

-- 
GJ

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Running exe problem

[Ashesh Vashi]

How did you install PostgreSQL on your system?
Microsoft Visual Studio redistribution binaries are missing on your system.

Download it from the following link and install it.
http://www.microsoft.com/downloads/details.aspx?familyid=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en

After installing it, postgresql should run properly.
--
Regards,
Ashesh Vashi
(Software Engineer)

EnterpriseDB INDIA: http://www.enterprisedb.com

Shahbaz A. Tyagi wrote:


Hi,

 

While trying to run "pg_ctl.exe" with valid parameters, using command 
prompt in windows XP sp2 machine, it's not getting executed.


 


In event viewer we are getting following events,

 


__

 


Event Type: Error

Event Source:  SideBySide

Event Category:  None

Event ID: 32

Date:   1/6/2009

Time:5:30:42 PM

User:N/A

Computer:   BOB

Description:

Dependent Assembly Microsoft.VC80.CRT could not be found and Last 
Error was The referenced assembly is not installed on your system.


 

 

For more information, see Help and Support Center at 
http://go.microsoft.com/fwlink/events.asp.


 

 

 


-

 

 

 


Event Type: Error

Event Source:  SideBySide

Event Category:  None

Event ID: 59

Date:   1/7/2009

Time:12:25:27 PM

User:N/A

Computer:   BOB

Description:

Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference 
error message: The referenced assembly is not installed on your system.


.

 

For more information, see Help and Support Center at 
http://go.microsoft.com/fwlink/events.asp.


 


__

 

 


Please suggest,

 

 


Thanks,

 


Shahbaz

[GENERAL] Running exe problem

[Shahbaz A. Tyagi]

Hi,

 

While trying to run "pg_ctl.exe" with valid parameters, using command prompt
in windows XP sp2 machine, it's not getting executed.

 

In event viewer we are getting following events,

 


__

 

Event Type: Error

Event Source:  SideBySide

Event Category:  None

Event ID: 32

Date:   1/6/2009

Time:5:30:42 PM

User:N/A

Computer:   BOB

Description:

Dependent Assembly Microsoft.VC80.CRT could not be found and Last Error was
The referenced assembly is not installed on your system.

 

 

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

 

 

 



-

 

 

 

Event Type: Error

Event Source:  SideBySide

Event Category:  None

Event ID: 59

Date:   1/7/2009

Time:12:25:27 PM

User:N/A

Computer:   BOB

Description:

Resolve Partial Assembly failed for Microsoft.VC80.CRT. Reference error
message: The referenced assembly is not installed on your system.

.

 

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

 


__

 

 

Please suggest,

 

 

Thanks,

 

Shahbaz