As the code stands plpgsql will try to issue something like
UPDATE/DELETE ... WHERE CURRENT OF $1
Since we don't try to do anything with the cursor name until runtime,
it seems that this would work if we allowed a parameter symbol there.
Offhand that doesn't look hard.
I tested it.
Alvaro Herrera [EMAIL PROTECTED] wrote:
No, I meant a while (sleep 1(or 10) and counter longtime) check for
exit instead of sleep longtime.
Ah; yes, what I was proposing (or thought about proposing, not sure if I
posted it or not) was putting a upper limit of 10 seconds in the sleep
On Sat, Jun 09, 2007 at 10:55:55PM +0200, Magnus Hagander wrote:
Magnus Hagander wrote:
Joachim Wieland attempted to post this patch, but it appears to be gone.
I tried a repost, and notivced it got rejected because it was 100kb.
Let me repeat previous objections that it really should be
Korry spotted two violations of the rule about accessing the first varlena
field directly which I had missed. In both cases I believe the accesses are
actually safe because they follow an int4 column and the data are either
explicitly detoasted or passed to textout which can handle 1-byte headers
On Tue, Jun 12, 2007 at 01:16:32PM +0200, Magnus Hagander wrote:
I have applied a fairly well reworked version of this. The big thing is
that I moved the building of the pgc code out of the regression test driver
and into the build system using msbuild.
I also did a couple of minor fixes to
On Tue, Jun 12, 2007 at 02:25:24PM +0200, Michael Meskes wrote:
On Tue, Jun 12, 2007 at 01:16:32PM +0200, Magnus Hagander wrote:
I have applied a fairly well reworked version of this. The big thing is
that I moved the building of the pgc code out of the regression test driver
and into the
Gregory Stark [EMAIL PROTECTED] writes:
Why do we even have those fields in the structs if they're unsafe to use?
1. genbki.sh
2. As you note, they're not always unsafe to use.
regards, tom lane
---(end of broadcast)---
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Why do we even have those fields in the structs if they're unsafe to use?
1. genbki.sh
But genbki.sh wouldn't care if we #if 0 around the unsafe ones would it?
2. As you note, they're not always unsafe to use.
Hi all,
Here is a brand new patch to log a checkpointing load information
to tune the bgwriter parameter.
When you enable trace_checkpoint parameter and process
the checkpoint, the bgwriter logs the number of
flushed buffer pages and the elapsed time.
Hi all,
Here is a brand new patch to log a checkpointing load information
to tune the bgwriter parameter.
When you enable trace_checkpoint parameter and process
the checkpoint, the bgwriter logs the number of
flushed buffer pages and the elapsed time.
Satoshi Nagayasu wrote:
Hi all,
Here is a brand new patch to log a checkpointing load information
to tune the bgwriter parameter.
When you enable trace_checkpoint parameter and process
the checkpoint, the bgwriter logs the number of
flushed buffer pages and the elapsed time.
I don't
2007/6/13, Alvaro Herrera [EMAIL PROTECTED]:
Well, more I/O numbers would be more interesting than CPU stats ...
Well, I think so too, and I attempted to print block in / out using getrusage(),
but I couldn't get them because they were always zero (on my linux).
I still can't understand the
Gregory Stark [EMAIL PROTECTED] writes:
Well, it seems like it would be nice to mark which ones are and aren't unsafe
rather than have them all be there waiting to trip people up.
We already do mark 'em --- that's what all the VARIABLE LENGTH FIELDS
START HERE comments are about. I'm not
On Tue, 12 Jun 2007, Satoshi Nagayasu wrote:
Here is a brand new patch to log a checkpointing load information
to tune the bgwriter parameter.
There is a work in progress patch that logs this and additional checkpoint
information being reviewed in hopes of making it into the 8.3 build. See
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
The other instance is in inv_api.c where it would be quite possible to use
fastgetattr() instead. But the column is always at the same fixed offset and
again it follows an int4 so it'll always be 4-byte aligned and
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
After looking closer, I think there are worse problems here: the code is
still using VARSIZE/VARDATA etc, which it should not be because the
field could easily be in 1-byte-header form.
Well that's ok because
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'll try to get a patch out for just the stderr case, which should be
back-patchable, then adjust the CSVlog patch to use it.
Sounds like a plan.
I'm thinking of handling the partial lines with a small dynahash of
Greg,
Thanks for comments.
Greg Smith wrote:
The idea of using pg_rusage_init is a new one though; I hadn't thought the
CPU usage info was interesting enough to figure out how to collect it.
The way the patch mentioned above works it would be hard to squeeze it in
the line usefully for
Andrew Dunstan [EMAIL PROTECTED] writes:
Can I not use a StringInfo in the syslogger?
Should work, elog.c expects it will --- I'd wonder about premature pfree
or something like that. Are you testing with --enable-cassert?
regards, tom lane
19 matches
Mail list logo
