Hi,
On Tue, 2007-11-27 at 23:53 -0500, Robert Treat wrote:
> I also think we should be a bit more generous on the EOL notice.
> Saying one more update after 8.3 is akin to giving a 1 month EOL
> notice; not friendly at all imo. Set it for July 2008 and I think you
> have given plenty of notice (a
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Josh Berkus wrote:
>>> ... DW operations aren't
>>> really testable without 18 hours to generate data ... but we could test a
>>> lot of things.
>
>> Performance isn't just about humungous DW apps.
>
> Indeed. I think the real tak
On Nov 28, 2007 5:38 AM, Josh Berkus <[EMAIL PROTECTED]> wrote:
>
> Nikhil S
>
>
Nikhil is from India, EnterpriseDB.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 28 Nov 2007 00:15:48 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Josh Berkus wrote:
> >> ... DW operations aren't
> >> really testable without 18 hours to generate data ... but we could
> >> test
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> ... DW operations aren't
>> really testable without 18 hours to generate data ... but we could test a
>> lot of things.
> Performance isn't just about humungous DW apps.
Indeed. I think the real take-home lesson from these past
On Nov 27, 2007 7:08 PM, Josh Berkus <[EMAIL PROTECTED]> wrote:
> Jaime Casanova, Venezuala
Ecuador
> Bernd Helmle
and he's from germany
http://www.oopsware.de/private/bernd.html
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and b
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Josh Berkus" <[EMAIL PROTECTED]> writes:
>> Time for the annual update of this list:
>> Greg Stark, USA
> I'm not sure what the countries are supposed to signify but that's
> neither the country I hail from nor where I'm currently living.
Just tell us
On Tuesday 27 November 2007 15:07, Simon Riggs wrote:
> On Tue, 2007-11-27 at 14:02 -0500, Tom Lane wrote:
> > There has been some discussion of making a project policy of dropping
> > support for old releases after five years. Should we consider formally
> > instituting that?
> >
> > I see that t
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Another possibility would be to change the declared signatures to show
>> "tsquery" rather than "internal" at the places where a tsquery argument
>> is expected. I'm less excited about that part though.
> The on
On Tuesday 27 November 2007 19:03, Tom Lane wrote:
> Last month I complained:
> > regression=# SELECT plainto_tsquery('the any');
> > NOTICE: query contains only stopword(s) or doesn't contain lexeme(s),
> > ignored plainto_tsquery
> > -
> >
> > (1 row)
> >
> > regression=# select
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Thanks, working on this now. Because the stop words can be any stop
> > > word I didn't imagine it could be in the subsitution. What stop word
> > > will it use? Anyway, coding it now to match the left-han
Josh Berkus wrote:
Andrew,
It's the tests I think belong in core, not the farm software. Currently
buildfarm performs functionality tests that are also in core.
Jignesh and I were talking about writing a Pole Position-style test which
measures peformance on each of a couple dozen s
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> All,
>
> Time for the annual update of this list:
>...
> Greg Stark, USA
I'm not sure what the countries are supposed to signify but that's neither the
country I hail from nor where I'm currently living.
--
Gregory Stark
EnterpriseDB htt
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Another possibility would be to change the declared signatures to show
> "tsquery" rather than "internal" at the places where a tsquery argument
> is expected. I'm less excited about that part though.
The use of "internal" arguments has always been the p
On Tue, 27 Nov 2007, Josh Berkus wrote:
Kris Jurka, Finland
USA actually.
Kris Jurka
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 27 Nov 2007 16:08:36 -0800
Josh Berkus <[EMAIL PROTECTED]> wrote:
> All,
>
> Time for the annual update of this list:
> http://www.postgresql.org/developer/bios
>
> Here's the list of people I gleaned from the release notes (btw, if
> people
All,
Time for the annual update of this list:
http://www.postgresql.org/developer/bios
Here's the list of people I gleaned from the release notes (btw, if people
have countries for the folks who aren't attributed, I'd appreciate them).
Of course, there are many contributors to essential non-co
Last month I complained:
> regression=# SELECT plainto_tsquery('the any');
> NOTICE: query contains only stopword(s) or doesn't contain lexeme(s), ignored
> plainto_tsquery
> -
> (1 row)
> regression=# select ''::tsquery;
> NOTICE: tsearch query doesn't contain lexeme(s): ""
Andrew,
> It's the tests I think belong in core, not the farm software. Currently
> buildfarm performs functionality tests that are also in core.
Jignesh and I were talking about writing a Pole Position-style test which
measures peformance on each of a couple dozen specific operations. There
a
On Nov 28, 2007 9:49 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I had a bit of a dig into this. A_Const->typename gets set directly
> > by the parse paths for "INTERVAL [(int)] string [interval range]". In
> > fact, as far as I can tell that's the _only_ place A_Const->typename
> > gets used at
On Nov 27, 2007 7:32 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> But a performance test machine
> probably needs to be dedicated to just that function. And at least some
> members of the performance test machines would need to be higher end
> machines. The number of people who can afford such r
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Simon Riggs wrote:
Should we do this as part of core, or as a separate pgfoundry project?
Core, please. This is mainline -hackers material.
Huh? The buildfarm isn't in core, why would a performfarm be?
On Nov 27, 2007 11:45 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> If you start with a set of tests and send it to me I will start work on
> a benchmarking step in the buildfarm client.
Are you sure it shouldn't be a separate client? I don't think neither
the prerequisites nor the results wante
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Thanks, working on this now. Because the stop words can be any stop
> > word I didn't imagine it could be in the subsitution. What stop word
> > will it use? Anyway, coding it now to match the left-hand-side.
>
> Why would you do t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Thanks, working on this now. Because the stop words can be any stop
> word I didn't imagine it could be in the subsitution. What stop word
> will it use? Anyway, coding it now to match the left-hand-side.
Why would you do that? There is not any corre
Thanks, working on this now. Because the stop words can be any stop
word I didn't imagine it could be in the subsitution. What stop word
will it use? Anyway, coding it now to match the left-hand-side.
---
Tom Lane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 27 Nov 2007 21:00:03 +
Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-11-27 at 12:36 -0800, Joshua D. Drake wrote:
>
> > The RHEL one as I know it, is the MyYearbook donated one. We are
> > currently unaware of the status of that m
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Should we do this as part of core, or as a separate pgfoundry project?
> Core, please. This is mainline -hackers material.
Huh? The buildfarm isn't in core, why would a performfarm be?
regards, tom lane
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I actually thought that A_ArrayExpr would be a good addition even if
> you ignore the matter of typecasting. It always seemed weird to me
> that the parser generates an ArrayExpr directly. ArrayExpr has a
> bunch of members that are only set by the tra
Simon Riggs wrote:
On Tue, 2007-11-27 at 13:32 -0500, Andrew Dunstan wrote:
We also need to talk about what would be a good set of tests to run.
Sounds like it's waiting on somebody to make the first move, so maybe I
should do that, then let everybody else chip into the framework.
Josh Berkus wrote:
Tom,
There has been some discussion of making a project policy of dropping
support for old releases after five years. Should we consider formally
instituting that?
The community consensus I recall was three versions only. Anything beyond
that would be up to the
Wasn't this patch
http://archives.postgresql.org/pgsql-committers/2007-11/msg00170.php
supposed to fix things so that we wouldn't be throwing NOTICEs out of
tsearch dictionary init functions? It seems to have gotten only
one of the two elog(NOTICE) calls in there. The other one is for a
stopword
I've just noticed that tsearch includes a couple of support functions
with rather vague names:
gin_extract_query(internal,internal,smallint)
gin_ts_consistent(internal,smallint,internal)
These are, in fact, specialized to the case of operating on tsquery
inputs, but you'd never gues
On Nov 28, 2007 4:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Now I'm thinking I leave the grammar rules alone (apart from making it
> > legal to specify an empty list of elements), and instead push the
> > typename down into the child node from makeT
On Tue, 2007-11-27 at 15:33 -0300, Alvaro Herrera wrote:
> Joshua D. Drake wrote:
> I agree
> > that we should *never* have a regression in performance from release
> > to release, which is what I believe has inspired this thread.
>
> Hmm. I have developed several features that have driven perfo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 27 Nov 2007 21:00:03 +
Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-11-27 at 12:36 -0800, Joshua D. Drake wrote:
>
> > The RHEL one as I know it, is the MyYearbook donated one. We are
> > currently unaware of the status of that m
On Tue, 2007-11-27 at 12:36 -0800, Joshua D. Drake wrote:
> The RHEL one as I know it, is the MyYearbook donated one. We are
> currently unaware of the status of that machine except to say it is
> currently running Gentoo.
>
> I don't know the status of the Solaris machine except that I think we
On Tue, 2007-11-27 at 13:32 -0500, Andrew Dunstan wrote:
> We also need to talk about what would be a good set of tests to run.
I think we should develop a series of performance regression tests that
can be run as an option on the buildfarm. We'd want a separate page for
that with graphs etc, as
"Andreas 'ads' Scherbaum" <[EMAIL PROTECTED]> writes:
> On Tue, 27 Nov 2007 11:08:58 -0800 Joshua D. Drake wrote:
>> Release 7.3.21 with and EOL addendum :). E.g; this is the last release
>> of 7.3 and 7.3 is now considered unsupported.
> I know at least one customer who is using RHEL-3 and PG 7.3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 27 Nov 2007 20:32:57 +
Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-11-27 at 13:54 -0500, Tom Lane wrote:
>
> > However, I think everybody agrees that getting blindsided by
> > unexpected performance dropoffs is a bad thing. We
On Tue, 2007-11-27 at 13:54 -0500, Tom Lane wrote:
> However, I think everybody agrees that getting blindsided by unexpected
> performance dropoffs is a bad thing. We really need to reinstitute
> the sort of daily (or near-daily) performance tracking that Mark Wong
> used to be doing, and extend
Josh Berkus <[EMAIL PROTECTED]> writes:
>> There has been some discussion of making a project policy of dropping
>> support for old releases after five years. Should we consider formally
>> instituting that?
> The community consensus I recall was three versions only. Anything beyond
> that woul
Tom,
> There has been some discussion of making a project policy of dropping
> support for old releases after five years. Should we consider formally
> instituting that?
The community consensus I recall was three versions only. Anything beyond
that would be up to the vendors.
Mind you, I don'
On Tue, 2007-11-27 at 17:49 +0100, [EMAIL PROTECTED] wrote:
> Any comment about Two Ways Replacement Selection (two heaps instead of just
> one) ?
It might allow dynamic heap size management more easily than with a
single heap.
If you really think it will be better, try it. You'll learn loads, r
On Tue, 27 Nov 2007 11:08:58 -0800 Joshua D. Drake wrote:
> Release 7.3.21 with and EOL addendum :). E.g; this is the last release
> of 7.3 and 7.3 is now considered unsupported.
I know at least one customer who is using RHEL-3 and PG 7.3 on dozens
machines worldwide. Yes, they are moving to 8.2
On Tue, 2007-11-27 at 14:02 -0500, Tom Lane wrote:
> There has been some discussion of making a project policy of dropping
> support for old releases after five years. Should we consider formally
> instituting that?
>
> I see that there are two or three minor bug fixes in the REL7_3_STABLE
> bra
Tom Lane wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
>>> From: Tom Lane <[EMAIL PROTECTED]>
>>> I see that there are two or three minor bug fixes in the REL7_3_STABLE
>>> branch since 7.3.20. Rather than just leaving those to rot, maybe the
>>> actual policy should be "only one more update af
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> This should do better:
Looks good to me, though I'd suggest updating gets_fromFile's header comment:
- * The result is a malloc'd string.
+ * The result is a malloc'd string, or NULL on EOF or input error.
regards, tom lane
> At some point back, I seem to recall the reason for bothering
> to backpatch to 7.3 is that it had to be maintained for
> RedHat anyway, so things might as well be backpatched? If
> that requirements is gone, I think it's time to drop it.
+1
> And +1 on pushing out one final "end of the tr
"Dave Page" <[EMAIL PROTECTED]> writes:
>> From: Tom Lane <[EMAIL PROTECTED]>
>> I see that there are two or three minor bug fixes in the REL7_3_STABLE
>> branch since 7.3.20. Rather than just leaving those to rot, maybe the
>> actual policy should be "only one more update after 8.3 comes out".
>
On Tue, 2007-11-27 at 14:02 -0500, Tom Lane wrote:
> By chance I happened to notice in the release notes
>
> Release 7.3
> Release date: 2002-11-27
>
> Man, it feels like a long time since that came out...
>
> There has been some discussion of making a project policy of dropping
> support for o
> --- Original Message ---
> From: Tom Lane <[EMAIL PROTECTED]>
> To: pgsql-hackers@postgresql.org
> Sent: 27/11/07, 19:02:24
> Subject: [HACKERS] PG 7.3 is five years old today
>
> I see that there are two or three minor bug fixes in the REL7_3_STABLE
> branch since 7.3.20. Rather than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 27 Nov 2007 14:02:24 -0500
Tom Lane <[EMAIL PROTECTED]> wrote:
> By chance I happened to notice in the release notes
>
> Release 7.3
> Release date: 2002-11-27
>
> Man, it feels like a long time since that came out...
5 years was a long tim
By chance I happened to notice in the release notes
Release 7.3
Release date: 2002-11-27
Man, it feels like a long time since that came out...
There has been some discussion of making a project policy of dropping
support for old releases after five years. Should we consider formally
instituting
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Joshua D. Drake wrote:
>> Well I think that we do take performance into account. I agree
>> that we should *never* have a regression in performance from release
>> to release, which is what I believe has inspired this thread.
> Hmm. I have developed se
Joshua D. Drake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, 27 Nov 2007 17:32:49 +
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
> > Maybe we should give each Beta a name, such as "Initial Beta",
> > "Performance Beta", "Usability Beta" as a way of encouraging folk to
Simon Riggs wrote:
We obviously need a performance build farm and I think everyone accepts
that. We just need to do it, so that's a given and is something I hope
to be involved in.
It's on my list ... Had I but world enough and time ...
Performance testing can be bolted onto the exitin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 27 Nov 2007 18:18:52 +
Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-11-27 at 10:08 -0800, Joshua D. Drake wrote:
> > Simon Riggs <[EMAIL PROTECTED]> wrote:
> Agreed. I either initiated or assisted with most of those items; but
>
On Tue, 2007-11-27 at 10:08 -0800, Joshua D. Drake wrote:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
> > Maybe we should give each Beta a name, such as "Initial Beta",
> > "Performance Beta", "Usability Beta" as a way of encouraging folk to
> > focus onto particular aspects of quality at what we con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 27 Nov 2007 17:32:49 +
Simon Riggs <[EMAIL PROTECTED]> wrote:
> Maybe we should give each Beta a name, such as "Initial Beta",
> "Performance Beta", "Usability Beta" as a way of encouraging folk to
> focus onto particular aspects of quali
On Tue, Nov 27, 2007 at 05:32:49PM +, Simon Riggs wrote:
> What I would really like to persuade everybody is that performance needs
> specific attention.
[. . .]
> Your thoughts are welcome,
Well, one thing that might help is something of the specifics you mention.
I remember mentioning to
Am Donnerstag, 15. November 2007 schrieb Tom Lane:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Donnerstag, 15. November 2007 schrieb Tom Lane:
> >> This seems too far removed from the scene of the crime
> >
> > Yeah, my zeroth attempt was to place this in gets_fromFile(), but there
> > yo
Just wanted to review a few thoughts and ideas around improving external
sorts, as recently encouraged to do by Jim Nasby.
Current issues/opportunities are these:
ISSUES
a) Memory is always in short supply, so using what we have more
effectively is going to be welcome.
b) Heap sort has a reaso
Martin is actually right. No assumption is made about the encoding of the
password. The password is recieved as a set of bytes over the wire-level
protocol and then processed accordingly as per your pg_hba settings. please
refer to auth.c method recv_password_packet(Port *port). The comment on t
Every release we seem to have the same debates about performance issues.
In 8.0 we shipped knowing that bgwriter had serious deficiencies, plus
had no way of logging SQL statements for performance tuning. In 8.2 we
even ended up tweaking the planner *after* release.
What I don't understand is a
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Now I'm thinking I leave the grammar rules alone (apart from making it
> legal to specify an empty list of elements), and instead push the
> typename down into the child node from makeTypeCast(), if the child is
> an A_ArrayExpr. Does that work better?
I need help understanding the following two release note items (see XXX):
Create a general mechanism that supports casts to and from the
standard string types (TEXT, VARCHAR,
CHAR) for every datatype, by
invoking the datatype's I/O functions (Tom) XXX exam
Any comment about Two Ways Replacement Selection (two heaps instead of just
one) ?
--
From: "Simon Riggs" <[EMAIL PROTECTED]>
Sent: Tuesday, November 27, 2007 1:03 PM
To: <[EMAIL PROTECTED]>
Cc:
Subject: Re: [HACKERS] Replacement Selection
On T
On Nov 28, 2007 2:56 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I wonder whether we are also interested in catching CAST(), e.g.:
>
> > CAST(ARRAY[] AS text[])
>
> I think you'll find that it's just about impossible to not handle both,
> because they look the same after the grammar gets done.
Tha
Rudolf van der Leeden <[EMAIL PROTECTED]> writes:
> What could be the cause of this problem? Is it a bug or my fault?
It looks like a corrupted-data kind of problem. Can you extract
a reproducible test case?
regards, tom lane
---(end of broadcast)
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> So far I've only considered the '::' cast syntax suggested in the
> original proposal, e.g.:
> ARRAY[]::text[]
> I wonder whether we are also interested in catching CAST(), e.g.:
> CAST(ARRAY[] AS text[])
I think you'll find that it's just about impo
On Tuesday 27 November 2007, Martijn van Oosterhout wrote:
> I was under the impression that the username/password, had no encoding,
> they are Just a Bunch of Bits, i.e. byte[].
I cannot agree to that, simply because Postgres supports (or at least claims
to) multi-byte characters. And user names
Rudolf van der Leeden wrote:
Hi folks,
I've been trying to test a backup/restore of our production database
(26GB on disk) using PG 8.2.4 as backup and PG 8.3beta3 for the restore.
FIRST TRY:
pg_dump (v8.3beta3) --format=cthe PG 8.2.4 database OK
pg_restore into a bran
So far I've only considered the '::' cast syntax suggested in the
original proposal, e.g.:
ARRAY[]::text[]
I wonder whether we are also interested in catching CAST(), e.g.:
CAST(ARRAY[] AS text[])
I'm personally okay with leaving it at support for '::', but
admittedly I am heavily biased toward
Le mardi 27 novembre 2007 à 10:00 -0500, Andrew Dunstan a écrit :
>
> Hubert FONGARNAND wrote:
> > We are using the CONNECT BY patch made by Evgen Potemkin on
> > PostGreSQL 8.2... It works like a charm with very high performances.
> >
> > But now, we are looking for the 8.3 release... Evgen
Hi folks,
I've been trying to test a backup/restore of our production database
(26GB on disk) using PG 8.2.4 as backup and PG 8.3beta3 for the restore.
FIRST TRY:
pg_dump (v8.3beta3) --format=cthe PG 8.2.4 database OK
pg_restore into a brandnew PG 8.3beta3 database
"Hubert FONGARNAND" <[EMAIL PROTECTED]> writes:
> Ce message et les éventuels documents joints peuvent contenir des
> informations confidentielles. Au cas où il ne vous serait pas destiné, nous
> vous remercions de bien vouloir le supprimer et en aviser immédiatement
> l'expéditeur. Toute utilisat
Hubert FONGARNAND wrote:
We are using the CONNECT BY patch made by Evgen Potemkin on
PostGreSQL 8.2... It works like a charm with very high performances.
But now, we are looking for the 8.3 release... Evgen Potemkin has
stopped to answer about this patch (it's quite normal, he's working at
On Tue, Nov 27, 2007 at 02:51:32PM +0200, [EMAIL PROTECTED] wrote:
> Simply put, what is the client encoding that the server assumes BEFORE the
> client connection is established, that is, during the authentication phase? I
> know there's a "client_encoding" setting on the server side that indica
Tom,
On Nov 27, 2007 3:58 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Please try this patch on your real app (not the dumbed-down test case)
> and see what it does for you ...
If I disable the cache in the application, the most visited page
generates 175 SQL queries, mix of simple and more complica
_
Ce message et les éventuels documents joints peuvent contenir des informations
confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir
le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation d
_
Ce message et les éventuels documents joints peuvent contenir des informations
confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir
le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation d
On Tue, 2007-11-27 at 09:25 +0100, [EMAIL PROTECTED] wrote:
> Others optimizations, for example, can be done with the "virtual
> concatenation" technique:
> storing a cache of couples (first_element,last_element) for each created
> run. This
> could be useful in case we can find 2 couples (first
Hi all.
I have read the documentation, searched the mailing lists and inspected the
code JDBC driver code. I do need to address this question to actual
developers.
Simply put, what is the client encoding that the server assumes BEFORE the
client connection is established, that is, during the a
--On Montag, November 26, 2007 21:41:33 +0100 I wrote:
--On Montag, November 26, 2007 13:02:14 -0500 Tom Lane
<[EMAIL PROTECTED]> wrote:
Bernd Helmle <[EMAIL PROTECTED]> writes:
... But isn't it worth to special case the
code in grow_memtuples() (and maybe other places where sort is likely to
Hi to all.
It seems a previous mail of mine with following body hasn't been sent.
Sorry for possibly getting it twice.
Actually I have now modified that body, so it's worth to read it once again.
Thanks for your attention.
Regards.
PREVIOUS MAIL--
Well, the
On Nov 27, 2007 6:34 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> And an additional beta might encourage more testing too.
I'm not that sure of this point. I'm really worried about the lack of
people testing 8.3 at the moment. We have really too little feedback.
Perhaps they didn't meet any prob
87 matches
Mail list logo
