Re: Thread safe connection-name mapping in ECPG. Is it - Mailing list pgsql-hackers

From Lee Kindness
Subject Re: Thread safe connection-name mapping in ECPG. Is it
Date
Msg-id 006a01c40176$9892e930$2c8fe150@coulter
Whole thread Raw
In response to Re: Thread safe connection-name mapping in ECPG. Is it  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Thread safe connection-name mapping in ECPG. Is it
List pgsql-hackers
Shridhar, want to discuss this off list a bit to work through the various
options and then revent back to the list with a suitable to-do (for
discussion)?

L.

----- Original Message -----
From: "Shridhar Daithankar" <shridhar@frodo.hserus.net>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Wednesday, March 03, 2004 2:10 PM
Subject: Re: Thread safe connection-name mapping in ECPG. Is it


> Oh.. By all means..Please do..
>
> The reason I posted it because I didn't wanted to work on it if core is
not
> going to accept it on account of non-compliance with spec.
>
> Is this fine?
>   * Allow a 'connection *' pointer to be specified instead of a string to
denote
> a connection.
>
> I plan to work on it whenever possible. What I would like to do is
eliminate the
> locks around name->connection mapping as we would be directly using the
> connection instead of a name.
>
> I think we can also add the SQL-CA to connection structure so that each
> connection gets it's  own SQL-CA. That way ECPG is as thread-safe as the
calling
> application gets.
>
> And on the plus side we don't have to worry about platform specific
threading
> models either.
>
> Thoughts?
>
>   Shridhar
>
> Bruce Momjian wrote:
>
> > Should I add this to the TODO list?
> >
>
> --------------------------------------------------------------------------
-
> >
> > Lee Kindness wrote:
> >
> >>Sort of related, I was thinking about adding some more thread-related
> >>code such that if a connection wasn't explicitely specified then the
> >>last connection SET or CONNECTed to for the current thread is used,
> >>rather than just the "last connection".
> >>
> >>But yeah, specifying the connection by variable (be it string or
> >>connection ptr) would be a definite step forward. Currently you cannot
> >>write a generic function like:
> >>
> >> int getit(char *using_connection)
> >> {
> >>  EXEC SQL BEGIN DECLARE SECTION;
> >>  char *s_connection = using_connection;
> >>  int s_it;
> >>  EXEC SQL END DECLARE SECTION;
> >>
> >>  EXEC SQL AT :s_connection SELECT it INTO :s_it FROM some_table;
> >>  return( s_it );
> >> }
> >>
> >>which could be run concurrently by multiple threads.
> >>
> >>L.
> >>
> >>Shridhar Daithankar writes:
> >> > On Friday 27 February 2004 20:54, Michael Meskes wrote:
> >> > > On Fri, Feb 27, 2004 at 04:22:33PM +0530, Shridhar Daithankar
wrote:
> >> > > > How about, allowing 'connection *'? If somebody puts a
'connection *'
> >> > > > there it is used. If it is a string a name search is performed.
Best of
> >> > > > both worlds.
> >> > >
> >> > > How shall anyone put a pointer to a connection struct inside the
SQL
> >> > > statement?
> >> > >
> >> > > It would help me a lot if you'd be able to give some examples.
> >> >
> >> > EXEC SQL BEGIN DECLARE SECTION;
> >> >  connect *connectionPtr;
> >> > EXEC SQL END DECLARE SECTION;
> >> >
> >> > EXEC SQL CONNECT TO db AS connectionPtr;
> >> > EXEC SQL AT connectionPtr SELECT 1;
> >> >
> >> > After all, it is matter of parsing some code and emitting equivalent
C code,
> >> > isn't it?
> >> >
> >> >  Shridhar
> >>
> >>---------------------------(end of broadcast)---------------------------
> >>TIP 4: Don't 'kill -9' the postmaster
> >>
> >
> >
>
>



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Out of space situation and WAL log pre-allocation (was
Next
From: Tom Lane
Date:
Subject: Re: [PERFORM] WAL Optimisation - configuration and usage