+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Any problems I backport the
http://svn.apache.org/viewvc?rev=657500view=rev
to 1.2 and 1.3 ?
I'm only worried about misuse; could you add a doxygen note that removing
the shm while in-use is absolutely not portable?
Think that docs clearly
Mladen Turk wrote:
The pool cleanup of apr_shm_create (apr_shm_destroy)
also removes the named resource
Now this is not true for win32, because the created
file never gets deleted afterwards, so IMHO this
should be fixed by actually deleting the mapping file
in shm_cleanup (distinguishing
I'm reviewing the providers themselves and trying to determine how and when
the dbd lock api should be used vs. a dso-module apr-util wide mutex should
be used instead.
The oracle provider alone is using this lock to prepare statements. While
the sqlite3 provider seems to use it much more
William A. Rowe, Jr. wrote:
I'm reviewing the providers themselves and trying to determine how and when
the dbd lock api should be used vs. a dso-module apr-util wide mutex should
be used instead.
The oracle provider alone is using this lock to prepare statements. While
the sqlite3 provider
On Mon, May 19, 2008 at 08:58:32AM +1000, Bojan Smojver wrote:
On Sat, 2008-05-17 at 09:07 -0400, Bob Rossi wrote:
I've been using sqlite3 dbd for some time now. I find that the function
apr_dbd_get_row,
On Sat, May 17, 2008 at 10:23:59AM +1000, Bojan Smojver wrote:
On Fri, 2008-05-16 at 06:26 -0400, Bob Rossi wrote:
configure:40279: gcc -o conftest -g -Wall -pthread -DLINUX=2
-D_REENTRANT -D_GNU_SOURCE conftest.c -lcrypt 5
configure:40285: $? = 0
configure:40313: result:
On Fri, May 16, 2008 at 11:21:46AM +1000, Bojan Smojver wrote:
On Thu, 2008-05-15 at 09:08 -0400, Bob Rossi wrote:
So,
I get a link error, because it needs to link against -lcrypt.
What kind of system do you have? Where does the -lcrypt live on your
system?
BTW, doing the pg_config
William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
I'm reviewing the providers themselves and trying to determine how and
when the dbd lock api should be used vs. a dso-module apr-util wide mutex
should be used instead.l
The oracle provider alone is using this lock to prepare
Tom Donovan wrote:
And a related question, any prepared statement can be portably used
across
any of the databases open within the specific provider. Correct?
In general no. Most databases consider a prepared statement to be
associated with a single database. This would seldom make sense,
On Mon, 2008-05-19 at 15:54 -0400, Bob Rossi wrote:
So basically I need -lSecur32 and ws2_32. What can I do about this?
I don't have any Windows machines (nor development tools), so I cannot
do this. I'm sure someone else on the list that does will pick this up.
Sorry...
--
Bojan
On Tue, May 20, 2008 at 07:05:51AM +1000, Bojan Smojver wrote:
On Mon, 2008-05-19 at 15:54 -0400, Bob Rossi wrote:
So basically I need -lSecur32 and ws2_32. What can I do about this?
I don't have any Windows machines (nor development tools), so I cannot
do this. I'm sure someone else on
On Mon, 2008-05-19 at 16:07 -0400, Bob Rossi wrote:
You know, I really think you should be using the --libs there. What
could the downside be? It's not like you need to add all the --libs to
the apr libs. It's just setup temporarily to get the -lpq to link.
This returns libraries that were
On Mon, 2008-05-19 at 16:33 -0400, Tom Donovan wrote:
It appears to be a presumption that only one dbd provider is used in an
application. A private
per-provider lock seems like a much better idea for dbd drivers which use it
like SQLite Oracle do.
Actually, in my apps I use all drivers,
Bojan Smojver wrote:
On Mon, 2008-05-19 at 16:07 -0400, Bob Rossi wrote:
You know, I really think you should be using the --libs there. What
could the downside be? It's not like you need to add all the --libs to
the apr libs. It's just setup temporarily to get the -lpq to link.
This returns
On Mon, May 19, 2008 at 04:22:18PM -0500, William A. Rowe, Jr. wrote:
Bojan Smojver wrote:
On Mon, 2008-05-19 at 16:07 -0400, Bob Rossi wrote:
You know, I really think you should be using the --libs there. What
could the downside be? It's not like you need to add all the --libs to
the apr
On Mon, 2008-05-19 at 15:56 -0500, William A. Rowe, Jr. wrote:
Then if we consider this non-portable, the prepared statement cache
certainly should not be a static, but scoped per apr_dbd_t?
I would prefer we /not/ offer dbd specific features, as the hacks around
the initial row offset
William A. Rowe, Jr. wrote:
Tom Donovan wrote:
And a related question, any prepared statement can be portably used
across
any of the databases open within the specific provider. Correct?
In general no. Most databases consider a prepared statement to be
associated with a single database.
Tom Donovan wrote:
I don't quite follow you here.
Are you referring to the Oracle dbd driver prepared-statement cache?
yes; my question is, even if we do construct a cache, is module lifetime
appropriate? When accessed by several different consumers at once? (e.g.
two libraries that rely
On Mon, 2008-05-19 at 16:22 -0500, William A. Rowe, Jr. wrote:
Well I'd rather it include more libraries than needed (which are not bound
on more sophisticated linkers) than an insufficient number.
OK, I'll do --libs then.
--
Bojan
On Mon, 2008-05-19 at 17:37 -0500, William A. Rowe, Jr. wrote:
yes; my question is, even if we do construct a cache, is module lifetime
appropriate? When accessed by several different consumers at once? (e.g.
two libraries that rely on dbd, or several different httpd modules and
William A. Rowe, Jr. wrote:
Are you referring to the Oracle dbd driver prepared-statement cache?
yes; my question is, even if we do construct a cache, is module lifetime
appropriate? When accessed by several different consumers at once? (e.g.
two libraries that rely on dbd, or several
Chris Darroch wrote:
William A. Rowe, Jr. wrote:
Are you referring to the Oracle dbd driver prepared-statement cache?
yes; my question is, even if we do construct a cache, is module lifetime
appropriate? When accessed by several different consumers at once?
(e.g.
two libraries that rely
On Tue, May 20, 2008 at 08:48:39AM +1000, Bojan Smojver wrote:
On Mon, 2008-05-19 at 16:22 -0500, William A. Rowe, Jr. wrote:
Well I'd rather it include more libraries than needed (which are not bound
on more sophisticated linkers) than an insufficient number.
OK, I'll do --libs then.
On Mon, 2008-05-19 at 20:05 -0400, Bob Rossi wrote:
If you make the change, I'll test out the latest snapshots and all your
fixes for me. Thanks so much Bojan!
Done. And you are welcome.
--
Bojan
On Tue, May 20, 2008 at 10:11:38AM +1000, Bojan Smojver wrote:
On Mon, 2008-05-19 at 20:05 -0400, Bob Rossi wrote:
If you make the change, I'll test out the latest snapshots and all your
fixes for me. Thanks so much Bojan!
Done. And you are welcome.
Hi Bojan,
This is almost correct.
On Mon, 2008-05-19 at 20:47 -0400, Bob Rossi wrote:
This is almost correct. It's simply missing the -L to the postgresql/lib
directory. My program failed to link because it couldn't find -lpgport
which lives there.
If fact, PostgreSQL manual
On Tue, 2008-05-20 at 11:21 +1000, Bojan Smojver wrote:
If fact, PostgreSQL manual
(http://www.postgresql.org/docs/8.3/static/libpq-build.html) confirms
that we should be using just --libdir.
BTW, if --libdir alone doesn't cut it for you for some reason, I'll add
--libs back too. But, if it
On Tue, May 20, 2008 at 11:24:03AM +1000, Bojan Smojver wrote:
On Tue, 2008-05-20 at 11:21 +1000, Bojan Smojver wrote:
If fact, PostgreSQL manual
(http://www.postgresql.org/docs/8.3/static/libpq-build.html) confirms
that we should be using just --libdir.
BTW, if --libdir alone doesn't
On Mon, May 19, 2008 at 08:58:32AM +1000, Bojan Smojver wrote:
On Sat, 2008-05-17 at 09:07 -0400, Bob Rossi wrote:
I've been using sqlite3 dbd for some time now. I find that the function
apr_dbd_get_row,
William A. Rowe, Jr. wrote:
Then my thought is to remove the code entirely from apr branch 1.3.x and
encourage it's development and refinement on trunk.
Personally, I'd suggest just removing it from trunk too ... I'm
not sure exactly how a global cache could be made to work across
multiple
On Mon, 2008-05-19 at 18:48 -0700, Chris Darroch wrote:
Personally, I'd suggest just removing it from trunk too ... I'm
not sure exactly how a global cache could be made to work across
multiple databases, since they might be of different versions, etc.
It's not likely to be trivial, I
Here is a patch I've been toying with. Essentially, it does these
things:
- cleans up PostgreSQL detection a bit more
- uses APRUTIL_PRIV_INCLUDES for all CPPFLAGS driver stuff (i.e. we
don't need to expose that to users of APU)
- is careful not to place LDFLAGS of drivers into APRUTIL_LDFLAGS
33 matches
Mail list logo
