On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Applied.
As I mentioned it before, is there any chance for this fix to be
backported to 8.3 branch? IMHO it's a usability regression.
Thanks.
--
Guillaume
--
Sent via pgsql-patches mailing list
On Fri, May 9, 2008 at 4:38 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
No, we don't change behaviors in back branches unless we get lots of
complaints, and we haven't in this case.
I suspect it's annoying for a lot of people, just not annoying enough
to make them complain about it.
I
On Mon, Apr 21, 2008 at 7:25 PM, Magnus Hagander [EMAIL PROTECTED] wrote:
Not really, but it did need a couple of adjustments :-)
It's been running fine now for a number of hours, with output that
looks similar to the stuff you posted. I'll leave it running..
If you can come up with an
On Mon, Apr 21, 2008 at 7:10 AM, Tom Lane [EMAIL PROTECTED] wrote:
Note that we are already exercising both ends of the
float8-byval option, so probably only --disable-float4-byval
is very interesting to test explicitly.
I'll set up a new animal with --disable-float4-byval this week.
--
On Mon, Apr 21, 2008 at 2:28 AM, Tom Lane [EMAIL PROTECTED] wrote:
Applied with revisions --- mostly, supporting configure-time control
over whether pass-by-value is used.
Do we need buildfarm coverage of these options?
--
Guillaume
--
Sent via pgsql-patches mailing list
On Sun, Mar 23, 2008 at 3:21 AM, Tom Lane [EMAIL PROTECTED] wrote:
I wrote:
A conservative approach would be to report the query texts *only* in the
server log and never to the client --- this would need a bit of klugery
but seems doable.
Anybody have any opinions about changing this
On Jan 27, 2008 8:13 PM, Neil Conway [EMAIL PROTECTED] wrote:
(Compare that with the irritation we may well see from the removal of
implicit casts in 8.3, which will break *far* more applications, for a
benefit that many users will no doubt find rather hard to observe.)
It's a bit off-topic
Hi Russell,
On Jan 28, 2008 7:27 AM, Russell Smith [EMAIL PROTECTED] wrote:
Can somebody explain why it's important to load with
synchronized_scanning off?
do_sql_command(g_conn, SET synchronized_scanning TO off);
It's the start point of this patch. See this thread [
On Dec 5, 2007 3:26 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Agreed, this would be a nice 8.4 thing. But what about 8.3 and 8.2? Is
there a reason not to make this change? I know I've been lazy and not run
any absolute figures, but rough tests show that raising it (from 10 to
100)
On 5/11/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
I agree that debug levels are not suitable for this.
Squid (the (reverse) proxy) has a nice feature for debugging purposes
(admin and developers). It's possible to have different logging level
for different sections of the code. For
On 5/9/07, Tom Lane [EMAIL PROTECTED] wrote:
Jim Nasby [EMAIL PROTECTED] writes:
Any time this happens it's generally a nasty surprise for users.
Really? Running out of work memory is expected on large tables.
Sure. Perhaps we should find a better error message but it's an
interesting
On 2/22/07, Teodor Sigaev [EMAIL PROTECTED] wrote:
From a previous discussion with Teodor, it would be better to store an
int in the index instead of a text (it takes less space and is
faster). I couldn't find any example so if anyone has an advice to fix
that, it's welcome (mostly how to
On 2/22/07, Teodor Sigaev [EMAIL PROTECTED] wrote:
How long is average length of strings in table?
test=# SELECT MIN(length(word)), MAX(length(word)), AVG(length(word))
FROM lieu_mots_gin;
min | max |avg
-+-+
1 | 38 | 7.4615463141373282
(1 row)
I don't
On 2/22/07, Oleg Bartunov oleg@sai.msu.su wrote:
You're right, it would be nice.
This is what we need for faster ranking in tsearch2, since currently we should
consult heap to get positional information, which slowdowns search.
We didn't investigate the possibility to keep additional information
Hi all,
Here is my preliminary work on porting pg_trgm to GIN. pg_trgm can be
a very good addition to tsearch2 to suggest spellings for mispelled
words as explained in the README.pg_trgm file and I'd like to use it
in this case. GIST implementation is a bit slow so I tried to port it
to use GIN.
On 2/20/07, Tom Lane [EMAIL PROTECTED] wrote:
Of course, the other side of that coin is that syslog is known to drop
messages altogether under sufficient load. (At least on some platforms;
dunno about yours.)
Yes I know. That's one of the reason why I asked for the bahaviour of
7.4
On 2/19/07, Greg Smith [EMAIL PROTECTED] wrote:
log_destination = 'stderr,sql' # Valid values are combinations of
# stderr, syslog, sql, and eventlog,
# depending on platform.
+1
# These are relevant when logging to sql:
log_sql_table = 'pg_log'
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Please don't do that. We already have a combined GUC option that is
used to change two different things (DateStyle) and I regularly see
people confused about how to use it.
Perhaps I don't understand your combined GUC option but ISTM it's
On 2/19/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
I don't think the syslog option is so nice to use these days; the
redirect_stderr stuff is more powerful and easy to use.
Did you already analyze logs of a highly loaded platform using stderr?
It's impossible to guarantee the consistency of
Added -hackers to CC:.
On 2/18/07, Greg Smith [EMAIL PROTECTED] wrote:
I've thought a bit about how to implement this TODO already (I have a log
file parser and I hate maintaining it)
Any problem using pgFouine?
Also, I feel that supporting the whole log_line_prefix syntax for this
feature
Hi all,
Sorry for arriving so late into the discussion.
I don't know if it's possible but it could be useful to have the text
of the query which required the creation of the temporary files as an
additional DETAIL line. At least, if it's possible to have it in this
part of the code.
Thoughts?
On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote:
Usually people don't want th query unless they ask for it. One nify
trick would be to print the query as DETAIL unless they are already
logging queries, but that just seems too complex. If you want the
query, why not just log them all?
Gregory,
You missed one in the first sentence you fixed:
! * if its needed. In case of *cleaned!=NULL caller is resposible to
s/resposible/responsible/
Regards,
--
Guillaume
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL
On 8/30/06, Bruce Momjian [EMAIL PROTECTED] wrote:
I thought about this, and because we are placing two pieces of
information on the same line, it seems | is the best choice.
Good idea. It's far more readable with a pipe.
Oh. You want to pull the parameters out of that. I am thinking you
On 8/29/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Good point. I thought it was clear enough, but obviously not. I had a
similar case with bind, and used a comma to separate them:
LOG: statement: prepare sel1, SELECT $1;
LOG: statement: bind sel1, $1 = 'a''b'
For this one,
Bruce,
I made a few tests here and the backend terminates with a SIG11 when a
parameter has the NULL value (it was logged as (null) before). I
suspect the new code broke something (perhaps it's due to the
escaping).
--
Guillaume
---(end of
On 8/29/06, Bruce Momjian [EMAIL PROTECTED] wrote:
DETAIL: prepare: SELECT $1; bind: $1 = 'a''b'
I attached a trivial patch to add a dash between the prepare part and
the bind part. People usually don't finish their queries with a semi
colon so it's more readable with a separator.
On 8/7/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Updated patch attached. It prints the text bind parameters on a single
detail line. I still have not seen portal names generated by libpq.
I'm currently testing CVS tip to generate sample log files. I noticed
that Bruce only patched
Bruce,
On 4/11/06, Bruce Momjian pgman@candle.pha.pa.us wrote:
but at this stage, I am thinking your using a
home-grown patch is your best approach.
That's what we decided to do even if maintaining our own RPM packages
is not what we used to do for critical software like PostgreSQL.
Thanks to
Tom,
On 3/30/06, Tom Lane [EMAIL PROTECTED] wrote:
I really find it pretty bizarre to want to log a duration without
logging the statement that caused it. Seems like the
log_min_duration_statement parameter ought to be enough. These logging
options are already messy and unintuitive, and
Hi,
This patch is a followup of a discussion on -hackers about the new
behaviour of log_duration in 8.x (
http://archives.postgresql.org/pgsql-hackers/2006-03/msg00687.php ).
As explained in the previous thread, we used to play with log_duration
and log_min_error_statement to have the following
31 matches
Mail list logo
