Here is a WIP patch to make prepared statements thread-safe in ecpg.
The variable prep_stmts was global but not protected by any locks.
I divided it into per-connection field so that we can access prepared
statements separately in each thread.
I needed to change the following exported functions,
On Mon, 2007-09-24 at 21:26 -0500, Jaime Casanova wrote:
On 9/24/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Sat, 2007-09-22 at 23:49 -0500, Jaime Casanova wrote:
On 6/19/07, Simon Riggs [EMAIL PROTECTED] wrote:
related TODO items:
- add a WAIT n clause in same SQL locations as
On Tue, 2007-04-10 at 16:23 +0900, Koichi Suzuki wrote:
Here're two patches for
1) lesslog_core.patch, patch for core, to set a mark to the log record
to be removed in archiving,
2) lesslog_contrib.patch, patch for contrib/lesslog, pg_compresslog and
pg_decompresslog,
respectively,
On Tue, Sep 25, 2007 at 03:22:13PM +0900, ITAGAKI Takahiro wrote:
Here is a WIP patch to make prepared statements thread-safe in ecpg.
The variable prep_stmts was global but not protected by any locks.
I divided it into per-connection field so that we can access prepared
statements separately
Simon Riggs [EMAIL PROTECTED] writes:
SQLServer and DB2 have more need of this than PostgreSQL, but we do
still need it.
Why? What does it do that statement_timeout doesn't do better?
regards, tom lane
---(end of
On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
SQLServer and DB2 have more need of this than PostgreSQL, but we do
still need it.
Why? What does it do that statement_timeout doesn't do better?
If the execution time is negligible, then setting
Simon Riggs [EMAIL PROTECTED] writes:
On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
SQLServer and DB2 have more need of this than PostgreSQL, but we do
still need it.
Why? What does it do that statement_timeout doesn't do better?
If the
This hook seems very strangely defined to me. Why did you not put the
hook at the point where the current geqo-vs-regular decision is made?
The reason is that I thought about gaining a control over the algorithm
used to solve individual subproblems in make_rel_from_joinlist. If we would
Marshall, Steve wrote:
I'm glad to see the patch making its way through the process. I'm also
glad you guys do comprehensive testing before accepting it, since we are
only able to test in a more limited range of environments.
We have applied the patch to our 8.2.4 installations and are
Julius Stroffek [EMAIL PROTECTED] writes:
This hook seems very strangely defined to me. Why did you not put the
hook at the point where the current geqo-vs-regular decision is made?
The reason is that I thought about gaining a control over the algorithm
used to solve individual subproblems
Well, It seems that I probably do not understand something quite well or
my explanation
is not clear. There is some example code of my idea in the attachment.
There is a function jos_search which has nearly the same code as
make_rel_from_joinlist.
The example tries geqo first and then the
Julius Stroffek [EMAIL PROTECTED] writes:
Parts of the result path might be found by geqo and parts of it by
regular algorithm.
Why would you care? Seems like forcing that to not happen is actively
making it stupider.
If there is no way of how to make the code work then it makes no sense
On 9/25/07, Simon Riggs [EMAIL PROTECTED] wrote:
On Tue, 2007-09-25 at 09:16 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
SQLServer and DB2 have more need of this than PostgreSQL, but we do
still need it.
Why? What does it do that statement_timeout doesn't do better?
Why would you care? Seems like forcing that to not happen is actively
making it stupider.
To better compare the algorithms and possibly not for final solution at
the beginning. If we would implement 10 algorithms and want to pickup
just 3 best ones to be used and throw 7 away.
Later on,
I wrote:
Awhile back, Chris Marcellino [EMAIL PROTECTED] wrote:
If this is in fact the case, I have a trivial patch to conditionally
enable SysV semaphores based on the OS release:
I've tried this patch on my Mac laptop, and while it seems to work as
advertised in terms of not eating a
Julius Stroffek [EMAIL PROTECTED] writes:
Why would you care? Seems like forcing that to not happen is actively
making it stupider.
To better compare the algorithms and possibly not for final solution at
the beginning. If we would implement 10 algorithms and want to pickup
just 3 best ones
Hiroshi Saito [EMAIL PROTECTED] writes:
Why do you need to #undef EXEC_BACKEND, and is there a specific reason for
removing the include of win32.h?
I put in in order to avoid -D of the Makefile.
If that matters, the problem is that somebody put the wrong stuff in the
wrong include file.
Hi.
From: Tom Lane [EMAIL PROTECTED]
Hiroshi Saito [EMAIL PROTECTED] writes:
Why do you need to #undef EXEC_BACKEND, and is there a specific reason for
removing the include of win32.h?
I put in in order to avoid -D of the Makefile.
If that matters, the problem is that somebody put the
Hiroshi Saito [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
Perhaps instead postgres_fe.h should #define FRONTEND?
Yes, I feared that the physique of a main part broke. Then, Magnus said the
same suggestion as you. It seems that it needs to be brushup.
I am going to improve by
Hi.
From: Tom Lane [EMAIL PROTECTED]
Hiroshi Saito [EMAIL PROTECTED] writes:
From: Tom Lane [EMAIL PROTECTED]
Perhaps instead postgres_fe.h should #define FRONTEND?
Yes, I feared that the physique of a main part broke. Then, Magnus said the
same suggestion as you. It seems that it needs
Here is a revised patch against CVS HEAD.
I fixed a bug in ECPGdeallocate_all().
Michael Meskes [EMAIL PROTECTED] wrote:
Could you please create a small example that we could add to the
regression suite?
The attached prep.pgc is an example for this fix,
that repeats EXEC SQL PREPARE and
Hello All,
We have prepared a patch (against CVS HEAD)for the TODO item:
* Hash
-During index creation, pre-sort the tuples to improve build speed
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php
Details of this patch's performance improvements can be found at
22 matches
Mail list logo
