On Mon, 2006-01-02 at 13:40 -0500, Bruce Momjian wrote:
This change reduced the stats_command_string time from 5.5 to 3.9, which
is closer to the 3.5 seconds with stats_command_string off.
Excellent work, port specific or not.
Best Regards, Simon Riggs
---(end of
Bruce Momjian wrote:
Tom Lane wrote:
A second improvement I discovered is that the statistics collector is
calling gettimeofday() for every packet received, so it can determine
the timeout for the select() call to write the flat file. I removed
that behavior and instead used setitimer() to
Joe Conway wrote:
Joe Conway wrote:
However, there is a remaining oddity with dblink_fetch(). Basically,
each time dblink_fetch() is called, the named cursor is advanced, even
though an error is thrown before returning any rows. Is there a simple
way to get the number of columns in the
Tom Lane wrote:
The average application that wants to use this view at all will be
looking to see did I already prepare FOO. If it's using the query
definition string for this purpose, comparing source text is easy
while comparing deparsed text to source is a nightmare.
Well, I don't see why
Joe Conway [EMAIL PROTECTED] writes:
Should I just accept that the cursor advances on a row type mismatch
error, fix using the attached patch and adding SCROLL to dblink_open(),
or something else? Any opinions out there?
I would go with accepting (and documenting) the cursor advance. Trying
Neil Conway [EMAIL PROTECTED] writes:
In any case, if we use the query string as supplied by the user, how do
we produce that string in the case of SQL PREPARE? Manually stripping a
PREPARE ... AS prefix from the query string is difficult to do
robustly, but it seems (a) expensive (b)
Tom Lane wrote:
In practice, any given application will probably use one method to the
exclusion of the other, and wouldn't notice the inconsistency anyway.
If you are using both methods of preparing statements for some reason,
it's not improbable that you would want to know which way a given
Marko Kreen [EMAIL PROTECTED] writes:
There is a signedness bug in Openwall gen_salt code that
pgcrypto uses. This makes the salt space for md5 and xdes
algorithms a lot smaller.
Salts for blowfish and standard des are unaffected.
Attached is upstream fix for it. This applies all the
way
Greetings,
The following patch implements individual privileges for TRUNCATE,
VACUUM and ANALYZE. Includes documentation and regression test
updates. Resolves TODO item 'Add a separate TRUNCATE permission'.
Created off of current (2005/01/03) CVS TIP.
At least the 'no one interested
Stephen Frost [EMAIL PROTECTED] writes:
The following patch implements individual privileges for TRUNCATE,
VACUUM and ANALYZE. Includes documentation and regression test
updates. Resolves TODO item 'Add a separate TRUNCATE permission'.
At least the 'no one interested has written a
On Tue, Jan 03, 2006 at 11:32:01PM -0500, Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
The following patch implements individual privileges for TRUNCATE,
VACUUM and ANALYZE. Includes documentation and regression test
updates. Resolves TODO item 'Add a separate TRUNCATE
11 matches
Mail list logo
