On 11.03.2011 06:21, Fujii Masao wrote:
On Thu, Dec 9, 2010 at 4:55 PM, Simon Riggs wrote:
On Thu, 2010-12-09 at 00:16 +0100, Heikki Linnakangas wrote:
On 09.12.2010 00:10, Heikki Linnakangas wrote:
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record
On 10.12.2010 19:55, Noah Misch wrote:
On Thu, Dec 09, 2010 at 09:48:25AM +, Simon Riggs wrote:
On Fri, 2010-12-03 at 21:43 +0200, Heikki Linnakangas wrote:
Seems reasonable. HeapTupleHeaderAdvanceLatestRemovedXid() will need
similar treatment. Actually, btree_xlog_delete_get_latestRemovedX
Robert Haas wrote:
> On Thu, Mar 10, 2011 at 10:36 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> Back in 2006, we have this commit:
> >>
> >> commit 2b25e1169f44368c120931787628d51731b5cc8c
> >> Author: Peter Eisentraut
> >> Date: ? Sat Oct 7 20:59:05 2006 +
> >>
> >> ? ? The -X option
Robert Haas wrote:
> Back in 2006, we have this commit:
>
> commit 2b25e1169f44368c120931787628d51731b5cc8c
> Author: Peter Eisentraut
> Date: Sat Oct 7 20:59:05 2006 +
>
> The -X option in pg_dump was supposed to be a workaround for the lack of
> portable long options. But we hav
Josh Kupershmidt wrote:
> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
> wrote:
> > It occurs to me that we may need a new mode, which disconnects sessions
> > that are not in a transaction (or as soon as they are) but leaves
> > in-progress transactions alone; this could be the new default. ?
Josh Berkus wrote:
> On 12/6/10 6:10 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mon, Dec 6, 2010 at 9:04 PM, Josh Berkus wrote:
> >>> Actually, on OSX 10.5.8, o_dsync and fdatasync aren't even available.
> >>> From my run, it looks like even so regular fsync might be better than
> >>> op
2011/3/11 Bruce Momjian :
>
> What happened with this patch? Alvaro saw a 25x speedup.
There is not conformance about form in this patch. But there are a
FOREACH statement - so if somebody uses this statement, then he will
not have a problems with performance.
Regards
Pavel
>
> ---
On Thu, Dec 9, 2010 at 4:55 PM, Simon Riggs wrote:
> On Thu, 2010-12-09 at 00:16 +0100, Heikki Linnakangas wrote:
>> On 09.12.2010 00:10, Heikki Linnakangas wrote:
>> > On 08.12.2010 16:00, Simon Riggs wrote:
>> >> Heikki pointed out to me that the btree delete record processing does
>> >> not res
On Thu, Mar 10, 2011 at 10:36 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> Back in 2006, we have this commit:
>>
>> commit 2b25e1169f44368c120931787628d51731b5cc8c
>> Author: Peter Eisentraut
>> Date: Sat Oct 7 20:59:05 2006 +
>>
>> The -X option in pg_dump was supposed to be a work
I have added a link to this on the TODO list:
Add "auto" expanded mode that outputs in expanded format if "wrapped"
mode can't wrap the output to the screen width
* Re: psql wrapped format default for backslash-d commands
* http://archives.postgres
Peter Eisentraut wrote:
> On fre, 2010-12-17 at 12:57 +0100, Magnus Hagander wrote:
> > The limit on max_standby_streaming_delay is currently 35 minutes
> > (around) - or you have to set it to unlimited. This is because the GUC
> > is limited to MAX_INT/1000, unit milliseconds.
> >
> > Is there a
On Thu, Mar 10, 2011 at 7:32 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> 2010/11/25 pasman pasma?ski :
>> >>I've seen this as well be a performance issue, in particular with
>> >>partitioned tables.
>> >>Out of habit I now write functions that always cache the value of the
>> >>function in
Robert Haas wrote:
> 2010/11/25 pasman pasma?ski :
> >>I've seen this as well be a performance issue, in particular with
> >>partitioned tables.
> >>Out of habit I now write functions that always cache the value of the
> >>function in
> >>a variable and use the variable in the actual query to avo
Bruce Momjian writes:
> What happened with this patch? Alvaro saw a 25x speedup.
It got bounced.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
Magnus Hagander writes:
> On Thu, Mar 10, 2011 at 22:22, Bruce Momjian wrote:
>>
>> Added to TODO:
>>
>> Rename unix domain socket 'ident' connections to 'peer', to avoid
>> confusion with TCP 'ident'
> Should we consider adding "peer" as an alias for "ident" already in
> 9.1 (an
What happened with this patch? Alvaro saw a 25x speedup.
---
Pavel Stehule wrote:
> Hello
>
> this patch remove a multiple detoasting of varlena values in plpgsql.
>
> It is usable mainly for iteration over longer array d
Magnus Hagander wrote:
> On Thu, Mar 10, 2011 at 22:22, Bruce Momjian wrote:
> >
> > Added to TODO:
> >
> > ? ? ? ?Rename unix domain socket 'ident' connections to 'peer', to avoid
> > ? ? ? ?confusion with TCP 'ident'
>
> Should we consider adding "peer" as an alias for "ident" already in
> 9.1
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > On Wed, Nov 17, 2010 at 19:54, Bruce Momjian wrote:
> > > Looking here:
> > >
> > > ? ? ? ?http://wiki.postgresql.org/wiki/Working_with_Git
> > >
> > > the script we recommend for doing context diffs for git,
> > > git-external-diff, is not portabl
This seems a tad unfriendly:
db1=# create table foo (f1 text collate "default");
ERROR: collation "default" for current database encoding "UTF8" does not exist
LINE 1: create table foo (f1 text collate "default");
^
Not being able to explicitly specify the defau
Martijn van Oosterhout writes:
> On Thu, Mar 10, 2011 at 05:16:52PM -0500, Tom Lane wrote:
>> On the other hand ... one thing that's been bothering me is that
>> select_common_collation assumes that "explicit" collation derivation
>> doesn't bubble up in the tree, ie a COLLATE is only a forcing fu
On Thu, Mar 10, 2011 at 05:16:52PM -0500, Tom Lane wrote:
> On the other hand ... one thing that's been bothering me is that
> select_common_collation assumes that "explicit" collation derivation
> doesn't bubble up in the tree, ie a COLLATE is only a forcing function
> for the immediate parent exp
I wrote:
> A post-pass is not out of the question, but it's enough unlike
> everything else the parser does that I'm not too thrilled about it.
On the other hand ... one thing that's been bothering me is that
select_common_collation assumes that "explicit" collation derivation
doesn't bubble up in
Martijn van Oosterhout writes:
> On Thu, Mar 10, 2011 at 10:34:00AM -0500, Tom Lane wrote:
>> I suspect this is probably not a good idea because of the added cost in
>> select_common_collation: aside from probably needing more syscache
>> lookups, there's a potential for worse-than-linear cost beh
On Thu, Mar 10, 2011 at 22:22, Bruce Momjian wrote:
>
> Added to TODO:
>
> Rename unix domain socket 'ident' connections to 'peer', to avoid
> confusion with TCP 'ident'
Should we consider adding "peer" as an alias for "ident" already in
9.1 (and change the default pg_hba.conf templ
2011/3/10 Jesper Krogh :
> On 2011-03-10 19:25, Bruce Momjian wrote:
>
>> Sure, anyone can add text to that wiki; you create a community account
>> here:
>>
>> http://www.postgresql.org/community/signup
>
> Suggestion: Add this url to the login box on the wiki.
+1, Adrian von Bidder had t
On Mon, Mar 7, 2011 at 4:47 AM, Fujii Masao wrote:
> Anyway, the reload of the configuration file should not
> cause the server to end unexpectedly. IOW, GUC assign hook should
> use GUC_complaint_elevel instead of FATAL, in ereport. The attached
> patch fixes that, and includes two typo fixes.
C
Added to TODO:
Rename unix domain socket 'ident' connections to 'peer', to avoid
confusion with TCP 'ident'
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01053.php
---
Magnu
On Thu, Mar 10, 2011 at 10:34:00AM -0500, Tom Lane wrote:
> Hmm. That suggests a third solution: revert the addition of *all* the
> collid fields except the ones that represent collation-to-apply-during-
> function-execution. (So they'd still be there in FuncExpr/OpExpr, but
> not most other plac
I have added a link to this from the exiting TODO item:
Improve handling of NULLs in arrays
* BUG #4509: array_cat's null behaviour is inconsistent
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php
--
Andrew Dunstan wrote:
>
>
> On 11/05/2010 06:54 PM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> The comment on the commit says:
> >> EXECUTE of a SELECT ... INTO now draws a 'not implemented' error,
> >> rather than executing the INTO clause with non-plpgsql semantics
> >> as
On Thu, Mar 10, 2011 at 3:29 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> they are, but there's no easy way to figure out what that means in
>> terms of wall-clock time, which I think would be useful.
>
> Jan Wieck had a detailed proposal to make that happen at last developper
> meeting,
Bruce Momjian wrote:
>
> Has this been addressed?
I see we have with this commit:
9de3aa65f01fb51cbc725e8508ea233e4e92c46c
---
>
> ---
>
>
On 03/10/2011 03:14 PM, Bruce Momjian wrote:
Did this get done? If so, I don't see it.
Oh, no. It skipped my TODO list. I'll try to get it done in the next day
or so.
I have added this to the 9.1 open items list:
http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items#Code_Issues
Has this been addressed?
---
Heikki Linnakangas wrote:
> On 13.11.2010 00:34, Greg Stark wrote:
> > On Fri, Nov 12, 2010 at 7:20 PM, Heikki Linnakangas
> > wrote:
> >> I think we can work around that with a small modificat
Tom Lane wrote:
> Bruce Momjian writes:
> > Andrew Dunstan wrote:
> >>
> >>
> >> On 02/21/2011 09:33 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> > Andrew Dunstan writes:
> > I propose that we add the following test for this case:
> > AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file
>
Bruce Momjian writes:
> Andrew Dunstan wrote:
>>
>>
>> On 02/21/2011 09:33 PM, Bruce Momjian wrote:
> Tom Lane wrote:
> Andrew Dunstan writes:
> I propose that we add the following test for this case:
> AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file
> is required for Python])])
> You'
Robert Haas writes:
> they are, but there's no easy way to figure out what that means in
> terms of wall-clock time, which I think would be useful.
Jan Wieck had a detailed proposal to make that happen at last developper
meeting, but then ran out of time to implement it for 9.1 it seems. The
ide
On tis, 2011-03-08 at 20:52 -0500, Tom Lane wrote:
> I think we should drop from TypeName and just have it
> in columnDef and the expression syntax.
Yes, that sounds better in retrospect. It's easier to see that now that
we see all the cases where it's used and not used.
> This might also ease
Peter Eisentraut writes:
> On ons, 2011-03-09 at 18:07 -0500, Tom Lane wrote:
>> Now the downside of that is that a runtime failure won't give you an
>> parse error pointer to indicate which function is having trouble ...
>> but having an error pointer for an error that shouldn't be thrown in
>> t
Andrew Dunstan wrote:
>
>
> On 02/21/2011 09:33 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Andrew Dunstan writes:
> >>> I propose that we add the following test for this case:
> >>> AC_CHECK_HEADER(Python.h, [], [AC_MSG_ERROR([header file
> >>> is required for Python])])
> >> Yo
On ons, 2011-03-09 at 18:07 -0500, Tom Lane wrote:
> The first of these errors is OK, but surely the second is not, because
> ||
> doesn't give a fig about collations. I think instead of this:
>
> /* XXX: If we knew which functions required collation
> information,
> * we could s
On Mon, Mar 7, 2011 at 6:21 AM, Fujii Masao wrote:
> On Mon, Mar 7, 2011 at 5:27 PM, Fujii Masao wrote:
>> On Mon, Mar 7, 2011 at 7:51 AM, Simon Riggs wrote:
>>> Efficient transaction-controlled synchronous replication.
>>> If a standby is broadcasting reply messages and we have named
>>> one or
On Thu, Mar 10, 2011 at 2:42 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> was. So you could then say things like "is the most recent time at
>> which the standby was caught up within the last 30 seconds?", which
>> would be a useful thing to monitor, and right now there's no way to do
>
Robert Haas writes:
> was. So you could then say things like "is the most recent time at
> which the standby was caught up within the last 30 seconds?", which
> would be a useful thing to monitor, and right now there's no way to do
Well in my experience with replication, that's not what I want t
On Tue, Mar 8, 2011 at 5:48 AM, Fujii Masao wrote:
> On Tue, Mar 8, 2011 at 12:04 PM, Fujii Masao wrote:
>> On Wed, Feb 9, 2011 at 5:12 PM, Magnus Hagander wrote:
>>> I was also worried about the non-hot-standby case, but I see that the
>>> patch makes sure you can't enable pause when not in hot
On Thu, Mar 10, 2011 at 1:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> Now that alpha4 is out the door (and the bug reports have begun to
>> roll in), we should probably give some more serious thought to the
>> road from here to beta1. There's a partial list of open items here:
>> http://wiki
On Wed, 2011-03-09 at 21:21 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Fri, 2011-03-04 at 23:15 +0900, Fujii Masao wrote:
> >
> > > postgres=# SELECT application_name, state, sync_priority, sync_state
> > > FROM pg_stat_replication;
> > > application_name | state | sync_priority
Robert Haas writes:
> Now that alpha4 is out the door (and the bug reports have begun to
> roll in), we should probably give some more serious thought to the
> road from here to beta1. There's a partial list of open items here:
> http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items
> Many o
On 2011-03-10 19:25, Bruce Momjian wrote:
Sure, anyone can add text to that wiki; you create a community account
here:
http://www.postgresql.org/community/signup
Suggestion: Add this url to the login box on the wiki.
--
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Thu, Mar 10, 2011 at 12:52 PM, Greg Stark wrote:
> On Thu, Mar 10, 2011 at 1:45 PM, Robert Haas wrote:
>> 1. Somebody inserts a bunch of new tuples into the relation, causing
>> growth in the index.
>
> In case it's not obvious VACUUM FULL would do precisely that.
Oh, I didn't even think abou
Jesper Krogh wrote:
> On 2011-03-10 18:00, Bruce Momjian wrote:
>
> > Dirty reads are unlikely to be implemented. We do have a TODO item
> > and wiki page about how to allow index scans without heap access:
> >
> > http://wiki.postgresql.org/wiki/Index-only_scans
>
> I think we (the company I
On 2011-03-10 18:00, Bruce Momjian wrote:
Dirty reads are unlikely to be implemented. We do have a TODO item
and wiki page about how to allow index scans without heap access:
http://wiki.postgresql.org/wiki/Index-only_scans
I think we (the company I work for) would help co-sponsor such
a f
On Thu, Mar 10, 2011 at 1:45 PM, Robert Haas wrote:
> 1. Somebody inserts a bunch of new tuples into the relation, causing
> growth in the index.
In case it's not obvious VACUUM FULL would do precisely that.
> 2. Before the blocks are written to disk, system crash.
> 3. pg_resetxlog
Do you have
On Thu, Mar 10, 2011 at 6:31 AM, hans wulf wrote:
> Hi,
>
> if you want to do dirty counts or sums or any aggreate stuff, you will always
> have to visit the table. For many applications nobody cares about 0,01%
> inaccuracy.
>
> If you could keep the data that has to be aggregated in the index
On Thu, Mar 10, 2011 at 12:31 PM, hans wulf wrote:
> I don't know the postgres code, but I don't thing it is a big deal, not to
> care about consistancy. The code for executing such a query should be quite
> basic, because no MVCC-Stuff has to be done.
I remember I used to think this would be s
hans wulf wrote:
> Hi,
>
> if you want to do dirty counts or sums or any aggreate stuff, you will
> always have to visit the table. For many applications nobody cares
> about 0,01% inaccuracy.
>
> If you could keep the data that has to be aggregated in the index you
> could approximate values rea
Tom Lane wrote:
> I expect to be spending a whole lot of time reading collate and
> SSI code over the next few weeks, so I'm in favor of pgindent'ing
> that stuff first.
I've been running that throughout development, but it hasn't been
run after the last few changes. If you want the SSI files
Hello, i have an old system where used implicit casting
float<->integer
numeric<->float
numeric<->integer
I want define implicit casts, but postgresql don`t know cast priority
now postgresql have PREFERRED flag, but only flag
I can`t define prefer level like
Integer=0
Numeric=1
Float=2
Maybe
tex
Hi,
if you want to do dirty counts or sums or any aggreate stuff, you will always
have to visit the table. For many applications nobody cares about 0,01%
inaccuracy.
If you could keep the data that has to be aggregated in the index you could
approximate values really fast.
But because "Read u
On Thu, Mar 10, 2011 at 10:59 AM, Tom Lane wrote:
> Robert Haas writes:
> Speaking of running scripts, I think we should run pgindent now.
>
>> Yeah, +1 for doing it as soon as Tom is at a good stopping point. It
>> makes things a lot simpler later on.
>
> IIRC the argument for an early pgin
On 03/10/2011 10:33 AM, Robert Haas wrote:
On Thu, Mar 10, 2011 at 10:21 AM, Bruce Momjian wrote:
Tom Lane wrote:
Itagaki Takahiro writes:
I found trivial mistakes in the recently added files.
Will they fixed by some automated batches, or by manual?
- "Copyright (c) xxx-*2010*, PostgreSQL
Robert Haas writes:
Speaking of running scripts, I think we should run pgindent now.
> Yeah, +1 for doing it as soon as Tom is at a good stopping point. It
> makes things a lot simpler later on.
IIRC the argument for an early pgindent run was to standardize the new
code for easier review.
On Thu, Mar 10, 2011 at 16:50, Robert Haas wrote:
> On Thu, Mar 10, 2011 at 10:47 AM, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Robert Haas wrote:
Speaking of running scripts, I think we should run pgindent now.
>>
>>> We usually do it during a late beta.
>>
>> Last time we did it early
On Wed, Mar 9, 2011 at 11:43 PM, Bruce Momjian wrote:
> Thom Brown wrote:
>> On 7 March 2011 22:31, Robert Haas wrote:
>> > On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown wrote:
>> >> On 7 March 2011 15:27, Thom Brown wrote:
>> >>> I've attached a small patch with a bit of clarification and a typo
On Thu, Mar 10, 2011 at 10:47 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Robert Haas wrote:
>>> Speaking of running scripts, I think we should run pgindent now.
>
>> We usually do it during a late beta.
>
> Last time we did it early and then again late, and that seemed to work
> well. I woul
Tom Lane wrote:
> Bruce Momjian writes:
> > Robert Haas wrote:
> >> Speaking of running scripts, I think we should run pgindent now.
>
> > We usually do it during a late beta.
>
> Last time we did it early and then again late, and that seemed to work
> well. I wouldn't object to a pgindent run
Now that alpha4 is out the door (and the bug reports have begun to
roll in), we should probably give some more serious thought to the
road from here to beta1. There's a partial list of open items here:
http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Open_Items
Many of those items related to synch
Bruce Momjian writes:
> Robert Haas wrote:
>> Speaking of running scripts, I think we should run pgindent now.
> We usually do it during a late beta.
Last time we did it early and then again late, and that seemed to work
well. I wouldn't object to a pgindent run now, but please sync with me
bef
Robert Haas wrote:
> On Thu, Mar 10, 2011 at 10:21 AM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Itagaki Takahiro writes:
> >> > I found trivial mistakes in the recently added files.
> >> > Will they fixed by some automated batches, or by manual?
> >>
> >> > - "Copyright (c) xxx-*2010*, Postg
Greg Stark writes:
> Can you give an example of what a column definition would look like if
> you put the COLLATE clause in the in a way that wouldn't
> be parsed according to your plan?
Column definitions look and act the same. The point of the change is to
not accept COLLATE in all the places
On Wed, Mar 9, 2011 at 7:03 PM, Josh Berkus wrote:
> Then I think the answer is that we need both data types. One for
> text-XML and one for binary-XML.
That's what I think, too. I'm not sure whether we want both of them
in core, but I think the binary-XML one would, at a minimum, make an
awful
Martijn van Oosterhout writes:
> On Wed, Mar 09, 2011 at 04:49:28PM -0500, Tom Lane wrote:
>> There are basically two things we could do about this:
>>
>> 1. Add two fields not one to nodes representing function/operator calls.
>>
>> 2. Change exprCollation() to do a type_is_collatable check on
On Thu, Mar 10, 2011 at 10:21 AM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Itagaki Takahiro writes:
>> > I found trivial mistakes in the recently added files.
>> > Will they fixed by some automated batches, or by manual?
>>
>> > - "Copyright (c) xxx-*2010*, PostgreSQL Global Development Group"
>
On Wed, Mar 9, 2011 at 9:21 PM, Bruce Momjian wrote:
> Simon Riggs wrote:
>> On Fri, 2011-03-04 at 23:15 +0900, Fujii Masao wrote:
>>
>> > postgres=# SELECT application_name, state, sync_priority, sync_state
>> > FROM pg_stat_replication;
>> > application_name | state | sync_priority | sync_s
Tom Lane wrote:
> Itagaki Takahiro writes:
> > I found trivial mistakes in the recently added files.
> > Will they fixed by some automated batches, or by manual?
>
> > - "Copyright (c) xxx-*2010*, PostgreSQL Global Development Group"
> > in pg_collation.h, pg_foreign_table.h, basebackup.h, sync
On Wed, Mar 9, 2011 at 1:52 AM, Tom Lane wrote:
> Another interesting item ... I see that you added a collation field to
> TypeName, apparently on the grounds that the SQL spec includes collation
> in . However, it seems to me that that is nonsense up with
> which we should not put.
The SQL comm
On Wed, Mar 9, 2011 at 9:01 PM, Fujii Masao wrote:
> On Thu, Mar 10, 2011 at 2:00 AM, Robert Haas wrote:
>> On Wed, Mar 9, 2011 at 6:11 AM, Fujii Masao wrote:
>>> The attached patch updates replication/README to reflect current
>>> walsender/walreceiver behavior. It doesn't include any descripti
On Wed, Mar 9, 2011 at 7:14 PM, Greg Stark wrote:
> On Wed, Mar 9, 2011 at 11:28 PM, Nikhil Sontakke
> wrote:
>> "Other peculiarity in the index file is that we found a lot of zeroed
>> out pages. Blocks from #279 to #518 are all completely zeroed out
>> without any signs of even a page header. A
Hi,
>> "Other peculiarity in the index file is that we found a lot of zeroed
>> out pages. Blocks from #279 to #518 are all completely zeroed out
>> without any signs of even a page header. Any ideas on how we can get
>> so many zeroed out blocks? Apart from the extend code path, I fail to
>> see
On Wed, Mar 09, 2011 at 04:49:28PM -0500, Tom Lane wrote:
> So I was moving some error checks around and all of a sudden the
> regression tests blew up on me, with lots of errors about how type X
> didn't support collations (which indeed it didn't). After some
> investigation I realized what shoul
80 matches
Mail list logo
