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
---
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
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
String
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 b
"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 ali
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
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 work fine. So
> for performance reas
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 es
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
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 do
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.
"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
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)---
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
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
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 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 shoul
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
19 matches
Mail list logo
