On 08/23/2016 06:18 PM, Heikki Linnakangas wrote:
On 08/22/2016 08:38 PM, Andres Freund wrote:
On 2016-08-22 20:32:42 +0300, Heikki Linnakangas wrote:
I
remember seeing ProcArrayLock contention very visible earlier, but I can't
hit that now. I suspect you'd still see contention on bigger
On 22 August 2016 at 16:56, Simon Riggs wrote:
> On 22 August 2016 at 13:44, Kuntal Ghosh wrote:
>
>> Please let me know your thoughts on this.
>
> Do the regression tests pass with this option enabled?
Hi,
I'd like to be a reviewer on this.
On Wed, Aug 24, 2016 at 4:35 AM, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Peter Geoghegan [mailto:p...@heroku.com]
> > On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote:
> > >> [Windows]
> > >> #clients onoff
> > >> 12 29793 38169
> > >>
On Wed, Aug 24, 2016 at 11:54 AM, Heikki Linnakangas
wrote:
> On 08/23/2016 06:18 PM, Heikki Linnakangas wrote:
>
>> On 08/22/2016 08:38 PM, Andres Freund wrote:
>>
>>> On 2016-08-22 20:32:42 +0300, Heikki Linnakangas wrote:
>>>
I
remember seeing ProcArrayLock
On 2016/04/04 23:24, Tom Lane wrote:
Amit Langote writes:
On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote:
* .Observation: *Prepare statement execution plan is not getting changed
even after altering foreign table to point to new schema.
I wonder if
Over in the thread about the SP-GiST inet opclass, I threatened to post
a patch like this, and here it is.
The basic idea is to track more than just the very latest page we've used
in each of the page categories that SP-GiST works with. I started with an
arrangement that gave an equal number of
On Wed, Aug 24, 2016 at 11:15 PM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> The patch attached includes all those tests and they are failing. We
>> are going to need a patch able to pass all that, and even for master
>> this is going to
2016-08-24 17:01 GMT-03:00 Martín Marqués :
> 2016-08-24 11:15 GMT-03:00 Stephen Frost :
>> Michael,
>>
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>>> The patch attached includes all those tests and they are failing. We
>>> are going to need
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi
> calculations may cause performance problem. Is there any need of writing
> this stats information to file? As this just provides the wait time
> information.
Yes, saving the
Hi,
I'd like to propose that we increase the default WAL segment size,
which is currently 16MB. It was first set to that value in commit
47937403676d913c0e740eec6b85113865c6c8ab in October of 1999; prior to
that, it was 64MB. Between 1999 and now, there have been three
significant changes that
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Sorry, my mistake!
I could not find a way to disable this
On Wed, Aug 24, 2016 at 10:36 PM, Gerdan Santos wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:
On 2016-08-25 00:28:58 -0400, Robert Haas wrote:
> On Wed, Aug 24, 2016 at 11:52 PM, Andres Freund wrote:
> > On 2016-08-24 23:26:51 -0400, Robert Haas wrote:
> >> On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote:
> >> > and I'm also rather doubtful
Robert Haas writes:
> I'd like to propose that we increase the default WAL segment size,
> which is currently 16MB.
That seems like a reasonable thing to consider ...
> Possibly it would make sense for this to be configurable at initdb
> time instead of requiring a
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Considering those three factors, I think we should consider pushing the
> default value up somewhat higher for v10. Reverting to the 64MB size that
> we had prior to
On 2016-08-24 22:33:49 -0400, Tom Lane wrote:
> > Possibly it would make sense for this to be configurable at initdb
> > time instead of requiring a recompile;
>
> ... but I think this is just folly. You'd have to do major amounts
> of work to keep, eg, slave servers on the same page as the
Andres Freund writes:
> On 2016-08-24 22:33:49 -0400, Tom Lane wrote:
>> ... but I think this is just folly. You'd have to do major amounts
>> of work to keep, eg, slave servers on the same page as the master
>> about what the segment size is.
> Don't think it'd actually be
On Thu, Aug 25, 2016 at 6:57 AM, Robert Haas wrote:
> On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi
> wrote:
>>
>> Based on the performance impact with the additional timing calculations,
>> we can decide the view default behavior, Are there any
Hello hackers,
I'm no PG hacker, so maybe I'm completely wrong, so sorry if I have wasted your
time. I try to make the best out of Tom Lanes comment.
What would happen if there's a database on a server with initdb (or whatever)
parameter -with-wal-size=64MB and later someone decides to make it
Hi Artur Zakirov,
0001-to-timestamp-format-checking-v3.patch looks pretty reasonable to me, other
than following concern:
#1.
Whitespace @ line # 317.
#2. Warning at compilation;
formatting.c: In function ‘do_to_timestamp’:
formatting.c:3049:37: warning: ‘prev_type’ may be used uninitialized
On Wed, Aug 24, 2016 at 10:31 PM, Robert Haas wrote:
> 1. Transaction rates are vastly higher these days. In 1999, I think
> we were still limited to ~2^32 transactions during the entire lifetime
> of the server; transaction ID wraparound hadn't been invented yet.[1]
>
On Wed, Aug 24, 2016 at 11:52 PM, Andres Freund wrote:
> On 2016-08-24 23:26:51 -0400, Robert Haas wrote:
>> On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote:
>> > and I'm also rather doubtful that it's actually without overhead.
>>
>> Really? Where
On Wed, Aug 24, 2016 at 11:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> What am I missing?
>
> Maybe nothing. But I'll point out that of the things that can currently
> be configured at initdb time, such as LC_COLLATE, there is not one single
> one
2016-08-25 13:46 GMT+09:00 Haribabu Kommi :
> On Thu, Aug 25, 2016 at 6:57 AM, Robert Haas wrote:
>> On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi
>> wrote:
>>>
>>> Based on the performance impact with the additional
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
I could not find a way to disable this functionality , I see
On Wed, Aug 24, 2016 at 10:33 PM, Tom Lane wrote:
> ... but I think this is just folly. You'd have to do major amounts
> of work to keep, eg, slave servers on the same page as the master
> about what the segment size is.
I said an initdb-time parameter, meaning not capable
On Wed, Aug 24, 2016 at 11:02 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-08-24 22:33:49 -0400, Tom Lane wrote:
>>> ... but I think this is just folly. You'd have to do major amounts
>>> of work to keep, eg, slave servers on the same page as
Robert Haas writes:
> What am I missing?
Maybe nothing. But I'll point out that of the things that can currently
be configured at initdb time, such as LC_COLLATE, there is not one single
one that matters to walsender/walreceiver. If you think there is zero
risk involved
On Wed, Aug 24, 2016 at 11:46 PM, Alvaro Herrera
wrote:
> Amit Kapila wrote:
>> $SUBJECT will make hash indexes reliable and usable on standby.
>
> Nice work.
>
> Can you split the new xlog-related stuff to a new file, say hash_xlog.h,
> instead of cramming it in hash.h?
On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote:
> On 2016-08-24 22:33:49 -0400, Tom Lane wrote:
>> > Possibly it would make sense for this to be configurable at initdb
>> > time instead of requiring a recompile;
>>
>> ... but I think this is just folly. You'd have to
On Thu, Aug 18, 2016 at 3:37 PM, Michael Paquier
wrote:
> On Tue, Aug 16, 2016 at 11:06 PM, Stephen Frost
> wrote:
> > I could see supporting an additional "pause" option that means "pause at
> > the end of WAL if you don't reach the recovery
On 08/25/2016 01:45 AM, Tom Lane wrote:
Over in the thread about the SP-GiST inet opclass, I threatened to post
a patch like this, and here it is.
The basic idea is to track more than just the very latest page we've used
in each of the page categories that SP-GiST works with. I started with
2016-08-24 21:34 GMT-03:00 Michael Paquier :
>
> Yes, you are right. If I look at the diffs this morning I am seeing
> the ACLs being dumped for this aggregate. So we could just fix the
> test and be done with it. I did not imagine the index issue though,
> and this is
On 24 August 2016 at 19:42, roshan_myrepublic wrote:
> Now, I am able to see the last added row in my subscriber table. All the
> other 4 rows which were added in the beginning are still missing. What am I
> doing wrong here?
Hi. This isn't really on topic for the
On 2016-08-24 23:26:51 -0400, Robert Haas wrote:
> On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote:
> > and I'm also rather doubtful that it's actually without overhead.
>
> Really? Where do you think the overhead would come from?
ATM we do a math involving
On Thu, Aug 25, 2016 at 12:35 AM, Andres Freund wrote:
> FWIW, I'm also doubtful that investing time into making this initdb
> configurable is a good use of time: The number of users that'll adjust
> initdb time parameters is going to be fairly small.
I have to admit that I
On 25 August 2016 at 09:22, Craig Ringer wrote:
> On 25 August 2016 at 03:26, Vladimir Gordiychuk wrote:
>> Hi. It has already passed a few months but patch still have required review
>> state. Can I help to speed up the review, or should i wait
On Thu, Jun 9, 2016 at 12:56 AM, Tom Lane wrote:
> Thom Brown writes:
>> On 15 May 2014 at 19:56, Bruce Momjian wrote:
>>> On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote:
A recent question from Tim Kane prompted me to measure
On 25 August 2016 at 03:26, Vladimir Gordiychuk wrote:
> Hi. It has already passed a few months but patch still have required review
> state. Can I help to speed up the review, or should i wait commitfest?
> I plane complete changes in pgjdbc drive inside PR
>
Robert Haas writes:
> On Wed, Aug 24, 2016 at 10:33 PM, Tom Lane wrote:
>> ... but I think this is just folly. You'd have to do major amounts
>> of work to keep, eg, slave servers on the same page as the master
>> about what the segment size is.
> I
On Wed, Aug 24, 2016 at 9:07 AM, Michael Paquier
wrote:
> On Wed, Aug 24, 2016 at 5:34 AM, Martín Marqués
> wrote:
>> Hi,
>>
>> 2016-08-23 16:46 GMT-03:00 Martín Marqués :
>>>
>>> I will add tests for sequence and
Hi,
> Well, that change should be part of Amit's patch to add WAL logging,
> not this patch, whose mission is just to improve test coverage.
I have just removed the warning message from expected output file as i
have performed the testing on Amit's latest patch that removes this
warning message
On 24/08/16 17:01, Mark Kirkwood wrote:
...actually I was wrong there, only 2 of them were the same. So I've
attached a new log of bt's of them all.
And I can reproduce with only 1 session, figured that might be a helpful
piece of the puzzle (trace attached).
$ pgbench -c 1 -T600
2016-08-23 21:00 GMT+02:00 Pavel Stehule :
> Hi
>
> 2016-08-19 10:58 GMT+02:00 Pavel Stehule :
>
>> Hi
>>
>> I am sending implementation of xmltable function. The code should to have
>> near to final quality and it is available for testing.
>>
>>
On Wed, Aug 24, 2016 at 11:44 AM, Mark Kirkwood
wrote:
> On 24/08/16 17:01, Mark Kirkwood wrote:
>>
>>
>> ...actually I was wrong there, only 2 of them were the same. So I've
>> attached a new log of bt's of them all.
>>
>>
>>
>
> And I can reproduce with only 1
On Wed, Aug 24, 2016 at 11:38 AM, Ashutosh Sharma wrote:
> Hi,
>
>> Well, that change should be part of Amit's patch to add WAL logging,
>> not this patch, whose mission is just to improve test coverage.
>
> I have just removed the warning message from expected output file
I looked at this, but I don't really find any of these changes to be
improvements. They just make it harder to read IMO.
I marked the patch as rejected in CF 2016-09.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 2016/04/04 20:11, Etsuro Fujita wrote:
I found an incorrect comment in contrib/postgres_fdw/deparse.c: s/FOR
SELECT or FOR SHARE/FOR UPDATE or FOR SHARE/ Attached is a patch to fix
that comment.
Other than this, I ran into some typos in contrib/postgres_fdw, while
working on join
--On 20. August 2016 12:41:48 -0400 Tom Lane wrote:
> So at this point I'm pretty baffled as to what the actual use-case is
> here. I am tempted to say that a standalone backend should refuse to
> start at all if a recovery.conf file is present. If we do want to
> allow
On Tue, Aug 23, 2016 at 3:59 AM, Andres Freund wrote:
>> Haribabu's categorization
>> scheme seems to need some work, but the idea of categorizing
>> statements by type and counting executions per type seems very
>> reasonable.
>
> I'd consider instead using something like
There was some discussion earlier in adding pg_stat_lwlock view in [1].
The main objections which I observed for that patch was showing LWLOCK
information to the user that don't understand what this lock used for and etc.
Currently as part of wait_event information in pg_stat_activity the LWLOCK
I wrote:
> Peter Eisentraut writes:
>> What does it do if you are displaying more than one function?
> It prints more than one footer. It's very much like the way that, say,
> rules are printed for tables by \d.
Or to be concrete: instead of
regression=#
> That would require changing it from an AlterEnumStmt to a RenameStmt
> instead. Those look to me like they're for renaming SQL objects,
> i.e. things addressed by identifiers, whereas enum labels are just
> strings. Looking at the implementation of a few of the functions called
> by
Andrew Gierth writes:
> Something is wrong with the way chgParam is being handled in Agg nodes.
> The code in ExecReScanAgg seems to assume that if the lefttree doesn't
> have any parameter changes then it suffices to re-project the data from
> the existing hashtable;
2016-08-24 17:08 GMT+02:00 Tom Lane :
> Andrew Gierth writes:
> > Something is wrong with the way chgParam is being handled in Agg nodes.
> > The code in ExecReScanAgg seems to assume that if the lefttree doesn't
> > have any parameter changes
> "Tom" == Tom Lane writes:
Tom> I'm not sure if it's worth trying to distinguish whether the Param
Tom> is inside any aggregate calls or not. The existing code gets the
Tom> right answer for
Tom> select array(select x+sum(y) from generate_series(1,3) y group by y)
> "Andrew" == Andrew Gierth writes:
> "Tom" == Tom Lane writes:
Tom> I'm not sure if it's worth trying to distinguish whether the Param
Tom> is inside any aggregate calls or not.
How about:
--
Andrew (irc:RhodiumToad)
diff --git
> "Pavel" == Pavel Stehule writes:
Pavel> The result should not depend on GUC - hashagg on/off changing
Pavel> output - it is error.
I don't think anyone's suggesting leaving it unfixed, just whether the
fix should introduce unnecessary rescans of the aggregate
Andrew Gierth writes:
> How about:
Hm, I was just working on inserting something of the sort into
ExecInitAgg. But I guess we could do it in the planner too.
Will run with your approach.
I think it's a bit too stupid as-is, though. We don't need to
recalculate for
On Tue, Aug 23, 2016 at 6:11 PM, Tomas Vondra
wrote:
> Could someone please explain how the unlogged tables are supposed to fix the
> catalog bloat problem, as stated in the initial patch submission? We'd still
> need to insert/delete the catalog rows when
On Tue, Aug 23, 2016 at 11:18 PM, Etsuro Fujita
wrote:
>> Yes, it seems what we are doing now is not consistent with what
>> happens for plain tables; that should probably be fixed.
>
> OK, I think we should fix the issue that postgres_fdw produces incorrect
> aliases
> "Tom" == Tom Lane writes:
Tom> Hm, I was just working on inserting something of the sort into
Tom> ExecInitAgg. But I guess we could do it in the planner too. Will
Tom> run with your approach.
Tom> I think it's a bit too stupid as-is, though. We don't need to
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I think it's a bit too stupid as-is, though. We don't need to
> Tom> recalculate for Params in aggdirectargs, do we?
> In theory we would need to.
How come? Those are only passed to
On 08/24/2016 12:20 AM, Andres Freund wrote:
On 2016-08-23 19:18:04 -0300, Claudio Freire wrote:
On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra
wrote:
Could someone please explain how the unlogged tables are supposed to fix the
catalog bloat problem, as stated
On August 24, 2016 9:32:48 AM PDT, Tomas Vondra
wrote:
>
>
>On 08/24/2016 12:20 AM, Andres Freund wrote:
>> On 2016-08-23 19:18:04 -0300, Claudio Freire wrote:
>>> On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra
>>> wrote:
Could
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi,
I haven't tested the performance yet, but the patch itself looks
On Wed, Aug 24, 2016 at 2:34 AM, Amit Kapila wrote:
> On Wed, Aug 24, 2016 at 11:38 AM, Ashutosh Sharma
> wrote:
>>> Well, that change should be part of Amit's patch to add WAL logging,
>>> not this patch, whose mission is just to improve test
On Tue, Aug 23, 2016 at 10:05 PM, Amit Kapila
wrote:
> On Wed, Aug 24, 2016 at 2:37 AM, Jeff Janes wrote:
>
> >
> > After an intentionally created crash, I get an Assert triggering:
> >
> > TRAP: FailedAssertion("!(((freep)[(bitmapbit)/32] &
> >
> Aside from the disturbing frequency of 100-to-1 split ratios, it also
> looks like the inclusion of the masklen bit is hardly pulling its weight,
> though that might be a artifact of this data set.
I was expecting this. Including masklen bit to decision was something
we could easily do. It
Kevin Grittner wrote:
> Modify BufferGetPage() to prepare for "snapshot too old" feature
I just noticed that this commit added a line to #include catalog/catalog.h
in storage/bufmgr.h. I can't find any reason for it doing so, and I
think it's a bad line to have there. Can we get it removed?
--
Sorry. I did not get last two mails from Amul. Don't know why. So I
reply to another mail.
Documented as working case, but unfortunatly it does not :
postgres=# SELECT to_timestamp('2000JUN', ' MON');
ERROR: invalid value "---" for "MON"
DETAIL: The given value did not match any of
On Wed, Aug 24, 2016 at 12:40 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> Modify BufferGetPage() to prepare for "snapshot too old" feature
>
> I just noticed that this commit added a line to #include catalog/catalog.h
> in storage/bufmgr.h. I can't find any
Amit Kapila wrote:
> $SUBJECT will make hash indexes reliable and usable on standby.
Nice work.
Can you split the new xlog-related stuff to a new file, say hash_xlog.h,
instead of cramming it in hash.h? Removing the existing #include
"xlogreader.h" from hash.h would be nice. I volunteer for
Alvaro Herrera wrote:
> Many have expressed their interest in this topic, but I haven't seen any
> design of how it should work. Here's my attempt; I've been playing with
> this for some time now and I think what I propose here is a good initial
> plan.
I regret to announce that I'll have to
On Wed, Aug 24, 2016 at 1:00 PM, Kevin Grittner wrote:
> On Wed, Aug 24, 2016 at 12:40 PM, Alvaro Herrera
> wrote:
>> #include catalog/catalog.h in storage/bufmgr.h.
>> Can we get it removed?
>
> Will do that now.
Done. Back-patched to 9.6
Hi Craig,
I am trying to set up pglogical replication. I have a table which has
around 4 rows in the provider server.
=
employee_id | visitor_email | vistor_id |date |
message
> "Andrew" == Andrew Gierth writes:
> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi,
Jeevan> While playing with LATERAL along with some aggregates in
Jeevan> sub-query, I have observed somewhat unusual behavior.
Andrew>
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> The patch attached includes all those tests and they are failing. We
> are going to need a patch able to pass all that, and even for master
> this is going to need more thoughts, and let's focus on HEAD/9.6
> first.
Are you sure you
Hi. It has already passed a few months but patch still have required review
state. Can I help to speed up the review, or should i wait commitfest?
I plane complete changes in pgjdbc drive inside PR
https://github.com/pgjdbc/pgjdbc/pull/550 but PR blocked current problem
with not available stop
On Wed, Aug 24, 2016 at 2:35 PM, Tsunakawa, Takayuki
wrote:
> From: Peter Geoghegan [mailto:p...@heroku.com]
>> On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote:
>> >> [Windows]
>> >> #clients onoff
>> >> 12 29793 38169
>> >> 24
I wrote:
> I've pushed this patch with mostly (not entirely) cosmetic adjustments.
> I still think it'd be worth looking into why the produced index is larger
> than the GiST equivalent, and for that matter exactly why the GiST
> equivalent is so much slower to search.
I spent some time poking at
On Tue, Aug 23, 2016 at 8:43 PM, Tom Lane wrote:
> It's interesting that nobody has complained about this behavior.
We have been known to emphasize that unless you have an ORDER BY
clause at the outermost level of a query, there is no guarantee
about the order of rows
Peter Eisentraut writes:
> On 8/22/16 1:52 PM, Pavel Stehule wrote:
>> If I understand to purpose of this patch - it is compromise - PL source
>> is removed from table, but it is printed in result.
> What does it do if you are displaying more than one function?
Emre Hasegeli writes:
>> Here is v4, which changes the command from ALTER VALUE to RENAME VALUE,
>> for consistency with RENAME ATTRIBUTE.
>
> It looks like we always use "ALTER ... RENAME ... old_name TO
> new_name" syntax, so it is better that way. I have noticed that all
>
On 8/22/16 1:52 PM, Pavel Stehule wrote:
> If I understand to purpose of this patch - it is compromise - PL source
> is removed from table, but it is printed in result.
What does it do if you are displaying more than one function?
--
Peter Eisentraut http://www.2ndQuadrant.com/
> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi,
Jeevan> While playing with LATERAL along with some aggregates in
Jeevan> sub-query, I have observed somewhat unusual behavior.
Simpler example not needing LATERAL:
select array(select sum(x+y) from
On Wed, Aug 24, 2016 at 2:41 AM, Etsuro Fujita
wrote:
> On 2016/04/04 20:11, Etsuro Fujita wrote:
>> I found an incorrect comment in contrib/postgres_fdw/deparse.c: s/FOR
>> SELECT or FOR SHARE/FOR UPDATE or FOR SHARE/ Attached is a patch to fix
>> that comment.
>
>
2016-08-24 11:15 GMT-03:00 Stephen Frost :
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> The patch attached includes all those tests and they are failing. We
>> are going to need a patch able to pass all that, and even for master
>> this is going to
On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi
wrote:
> There was some discussion earlier in adding pg_stat_lwlock view in [1].
> The main objections which I observed for that patch was showing LWLOCK
> information to the user that don't understand what this lock used
89 matches
Mail list logo