On Sep 1, 2010, at 11:52 AM, Pavel Stehule wrote:
>> regression=# create or replace function array_agg_transfn_strict(internal,
>> anyelement) returns internal as 'array_agg_transfn' language internal
>> immutable;
>> CREATE FUNCTION
>> regression=# create aggregate array_agg_strict(anyelement)
On Fri, Oct 1, 2010 at 4:33 AM, Leonardo Francalanci wrote:
>> I ran a few more performance tests on this patch. Here's what I got
>> for the tests Leonardo posted originally:
>> * 2M rows: 22 seconds for seq. scan, 24 seconds for index scan
>> * 5M rows: 139 seconds for seq. scan, 97 s
On Fri, Oct 1, 2010 at 4:00 PM, Josh Berkus wrote:
>
> Our current arrangement of having a postgresql.conf file, a
> recovery.conf file, and potentially a trigger file (during final
> recovery) seems horribly hackish and impossible to manage neatly.
>
all the contrary, IMHO what we have now seems
On Fri, Oct 1, 2010 at 7:15 AM, Kevin Grittner
wrote:
> An interesting exercise it so think about what
> real-life lines you could have which would have multiple occurrences
> in this pattern, and think about whether you would then prefer the
> --patience output, especially if this were part of a
Josh Berkus writes:
> Then instead of having a trigger file, the admin could just update the
> status file in recovery.conf and save it (or overwrite the file).
This doesn't seem like a terribly bright idea. We've expended megabytes
of list traffic on arguing about automatic updates of config fi
On 10/1/10 4:05 AM, Robert Haas wrote:
>>> And
>>> >> have PG poll that text file periodically so that you could update it and
>>> >> it would fail over?
>> >
>> > Hmm.. instead of that text file (i.e., recovery.conf), trigger file is
>> > periodically polled by the standby server.
>
> I'm not s
On Fri, Oct 1, 2010 at 2:34 PM, Pavel Stehule wrote:
> Hello
>
> 2010/10/1 Robert Haas :
>> On Mon, Sep 27, 2010 at 11:30 PM, Robert Haas wrote:
>>> On Tue, Sep 7, 2010 at 1:30 PM, Tom Lane wrote:
In the particular case here, the dictionary structures could probably
safely use such a c
Marios Vodas writes:
> This is how timestamp_in starts, *#ifdef NOT_USED* is a litle bit confusing.
> Datum timestamp_in(PG_FUNCTION_ARGS)
> {
> char *str = PG_GETARG_CSTRING(0);
> #ifdef NOT_USED
> Oidtypelem = PG_GETARG_OID(1);
> #endif
> int32typmod = PG_G
Hello
updated version
* memsort removed
* window aggregate support blocked
Regards
Pavel
2010/10/1 Pavel Stehule :
> 2010/10/1 Hitoshi Harada :
>> 2010/10/2 Tom Lane :
>>> Hitoshi Harada writes:
2010/10/2 Tom Lane :
> The implementation I would've expected to see is to do the sort
Andrew Dunstan writes:
> On 10/01/2010 01:23 PM, Andres Freund wrote:
>> If you want that as a default behaviour:
>> "For example, to default to pushing only the current branch to origin use git
>> config remote.origin.push HEAD. Any valid (like the ones in the
>> examples below) can be configure
On 10/01/2010 01:08 PM, I wrote:
"git push origin HEAD" pushes the current branch, whatever it might
be. That might be a useful alias for you to set up.
Oh, and you can change the default by setting push.default to 'current'
instead of 'matching', which is the default default ;-) "man g
On Fri, 2010-10-01 at 18:52 +0900, Hitoshi Harada wrote:
> While tackling the top-level CTEs patch, I found that INSERT ...
> VALUES isn't aware of ORDER BY / LIMIT.
>
> regression=# CREATE TABLE t1(x int);
> CREATE TABLE
> regression=# INSERT INTO t1 VALUES (1),(2),(3) LIMIT 1;
> INSERT 0 3
That
Hello
2010/10/1 Robert Haas :
> On Mon, Sep 27, 2010 at 11:30 PM, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 1:30 PM, Tom Lane wrote:
>>> In the particular case here, the dictionary structures could probably
>>> safely use such a context type, but I'm not sure it's worth bothering
>>> if the l
On 10/01/2010 01:23 PM, Andres Freund wrote:
If you want that as a default behaviour:
"For example, to default to pushing only the current branch to origin use git
config remote.origin.push HEAD. Any valid (like the ones in the
examples below) can be configured as the default for git push ori
On Mon, Sep 27, 2010 at 11:30 PM, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 1:30 PM, Tom Lane wrote:
>> In the particular case here, the dictionary structures could probably
>> safely use such a context type, but I'm not sure it's worth bothering
>> if the long-term plan is to implement a preco
On fre, 2010-10-01 at 16:26 +0200, Magnus Hagander wrote:
> Personally, I don't see any advantage at all of git.postgresql.org
> over github for a development repository. Others may have different
> opinions, of course.
My personal objection is merely that it was apparently semi-unilaterally
decid
On Thu, Sep 30, 2010 at 6:51 PM, Itagaki Takahiro
wrote:
> How much overhead do you have with "resource" option?
> getrusage() calls for each tuple might have considerable overheads.
> How much difference between (analyze) and (analyze, resource) options?
Here's strace -c for a select count(*) fr
On Fri, Oct 1, 2010 at 11:53 AM, Tom Lane wrote:
> BTW, I've noticed that "git push" will reject an attempt to push an
> update in one branch if my other branches are not up to date, even
> if I am not trying to push anything for those branches. That's
> pretty annoying too; is there a way around
On Fri, Oct 1, 2010 at 10:59 AM, Magnus Hagander wrote:
> On Fri, Oct 1, 2010 at 16:40, Robert Haas wrote:
>> On Fri, Oct 1, 2010 at 10:37 AM, Magnus Hagander wrote:
>>> On Fri, Oct 1, 2010 at 16:36, Robert Haas wrote:
On Fri, Oct 1, 2010 at 4:07 AM, Magnus Hagander
wrote:
> On
Would this be correct?
DatumGetTimestamp(DirectFunctionCall3(timestamp_in, CStringGetDatum(time),
PointerGetDatum(0), Int32GetDatum(MAX_TIMESTAMP_PRECISION)));
This is how timestamp_in starts, *#ifdef NOT_USED* is a litle bit confusing.
Datum timestamp_in(PG_FUNCTION_ARGS)
{
char *str =
2010/10/1 Hitoshi Harada :
> 2010/10/2 Tom Lane :
>> Hitoshi Harada writes:
>>> 2010/10/2 Tom Lane :
The implementation I would've expected to see is to do the sort and then
have two code paths for retrieving the median, depending on whether the
sort result is all in memory or not.
On Friday 01 October 2010 18:48:25 Heikki Linnakangas wrote:
> On 01.10.2010 18:53, Tom Lane wrote:
> > BTW, I've noticed that "git push" will reject an attempt to push an
> > update in one branch if my other branches are not up to date, even
> > if I am not trying to push anything for those branch
On 10/01/2010 01:08 PM, I wrote:
"git push origin HEAD" pushes the current branch, whatever it might
be. That might be a useful alias for you to set up.
Oh, and you can change the default by setting push.default to 'current'
instead of 'matching', which is the default default ;-) "man git-
On 10/01/2010 12:49 PM, Tom Lane wrote:
Magnus Hagander writes:
On Fri, Oct 1, 2010 at 17:53, Tom Lane wrote:
BTW, I've noticed that "git push" will reject an attempt to push an
update in one branch if my other branches are not up to date, even
if I am not trying to push anything for those
Magnus Hagander writes:
> On Fri, Oct 1, 2010 at 17:53, Tom Lane wrote:
>> BTW, I've noticed that "git push" will reject an attempt to push an
>> update in one branch if my other branches are not up to date, even
>> if I am not trying to push anything for those branches. That's
>> pretty annoyin
On 01.10.2010 18:53, Tom Lane wrote:
BTW, I've noticed that "git push" will reject an attempt to push an
update in one branch if my other branches are not up to date, even
if I am not trying to push anything for those branches. That's
pretty annoying too; is there a way around that?
Yeah, that
On Fri, Oct 1, 2010 at 17:53, Tom Lane wrote:
> Aidan Van Dyk writes:
>> On Fri, Oct 1, 2010 at 11:27 AM, Tom Lane wrote:
>>> man git-pull sayeth
>>>
>>> In its default mode, git pull is shorthand for git fetch followed by
>>> git merge FETCH_HEAD.
>>>
>>> However, I just tried that and
On Fri, Oct 1, 2010 at 11:53 AM, Tom Lane wrote:
> Yeah, I don't want a merge. I have these config entries (as per our
> wiki recommendations):
>
> [branch "master"]
> rebase = true
> [branch]
> autosetuprebase = always
>
> and what I really want is to update all my workdirs the sa
Aidan Van Dyk writes:
> On Fri, Oct 1, 2010 at 11:27 AM, Tom Lane wrote:
>> man git-pull sayeth
>>
>> In its default mode, git pull is shorthand for git fetch followed by
>> git merge FETCH_HEAD.
>>
>> However, I just tried that and it failed rather spectacularly. How do
>> you *really
On Fri, Oct 1, 2010 at 11:27 AM, Tom Lane wrote:
> man git-pull sayeth
>
> In its default mode, git pull is shorthand for git fetch followed by
> git merge FETCH_HEAD.
>
> However, I just tried that and it failed rather spectacularly. How do
> you *really* update your local repo without a
On Fri, Oct 01, 2010 at 10:54:47AM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Thu, Sep 30, 2010 at 10:29:56PM -0400, Robert Haas wrote:
> >> Yeah, that might be better. Is it reasonable to assume we always
> >> want to push down as much as possible, or do we need to think about
> >> loc
2010/10/2 Kevin Grittner :
> Tom Lane wrote:
>> Hitoshi Harada writes:
>>> Another suggestion?
>>
>> The implementation I would've expected to see is to do the sort
>> and then have two code paths for retrieving the median, depending
>> on whether the sort result is all in memory or not.
>
> Woul
2010/10/2 Tom Lane :
> Hitoshi Harada writes:
>> 2010/10/2 Tom Lane :
>>> The implementation I would've expected to see is to do the sort and then
>>> have two code paths for retrieving the median, depending on whether the
>>> sort result is all in memory or not.
>
>> Hm? The problem we encountere
man git-pull sayeth
In its default mode, git pull is shorthand for git fetch followed by
git merge FETCH_HEAD.
However, I just tried that and it failed rather spectacularly. How do
you *really* update your local repo without an extra git fetch step?
Poking around, it looks like each w
On 1 October 2010 15:41, Robert Haas wrote:
> On Fri, Oct 1, 2010 at 8:40 AM, Simon Riggs wrote:
>> On Fri, 2010-10-01 at 18:47 +0900, Fujii Masao wrote:
>>> On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
>>> > On 9/29/10 7:54 PM, Tom Lane wrote:
>>> >> Robert Haas writes:
>>> >>> But that'
Hitoshi Harada writes:
> 2010/10/2 Tom Lane :
>> The implementation I would've expected to see is to do the sort and then
>> have two code paths for retrieving the median, depending on whether the
>> sort result is all in memory or not.
> Hm? The problem we encountered in the middle of the patch
2010/10/2 Tom Lane :
> Hitoshi Harada writes:
>> Another suggestion?
>
> The implementation I would've expected to see is to do the sort and then
> have two code paths for retrieving the median, depending on whether the
> sort result is all in memory or not.
>
Hm? The problem we encountered in th
Tom Lane wrote:
> Hitoshi Harada writes:
>> Another suggestion?
>
> The implementation I would've expected to see is to do the sort
> and then have two code paths for retrieving the median, depending
> on whether the sort result is all in memory or not.
Would it make sense to accumulate value/
Hitoshi Harada writes:
> Another suggestion?
The implementation I would've expected to see is to do the sort and then
have two code paths for retrieving the median, depending on whether the
sort result is all in memory or not.
regards, tom lane
--
Sent via pgsql-hackers
Fujii Masao writes:
> I proposed to implement the "return-immediately" at first because it doesn't
> require standby registration. But if many people think that the "wait-forever"
> is the core rather than the "return-immediately", I'll follow them. We can
> implement the "return-immediately" afte
2010/10/1 Tom Lane :
> Hitoshi Harada writes:
>> 2010/10/1 Tom Lane :
>>> If this patch tries to force the entire sort to happen in memory,
>>> it is not committable.
>
>> What about array_agg()? Doesn't it exceed memory even if the huge data come
>> in?
>
> Yeah, but for array_agg the user shoul
On Fri, Oct 1, 2010 at 16:40, Robert Haas wrote:
> On Fri, Oct 1, 2010 at 10:37 AM, Magnus Hagander wrote:
>> On Fri, Oct 1, 2010 at 16:36, Robert Haas wrote:
>>> On Fri, Oct 1, 2010 at 4:07 AM, Magnus Hagander wrote:
On Thu, Sep 30, 2010 at 23:45, Robert Haas wrote:
> On Thu, Sep 30,
David Fetter writes:
> On Thu, Sep 30, 2010 at 10:29:56PM -0400, Robert Haas wrote:
>> Yeah, that might be better. Is it reasonable to assume we always
>> want to push down as much as possible, or do we need to think about
>> local work vs. remote work trade-offs?
> In cases where the foreign si
On Fri, Oct 1, 2010 at 4:33 AM, Leonardo Francalanci wrote:
> I guess that if the planner makes a wrong choice in this case (that is,
> seq scan + sort instead of index scan) there's no way for "cluster" to
> behave in a different way. If, on the contrary, the "create table..." uses
> the right pl
On Fri, Oct 1, 2010 at 10:11 AM, Hitoshi Harada wrote:
> 2010/10/1 Tom Lane :
>> Hitoshi Harada writes:
>>> 2010/9/26 Pavel Stehule :
This patch needs a few work - can share a compare functionality with
tuplesort.c, but I would to verify a concept now.
>>
>>> Sorry for delay. I read the
Hitoshi Harada writes:
> 2010/10/1 Tom Lane :
>> If this patch tries to force the entire sort to happen in memory,
>> it is not committable.
> What about array_agg()? Doesn't it exceed memory even if the huge data come
> in?
Yeah, but for array_agg the user should be expecting a result of
appro
On Fri, Oct 1, 2010 at 8:40 AM, Simon Riggs wrote:
> On Fri, 2010-10-01 at 18:47 +0900, Fujii Masao wrote:
>> On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
>> > On 9/29/10 7:54 PM, Tom Lane wrote:
>> >> Robert Haas writes:
>> >>> But that's not what Tom is talking about, I don't think: you
On Fri, Oct 1, 2010 at 10:37 AM, Magnus Hagander wrote:
> On Fri, Oct 1, 2010 at 16:36, Robert Haas wrote:
>> On Fri, Oct 1, 2010 at 4:07 AM, Magnus Hagander wrote:
>>> On Thu, Sep 30, 2010 at 23:45, Robert Haas wrote:
On Thu, Sep 30, 2010 at 5:38 PM, Gurjeet Singh
wrote:
> Can
On Fri, Oct 1, 2010 at 16:36, Robert Haas wrote:
> On Fri, Oct 1, 2010 at 4:07 AM, Magnus Hagander wrote:
>> On Thu, Sep 30, 2010 at 23:45, Robert Haas wrote:
>>> On Thu, Sep 30, 2010 at 5:38 PM, Gurjeet Singh
>>> wrote:
Can we please change the comment lines below the patch heading to ha
On Fri, Oct 1, 2010 at 4:07 AM, Magnus Hagander wrote:
> On Thu, Sep 30, 2010 at 23:45, Robert Haas wrote:
>> On Thu, Sep 30, 2010 at 5:38 PM, Gurjeet Singh
>> wrote:
>>> Can we please change the comment lines below the patch heading to have the
>>> real name instead of the postgresql.org ID?
>
On Thu, Sep 30, 2010 at 10:29:56PM -0400, Robert Haas wrote:
> On Sep 29, 2010, at 10:09 AM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of mar sep 28 10:26:54 -0400 2010:
> >
> >> Then:
> >>
> >> - Begin a sequential scan with the following set of quals.
> >> - Begin an ind
On Fri, Oct 1, 2010 at 16:09, Gurjeet Singh wrote:
> On Fri, Oct 1, 2010 at 10:00 AM, Magnus Hagander
> wrote:
>>
>> On Fri, Oct 1, 2010 at 15:50, Gurjeet Singh
>> wrote:
>> > I hope this is the right forum to talk about git.postgresql.org
>> >
>> > My community login is singh.gurjeet, but our s
On Fri, Oct 1, 2010 at 10:00 AM, Magnus Hagander wrote:
> On Fri, Oct 1, 2010 at 15:50, Gurjeet Singh
> wrote:
> > I hope this is the right forum to talk about git.postgresql.org
> >
> > My community login is singh.gurjeet, but our setup seems to not like the
> > special character there; users/si
On Fri, Oct 01, 2010 at 07:48:25PM +0900, Fujii Masao wrote:
> I proposed to implement the "return-immediately" at first because it
> doesn't require standby registration. But if many people think that
> the "wait-forever" is the core rather than the "return-immediately",
> I'll follow them. We ca
Gurjeet Singh wrote:
> Alvaro Herrera wrote:
>> There is a very simple example posted on some of the blog posts
>> that goes something like
>>
>>
>>
>>
>>
>>
>>
>> xyz
>>
>> and the "xyz" is moved to the front. In this corner case, the
>> pa
2010/10/1 Tom Lane :
> Hitoshi Harada writes:
>> 2010/9/26 Pavel Stehule :
>>> This patch needs a few work - can share a compare functionality with
>>> tuplesort.c, but I would to verify a concept now.
>
>> Sorry for delay. I read the patch and it seems the result is sane. For
>> window function c
On Fri, Oct 1, 2010 at 15:50, Gurjeet Singh wrote:
> I hope this is the right forum to talk about git.postgresql.org
>
> My community login is singh.gurjeet, but our setup seems to not like the
> special character there; users/singh.gurjeet/postgres is rejected.
>
> Would it be a problem if I requ
I hope this is the right forum to talk about git.postgresql.org
My community login is singh.gurjeet, but our setup seems to not like the
special character there; users/singh.gurjeet/postgres is rejected.
Would it be a problem if I requested users/gsingh/postgres ? I hope that
doesn't cause any tr
On Fri, Oct 1, 2010 at 9:38 AM, Alvaro Herrera
wrote:
> Excerpts from Kevin Grittner's message of jue sep 30 16:38:11 -0400 2010:
>
> > When I read the description of the algorithm, I can't imagine a
> > situation where --patience would make the diff *worse*. I was
> > somewhat afraid (based on t
Excerpts from Kevin Grittner's message of jue sep 30 16:38:11 -0400 2010:
> When I read the description of the algorithm, I can't imagine a
> situation where --patience would make the diff *worse*. I was
> somewhat afraid (based on the name) that it would be slow; but
> if it is slower, it hasn't
2010/10/1 Tom Lane :
> Hitoshi Harada writes:
>> 2010/9/26 Pavel Stehule :
>>> This patch needs a few work - can share a compare functionality with
>>> tuplesort.c, but I would to verify a concept now.
>
>> Sorry for delay. I read the patch and it seems the result is sane. For
>> window function c
Hitoshi Harada writes:
> 2010/9/26 Pavel Stehule :
>> This patch needs a few work - can share a compare functionality with
>> tuplesort.c, but I would to verify a concept now.
> Sorry for delay. I read the patch and it seems the result is sane. For
> window function calls, I agree that the curren
On Fri, 2010-10-01 at 18:47 +0900, Fujii Masao wrote:
> On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
> > On 9/29/10 7:54 PM, Tom Lane wrote:
> >> Robert Haas writes:
> >>> But that's not what Tom is talking about, I don't think: you might
> >>> also want a way to explicitly whack the flag i
On 10/01/2010 04:35 AM, Dean Rasheed wrote:
2). In enum_ccmp(), when you cache the full list of elements, you're
not updating mycache->sort_list_length, so it will keep fetching the
full list each time. Also, I think that function could use a few more
comments.
Good catch. Will fix.
3). I t
On Oct 1, 2010, at 5:47 AM, Fujii Masao wrote:
> On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
>> On 9/29/10 7:54 PM, Tom Lane wrote:
>>> Robert Haas writes:
But that's not what Tom is talking about, I don't think: you might
also want a way to explicitly whack the flag in pg_contr
On Fri, Oct 1, 2010 at 11:13, Fujii Masao wrote:
> On Wed, Sep 29, 2010 at 5:47 PM, Magnus Hagander wrote:
>> It's actually intentional. If we create a file at first, there is no
>> way to figure out exactly how far through a partial segment we are
>> without parsing the details of the log. This
On Thu, Sep 30, 2010 at 11:32 PM, Heikki Linnakangas
wrote:
> The standby can already use restore_command to fetch WAL files from the
> archive. I don't see why the master should be involved in that.
To make the standby use restore_command to do that, you have to specify
something like scp in arc
On Thu, Sep 30, 2010 at 3:09 PM, Heikki Linnakangas
wrote:
>>> * Support multiple standbys with various synchronization levels.
>>
>> Not required for that case.
>
> IMHO at least we'll still need to support asynchronous standbys in the same
> mix, that's an existing feature.
My intention is to c
While tackling the top-level CTEs patch, I found that INSERT ...
VALUES isn't aware of ORDER BY / LIMIT.
regression=# CREATE TABLE t1(x int);
CREATE TABLE
regression=# INSERT INTO t1 VALUES (1),(2),(3) LIMIT 1;
INSERT 0 3
regression=# TABLE t1;
x
---
1
2
3
(3 rows)
regression=# TRUNCATE t1;
T
On Fri, Oct 1, 2010 at 9:21 AM, Josh Berkus wrote:
> On 9/29/10 7:54 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> But that's not what Tom is talking about, I don't think: you might
>>> also want a way to explicitly whack the flag in pg_control around.
>>> That would probably be along the lines
On Wed, Sep 29, 2010 at 5:47 PM, Magnus Hagander wrote:
> It's actually intentional. If we create a file at first, there is no
> way to figure out exactly how far through a partial segment we are
> without parsing the details of the log. This is useful both for the
> admin (who can look at the dir
Hello
2010/10/1 Hitoshi Harada :
> 2010/9/26 Pavel Stehule :
>> Hello,
>>
>> there is updated version - with support of window clause. The limits
>> are work_mem for using inside window aggregate or unlimited when it is
>> used as standard query.
>>
>> This patch needs a few work - can share a com
On 29 September 2010 20:46, Andrew Dunstan wrote:
>
> Attached is a a slightly updated version of this with the bitrot fixed.
>
> cheers
>
> andrew
>
Hi,
I had a quick look at this last night. I haven't had time to give it a
full review, but I did spot a couple of things:
1). It still has no do
> I ran a few more performance tests on this patch. Here's what I got
> for the tests Leonardo posted originally:
>* 2M rows: 22 seconds for seq. scan, 24 seconds for index scan
>* 5M rows: 139 seconds for seq. scan, 97 seconds for index scan
>* 10M rows: 256 seconds seq. scan, 61
2010/9/26 Pavel Stehule :
> Hello,
>
> there is updated version - with support of window clause. The limits
> are work_mem for using inside window aggregate or unlimited when it is
> used as standard query.
>
> This patch needs a few work - can share a compare functionality with
> tuplesort.c, but
On Thu, Sep 30, 2010 at 17:25, Kevin Grittner
wrote:
> Aidan Van Dyk wrote:
>
>> When the "being written to" segmnt copmletes moves to the final
>> location, he'll get an extra whole "copy" of the file. But of the
>> "move" can be an exec of his scritpt, the compressed/gzipped final
>> result sh
On Thu, Sep 30, 2010 at 23:45, Robert Haas wrote:
> On Thu, Sep 30, 2010 at 5:38 PM, Gurjeet Singh
> wrote:
>> Can we please change the comment lines below the patch heading to have the
>> real name instead of the postgresql.org ID?
>>
>> Patch by Pavel Stehule
>> Patch by Gurjeet Singh
>>
>> in
On tor, 2010-09-30 at 15:07 -0700, Greg Stark wrote:
> > It's too bad there is no cross-platform way to ask what level of
> hardware-syncing is available.
>
> Why would the user want to ask this? As far as the user is concerned
> either there are only two "levels": synced or not synced. If it's no
78 matches
Mail list logo
