On Fri, 14 Nov 2008, Gregory Stark wrote:
In particular I was hoping Zoltan who original reported the sequential
file strategy stuff being helpful might be able to see if this works for
him.
The original message there suggested it was particularly valuable when
working with a somewhat broken
Tom Lane <[EMAIL PROTECTED]> writes:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>> What's particularly unfortunate is Greg's comment that this would work
>> if the planner chose an index scan. Had I defined an index on the
>> columns in question, my code might have worked and been deployed to
>>
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
On the whole I vote for #4 out of these.
I attached a patch for the docs. Its documented as a NOTE to the
PGEventProc.
Applied, but I editorialized on the wording a bit. Let me know if you
think this is wrong ...
It's correct,
Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm trying to figure out what is the status of this patch? I'm not sure
> if there's any point in applying it, when contrib/pg_stat_statements
> hasn't been updated to make use of it.
Here is an updated patch to use QueryDesc.queryText and supports nested
st
> This is the whole patch of Synch Rep against head. This also contain
> "Infrastructure changes for recover" patch by Simon because I'd like to
> make walreceiver work in consistent recovery mode.
Given that both this patch and Simon's hot standby patches need this
infrastructure, it seems like i
> However ... the more I think about it, the more I wonder if we shouldn't
> rip out the current search-the-plan-tree hack and allow WHERE CURRENT OF
> *only* for cursors that say FOR UPDATE. Aside from the above issue,
> there's an already known and documented risk if you omit FOR UPDATE,
> which
Tom Lane <[EMAIL PROTECTED]> wrote:
> Now that I look closer, the "contrib infrastructure" item is just a
> combination of the auto_explain and pg_stat_statements items, and I
> guess the reason you and Matthew were shown as reviewers was that
> you'd each been assigned one of those two items. A
> Here's a draft patch (no docs, no regression test) for that. It doesn't
> look as ugly as I expected. Comments? I'm hesitant to call this a bug
> fix, and we are past feature freeze ...
Considering the number of and invasiveness of the patches remaining in
the queue, I'm inclined to consider
"Robert Haas" <[EMAIL PROTECTED]> writes:
> What's particularly unfortunate is Greg's comment that this would work
> if the planner chose an index scan. Had I defined an index on the
> columns in question, my code might have worked and been deployed to
> production - and then broken if the planner
Hitoshi Harada wrote:
> > david=# explain select date,lag(date,1) over (order by date) from
> > meter_Readings order by date;
> > QUERY PLAN
> >
>
> > --
I wrote:
> [ dept of second thoughts... ] Actually, given that he said FOR UPDATE,
> the plan should be propagating the tuple identity through to top level
> so that execMain can do its thing. So in principle we could probably
> get the information without widespread changes. This would fit
> re
On Friday 14 November 2008 13:37:05 hernan gonzalez wrote:
> On Fri, Nov 14, 2008 at 4:12 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "hernan gonzalez" <[EMAIL PROTECTED]> writes:
> >> I've added an option to pg_dump to reorder
> >> columns in the ouput "CREATE TABLE" dump.
> >
> > This doesn't see
Andrew Chernow <[EMAIL PROTECTED]> writes:
>> On the whole I vote for #4 out of these.
> I attached a patch for the docs. Its documented as a NOTE to the
> PGEventProc.
Applied, but I editorialized on the wording a bit. Let me know if you
think this is wrong ...
regar
> As this hasn't happened and I haven't been able to demonstrate it being useful
> myself I guess it makes more sense to separate the two now and set the
> sequential scan stuff aside until someone can demonstrate it being useful.
Sounds good. How soon do you think you can post updated patches?
"Robert Haas" <[EMAIL PROTECTED]> writes:
> I was pretty leery about reviewing this one due to the feeling that I
> might well be in over my head, but they talked me into it, so here
> goes nothin'. Apologies in advance for any deficiencies in this
> review.
>
> - Overall, this looks pretty clean
> [ dept of second thoughts... ] Actually, given that he said FOR UPDATE,
> the plan should be propagating the tuple identity through to top level
> so that execMain can do its thing. So in principle we could probably
> get the information without widespread changes. This would fit
> reasonably
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>> I found the following behavior surprising. Is there a reason for it?
>> This is 8.3.5. ...Robert
>>
>> rhaas=# DECLARE c CURSOR FOR SELECT id FROM test_table ORDER BY foo FOR
>> UPDATE;
> Skimming the cod
Tom Lane wrote:
> ... meanwhile, the MSVC port has got its own issues:
>
> Generating win32ver.rc for src\backend
> Building src\pl\plperl\SPI.c...
> Could not determine contrib module type for intagg
> at build.pl line 37
>
> I am not sure what if anything that script needs to do for a contrib
"Robert Haas" <[EMAIL PROTECTED]> writes:
> I found the following behavior surprising. Is there a reason for it?
Yes.
regards, tom lane
(Oh, you wanted to know what the reason is? It's because a sort step
is not going to pass through any tuple identity information.)
--
... meanwhile, the MSVC port has got its own issues:
Generating win32ver.rc for src\backend
Building src\pl\plperl\SPI.c...
Could not determine contrib module type for intagg
at build.pl line 37
I am not sure what if anything that script needs to do for a contrib
module with no .c files.
"Robert Haas" <[EMAIL PROTECTED]> writes:
> I found the following behavior surprising. Is there a reason for it?
> This is 8.3.5. ...Robert
>
> rhaas=# DECLARE c CURSOR FOR SELECT id FROM test_table ORDER BY foo FOR
> UPDATE;
> DECLARE CURSOR
Skimming the code we don't support WHERE CURRENT O
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Your second go at fixing this seems to have almost worked. Is there a
> reason why, alone of the utility programs, pg_resetxlog.c uses
> postgres.h rather than postgres_fe.h?
It doesn't compile otherwise.
We could possibly refactor the backend includ
Tom Lane wrote:
I did this:
http://archives.postgresql.org/pgsql-committers/2008-11/msg00156.php
to try to fix this:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhal&dt=2008-11-12%2021:00:01
only to get this:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhal&dt=2008-11-13%2015:
Alvaro Herrera wrote:
> I didn't check the rest of the code, so don't count this as a review.
I had a look at aclchk.c and didn't like your change to
objectNamesToOids; seems rather baroque. I changed it per the attached
patch.
Moreover I didn't very much like the way aclcheck_error_col is deal
I found the following behavior surprising. Is there a reason for it?
This is 8.3.5. ...Robert
rhaas=# BEGIN WORK;
BEGIN
rhaas=# CREATE TABLE test_table (id serial, foo integer, bar integer);
NOTICE: CREATE TABLE will create implicit sequence
"test_table_id_seq" for serial column "test_table.id
Fujii Masao wrote:
Attached is a patch of signal handling changes for Synch Rep.
It seems that we wouldn't need to use the BackendPidGetProc function,
nor the new AuxiliaryPidGetProc function, if we stored a PGPROC *
instead of the pid in ProcState.procPid.
--
Heikki Linnakangas
Enterpr
On Fri, 14 Nov 2008, Richard Huxton wrote:
Is it only me that thinks this should be a service on the website too
(or even first)? Fill in web form, click button, get sample
postgresql.conf (with comments) back.
Sounds familiar...ah, here it is:
http://archives.postgresql.org/pgsql-performance
Martin Pihlak <[EMAIL PROTECTED]> writes:
> ITAGAKI Takahiro wrote:
>>> But is the idea of extending QueryDesc generally acceptable? Is it OK
>>> to make a copy of the query string?
>>
>> The only thing I'm worried about is that QueryDesc lives longer than
>> its queryText. Can I assume it never o
Jeff Davis <[EMAIL PROTECTED]> writes:
> On Thu, 2008-11-13 at 14:31 -0500, Tom Lane wrote:
>> This patch seems to contain a subset of the "contrib infrastructure"
>> patch that's listed separately on the commitfest page. While I have
>> no strong objection to what's here, I'm wondering what sort
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I'm submitting 2 contrib modules and there 3 patches to core for them
> from me and Martin, but they confict each other and there are some hunks
> and rejections already. Here is an assorted patch of them.
> Can I ask you to review the patches in this
On Thu, Nov 13, 2008 at 11:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> A lot of people have suggested raising our default_statistics target,
>> and it has been rejected because there's some O(n^2) behavior in the
>> planner, and it makes ANALYZE sl
On Fri, Nov 14, 2008 at 4:12 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "hernan gonzalez" <[EMAIL PROTECTED]> writes:
>> I've added an option to pg_dump to reorder
>> columns in the ouput "CREATE TABLE" dump.
>
> This doesn't seem like a particularly good idea to me. In the first
> place, pg_dump i
Tom Lane wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
On Fri, Nov 14, 2008 at 11:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
IMHO, the only thing worse than an unstable plan is a stable one.
Your opinion contradicts the majority of the industry then, I'm
afraid. Like query hints, peo
On Fri, 2008-11-14 at 19:23 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2008-11-14 at 19:00 +0200, Heikki Linnakangas wrote:
> >> Why do we need a separate XLogsndRqst variable in shared memory? Don't
> >> we always want to send the WAL up to the same point as we flush it?
>
"hernan gonzalez" <[EMAIL PROTECTED]> writes:
> I've added an option to pg_dump to reorder
> columns in the ouput "CREATE TABLE" dump.
This doesn't seem like a particularly good idea to me. In the first
place, pg_dump is a tool for reproducing your database, not altering it,
so it seems like basi
On Fri, Nov 14, 2008 at 12:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> And, very often, they're not --- or more likely, they were smarter than
> the optimizer last year, but now conditions have changed. Failing to
> adapt to new conditions is exactly the problem with query hints, and
> in general
Simon Riggs wrote:
On Fri, 2008-11-14 at 19:00 +0200, Heikki Linnakangas wrote:
Why do we need a separate XLogsndRqst variable in shared memory? Don't
we always want to send the WAL up to the same point as we flush it?
If we're doing synch rep and we're committing.
You flush and send the WAL
Hi.
As I wanted to change the order of columns of some tables (I know, I
know, my code does not depend
on that; but I prefer that \dt gives me a more organized ouput...)
I've added an option to pg_dump to reorder
columns in the ouput "CREATE TABLE" dump.
The specified order is given in a external f
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On Fri, Nov 14, 2008 at 11:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> IMHO, the only thing worse than an unstable plan is a stable one.
> Your opinion contradicts the majority of the industry then, I'm
> afraid. Like query hints, people are somet
On Fri, 2008-11-14 at 19:00 +0200, Heikki Linnakangas wrote:
> Fujii Masao wrote:
> > Attached is the latest version of Synch Rep patch.
>
> Why do we need a separate XLogsndRqst variable in shared memory? Don't
> we always want to send the WAL up to the same point as we flush it?
If we're doin
On Thu, Nov 13, 2008 at 01:05, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> It means I will go ahead and apply it once I have looked it over once more.
>
> Thanks for review+testing!
>
> You may now move on to the next ssl patch if you're interested ;)
Sure thing probably wont get to it till tomor
Fujii Masao wrote:
Attached is the latest version of Synch Rep patch.
Why do we need a separate XLogsndRqst variable in shared memory? Don't
we always want to send the WAL up to the same point as we flush it?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via p
Michael Meskes <[EMAIL PROTECTED]> writes:
> Added.
Looks alright to me now --- you might as well commit and let the
buildfarm find any remaining problems.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> For some historic reasons, I have my local scripts set up so that they
> build development instances using the hardcoded port 65432. This will
> cause a temp install regression test to attempt to use port 565432 which
> will be rejected silently by
On Fri, Nov 14, 2008 at 11:43 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> IMHO, the only thing worse than an unstable plan is a stable one.
Your opinion contradicts the majority of the industry then, I'm
afraid. Like query hints, people are sometimes smarter than the
optimizer.
--
Jonah H. Harris
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> You're right, I haven't, but yes I know that's a problem. We've chatted
> about that with Greg sometimes. It would be nice to have more stable
> plans. My favorite idea is to stop using the current relation size in
> the planner, and use the value
"Robert Haas" <[EMAIL PROTECTED]> writes:
> On Fri, Nov 14, 2008 at 10:12 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Robert Haas" <[EMAIL PROTECTED]> writes:
>>> I would feel a lot better about it if we could invent some way of
>>> distinguishing between different types of "internal", based on wha
On Fri, Nov 14, 2008 at 10:44:08AM -0500, Tom Lane wrote:
> preproc.y should be removed by make maintainer-clean. For consistency
> it probably ought to be listed in the distprep target too, even though
> it would be indirectly updated by the preproc.c target. I suspect it
> would be a good idea
On Sat, 2008-11-15 at 00:58 +0900, KaiGai Kohei wrote:
> Sorry, it seems to me you misunderstand something.
Yep, seems so. Thank goodness for that. Thanks for putting me straight.
> > I would also like to see the feature part of normal Postgres, rather
> > than as a compile time option. The per
"Dmitry Koterov" <[EMAIL PROTECTED]> writes:
> Thank you for a possible solution.
> But what about the database which exists and works correctly (and conforms
> all the standards from the documentation), but dump+restore sequence is
> failed for it? Does it mean that pg_dump should be improved to p
On Fri, Nov 14, 2008 at 10:12 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Robert Haas" <[EMAIL PROTECTED]> writes:
>> I would feel a lot better about it if we could invent some way of
>> distinguishing between different types of "internal", based on what is
>> actually being pointed to.
>
> Yeah, we
Michael Meskes wrote:
Does anyone see a problem with these changes? Or else I will commit.
FWIW, I have looked at this a bit. I want to refactor it at some stage
because it's ugly and fragile and rather obtuse, but the refactoring
won't be happening for a while.
cheers
andrew
Peter Eisentraut wrote:
So even if I configured my local scripts to use ports that are all
different from each other and from 65432, this problem would still exist.
Only if you choose the private port to be above . The standard
buildfarm config file contains a warning against using suc
Simon Riggs wrote:
> On Thu, 2008-11-13 at 10:44 +0900, KaiGai Kohei wrote:
>
>> It's unclear for me what is the point you said.
>> I guess you concern the fixed length field is always allocated in
>> the case when any security feature is not enabled also, or performance
>> degradation on the larg
On Fri, Nov 14, 2008 at 10:50 AM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
>> Oracle already thought of that a long time ago, which is why the plan
>> has to come out better for it to take effect.
>
> Huh? We would never willingly choose a worse plan, of course, but the point
> is that what lo
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> But I understand the problem is that you want to continue in the face
> of torn pages, something which is AFAICS ambitious. At least MS-SQL
> just blows up on a torn page, havn't found results for other
> databases...
I don't think it's too "amb
Jonah H. Harris wrote:
Oracle already thought of that a long time ago, which is why the plan
has to come out better for it to take effect.
Huh? We would never willingly choose a worse plan, of course, but the
point is that what looks like a better plan, with a smaller cost
estimate, is someti
Michael Meskes <[EMAIL PROTECTED]> writes:
> Does anyone see a problem with these changes? Or else I will commit.
preproc.y should be removed by make maintainer-clean. For consistency
it probably ought to be listed in the distprep target too, even though
it would be indirectly updated by the prep
Due to some code reshuffling, xmlconcat(NULL) will crash in 8.3 and 8.4.
The pfree(buf.data) in ExecEvalXml() frees a buffer that is actuall
only initialized in the XMLFOREST case. So then the xmlconcat(NULL)
falls through to the pfree() it crashes. I have attached a patch for
8.3 and 8.4 to
On Fri, Nov 14, 2008 at 2:52 AM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
>> Other systems do it. For example, Oracle tracks column usage and
>> attempts to determine the optimal statistics for that column (based on
>> the queries that used it) on an iterative basis. We don't track
>> column
I have experienced some brittleness in the regression test setup that
causes the tests to be run against a different server instance or fail
in confusing ways when you have multiple instances running.
For some historic reasons, I have my local scripts set up so that they
build development inst
"Robert Haas" <[EMAIL PROTECTED]> writes:
> I would feel a lot better about it if we could invent some way of
> distinguishing between different types of "internal", based on what is
> actually being pointed to.
Yeah, we discussed that awhile ago, but nothing's been done about it.
At this point I
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Does that mean that it's possible to use as STYPE pointer to complex
> C-structure
> with internal pointers?
That's exactly what array_agg is doing. You have to be careful about
which context you keep the data in ...
regards,
On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > Your factual comments are accurate, but for Josh's stated target of Data
> > Warehousing, a stats target of 400 is not unreasonable in some cases.
> > What you forget to mention is that sample
On Thu, 2008-11-13 at 10:44 +0900, KaiGai Kohei wrote:
> It's unclear for me what is the point you said.
> I guess you concern the fixed length field is always allocated in
> the case when any security feature is not enabled also, or performance
> degradation on the large scale databases.
> If inc
> You can certainly screw yourself up by connecting some incompatible
> internal-accepting functions together this way. So what I propose is
> that we allow STYPE = internal to be specified in CREATE AGGREGATE,
> but only by superusers, who are trusted not to create security holes
> anyway.
>
> Co
Thank you for a possible solution.
But what about the database which exists and works correctly (and conforms
all the standards from the documentation), but dump+restore sequence is
failed for it? Does it mean that pg_dump should be improved to pass
dump+restore sequence?
Besides that, for pg_dum
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > I'll probably fix both things and submit an updated version tomorrow.
>
> Here it is.
Really attached this time.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
co
Alvaro Herrera wrote:
> I'll probably fix both things and submit an updated version tomorrow.
Here it is. This applies cleanly to current CVS HEAD and passes the
regression tests. Apart from fixing the conflicts, I updated psql's \z
with the new array aggregate, and changed the Schema_pg_* decl
On Fri, Nov 14, 2008 at 09:03:34AM -0300, Alvaro Herrera wrote:
> > +$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y
> > + $(PERL) $(srcdir)/parse.pl $(srcdir) < $< > $@
>
> Why are you passing $(srcdir) as a parameter here? It doesn't look like
> the script uses it at all, or doe
4. what we do now, but document loudly that PGEventProc must be static.
If it can't be referenced outside the DLL directly then the issue can't
arise. If you need the function address for calls to PQinstanceData, an
implementor can create a public function that returns their private
PGEven
Michael Meskes wrote:
> +$(srcdir)/preproc.y: $(top_srcdir)/src/backend/parser/gram.y
> + $(PERL) $(srcdir)/parse.pl $(srcdir) < $< > $@
Why are you passing $(srcdir) as a parameter here? It doesn't look like
the script uses it at all, or does it?
--
Alvaro Herrera
I updated the patch set of SE-PostgreSQL (revision 1216).
There are no new features and bugfixes, but it was rebased to the latest
CVS HEAD, because the previous r1206 got a few conflictions.
These patches are ready for reviewing.
We need your help to make progress them so much!
[1/6]
http://se
internal-accepting functions together this way. So what I propose is
that we allow STYPE = internal to be specified in CREATE AGGREGATE,
but only by superusers, who are trusted not to create security holes
anyway.
Does that mean that it's possible to use as STYPE pointer to complex C-structure
Josh Berkus wrote:
> Greg,
>
> BTW, I think this is still in enough flux that we really ought to make
> it a pgfoundry project. I don't think we'll have anything ready for 8.4
> contrib.
[Been trying to find the right point to post this reply.]
Is it only me that thinks this should be a service
On Tue, Nov 11, 2008 at 9:12 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-11-10 at 18:22 +0900, Fujii Masao wrote:
>
>> Yeah, I also add walsender as new auxiliary process at first. But,
>> during coding,
>> I made out that this is more complicated for code and user.
>>
>> First prob
On Thu, Nov 13, 2008 at 09:03:41PM -0300, Alvaro Herrera wrote:
> The first idea that comes to mind is skipping hint bits in the CRC too.
> That does away with a lot of the trouble (PD_UNLOGGED_CHANGE, the
> necessity of WAL-logging hint bits, etc). The problem, again, is that
> the checksumming p
On Thu, Nov 13, 2008 at 03:10:04PM -0500, Tom Lane wrote:
> VPATH build. (Parts of this patch have that right and part don't.
> You might want to test in a VPATH build before committing.)
Did that and fixed the remaining problems. Attached you'll find the latest
version. I already committed the n
On Fri, Nov 14, 2008 at 9:48 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-11-14 at 08:57 +, Dave Page wrote:
>> On Fri, Nov 14, 2008 at 8:10 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>> >
>> > On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
>> >
>> >> On the other hand w
On Fri, 2008-11-14 at 08:57 +, Dave Page wrote:
> On Fri, Nov 14, 2008 at 8:10 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
> >
> >> On the other hand what does occur to me in retrospect is that I regret
> >> that I didn't think abo
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The next question is whether the "pending rel deletion" stuff in smgr.c should
> be moved to the new file too. It seems like it would belong there better. That
> would leave smgr.c as a very thin wrapper around md.c
Well it's just a switch, albeit
On Fri, Nov 14, 2008 at 8:10 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
>
>> On the other hand what does occur to me in retrospect is that I regret
>> that I didn't think about how I was disparaging the importance of
>> mental illness and
Heikki Linnakangas wrote:
Another thing that does need to be fixed, is the way that the extension
and truncation of the visibility map is handled; that's broken in the
current patch. I started working on the patch a long time ago, before
the FSM rewrite was finished, and haven't gotten around f
On Thu, Nov 13, 2008 at 03:57:49PM -0500, Tom Lane wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
> > That's what I did first, but Magnus had a good reasoning to not keep
> > preproc.y
> > if we keep preproc.c in our tarball. And I agreed that there doesn't seem
> > to be
> > an advantage.
>
On Fri, 2008-11-14 at 02:21 +, Gregory Stark wrote:
> On the other hand what does occur to me in retrospect is that I regret
> that I didn't think about how I was disparaging the importance of
> mental illness and hope nobody took offense for that reason.
Your comments surprise me because yo
85 matches
Mail list logo
