On 6 October 2012 22:40, Tom Lane wrote:
> Thus for example "MSK" apparently now means GMT+4 not GMT+3. We can
> change the tznames entry for that, but should we get rid of "MSD"
> entirely? Some input from the Russians on this list would be helpful.
...
> Comments?
It shouldn't be our job to
On 7 October 2012 18:27, Tom Lane wrote:
> Sean Chittenden recently reported that 9.2 can crash after logging
> "FATAL: pipe() failed" if the kernel is short of file descriptors:
> http://archives.postgresql.org/pgsql-general/2012-10/msg00202.php
>
> The only match to that error text is in initSel
Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Oct 5, 2012, at 6:12 PM, Tom Lane wrote:
>>> Now, having said that, I think it has to be the reponsibility of the
FDW
>>> to apply any required check ... which makes this a bug report
against
>>> oracle_fdw, not the core system. (FWIW, contrib/f
On Oct 8, 2012, at 12:25 AM, "Albe Laurenz" wrote:
> As the author I agree that this is a bug in oracle_fdw.
Thanks. Should I file a report somewhere?
> This was caused by ignorance on my part: I had assumed that the
> type input functions would perform the necessary checks, but it
> seems lik
On 08.10.2012 10:03, Simon Riggs wrote:
On 6 October 2012 22:40, Tom Lane wrote:
Thus for example "MSK" apparently now means GMT+4 not GMT+3. We can
change the tznames entry for that, but should we get rid of "MSD"
entirely? Some input from the Russians on this list would be helpful.
...
C
2012/10/8 Tom Lane :
> Julien Tachoires writes:
>> About \ds behaviour, I think to add 2 columns :
>> - 'LastValue'
>> - 'Increment'
>
> That would make the command a great deal slower, since it would have to
> access each sequence to get that info. I don't object to adding such
> columns to \ds+
On 8 October 2012 09:05, Heikki Linnakangas wrote:
>> * Make the tz file configurable, so people can be more explicit about
>> what *they* mean by certain codes, to avoid the need for choosing
>> between countries. For example, someone may have hardcoded particular
>> codes with the understanding
Am 08.10.12 11:07, schrieb Simon Riggs:
> On 8 October 2012 09:05, Heikki Linnakangas wrote:
>
>>> * Make the tz file configurable, so people can be more explicit about
>>> what *they* mean by certain codes, to avoid the need for choosing
>>> between countries. For example, someone may have hardc
On 8 October 2012 11:14, Marc Balmer wrote:
>> So I think we need 2 new settings: one called "Postgres92", one called
>> "Postgres93". 93 has the new settings and is the default.
>>
>> "Default" would no longer map to anything, to make sure we have an
>> explicit break of compatibility.
>
> Remov
On 08.10.2012 04:04, Tomonari Katsumata wrote:
I work with streaming replication and hot standby.
And I noticed that error message is not proper when I issue
ANALYZE command to standby.
...
>
This is not big problem, but error message should report
actual thing. please check it.
Thanks, comm
On 04.10.2012 20:07, Fujii Masao wrote:
On Thu, Oct 4, 2012 at 4:59 PM, Heikki Linnakangas
But I wonder why promoting a standby renders the backup invalid in the first
place? Fujii, Simon, can you explain that?
Simon had the same question and I answered it before.
http://archives.postgresql.o
On Mon, Jun 18, 2012 at 02:08:29PM +0500, Talha Bin Rizwan wrote:
> PostgreSQL 9.2 Windows build is having trouble with the XML support:
> http://postgresql.1045698.n5.nabble.com/9-2-beta1-libxml2-can-t-be-loaded-on-Windows-td5710672.html
> Therefore, I used first approach to get libxml2 version n
Hello,
In my C++ program, i want to partition sql table, there is sample code below.
It is working right. the problem is after func called 2 or 3 times in func1,
PQntuples results 0 although tablename exist. Also when i disabled PQntuples
at if statement, other psql function PQgetvalue(res)
On Sun, Oct 07, 2012 at 08:30:22PM +0200, Brar Piening wrote:
> Noah Misch wrote:
>> I'm marking this patch Waiting on Author, but the changes needed to
>> get it Ready for Committer are fairly trivial. Thanks, nm
>
> Thanks for your review and sorry for my delayed response - I've been on
> va
On 4 October 2012 18:07, Fujii Masao wrote:
> On Thu, Oct 4, 2012 at 4:59 PM, Heikki Linnakangas
> wrote:
>> On 03.10.2012 18:15, Amit Kapila wrote:
>>>
>>> On Tuesday, October 02, 2012 4:21 PM Heikki Linnakangas wrote:
Hmm, should a base backup be aborted when the standby is promoted?
Do you think you can follow through on this soon, Robert? I don't
believe that there are any outstanding issues. I'm not going to make
an issue of the fact that strxfrm() hasn't been taken advantage of. If
you could please post a new revision, with the suggested alterations
(that you agree with), I
On Sun, Oct 7, 2012 at 10:29 AM, Tom Lane wrote:
> Atri Sharma writes:
>> Does that mean that using (some) global storage is the cause of the problem?
>
> If you're using global storage for state that needs to be replicated
> per-scan, yes, probably. But it's hard to be sure when you're being
>
We seem to have an intermittent failure on the alter_generic tests that
look like this:
SET SESSION AUTHORIZATION regtest_alter_user1;
CREATE FUNCTION alt_func1(int) RETURNS int LANGUAGE sql
AS 'SELECT $1 + 1';
+ ERROR: permission denied for language sql
CREATE F
Tom Lane writes:
> going to be required below that ... but the point I'm trying to make is
> that it would be a one-and-done task. Adding a requirement to be able
> to decompile raw parse trees will be a permanent drag on every type of
> SQL feature addition.
I'll show some examples of very invo
On 5 October 2012 04:37, Tom Lane wrote:
> A bit later: testing on an F17 box (glibc-2.15-56.fc17.x86_64)
> confirms Peter G's complaint, and also confirms that putting
> the above into port/linux.h (instead of the template file) fixes the
> problem. Don't know how to disable it on ICC, but I sup
Simon Riggs writes:
> We still have to consider how Postgres would operate without the
> latches. I don't see that it can, so a shutdown seems appropriate. Is
> the purpose of this just to allow a cleaner and more informative
> shutdown? Or do you think we can avoid?
The point is that right now,
On 20 August 2012 14:09, Pavel Stehule wrote:
> (eelog-2012-08-20.diff)
This patch has the following reference to relerror.c:
"""
*** a/src/include/utils/rel.h
--- b/src/include/utils/rel.h
***
*** 394,397 typedef struct StdRdOptions
--- 394,402
extern void RelationI
On Thu, Oct 4, 2012 at 6:12 AM, Amit kapila wrote:
> 1. One new configuration parameter wal_receiver_timeout is added to detect
> timeout at receiver task.
> 2. Existing parameter replication_timeout is renamed to wal_sender_timeout.
-1 from me on a backward compatibility break here. I don't kn
On Fri, Oct 5, 2012 at 3:32 AM, Albe Laurenz wrote:
> Phil Sorber wrote:
>> Thom Brown and I were doing some hacking the other day and came across
>> this missing define. We argued over who was going to send the patch in
>> and I lost. So here it is.
>
> +1
>
> I have been missing this #define.
A
Hi,
PL/pgsql seems to have a strange restriction regarding "RETURN".
Normally, you can write "RETURN ". But if the function
returns a row type, then you can only write "RETURN variable" or
"RETURN NULL".
rhaas=# create type xyz as (a int, b int);
CREATE TYPE
rhaas=# select row(1,2)::xyz;
row
-
> On Monday, October 08, 2012 7:38 PM Robert Haas wrote:
> On Thu, Oct 4, 2012 at 6:12 AM, Amit kapila
> wrote:
> > 1. One new configuration parameter wal_receiver_timeout is added to
> detect timeout at receiver task.
> > 2. Existing parameter replication_timeout is renamed to
> wal_sender_timeou
On Mon, Oct 8, 2012 at 3:49 AM, Julien Tachoires wrote:
> 2012/10/8 Tom Lane :
>> Julien Tachoires writes:
>>> About \ds behaviour, I think to add 2 columns :
>>> - 'LastValue'
>>> - 'Increment'
>>
>> That would make the command a great deal slower, since it would have to
>> access each sequence
On Mon, Oct 8, 2012 at 12:14:15PM +0200, Marc Balmer wrote:
> A good starting point would be to take the timezone information directly
> from the the files IANA distributes, instead of manually copying and
> maintaining them in a separate file. If no one else does, I can try to
> maintain these f
Julien Tachoires writes:
> 2012/10/8 Tom Lane :
>> The other problem you're going to have here is that there is in fact no
>> such command as "\ds" (nor "\ds+"); rather, it's a special case of
>> \dtsvi. As such, putting any relkind-specific info into the result is
>> problematic. I think you're
2012/10/8 Robert Haas :
> On Mon, Oct 8, 2012 at 3:49 AM, Julien Tachoires wrote:
>> 2012/10/8 Tom Lane :
>>> Julien Tachoires writes:
About \ds behaviour, I think to add 2 columns :
- 'LastValue'
- 'Increment'
>>>
>>> That would make the command a great deal slower, since it would
Robert Haas writes:
> ERROR: RETURN must specify a record or row variable in function returning row
> Off the top of my head, I can't think of any reason for this
> restriction, nor can I find any code comments or anything in the
> commit log which explains the reason for it. Does anyone know w
Bruce Momjian writes:
> Could we pull an abbreviation list from one of the BSDs?
And that would be authoritative why?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
On Mon, Oct 8, 2012 at 11:10:08AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Could we pull an abbreviation list from one of the BSDs?
>
> And that would be authoritative why?
It would be somone else maintaining it. :-)
--
Bruce Momjian http://momjian.us
EnterpriseDB
Am 08.10.12 16:53, schrieb Bruce Momjian:
> On Mon, Oct 8, 2012 at 12:14:15PM +0200, Marc Balmer wrote:
>> A good starting point would be to take the timezone information directly
>> from the the files IANA distributes, instead of manually copying and
>> maintaining them in a separate file. If no
On Mon, Oct 8, 2012 at 05:15:18PM +0200, Marc Balmer wrote:
> Am 08.10.12 16:53, schrieb Bruce Momjian:
> > On Mon, Oct 8, 2012 at 12:14:15PM +0200, Marc Balmer wrote:
> >> A good starting point would be to take the timezone information directly
> >> from the the files IANA distributes, instead o
2012/10/8 Tom Lane :
> Julien Tachoires writes:
>> 2012/10/8 Tom Lane :
>>> The other problem you're going to have here is that there is in fact no
>>> such command as "\ds" (nor "\ds+"); rather, it's a special case of
>>> \dtsvi. As such, putting any relkind-specific info into the result is
>>>
Simon Riggs writes:
> Sorry for any confusion. I've not suggested removing timezone
> abbreviations, nor do I wish to do so.
> I did suggest that we do not rely upon TZ abbreviations in any code
> shipped by PostgreSQL project, but I suspect that is a non-problem
> anyway.
No, we don't rely on t
On Mon, Oct 8, 2012 at 8:47 AM, Peter Geoghegan wrote:
> Do you think you can follow through on this soon, Robert? I don't
> believe that there are any outstanding issues. I'm not going to make
> an issue of the fact that strxfrm() hasn't been taken advantage of. If
> you could please post a new r
Hanada-san,
The attached patch is a revised one according to my previous
suggestion. It re-defines "PQconninfoOption *options" as static
variable with NULL initial value, then, PQconndefaults() shall
be invoked at once. The default options never changed during
duration of the backend process, so h
On 08.10.2012 18:26, Tom Lane wrote:
The other thing that the abbreviation list files are doing for us is
providing a user-configurable way to resolve conflicting abbreviations,
for instance IST (the Indians and the Israelis both use this, but not to
mean the same thing). This requirement isn't
The ilist patch from Andres Freund introduces a cute trick for defining
maybe-inline functions, which works regardless of whether the compiler
supports inlining, and eliminates the need to write the code twice
(first in the header and also the .c file.) It's really quite a simple
thing, but the wh
Heikki Linnakangas writes:
> On 08.10.2012 18:26, Tom Lane wrote:
>> The other thing that the abbreviation list files are doing for us is
>> providing a user-configurable way to resolve conflicting abbreviations,
>> for instance IST (the Indians and the Israelis both use this, but not to
>> mean t
I am seeing the following warnings in git head from zic.c:
zic.c:1505: warning: ignoring return value of ‘fwrite’, declared with
attribute warn_unused_result
zic.c:1514: warning: ignoring return value of ‘fwrite’, declared with
attribute warn_unused_result
zic.c:1752: war
Alvaro Herrera writes:
> What's being done in this patch is exactly what would be done in the
> ilist code. So if there are problems with this, please speak up.
Stylistic gripe: in palloc.h you didn't follow the pattern of
#ifndef USE_INLINE
extern ...
#endif
before (rath
Bruce Momjian writes:
> I am seeing the following warnings in git head from zic.c:
> zic.c:1505: warning: ignoring return value of âfwriteâ, declared
> with attribute warn_unused_result
Yeah, this is probably a consequence of the _FORTIFY_SOURCE addition.
I believe that ratchets up war
On Mon, Oct 8, 2012 at 8:58 AM, Bruce Momjian wrote:
> I am seeing the following warnings in git head from zic.c:
>
> zic.c:1505: warning: ignoring return value of ‘fwrite’, declared with
> attribute warn_unused_result
...
>
> Seems casting to void is not enough. Not sure why the error j
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
We were struggling today with some java code binding values violating
some constraints in a prepared statement.
We don't own the code and couldn't make tests with it. So we tried to
find if PostgreSQL was able to log binded values when the BIND
o
2012/10/8 Tom Lane :
> Robert Haas writes:
>> ERROR: RETURN must specify a record or row variable in function returning
>> row
>
>> Off the top of my head, I can't think of any reason for this
>> restriction, nor can I find any code comments or anything in the
>> commit log which explains the re
On 8 October 2012 16:30, Robert Haas wrote:
> I don't have any plans to work on this further. I think all of the
> criticism that has been leveled at this patch is 100% bogus, and I
> greatly dislike the changes that have been proposed. That may not be
> fair, but it's how I feel, and in light o
Jehan-Guillaume de Rorthais writes:
> PFA a patch that catch any error while creating the query plan and add
> parameters values to the error message if log_statement or
> log_min_duration_statement would have logged it.
If that works, it's only by accident --- you're not supposed to add more
inf
Pavel Stehule writes:
> 2012/10/8 Tom Lane :
>> Laziness, probably. Feel free to have at it.
> I wrote patch some years ago. It was rejected from performance reasons
> - because every row had to be casted to resulted type.
I don't recall that patch in any detail, but it's not apparent to me
tha
On Oct 5, 2012, at 6:12 PM, Tom Lane wrote:
> Now, having said that, I think it has to be the reponsibility of the FDW
> to apply any required check ... which makes this a bug report against
> oracle_fdw, not the core system. (FWIW, contrib/file_fdw depends on the
> COPY code, which will check e
"David E. Wheeler" writes:
> On Oct 5, 2012, at 6:12 PM, Tom Lane wrote:
>> Now, having said that, I think it has to be the reponsibility of the FDW
>> to apply any required check ... which makes this a bug report against
>> oracle_fdw, not the core system. (FWIW, contrib/file_fdw depends on the
On Oct 8, 2012, at 11:13 AM, Tom Lane wrote:
>> FWIW, I believe that dblink does not check encoding.
>
> In dblink's case, that boils down to trusting a remote instance of
> Postgres to get this right, which doesn't seem totally unreasonable.
> But I wouldn't object to adding checks there if som
On 10/08/2012 02:13 PM, Tom Lane wrote:
"David E. Wheeler" writes:
On Oct 5, 2012, at 6:12 PM, Tom Lane wrote:
Now, having said that, I think it has to be the reponsibility of the FDW
to apply any required check ... which makes this a bug report against
oracle_fdw, not the core system. (FWI
On 8 October 2012 15:57, Kohei KaiGai wrote:
> The attached patch is a refreshed version towards the latest master branch,
> to fix up patch conflicts.
> Here is no other difference from the previous revision.
>
> Thanks,
>
I had another look at this over the weekend and I found couple of
additio
A while ago I noticed that in some places we strdup/pg_strdup() optarg
strings from getopt(), and in some places we don't.
If we needed the strdup(), the missing cases should generate errors. If
we don't need them, the strdup() is unnecessary, and research confirms
they are unnecessary. Should w
On 09/10/12 03:53, Robert Haas wrote:
On Mon, Oct 8, 2012 at 3:49 AM, Julien Tachoires wrote:
2012/10/8 Tom Lane :
Julien Tachoires writes:
About \ds behaviour, I think to add 2 columns :
- 'LastValue'
- 'Increment'
That would make the command a great deal slower, since it would have to
acc
On Mon, Oct 8, 2012 at 11:54 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 08.10.2012 18:26, Tom Lane wrote:
>>> The other thing that the abbreviation list files are doing for us is
>>> providing a user-configurable way to resolve conflicting abbreviations,
>>> for instance IST (the Indi
2012/10/8 Dean Rasheed :
> On 8 October 2012 15:57, Kohei KaiGai wrote:
>> The attached patch is a refreshed version towards the latest master branch,
>> to fix up patch conflicts.
>> Here is no other difference from the previous revision.
>>
>> Thanks,
>>
>
> I had another look at this over the w
On 10/08/2012 02:40 PM, Bruce Momjian wrote:
A while ago I noticed that in some places we strdup/pg_strdup() optarg
strings from getopt(), and in some places we don't.
If we needed the strdup(), the missing cases should generate errors. If
we don't need them, the strdup() is unnecessary, and r
Christopher Browne writes:
> The scenario where we could unambiguously include time zones is where
> the symbols are unique. If we were to include *all* uniquely-named
> symbols, that would minimize the number of complaints about missing
> zones, whilst evading the cases where the symbols are non
Hi Peter,
On Monday, October 08, 2012 09:43:51 PM Peter Geoghegan wrote:
> Pendantry: This should be in alphabetical order:
>
> ! OBJS = stringinfo.o ilist.o
Argh. Youve said that before. Somehow I reintroduced it...
> I notice that the patch (my revision) produces a whole bunch of
> warnings li
Bruce Momjian writes:
> A while ago I noticed that in some places we strdup/pg_strdup() optarg
> strings from getopt(), and in some places we don't.
> If we needed the strdup(), the missing cases should generate errors. If
> we don't need them, the strdup() is unnecessary, and research confirms
On Mon, Oct 8, 2012 at 12:26 PM, Peter Geoghegan wrote:
> If it was the case that you were only 50% of the way to getting
> something committable, I guess I'd understand; this is, after all, a
> volunteer effort, and you are of course free to pursue or not pursue
> whatever you like. It's more lik
On Oct 6, 2012 3:00 AM, "Peter Eisentraut" wrote:
>
> src/backend/replication/Makefile calls bison with -d to create a
> repl_gram.h header file, but that is not used anywhere. Is this an
> oversight?
That's probably a copy/paste caused oversight. I don't recall any
particular reason for it.
/M
Hi,
#define MemSetLoop(start, val, len) \
do \
{ \
long * _start = (long *) (start); \
long * _stop = (long *) ((char *) _start + (Size) (len)); \
\
while (_start < _stop) \
*_start++ = 0; \
} w
On Monday, October 08, 2012 10:39:27 PM Andres Freund wrote:
> The 'val' parameter is ignored.
Trivial patch attached.
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From a4056e1110961c64b56d61a88c0d472c58a80579 Mon Sep
On 10/5/12 9:57 PM, Michael Paquier wrote:
In the current version of the patch, at the beginning of process a new index is
created. It is a twin of the index it has to replace, meaning that it copies
the dependencies of old index and creates twin entries of the old index even in
pg_depend and
On Monday, October 08, 2012 11:57:46 PM Jim Nasby wrote:
> On 10/5/12 9:57 PM, Michael Paquier wrote:
> > In the current version of the patch, at the beginning of process a new
> > index is created. It is a twin of the index it has to replace, meaning
> > that it copies the dependencies of old inde
On 8 October 2012 21:35, Robert Haas wrote:
> Hey, if me deciding I don't want to work on a patch any more is going
> to make you feel slighted, then you're out of luck. The archives are
> littered with people who have decided to stop working on things
> because the consensus position on list was
While looking at the 64-bit large object patch, I happened to notice
that the LO permissions checks that were added a release or two back
seem to be done exceedingly inefficiently. To wit, they're done in
lo_read() and lo_write(), which means that if the user say reads an 8MB
large object with an
Andres Freund writes:
> The 'val' parameter is ignored.
This is not broken. Read the comments for MemSetTest.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Tuesday, October 09, 2012 12:56:16 AM Tom Lane wrote:
> Andres Freund writes:
> > The 'val' parameter is ignored.
>
> This is not broken. Read the comments for MemSetTest.
Ah. I was surprised about that already. The comment says that val has to be
constant though, not that it has to be zero.
On 10/8/12 6:12 PM, Tom Lane wrote:
Jim Nasby writes:
Yeah, what's the risk to renaming an index during concurrent access?
SnapshotNow searches for the pg_class row could get broken by *any*
transactional update of that row, whether it's for a change of relname
or some other field.
A lot of
On 10/8/12 5:08 PM, Andres Freund wrote:
On Monday, October 08, 2012 11:57:46 PM Jim Nasby wrote:
>On 10/5/12 9:57 PM, Michael Paquier wrote:
> >In the current version of the patch, at the beginning of process a new
> >index is created. It is a twin of the index it has to replace, meaning
> >th
On 10/4/12 11:34 AM, Greg Sabino Mullane wrote:
I was wondering recently if there was any command line tool that
>utilized PQping() or PQpingParams(). I searched the code and couldn't
>find anything and was wondering if there was any interest to have
>something like this included? I wrote somethi
On 10/5/12 11:15 AM, Tom Lane wrote:
Also, we need to normalize that command string. Tools needing to look at
>it won't want to depend on random white spacing and other oddities.
Instead, they'll get to depend on the oddities of parse transformations
(ie, what's done in the raw grammar vs. what'
Jim Nasby writes:
> Yeah, what's the risk to renaming an index during concurrent access?
SnapshotNow searches for the pg_class row could get broken by *any*
transactional update of that row, whether it's for a change of relname
or some other field.
A lot of these problems would go away if we rej
Andres Freund writes:
> On Tuesday, October 09, 2012 12:56:16 AM Tom Lane wrote:
>> Andres Freund writes:
>>> The 'val' parameter is ignored.
>> This is not broken. Read the comments for MemSetTest.
> Ah. I was surprised about that already. The comment says that val has to be
> constant thoug
On Mon, Oct 8, 2012 at 04:33:29PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > A while ago I noticed that in some places we strdup/pg_strdup() optarg
> > strings from getopt(), and in some places we don't.
>
> > If we needed the strdup(), the missing cases should generate errors. If
> > w
On Tue, Oct 9, 2012 at 8:14 AM, Jim Nasby wrote:
> Hrm... the claim was made that everything relating to the index, including
> pg_depend and pg_contstraint, got duplicated. But I don't know how you
> could duplicate a constraint without also playing name games. Perhaps name
> games are being pla
On Mon, Oct 8, 2012 at 4:00 PM, Tom Lane wrote:
> We can't just refuse to deal with this ambiguity. We have to have some
> very-low-pain way to install settings that will please those large
> fractions of our user base. Moreover, if that very-low-pain way isn't
> the exact same way it's been don
The backend code for large objects goes to some lengths to be
intelligent about sparsely-written blobs: if you seek out to the middle
of nowhere and write a few bytes, you don't end up allocating space in
pg_largeobject for all the byte positions you skipped over. However,
pg_dump knows nothing of
One more thing -- I tried a build with NLS support and encountered this:
src\backend\utils\adt\pg_locale.c(746): error C2039: 'lc_handle' : is not a
member of 'threadlocaleinfostruct'
[c:\cygwin\home\nm\src\pg\postgresql\postgres.vcxproj]
That's in the function IsoLocaleName(), which digs aro
On Monday, October 01, 2012 11:11 PM Jeff Davis wrote:
> On Mon, 2012-10-01 at 18:14 +0100, Simon Riggs wrote:
> > You are missing large parts of the previous thread, giving various
> > opinions on what the UI should look like for enabling checksums.
>
> I read through all of the discussion that I
86 matches
Mail list logo
