Neil Conway wrote:
Attached is a revised patch.
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend
This patch optimizes the md5_text() function (which is used to implement
the md5() SQL-level function). The old code did the following:
1. de-toast the datum
2. convert it to a cstring via textout()
3. get the length of the cstring via strlen()
Since we are treating the datum context as a blob of
Neil Conway wrote:
This patch optimizes the md5_text() function (which is used to implement
the md5() SQL-level function).
Applied.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe
John Hansen wrote:
Will this be backpatched to 8.0?
Since it's just a performance optimization, I wasn't planning to
backpatch it, no. I suppose the OOM fix might be worth backporting,
although that is more of a theoretical problem than something I would
expect to actually occur in practice.
-N
I've applied a modified version of this patch from seanc:
http://candle.pha.pa.us/mhonarc/patches2/msg00029.html
(Sorry, I've lost the original thread.) The patch as I applied it is
attached. Catalog version bumped.
-Neil
Index: src/backend/utils/adt/int.c
Barring any objections, I'll apply this patch to HEAD tomorrow:
http://candle.pha.pa.us/mhonarc/patches2/msg7.html
(Sorry, lost track of this patch as well... :P)
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend
Peter Eisentraut wrote:
- Casting back and forth does not preserve information. (This may be
true for some other type pairs as well, but in this case it's true in
almost every instance.)
Right, there are many other explicit casts that lose information. In
fact, I think that's somewhat the point
Peter Eisentraut wrote:
That email message is about a timestamp data type.
Hmm, it seems that when Bruce removes items from the patch queue, the
remaining items are renumbered. You can find the original thread here:
http://archives.postgresql.org/pgsql-patches/2004-10/msg00140.php
I believe I w
Neil Conway wrote:
Barring any objections, I'll apply this patch to HEAD tomorrow:
http://candle.pha.pa.us/mhonarc/patches2/msg7.html
Applied.
-Neil
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index
Mark Kirkwood wrote:
does not worry too much about a consistent view of the buffer
contents (as I didn't want it to block all other activity!).
I don't like accessing shared data structures without acquiring the
appropriate locks; even if it doesn't break anything, it seems like just
asking for t
Alvaro Herrera wrote:
I wrote an "install" program in C. It's supposed to replace the
config/install-sh script, limited to the functionality we need, i.e.
what is in Makefiles in the Pg main source tree. The main objective of
this exercise is to reduce "make install" execution time; a part of tha
Mark Kirkwood wrote:
If so, it looks like I need to do some stuff with ResourceOwners,
otherwise ReleaseBuffer will fail (or am I wandering up the wrong track
here?). I am using anoncvs from yesterday, so if Tom's new scheme is
*very* new I may be missing it.
It's so new, in fact, it's not in CVS y
This patch moves all the common code that is usually invoked before
doing a fork() into a single function, fork_process(). It is not aware
of the EXEC_BACKEND machinery, so it should be used as fork() currently
is -- inside an #ifndef EXEC_BACKEND block, if appropriate.
I wasn't sure whether to
Tom Lane wrote:
It'd be possible to dispense with the per-buffer spinlocks so long as
you look only at the tag (and perhaps the TAG_VALID flag bit). The
tags can't be changing while you hold the BufMappingLock.
That's what I had thought at first, but this comment in buf_internals.h
dissuaded me
Only two things to add: you forgot to add `cachedump.o' to the list of
OBJS in the utils/adt Makefile.
Mark Kirkwood wrote:
+typedef struct
+{
+ uint32 bufferid;
+ Oid relfilenode;
+ Oid reltablespace;
+ Oid
Heikki Linnakangas wrote:
Here's a tiny fix for a harmless typo in catalog.c
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
- You should write some regression tests for this functionality
- You should update the documentation
- Is there a reason why you've made the type of SQLCODE `text', rather
than integer?
Pavel Stehule wrote:
+ fict_vars_sect:
+ {
+ plpgsql_ns_setlocal(false);
+
Tom Lane wrote:
I'm worried about whether this doesn't break the EXEC_BACKEND case.
Most of the code you've moved out isn't applicable to Windows, but
the fflushes probably are
Right, which is why the patch adds fflushes to the Unix implementation
of internal_forkexec(). On reflection, it is proba
Mark Kirkwood wrote:
+ tupledesc = CreateTemplateTupleDesc(NUM_BUFFERCACHE_PAGES_ELEM,
false);
+ TupleDescInitEntry(tupledesc, (AttrNumber) 1, "bufferid",
+
INT4OID, -1, 0);
+ TupleDesc
Tom Lane wrote:
Perhaps OID would be a good choice even though it's horribly wrong on
one level.
Either that or add unsigned numeric types to PG :-)
I would rather see this as a contrib module.
I don't really have an opinion either way. Does anyone else have
thoughts on this?
There has been *zero
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&#x
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
=
Russell Smith wrote:
*** 1083,1091
locallock->lock, locallock->tag.mode);
old_status = pstrdup(get_ps_display());
! new_status = (char *) palloc(strlen(old_status) + 10);
strcpy(new_status, old_status);
! strcat(new_status, " waiting");
Neil Conway wrote:
I'll apply this patch to HEAD later today, barring any objections.
Applied.
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Mark Kirkwood wrote:
A couple of minor amendments here [...]
Barring any objections, I'll apply this tomorrow.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL
Neil Conway wrote:
memcpy(new_status, old_status, len) would be faster yet. Which is what I
originally implemented, and then decided the sprintf() was clearer
(since performance isn't very important here). On reflection, memcpy() +
strcpy() should be fine; I'll commit this tomorro
This patch makes default_with_oids disabled by default, per earlier
discussion, and updates the documentation accordingly. I might have
missed a few spots in the documentation that implicitly assume that OIDs
are present in user tables by default, but I think I got most of them.
Barring any obj
Qingqing Zhou wrote:
!gettext_noop("Create new tables with OIDs by default."),
without?
Right: if the variable is "on", Postgres will "create new tables with
OIDs by default". If the variable is "off", it won't. This is similar to
how the check_function_bodies GUC var is already documented.
Marko Kreen wrote:
Some builds (depends on crypto engine support?) of OpenSSL
0.9.7x have EVP_DigestFinal function which which clears all of
EVP_MD_CTX. This makes pgcrypto crash in functions which
re-use one digest context several times: hmac() and crypt()
with md5 algorithm.
Following patch fixe
This patch allows ALTER FUNCTION set change a function's strictness. In
and of itself this isn't very useful, but it is defined in SQL2003, so
it's probably worth implementing.
Notes:
- the optimizer considers strictness; for example, the optimizer will
pre-evaluate calls to a strict function t
Mark Kirkwood wrote:
A couple of minor amendments here:
- remove link to libpq (from cut+past of dblnk's Makefile)
- add comment for pg_buffercache module in contrib/README
- change my listed email to this one (I have resigned)
Applied, thanks for the patch.
BTW, I removed the "REGRESS=..." lin
Marko Kreen wrote:
Would you apply this one aswell? I see that the original
patch (openssl.c r1.11) applies to both branches without problems.
It is a bit larger than this one tho'.
Should there have been a patch attached to this mail?
-Neil
---(end of broadcast)---
Neil Conway wrote:
This patch makes default_with_oids disabled by default, per earlier
discussion, and updates the documentation accordingly.
Applied.
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend
Marko Kreen wrote:
Ah, ofcourse.
The patch seems rather large to be applying to 7.3 and 7.2 -- but it's
your contrib/ module, so I'll assume you're pretty confident this
doesn't cause any regressions...
I'll apply the patch to 7.3 and 7.2 stable branches tomorrow.
-Neil
-
Tom Lane wrote:
You realize of course that that can already be done with CREATE OR
REPLACE FUNCTION.
Good point; that makes me less wary of breaking dependencies on existing
functions via ALTER, since in any case that can already be done.
Incidentally, is there a reason that DROP FUNCTION doesn't
Marko Kreen wrote:
The patch itself is simply "cvs diff -r1.10 -r1.11 openssl.c",
so there should not be any recent typos in it. Now I also tested
it with both REL7_3_STABLE and REL7_2_STABLE and found no problems.
So I think its fine.
I've applied both this patch and the original patch (fix-opens
Neil Conway wrote:
Attached is a revised patch that also allows security definer and
function volatility to be changed.
Applied.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
David Fetter wrote:
Please find enclosed a patch that fixes the SGML so openjade doesn't
complain :)
Thanks, applied.
BTW, what version of openjade are you using? I'm using 1.4devel, and it
didn't complain about the markup mistakes.
-Neil
---(end of broadcast)-
Thomas Hallgren wrote:
This patch will ensure that the hash table iteration performed by
AtCommit_Portals is restarted when a portal is deleted. This is
necessary since the deletion of a portal may cause the deletion of
another which on rare occations may cause the iterator to return a
deleted
Christopher Kings-Lynne wrote:
This patch makes \d on tables and views sort fk constraints, triggers
and rules alphabetically in the output. This makes it the same as for
indexes and stops the irritating random or reverse ordering it currently
has.
I'll apply this to HEAD later today, barring a
Christopher Kings-Lynne wrote:
This patch makes \d on tables and views sort fk constraints, triggers
and rules alphabetically in the output. This makes it the same as for
indexes and stops the irritating random or reverse ordering it currently
has.
Thanks, applied.
-Neil
---
Christopher Kings-Lynne wrote:
This just adds a link to the pattern_ops operator class section from the
part of the locale docs that mentions that indexes don't work for LIKE
under a non-C locale.
Patch applied, with some changes. We can't assume that the reader can
follow hyperlinks, since they
This patch moves some code for preprocessing FOR UPDATE from
grouping_planner() to preprocess_targetlist(), according to a comment in
grouping_planner(). I think the refactoring makes sense, and moves some
extraneous details out of grouping_planner().
Barring any objections, I'll apply this to
Neil Conway wrote:
This patch moves some code for preprocessing FOR UPDATE from
grouping_planner() to preprocess_targetlist(), according to a comment in
grouping_planner(). I think the refactoring makes sense, and moves some
extraneous details out of grouping_planner().
Applied.
-Neil
Marko Kreen wrote:
Here are various updates for pgcrypto that
I've been sitting on for some time now.
I'll apply all these later today, barring any objections.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister
Michael Fuhr wrote:
Should the PL/Python documentation mention this behavior?
Isn't this the behavior the user would expect? If so, I guess it's okay
not to document it.
How should I submit regression tests?
Yes, please.
*** src/pl/plpython/plpython.c 17 Dec 2004 02:14:48 - 1.58
--- src/pl/pl
Alvaro Herrera wrote:
Is there any reason why HeapTupleSatisfiesUpdate return codes are not an
enum, like they are for HeapTupleSatisfiesVacuum?
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an a
Marko Kreen wrote:
Here are various updates for pgcrypto that
I've been sitting on for some time now.
Thanks, applied.
-Neil
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's data
Alvaro Herrera wrote:
Also, keep in my that this C install program has the extra feature of
being able to install multiple files on one invocation, per suggestion
from Tom Lane. This allows us to save the nested for-loop in
src/include/Makefile. GNU install (available on my system) also has
this
I noticed there is an SPI API function to get the name of a specified
Relation, but no similar function to get the Relation's namespace.
Attached is a patch that implements SPI_getnspname().
I wasn't sure if I should refer to the relation's "schema" or its
"namespace"; my feeling was that SPI i
Neil Conway wrote:
I noticed there is an SPI API function to get the name of a specified
Relation, but no similar function to get the Relation's namespace.
Attached is a patch that implements SPI_getnspname().
Applied.
-Neil
---(end of broa
ExecHash() currently returns a null TupleTableSlot, and a misleading
comment from 1991 claims there is a good reason for this. AFAICS there
isn't and the return value isn't used, so I've changed it to return NULL.
Barring any objections I'll apply this tomorrow.
-Neil
Index: src/backend/executor
Neil Conway wrote:
ExecHash() currently returns a null TupleTableSlot, and a misleading
comment from 1991 claims there is a good reason for this. AFAICS there
isn't and the return value isn't used, so I've changed it to return NULL.
Applied.
-Neil
---(e
Mark Kirkwood wrote:
Great that it fixes it... however, I had submitted a tidier patch that
puts the macro in the header
How is this tidier?
(I don't see a reason for pg_buffercache_pages.h at all, actually.)
-Neil
---(end of broadcast)---
TIP 7: don
Mark Kirkwood wrote:
So, please ignore my previous patch to the header file, and consider
this one - which eliminates it completely.
Thanks, applied.
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.p
Alvaro Herrera wrote:
Oops, somehow I left that parth out of the patch.
Thanks, both patches applied.
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Robert Treat wrote:
Inspired by comments from steve <[EMAIL PROTECTED]>, adds a few urls for
more download options.
Thanks for the patch -- I applied a modified version (we can't use
description since that won't work for printed
versions of the docs).
-Neil
---(end of b
I've applied the attached patch to HEAD: it fixes the spelling of the
"ABSOLUTE" keyword, and completes FETCH with FROM and IN,
rather than FROM and TO (since the latter is not valid syntax).
-Neil
Index: src/bin/psql/tab-complete.c
=
This patch is a cleaned up version of Euler Taveira de Oliveira's patch
implementing DELETE ... USING. I removed a bunch of unused code (no need
to tlist transformations), updated copyfuncs/equalfuncs, improved the
documentation, rearranged a few things, and added regression tests. I
haven't do
This patch changes int2_avg_accum() and int4_avg_accum() use the nodeAgg
performance hack Tom introduced recently. This means we can avoid
copying the transition array for each input tuple if these functions are
invoked as aggregate transition functions.
To test the performance improvement, I c
Tom Lane wrote:
Why only those two? Might as well make all the accum functions look alike.
Yeah, there might be some others we could improve. float4_accum() and
float8_accum() look like they could be improved pretty easily, and
do_numeric_accum() should also be fixable with some hackery. I suppo
Tom Lane wrote:
BTW, this patch is lacking ruleutils.c support. Put a DELETE USING
into a rule and see whether pg_dump will dump the rule correctly ...
Good catch; a revised patch is attached.
-Neil
Index: doc/src/sgml/ref/delete.sgml
===
[ CC'ing hackers to see if anyone else wants to weigh in ]
Tom Lane wrote:
Of course, the entire reason this didn't happen years ago is that we
couldn't agree on what keyword to use... you sure you want to reopen
that discussion?
Sure, it doesn't seem too difficult to settle to me.
I don't think ch
Euler Taveira de Oliveira wrote:
I'm worried about add_missing_from enabled.
The plan is to make add_missing_from default to false in 8.1
euler=# delete from t3 using t1 where b > 500;
DELETE 4
euler=# select * from t3;
x | y
---+---
(0 rows)
In this case, I 'forget' to do the join and it delete
Tom Lane wrote:
... but when it is TRUE, there should be a notice, same as there is in
SELECT. UPDATE should produce such a notice too, IMHO. Probably we
omitted the message originally because there was no way to avoid it
in a DELETE, but now there will be.
Well, my previous message described why
Alvaro Herrera wrote:
This file was whacked by pgindent before it knew it shouldn't remove
braces around single statements (for PG_TRY macros). This patch fixes
it. Please apply.
Thanks, applied.
-Neil
---(end of broadcast)---
TIP 4: Don't 'kill -9'
Greg Sabino Mullane wrote:
Patch to show check information when listing domains via \dD in psql.
Per question by Edmund Bacon on the pgsql-general list.
Patch applied, thanks. I didn't change the left join to pg_namespace to
be an inner join; while I think this is probably worth doing, it is a
se
Tom Lane wrote:
Hmm. There's some merit in that position, but consider this: we are
encouraging people rather strongly to move to the add_missing_from=false
behavior. So add_missing_from=true could be seen as a testing situation
in which you'd like to know which of your queries have a problem, wh
Neil Conway wrote:
Yeah, there might be some others we could improve. float4_accum() and
float8_accum() look like they could be improved pretty easily, and
do_numeric_accum() should also be fixable with some hackery. I suppose
it's also worth optimizing int2_sum(), int4_sum() and int
Euler Taveira de Oliveira wrote:
Could you provide a patch?
Sure, a revised patch is attached. Note that this change will also
require updating 25 (!) of the regression tests, since they use the
SELECT-without-FROM syntax. I will update the tests (by adding an
explicit FROM clause) before applyi
Neil Conway wrote:
Attached is a patch that applies the same optimization to int2_sum(),
int4_sum(), float4_accum(), and float8_accum(). It wasn't possible to
optimize do_numeric_accum() or int8_sum() since they both use numerics.
Applied.
-Neil
---(end of broa
Neil Conway wrote:
Sure, a revised patch is attached. Note that this change will also
require updating 25 (!) of the regression tests, since they use the
SELECT-without-FROM syntax.
I've applied the attached patch to HEAD. Due to the widespread updates
to the regression tests, the test
Now that DELETE has a USING clause, we should be able to make
add_missing_from=false the default in 8.1; the attached patch implements
this and updates the documentation.
Barring any objections, I'll apply this tomorrow.
-Neil
Index: doc/src/sgml/runtime.sgml
Much to my chagrin, I recently noticed that I forgot to convert the
pgstat fork() code to use fork_process() when I applied the original
fork_process() patch a few months ago. This patch does that.
Barring any objections, I'll apply this tomorrow.
-Neil
Index: src/backend/postmaster/pgstat.c
===
Neil Conway wrote:
Now that DELETE has a USING clause, we should be able to make
add_missing_from=false the default in 8.1; the attached patch implements
this and updates the documentation.
Applied.
-Neil
---(end of broadcast)---
TIP 7: don&#
Neil Conway wrote:
Much to my chagrin, I recently noticed that I forgot to convert the
pgstat fork() code to use fork_process() when I applied the original
fork_process() patch a few months ago. This patch does that.
Applied.
-Neil
---(end of broadcast
Bruce Momjian wrote:
Is this what we want? I don't think so. I thought we wanted to
maintain the backward-compatible syntax of no FROM clause.
We do? Why?
It is just as noncompliant with the SQL spec as other variants of this
behavior. add_missing_from would *always* have rejected those queries,
Simon Riggs wrote:
During recent tuning of the TPC-C workload, I produced the following
patch to force COPY to leave some space in each data block when it loads
data into heap relations.
I can't get too excited about incorporating changes designed solely to
improve performance for the workload of
Qingqing Zhou wrote:
Remove an unused variable waitingForSignal in /storage/lmgr/proc.c.
I guess it was there because orignally PG uses singals to implement
ProcWaitForSignal() stuff, so we may need to remember the process status.
But now we don't need it.
Applied, thanks.
-Neil
---
Niels Breet wrote:
This patch changes the use of varargs.h to stdarg.h as
required by GCC.
Patch applied, thanks.
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Andrew Dunstan wrote:
I have confirmed that the attached patch works on Cygwin as well as
Windows. Please apply.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 8: explain analyze is your friend
Simon Riggs wrote:
These are the only two files in /executor that have old QUEL comments in
to describe their behaviour, AFAICS.
Applied with some minor cleanups. Thanks for the patch.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list a
This patch fixes a bug in the error message emitted by pg_restore on an
incorrect -F argument: write_msg() expects its first parameter to be a
"module name", not the format string. Patch applied to HEAD. Is this
worth backporting?
BTW, is there a reason that pg_restore seems to accept 'f', 't',
GCC 4.0 includes a new warning option, -Wformat-literal, that emits a
warning when a variable is used as a format string for printf() and
similar functions (if the variable is derived from untrusted data, it
could include unexpected formatting sequences). This emits too many
warnings to be enab
Tom Lane wrote:
Certainly --- particularly if the error makes it dump core, as seems
likely (haven't tried it).
Ok, backpatched to stable branches back to 7.2
-Neil
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http
Neil Conway wrote:
Barring any objections, I'll apply this to HEAD and backport it to
stable branches back to 7.2 tomorrow.
Applied and backpatched. I noticed an additional pg_dump format string
bug in 7.2 and fixed that as well (it does not occur in later branches).
I also didn
Robert Treat wrote:
Is there any plans to back patch this into 8.0.x?
Yeah, I was wondering about that -- I've backported the patch to
REL8_0_STABLE.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://arc
Robert Treat wrote:
A couple of the domain commands were missing "see also" references, this patch
adds those references.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgr
Magnus Hagander wrote:
* Add session start time and last statement time to pg_stat_activity
(we already had last-statement-time, provided command string stats were
enabled)
* Add the client IP address and port to pg_stat_activity
Looks pretty good -- barring any objections I'll apply this to HEAD
The issue has been raised in the past that our build system links each
executable against the maximal set of libraries it might need. So for
example, if one executable requires `libreadline', all executables are
linked against it.
The easiest fix is to make use of GNU ld's --as-needed flag, whi
Tom Lane wrote:
Minor gripe --- what's the motivation for moving this down as you did?
What do you mean by "this"? I moved the AC_MSG_NOTICEs for CPPFLAGS and
LDFLAGS down below the --as-needed check, since the --as-needed check
may modify LDFLAGS.
Also, please s/same platforms/some platforms/
T
Tom Lane wrote:
Well, I guess the question is why you put the --as-needed check where
you did, rather than above the existing AC_MSG_NOTICE displays. If it
has an interaction with the intervening tests, what is that exactly?
PGAC_PROG_LD needs to be invoked to figure out if we're using gnu ld.
Th
Magnus Hagander wrote:
Updated patch attached.
A few more comments:
- why did you add the client address to PgStat_MsgHdr, rather than
PgStat_MsgBestart? It would be nice to avoid sending the client address
for each and every stats message, as it shouldn't change over the life
of the session.
-
Tom Lane wrote:
Why is that a good idea? In a complex application it'd be awfully easy
to break logic that depends on such a thing.
True, but I think it offers a usefully concise syntax for simpler
applications. Perhaps the documentation should be amended to mention the
potential risks? (e.g. ad
Magnus Hagander wrote:
I guess that's from not reading things carefully enough. I looked for
where "backend pid" was transmitted, because I thought that would be a
good place to put it.
On adapting the code to just send the client address in the BE start
message, I'm not actually sure this is the
Tom Lane wrote:
I think this argument is a red herring ... or at least it leads in a
direction I find unacceptable.
I agree -- I was just pointing out the reason that, in the current
design, there is cause to do things as Magnus' original patch did.
We are already transmitting three more fields t
Tom Lane wrote:
I'd vote against that. The mechanism is lossy by design
Is it _lossy_, or merely unordered? While UDP doesn't guarantee message
delivery, I wonder what kind of extreme circumstances would need to
exist for you to lose UDP packets outright over the loopback interface.
> I don't t
Tom Lane wrote:
If the stats collector gets sufficiently backed up, you will lose
messages. [...] Please do not try to make piecemeal changes in that
basic design decision.
Fair enough.
> (Actually, we could skinny it down to backend PID only ...
but that would add a hashtable lookup to every mess
Andrew Dunstan wrote:
Is this what broke the regression tests on HEAD?
Yes, it is -- fix checked in to HEAD. My apologies for missing this.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscr
Andrew Dunstan wrote:
tiny patch to test this feature.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
701 - 800 of 1000 matches
Mail list logo
