On Mon, Jan 5, 2015 at 11:55 PM, Robert Haas wrote:
> On Fri, Jan 2, 2015 at 3:45 PM, Tom Lane wrote:
> > In short, you can't force 2PC technology on people who aren't using it
> > already; while for those who are using it already, this isn't nearly
> > good enough as-is.
>
> I was involved in s
Peter Eisentraut writes:
> committed version 7
Isn't that a back-patchable bug fix?
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-hackers
On 07 January 2015 11:21, Amit Kapila Wrote,
>Tom has spotted this problem and suggested 3 different options
>to handle this issue, apart from above 2, third one is "Go over to
>a byte-count-then-value format". Then Andrew and Heikki
>supported/asked to follow option 2 (as is followed in patch) a
On Wed, Jan 7, 2015 at 10:45 AM, Dilip kumar wrote:
>
> On 20 December 2014 16:30, Amit Kapila Wrote,
> >Summarization of latest changes:
>
> >1. Change file name from symlink_label to tablespace_map and changed
>
> >the same every where in comments and variable names.
>
> >2. This feature will be
On 20 December 2014 16:30, Amit Kapila Wrote,
>Summarization of latest changes:
>1. Change file name from symlink_label to tablespace_map and changed
>the same every where in comments and variable names.
>2. This feature will be supportted for both windows and linux; tablespace_map
>file will be
On Tue, Jan 6, 2015 at 12:12 AM, Atri Sharma wrote:
> I will add the patch to current commitfest.
It has been indeed added to the commit fest 2014-12. That's a bit
late, moving it to upcoming one 2015-02.
Thanks,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
committed version 7
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Not in all cases
postgres=# create function non_im_immutable_function() returns float as $$
begin
return *random()*;
end;
$$ language plpgsql *immutable*;
CREATE FUNCTION
postgres=# select proname, provolatile from pg_proc where proname =
'random' or proname = 'non_im_immutable_function';
On Wed, Jan 7, 2015 at 12:51 AM, Rahila Syed wrote:
> Following are some comments,
Thanks for the feedback.
>>uint16 hole_offset:15, /* number of bytes in "hole" */
> Typo in description of hole_offset
Fixed. That's "before hole".
>>for (block_id = 0; block_id <= record->max_block_id; b
On Wed, Jan 7, 2015 at 3:03 AM, Peter Eisentraut wrote:
>
> On 12/27/14 8:02 PM, Robert Haas wrote:
> > On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut
wrote:
> >> On 12/22/14 10:00 PM, Amit Kapila wrote:
> >>> There is already a patch [1] in this CF which will handle both cases,
so
> >>> I am
On 07-01-2015 AM 08:33, Jim Nasby wrote:
> On 1/6/15, 1:00 AM, Ashutosh Bapat wrote:
>>
>> Even checking whether the output of the function is in the right order
>> or not, has its cost. I am suggesting that we can eliminate this cost
>> as well. For example, PostgreSQL does not check whether a fun
On 1/6/15, 10:33 AM, Robert Haas wrote:
>Entrypints?
Already noted by Andres; fixed in the attached version.
Perhaps we only parallelize while drinking beer... ;)
CreateParallelContext(): Does it actually make sense to have nworkers=0? ISTM
that's a bogus case. Also, since the number of work
Stefan Kaltenbrunner wrote:
> On 01/06/2015 10:12 PM, Alvaro Herrera wrote:
> > This makes me wonder however how wise it is to update the copyright
> > notices in every single file in the repo. Why do we need this? Why not
> > abolish the practice and live forever with most files having copyrigh
On 01/06/2015 05:17 PM, Andres Freund wrote:
> A real solution to this requires more. You need to 1) disable writing
> any wal 2) force catchup of all possible standbys, including apply. Most
> importantly of the new master. This requires knowing which standbys
> exist. 3) promote new master. 4) on
On 07-01-2015 AM 04:25, Stephen Frost wrote:
> Robert, Amit,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
>> I don't think that's a typo, although it's not particularly
>> well-worded IMHO. I might rewrite the whole paragraph like this:
>>
>> A policy limits the ability to SELECT, INSERT, UPD
On 2015-01-06 17:08:20 -0800, Josh Berkus wrote:
> On 01/06/2015 04:42 PM, Andres Freund wrote:
> > On 2015-01-06 16:33:36 -0800, Josh Berkus wrote:
> >> F. Inability to remaster without restarting the replica.
> >
> > That has pretty much nothing to do with the topic at hand.
>
> It has *everyth
On 2015-01-05 20:43:12 -0500, Peter Eisentraut wrote:
> For example, putting recovery target parameters into postgresql.conf
> might not make sense to some people. Once you have reached the recovery
> end point, the information is obsolete. Keeping it set could be
> considered confusing.
I don't
On 01/06/2015 04:42 PM, Andres Freund wrote:
> On 2015-01-06 16:33:36 -0800, Josh Berkus wrote:
>> F. Inability to remaster without restarting the replica.
>
> That has pretty much nothing to do with the topic at hand.
It has *everything* to do with the topic at hand. The *only* reason we
can't
On 2015-01-06 16:33:36 -0800, Josh Berkus wrote:
> F. Inability to remaster without restarting the replica.
That has pretty much nothing to do with the topic at hand.
> I. Fairly duplicative options between pg.conf and recovery.conf (i.e.
> "standby_mode" vs. "hot_standby")
Those aren't the same
Peter, all:
Let me go over the issues I find with recovery.conf, based on 3 aspects
of my experience (1) doing DBA support (2) as a tool author (HandyRep)
and (3) as a trainer, teaching new users about it. If we agree on a
list of problems with the current setup (as well as a list of benefits)
th
On Tue, Jan 6, 2015 at 4:15 PM, Jim Nasby wrote:
> On 1/6/15, 10:32 AM, Alvaro Herrera wrote:
>
>> Tom Lane wrote:
>>
>> What would make sense to me is to teach the planner about inlining
>>> SQL functions that include ORDER BY clauses, so that the performance
>>> issue of a double sort could be
On 2015-01-06 15:39:29 -0500, Peter Eisentraut wrote:
> I applaud the ingenuity on all levels in this patch. But it seems to me
> that there is way too much backend knowledge encoded and/or duplicated
> in a front-end program.
Hm. There's really not that much in the current version anymore? Sure,
Jim Nasby writes:
> On 1/6/15, 3:30 PM, Stefan Kaltenbrunner wrote:
>> I dont know why it is really needed but maybe for the files that have
>> identical copyrights one could simple reference to the COPYRIGHT file we
>> already have in the tree?
> +1
Unless either of you is a copyright lawyer, y
On Wed, Jan 7, 2015 at 4:24 AM, Petr Jelinek wrote:
> Hi,
>
> when I was fixing how commit_ts handles the XLOG_PARAMETER_CHANGE I noticed
> that for wal_log_hints we assign the value in ControFile to current value
> instead of value that comes from WAL.
>
> ISTM it has just information value so it
On Wed, Jan 7, 2015 at 8:48 AM, Jim Nasby wrote:
> On 1/6/15, 3:30 PM, Stefan Kaltenbrunner wrote:
>>
>> I dont know why it is really needed but maybe for the files that have
>> identical copyrights one could simple reference to the COPYRIGHT file we
>> already have in the tree?
>
>
> +1
>
> Also,
On 01/06/2015 03:39 PM, Peter Eisentraut wrote:
I applaud the ingenuity on all levels in this patch. But it seems to me
that there is way too much backend knowledge encoded and/or duplicated
in a front-end program.
If this ends up shipping, it's going to be a massively popular tool. I
see it
On 1/6/15, 3:30 PM, Stefan Kaltenbrunner wrote:
I dont know why it is really needed but maybe for the files that have
identical copyrights one could simple reference to the COPYRIGHT file we
already have in the tree?
+1
Also, now that we're on git it wouldn't be that hard to add commit hooks t
On Wed, Jan 7, 2015 at 5:39 AM, Peter Eisentraut wrote:
> Also, since you have been maintaining this tool for a while, what is the
> effort for maintaining it from version to version?
>From my own experience, the main source of maintenance across major
versions is the modification of the WAL recor
> > scan_relid != InvalidOid
> >
>
> Ideally, they should be OidIsValid(scan_relid)
>
Scan.scanrelid is an index of range-tables list, not an object-id.
So, InvalidOid or OidIsValid() are not a good choice.
The bare relation oid has to be saved on relid of RangeTblEntry
which can be pulled using
On 1/6/15, 1:00 AM, Ashutosh Bapat wrote:
Even checking whether the output of the function is in the right order or not,
has its cost. I am suggesting that we can eliminate this cost as well. For
example, PostgreSQL does not check whether a function is really immutable or
not.
Actually, it
On 07/01/15 00:05, Jim Nasby wrote:
On 1/6/15, 8:17 AM, Kouhei Kaigai wrote:
The attached patch is newer revision of custom-/foreign-join
interface.
Shouldn't instances of
scan_relid > 0
be
scan_relid != InvalidOid
Ideally, they should be OidIsValid(scan_relid)
--
Petr Jelinek
I also don't see this behavior documented (this is from process_policies()):
/*
* If we end up with only USING quals, then use those as
* WITH CHECK quals also.
*/
if (with_check_quals == NIL)
with_check_quals = copyObject(quals);
Now, I do see a reference to it under "Per-Command policies -
On 12/21/2014 02:50 PM, Andrew Dunstan wrote:
On 12/21/2014 02:12 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 12/21/2014 01:23 PM, Alvaro Herrera wrote:
The point, I think, is that without atomic instructions you have to
hold
a lock while incrementing the counters.
Hmm, do we do that no
On 1/6/15, 10:32 AM, Alvaro Herrera wrote:
Tom Lane wrote:
What would make sense to me is to teach the planner about inlining
SQL functions that include ORDER BY clauses, so that the performance
issue of a double sort could be avoided entirely transparently to
the user.
Wouldn't this be appli
On 1/5/15, 3:14 PM, Tom Lane wrote:
Jim Nasby writes:
Related... I'd like to see a way to inline a function that does something like:
CREATE FUNCTION foo(text) RETURNS int LANGUAGE sql AS $$
SELECT a FROM b WHERE lower(b.c) = lower($1)
$$
The reason that's not inlined ATM is that the seman
On 1/6/15, 8:17 AM, Kouhei Kaigai wrote:
The attached patch is newer revision of custom-/foreign-join
interface.
Shouldn't instances of
scan_relid > 0
be
scan_relid != InvalidOid
?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
On 01/06/2015 01:22 PM, Peter Eisentraut wrote:
> That said, there is a much simpler way to achieve that specific
> functionality: Expose all the recovery settings as fake read-only GUC
> variables. See attached patch for an example.
I have no objections to that idea in principle. As long as it
On 6 January 2015 at 21:01, Robert Haas wrote:
> On Tue, Jan 6, 2015 at 3:04 PM, Simon Riggs wrote:
>> If you can explain it in more detail in comments and README, I may
>> agree. At present, I don't get it and it makes me nervous.
>>
>> The comment says
>> "Only the top frame of the transaction
On 12/27/14 8:02 PM, Robert Haas wrote:
> On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut wrote:
>> On 12/22/14 10:00 PM, Amit Kapila wrote:
>>> There is already a patch [1] in this CF which will handle both cases, so
>>> I am
>>> not sure if it is very good idea to go with a new tar format to h
On 01/06/2015 10:12 PM, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>> On Tue, Jan 6, 2015 at 08:46:19PM +0100, Stefan Kaltenbrunner wrote:
I will run the script today. I didn't do it earlier because I want to
be current on reading community email before doing it.
>>>
>>> hmm is it int
On 1/6/15 12:57 AM, Josh Berkus wrote:
> On 01/05/2015 05:43 PM, Peter Eisentraut wrote:
>> The wins on the other hand are obscure: You can now use SHOW to inspect
>> recovery settings. You can design your own configuration file include
>> structures to set them. These are not bad, but is that al
On Tue, Jan 6, 2015 at 06:12:30PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Tue, Jan 6, 2015 at 08:46:19PM +0100, Stefan Kaltenbrunner wrote:
> > > > I will run the script today. I didn't do it earlier because I want to
> > > > be current on reading community email before doing
Oleg, Teodor:
I take it VODKA is sliding to version 9.6?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian wrote:
> On Tue, Jan 6, 2015 at 08:46:19PM +0100, Stefan Kaltenbrunner wrote:
> > > I will run the script today. I didn't do it earlier because I want to
> > > be current on reading community email before doing it.
> >
> > hmm is it intentional that the commit also changed other fi
On Tue, Jan 6, 2015 at 1:03 PM, Robert Haas wrote:
> I thought my rewrite clarified this distinction pretty well. Maybe
> I'm wrong? We're talking about the same paragraph.
Sorry, I didn't express myself clearly. I think that you did get it
right, but I would like to see that distinction also
On Tue, Jan 6, 2015 at 2:48 PM, Peter Geoghegan wrote:
> On Tue, Jan 6, 2015 at 11:25 AM, Stephen Frost wrote:
>> Looks reasonable to me. Amit, does this read better for you? If so, I
>> can handle making the change to the docs.
>
> The docs also prominently say:
>
> "The security-barrier quali
On Tue, Jan 6, 2015 at 3:04 PM, Simon Riggs wrote:
> If you can explain it in more detail in comments and README, I may
> agree. At present, I don't get it and it makes me nervous.
>
> The comment says
> "Only the top frame of the transaction state stack is copied to a parallel
> worker"
> but I'm
On Tue, Jan 6, 2015 at 08:46:19PM +0100, Stefan Kaltenbrunner wrote:
> > I will run the script today. I didn't do it earlier because I want to
> > be current on reading community email before doing it.
>
> hmm is it intentional that the commit also changed other files?
>
> looks like the commit
Another issue that I see is that there is only one resultRelation
between the INSERT and UPDATE. That means that without some additional
special measure, both UPDATE and INSERT "WITH CHECK ( ... ) " options
are applied regardless of whether the INSERT path was taken, or the
UPDATE path. Maybe that'
I applaud the ingenuity on all levels in this patch. But it seems to me
that there is way too much backend knowledge encoded and/or duplicated
in a front-end program.
If this ends up shipping, it's going to be a massively popular tool. I
see it as a companion to pg_basebackup. So it should sort
On 6 January 2015 at 16:33, Robert Haas wrote:
>> These comments don’t have any explanation or justification
>
> OK, I rewrote them. Hopefully it's better now.
Thanks for new version and answers.
>> * Transaction stuff strikes me as overcomplicated and error prone.
>> Given there is no explana
On Tue, Jan 6, 2015 at 11:25 AM, Stephen Frost wrote:
> Looks reasonable to me. Amit, does this read better for you? If so, I
> can handle making the change to the docs.
The docs also prominently say:
"The security-barrier qualifications will always be evaluated prior to
any user-defined funct
On 01/06/2015 04:19 PM, Bruce Momjian wrote:
> On Sat, Jan 3, 2015 at 01:45:37PM -0800, David Fetter wrote:
>> On Sat, Jan 03, 2015 at 09:54:16PM +0900, Michael Paquier wrote:
>>> Hi all,
>>>
>>> Shouldn't we update the copyright notices to 2015 for PGDG like in
>>> 7e04792? I mean those things ma
On Tue, Jan 6, 2015 at 9:39 AM, Robert Haas wrote:
> I think the INSERT .. ON CONFLICT UPDATE shouldn't be able to attempt
> an update unless the UPDATE policies of the table are such that a
> regular UPDATE would find the affected row. The post-image of the row
> needs to satisfy any UPDATE CHEC
Robert, Amit,
* Robert Haas (robertmh...@gmail.com) wrote:
> I don't think that's a typo, although it's not particularly
> well-worded IMHO. I might rewrite the whole paragraph like this:
>
> A policy limits the ability to SELECT, INSERT, UPDATE, or DELETE rows
> in a table to those rows which m
Hi,
when I was fixing how commit_ts handles the XLOG_PARAMETER_CHANGE I
noticed that for wal_log_hints we assign the value in ControFile to
current value instead of value that comes from WAL.
ISTM it has just information value so it should not have any practical
impact, but it looks like a b
On Tue, Jan 6, 2015 at 2:58 AM, Michael Paquier
wrote:
> So, we would need additional information other than the node ID *and*
> the timestamp to ensure proper transaction commit ordering on Windows.
> That's not cool and makes this feature very limited on this platform.
You can't use the timesta
On 2015-01-06 13:46:57 -0500, Robert Haas wrote:
> On Tue, Jan 6, 2015 at 8:22 AM, Andres Freund wrote:
> > I've attached attached, for posterities sake, the last version of that
> > script. I think we should have at least some of these tests in the tap
> > tests. I'd not used that framework becau
On Tue, Jan 6, 2015 at 8:22 AM, Andres Freund wrote:
> I've attached attached, for posterities sake, the last version of that
> script. I think we should have at least some of these tests in the tap
> tests. I'd not used that framework because I wanted to test back to 9.1,
> but ...
I don't see a
Joe Conway writes:
> This seems like either a psql bug or maybe just a documentation bug. I
> know the psql docs say that -c behavior can be surprising, but I find
> the below surprising even after reading the docs a couple of times.
> Given that ON_ERROR_STOP defaults to off, it seems like these
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This seems like either a psql bug or maybe just a documentation bug. I
know the psql docs say that -c behavior can be surprising, but I find
the below surprising even after reading the docs a couple of times.
Given that ON_ERROR_STOP defaults to off, i
On Mon, Jan 5, 2015 at 3:23 PM, Tom Lane wrote:
> Well, we intentionally didn't couple the FDW stuff closely into
> transaction commit, because of the thought that the "far end" would not
> necessarily have Postgres-like transactional behavior, and even if it did
> there would be about zero chance
On Mon, Jan 5, 2015 at 12:54 PM, Peter Geoghegan wrote:
> The patch that implements INSERT ... ON CONFLICT UPDATE has support
> and tests for per-column privileges (which are not relevant to the
> IGNORE variant, AFAICT). However, RLS support is another thing
> entirely. It has not been properly t
On Tue, Jan 6, 2015 at 12:26 AM, Amit Langote
wrote:
> Following is perhaps a typo:
>
> - qualifications of queries which are run against the table the policy
> is on,
> + qualifications of queries which are run against the table if the
> policy is on,
>
> Attached fixes it if so.
I don't thi
Tom Lane wrote:
> What would make sense to me is to teach the planner about inlining
> SQL functions that include ORDER BY clauses, so that the performance
> issue of a double sort could be avoided entirely transparently to
> the user.
Wouldn't this be applicable to functions in other languages t
Hello,
>Yes, that's caused by ccb161b. Attached are rebased versions.
Following are some comments,
>uint16 hole_offset:15, /* number of bytes in "hole" */
Typo in description of hole_offset
>for (block_id = 0; block_id <= record->max_block_id; block_id++)
>- {
>-
On Tue, 6 Jan 2015 08:26:22 -0500
Robert Haas wrote:
> Three, scan the WAL generated since the incremental backup and summarize it
> into a list of blocks that need to be backed up.
This can be done from the archive side. I was talking about some months ago
now:
http://www.postgresql.org/mes
On Sat, Jan 3, 2015 at 01:45:37PM -0800, David Fetter wrote:
> On Sat, Jan 03, 2015 at 09:54:16PM +0900, Michael Paquier wrote:
> > Hi all,
> >
> > Shouldn't we update the copyright notices to 2015 for PGDG like in
> > 7e04792? I mean those things mainly:
> > Portions Copyright (c) 1996-2014, Pos
On Mon, Jan 5, 2015 at 10:37 AM, Fabien COELHO wrote:
> Anyway, I suggest to keep that for another round and keep the Robert's
> isofunctional patch as it is before extending.
+1. Let's please get the basic thing committed, and then people can
write more patches to extend and improve it. There
Hello,
The attached patch is newer revision of custom-/foreign-join
interface.
I've ported my PG-Strom extension to fit the latest custom-scan
(+this patch) interface in this winter vacation.
The concept of "join replaced by foreign-/custom-scan" almost
works well, however, here are two small ov
Jim, Thanks for your reviewing the patch.
The attached patch is revised one according to your suggestion,
and also includes bug fix I could found.
* Definitions of TIDOperator was moved to pg_operator.h
as other operator doing.
* Support the case of "ctid (operator) Param" expression.
* Add
On Tue, Oct 14, 2014 at 1:17 PM, Marco Nenciarini
wrote:
> I would to replace the getMaxLSN function with a more-or-less persistent
> structure which contains the maxLSN for each data segment.
>
> To make it work I would hook into the ForwardFsyncRequest() function in
> src/backend/postmaster/chec
On 2015-01-06 14:22:16 +0100, Petr Jelinek wrote:
> On 06/01/15 08:51, Michael Paquier wrote:
> >On Tue, Dec 23, 2014 at 5:21 AM, Petr Jelinek wrote:
> >>Attached is v3 which besides the fixes mentioned above also includes changes
> >>discussed with Tomas (except the CREATE/DROP TABLESAMPLE METHOD
On 2015-01-05 18:45:22 +0200, Heikki Linnakangas wrote:
> On 01/03/2015 08:59 PM, Andres Freund wrote:
> >Hi Heikki,
> >
> >While writing a test script for
> >http://archives.postgresql.org/message-id/20141205002854.GE21964%40awork2.anarazel.de
> >I noticed that this commit broke starting a pg_base
On 06/01/15 08:51, Michael Paquier wrote:
On Tue, Dec 23, 2014 at 5:21 AM, Petr Jelinek wrote:
Attached is v3 which besides the fixes mentioned above also includes changes
discussed with Tomas (except the CREATE/DROP TABLESAMPLE METHOD), fixes for
crash with FETCH FIRST and is rebased against c
On 06/01/15 08:58, Michael Paquier wrote:
On Fri, Dec 19, 2014 at 3:53 PM, Noah Misch wrote:
localhost template1=# select clock_timestamp(), pg_sleep(.1 * (n % 2)) from
generate_series(0,7) t(n);
clock_timestamp| pg_sleep
---+--
2014-12-18
On Mon, Jan 5, 2015 at 9:56 PM, Peter Eisentraut wrote:
> On 11/19/14 7:36 AM, Magnus Hagander wrote:
> > +
> > +
>
> pg_stat_sslpg_stat_ssl
> > + One row per connection (regular and replication), showing
> statistics about
> > +SSL used on this connection.
> > +See
At 2015-01-02 16:46:29 +0200, hlinnakan...@vmware.com wrote:
>
> In the slicing-by-8 version, I wonder if it would be better to do
> single-byte loads to c0-c7, instead of two 4-byte loads and shifts.
Nope. I did some tests, and the sb8 code is slightly slower if I remove
the 0-7byte alignment loo
On Tue, Dec 9, 2014 at 4:45 AM, Jeff Janes wrote:
> In the past, building under MinGW produced so many warnings that I never
> bothered to read them.
>
> Now most of them have been removed, so the ones that are left might be worth
> reporting.
>
> Using gcc.exe (GCC) 4.6.2 on REL9_4_STABLE
> eadd8
On Tuesday, January 6, 2015, Amit Langote
wrote:
> On 06-01-2015 PM 04:26, Atri Sharma wrote:
> > On Tue, Jan 6, 2015 at 12:43 PM, Amit Langote <
> langote_amit...@lab.ntt.co.jp
> >> wrote:
> >> Though, I have no strong opinion on whether one thing is good or the
> >> other or whether they cover
On 06-01-2015 PM 04:26, Atri Sharma wrote:
> On Tue, Jan 6, 2015 at 12:43 PM, Amit Langote > wrote:
>> Though, I have no strong opinion on whether one thing is good or the
>> other or whether they cover some particular use case all the same.
>> Perhaps you can say that better.
>>
>>
> Personally, I
81 matches
Mail list logo
