off-by-one is true, but I am not sure if the revised code is faster.
sprintf() need the extra job to parse the format. In win32, I am sure it is
much slower.
"Neil Conway" <[EMAIL PROTECTED]> news:[EMAIL PROTECTED]
> This patch refactors some code in WaitOnLock slightly. The old code was
> sl
On Mon, Feb 14, 2005 at 10:09:55PM -0500, Bruce Momjian wrote:
> With us moving to a normal 8.1 release do you want to submit submit to
> be applied to CVS?
Here it is in a single tarball. I keep the previous description below.
Thanks,
Here is the latest installation of my shared dependency p
Mark Kirkwood wrote:
Tom Lane wrote:
One reason for making it contrib is that I don't think you've got it
entirely right yet, and there will be several iterations before it
settles down. In a contrib module that is no problem, in core it's a
forced initdb each time.
Yeah - certainly less intrusiv
This patch refactors some code in WaitOnLock slightly. The old code was
slow, and I believe it was off-by-one (it allocates one byte of memory
more than needed).
Barring any objections I'll apply this to HEAD later today.
-Neil
Index: src/backend/storage/lmgr/lock.c
=
Neil Conway wrote:
Right, which is why the patch adds fflushes to the Unix implementation
of internal_forkexec(). On reflection, it is probably more
straightforward to just invoke fork_process() from the Unix version of
internal_forkexec() -- attached is a revised patch that does this.
I'll appl
Tom Lane wrote:
One reason for making it contrib is that I don't think you've got it
entirely right yet, and there will be several iterations before it
settles down. In a contrib module that is no problem, in core it's a
forced initdb each time.
Yeah - certainly less intrusive as a contrib if amen
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I would rather see this as a contrib module. There has been *zero*
>> consensus that we need this in core, nor any discussion about whether
>> it might be a security hole.
> Hmmm, I guess my motivation for thinking it might be useful
Hello,
I changed code by your and Neil's notes. The name SQLCODE isn't well,
better is SQLSTATE. It's very similar DB2 variable. I am not sure, so my
solutions is best. Propably not. It's only particular solution for
plpgsql. The files plpgsql.sql and plpgsql.out are diffs for regression
tests.
Neil Conway wrote:
Mark Kirkwood wrote:
+ TupleDescInitEntry(tupledesc, (AttrNumber) 5, "relblockbumber",
+ NUMERICOID, -1, 0);
I think this should be an int4, not numeric.
I was looking for an UINT4OID :-), but numeric seemed the best
compromise (safer
On Tue, Mar 08, 2005 at 12:27:21PM +0800, Christopher Kings-Lynne wrote:
> >Luckily, PG 8 is available for this. Do you have a short example?
>
> No, and I think it should be in the manual as an example.
>
> You will need to enter a loop that uses exception handling to detect
> unique_violation.
Tom Lane wrote:
I would rather see this as a contrib module. There has been *zero*
consensus that we need this in core, nor any discussion about whether
it might be a security hole.
Hmmm, I guess my motivation for thinking it might be useful in core was
that it was similar to 'pg_locks' and 'pg_st
11 matches
Mail list logo
