On Sat, Jan 6, 2024 at 9:04 AM John Naylor wrote:
>
> On Fri, Jan 5, 2024 at 6:58 PM jian he wrote:
> > -Dcassert=true \
>
> > -Dbuildtype=debug \
>
> These probably don't matter much for this test, but these should be
> off for any performance testing.
>
> >
On Fri, Jan 5, 2024 at 6:58 PM jian he wrote:
> -Dcassert=true \
> -Dbuildtype=debug \
These probably don't matter much for this test, but these should be
off for any performance testing.
> -DWRITE_READ_PARSE_PLAN_TREES
> -DCOPY_PARSE_PLAN_TREES
On Fri, Jan 5, 2024 at 4:37 PM jian he wrote:
>
> > > > be reused for a different user.
> > > >
> > >
> > > You are right.
> > > so I changed, now the schema owner will be the error table owner.
> > > every error table tuple inserts,
> > > I switch to schema owner, do the insert, then switch back
some tests after applying V33 and my small changes.
setup:
create table test_scalar1(js jsonb);
insert into test_scalar1 select jsonb '{"a":"[12,13]"}' FROM
generate_series(1,1e5) g;
create table test_scalar2(js jsonb);
insert into test_scalar2 select jsonb '{"a":12}' FROM generate_series(1,1e5)
On Fri, Jan 5, 2024 at 4:36 PM Tom Lane wrote:
> I don't think I believe this code change, let alone any of the
> explanations for it. The point of these Asserts is to be sure that
> we don't form an alleged parameterization set that includes any rels
> that are included in the new join, because
Hi Tomas,
> Another reason was that the algorithm described in the two papers you
> reference (1988 paper by DeWitt and the evaluation by Carlson and
> Sutherland from ~2010) is simple but has pretty obvious weaknesses. It
> processes the columns one by one - first build bucket on column "a",
>
On Fri, Jan 5, 2024 at 2:47 PM Andres Freund wrote:
> On 2024-01-04 17:37:27 -0500, Melanie Plageman wrote:
> > On Thu, Jan 4, 2024 at 3:03 PM Andres Freund wrote:
> > >
> > > On 2023-11-17 18:12:08 -0500, Melanie Plageman wrote:
> > > > @@ -972,20 +970,21 @@ lazy_scan_heap(LVRelState *vacrel)
>
On Fri, Oct 13, 2023 at 11:02:39AM +0200, Daniel Gustafsson wrote:
> That's a more compelling reason IMO. I'm not sure if I prefer the
> GUC_check_errdetail-like approach better, I would for sure not be opposed to
> reviewing a version of the patch doing it that way.
>
> Tung Nguyen: are you
Hi,
On 2024-01-05 15:57:23 +0100, Peter Eisentraut wrote:
> On 05.01.24 01:00, Matthias Kuhn wrote:
> > Attached a patch with a (hopefully) better wording of the comment.
> >
> > I have unsuccessfully tried to find an official source for this policy.
> > So for reference some discussions about
Robert Haas writes:
> On Fri, Nov 3, 2023 at 2:47 AM Richard Guo wrote:
>> Comment is now added above the Asserts. Thanks for taking an interest
>> in this.
> I'd like to suggest rewording this comment a little more. Here's my proposal:
> Both of the paths passed to this function are still
Hi,
On 2024-01-05 15:23:12 -0500, Robert Haas wrote:
> On Fri, Jan 5, 2024 at 3:05 PM Andres Freund wrote:
> > An aside:
> >
> > As I think we chatted about before, I eventually would like the option to
> > remove index entries for a tuple during on-access pruning, for OLTP
> > workloads. I.e.
On Fri, Jan 5, 2024 at 1:47 PM Robert Haas wrote:
>
> On Fri, Jan 5, 2024 at 12:59 PM Melanie Plageman
> wrote:
> MP> I am planning to add a VM update into the freeze record, at which point
> MP> I will move the VM update code into lazy_scan_prune(). This will then
> MP> allow us to consolidate
Hi,
On 2024-01-05 16:00:01 +0100, Peter Eisentraut wrote:
> On 01.01.24 06:25, Matthias Kuhn wrote:
> > It looks like meson does not currently support building for android, the
> > following output is what I get (but I have actually no experience with
> > meson):
> >
> > meson.build:320:2:
On Fri, Jan 5, 2024 at 3:05 PM Andres Freund wrote:
> OTOH, the pruning logic, including its WAL record, already supports marking
> items unused, all we need to do is to tell it to do so in a few more cases. If
> we didn't already need to have support for this, I'd a much harder time
> arguing
On Fri, Jan 5, 2024 at 3:16 PM Andres Freund wrote:
> On 2024-01-05 12:23:25 -0500, Robert Haas wrote:
> > I agree that in the memory-context case it might be worth expending
> > some more code to be more clever. But I probably wouldn't do that for
> > MemoryContextStats(); check_stack_depth()
On Thu, Mar 23, 2023 at 11:02 PM Kyotaro Horiguchi
wrote:
> [ new patch ]
Well, I guess nobody is too excited about fixing this, because it's
been another 10 months with no discussion. Andres doesn't even seem to
think this is as much a bug as it is a limitation, for all that it's
filed in the
Hi,
On 2024-01-05 12:23:25 -0500, Robert Haas wrote:
> I agree that in the memory-context case it might be worth expending
> some more code to be more clever. But I probably wouldn't do that for
> MemoryContextStats(); check_stack_depth() seems fine for that one.
We run MemoryContextStats() when
Hi,
On 2024-01-05 08:59:41 -0500, Robert Haas wrote:
> On Thu, Jan 4, 2024 at 6:03 PM Melanie Plageman
> wrote:
> > When a single page is being processed, page pruning happens in
> > heap_page_prune(). Freezing, dead items recording, and visibility
> > checks happen in lazy_scan_prune().
I wrote:
> "Kumar, Sachin" writes:
>> I was not able to find email thread which details why we are not using
>> parallel pg_restore for pg_upgrade.
> Well, it's pretty obvious isn't it? The parallelism is being applied
> at the per-database level instead.
On further reflection, there is a very
05.01.2024 02:48, Michael Paquier wrote:
On Thu, Jan 04, 2024 at 04:00:01PM +0300, Alexander Lakhin wrote:
Reproduced here.
Did you just make the run slow enough to show the failure with
valgrind?
Yes, I just run several test instances (with no extra modifications) under
Valgrind with
On Tue, Oct 24, 2023 at 4:28 AM Kyotaro Horiguchi
wrote:
> In the attached, fixed the existing two messages, and adjusted one
> message to display an error code, all in the consistent format.
Hi,
I'm not a Windows expert, but my guess is that 0001 is a very good
idea. I hope someone who is a
Hi,
On 2024-01-04 17:37:27 -0500, Melanie Plageman wrote:
> On Thu, Jan 4, 2024 at 3:03 PM Andres Freund wrote:
> >
> > On 2023-11-17 18:12:08 -0500, Melanie Plageman wrote:
> > > Assert(ItemIdIsNormal(lp));
> > > htup = (HeapTupleHeader) PageGetItem(dp, lp);
> > > @@
On Fri, Sep 15, 2023 at 7:47 AM Heikki Linnakangas wrote:
> Thinking about this some more, I think this is still not 100% correct,
> even with the patch I posted earlier:
This is marked as needing review, but that doesn't appear to be
correct, because there's this comment, indicating that the
On Mon, Aug 28, 2023 at 8:59 PM Jimmy Yih wrote:
> Thanks for the insightful response! I have attached an updated patch
> that moves the proposed logic to the end of StartupXLOG where it seems
> more correct to do this. It also helps with backporting (if it's
> needed) since the archiver process
Hi,
On 2024-01-05 14:19:23 -0500, Robert Haas wrote:
> On Fri, Jan 5, 2024 at 2:11 PM Andres Freund wrote:
> > I see it fairly regularly. Including finding several related bugs that lead
> > to
> > stuck systems last year (signal handlers are a menace).
>
> In that case, I think this proposal
Hi,
On 2024-01-05 10:20:39 +0800, Andy Fan wrote:
> Andres Freund writes:
> > On 2024-01-04 14:59:06 +0800, Andy Fan wrote:
> >> My question is if someone doesn't obey the rule by mistake (everyone
> >> can make mistake), shall we PANIC on a production environment? IMO I
> >> think it can be a
On Fri, Jan 5, 2024 at 2:11 PM Andres Freund wrote:
> I see it fairly regularly. Including finding several related bugs that lead to
> stuck systems last year (signal handlers are a menace).
In that case, I think this proposal is dead. I can't personally
testify to this code being a force for
On Fri, Nov 3, 2023 at 2:47 AM Richard Guo wrote:
> Comment is now added above the Asserts. Thanks for taking an interest
> in this.
I'd like to suggest rewording this comment a little more. Here's my proposal:
Both of the paths passed to this function are still parameterized by
the topmost
Hi,
On 2024-01-05 08:51:53 -0500, Robert Haas wrote:
> On Thu, Jan 4, 2024 at 6:06 PM Andres Freund wrote:
> > I think we should add infrastructure to detect bugs like this during
> > development, but not PANICing when this happens in production seems
> > completely
> > non-viable.
>
> I mean
Robert Haas writes:
> OK, so a few people like the current form of this patch but we haven't
> heard from Tom since August. Tom, any thoughts on the current
> incarnation?
Not yet, but it is on my to-look-at list. In the meantime I concur
with your comments here.
On Fri, Jan 5, 2024 at 12:59 PM Melanie Plageman
wrote:
> I actually think we are going to want to stop referring to these steps
> as pruning and vacuuming. It is confusing because vacuuming refers to
> the whole process of doing garbage collection on the table and also to
> the specific step of
Hi,
Zhang Mingli
www.hashdata.xyz
On Jan 6, 2024 at 01:38 +0800, Geoff Winkless , wrote:
>
> Am I missing some reason why the first set isn't sorted as I'd hoped?
Woo, it’s a complex order by, I try to understand your example.
And I think the order is right, what’s your expected order result?
On Tue, Dec 12, 2023 at 9:55 PM Andrei Lepikhov
wrote:
> By and large, this patch is in a good state and may be committed.
OK, so a few people like the current form of this patch but we haven't
heard from Tom since August. Tom, any thoughts on the current
incarnation?
Richard, I think it could
On Tue, Dec 5, 2023 at 1:35 PM Tristan Partin wrote:
> On Wed Nov 29, 2023 at 11:48 AM CST, Tristan Partin wrote:
> > I am not completely in love with the code I have written. Lots of
> > conditional compilation which makes it hard to read. Looking forward to
> > another round of review to see
On 1/5/24 12:56, Robert Haas wrote:
On Sun, Aug 27, 2023 at 4:25 PM Heikki Linnakangas wrote:
I think you got that it backwards. 'perl_locale_obj' is set to the perl
interpreter's locale, whenever we are *outside* the interpreter.
This thread has had no update for more than 4 months, so I'm
On Fri, Jan 5, 2024 at 8:59 AM Robert Haas wrote:
>
> On Thu, Jan 4, 2024 at 6:03 PM Melanie Plageman
> wrote:
> > When a single page is being processed, page pruning happens in
> > heap_page_prune(). Freezing, dead items recording, and visibility
> > checks happen in lazy_scan_prune().
On Sun, Aug 27, 2023 at 4:25 PM Heikki Linnakangas wrote:
> I think you got that it backwards. 'perl_locale_obj' is set to the perl
> interpreter's locale, whenever we are *outside* the interpreter.
This thread has had no update for more than 4 months, so I'm marking
the CF entry RwF for now.
On Thu, Oct 5, 2023 at 11:15 PM Tom Lane wrote:
> kuroda.keis...@nttcom.co.jp writes:
> > On 2023-06-14 15:31, vignesh C wrote:
> >> I have attempted to convert pg_get_indexdef() to use
> >> systable_beginscan() based on transaction-snapshot rather than using
> >> SearchSysCache().
>
> Has
On Sat, Dec 30, 2023 at 11:50 AM Joe Conway wrote:
> In the meantime, in case it helps, see
>
>https://github.com/pgaudit/set_user
>
> Specifically set_session_auth(text):
> -
> When set_session_auth(text) is called, the effective session and current
> user is switched to the
On Fri, Jan 05, 2024 at 10:42:03AM -0600, Nathan Bossart wrote:
> On Fri, Jan 05, 2024 at 07:39:39AM +, Bertrand Drouvot wrote:
>> + die "lists of predefined LWLocks in lwlocknames.txt and
>> wait_event_names.txt do not match"
>> + unless $wait_event_lwlocks[$i] eq $lockname;
>>
On Fri, Jan 5, 2024 at 12:35 PM Tom Lane wrote:
> I think it'd be quite simple. As I said, it's just a small variation
> on how some GUCs already work. The only thing that's really
> transactional is SQL-driven updates, which'd be disallowed for this
> class of variables.
Well, I know better
On Thu, Apr 13, 2023 at 2:04 PM Fujii Masao wrote:
> >> To clarify, are you suggesting that PQgetCancel() should
> >> only parse the parameters for TCP connections
> >> if cancel->raddr.addr.ss_family != AF_UNIX?
> >> If so, I think that's a good idea.
> >
> > You're right. I used connip in the
On 05/01/2024 11:37, vignesh C wrote:
> One of the tests was aborted at [1], kindly post an updated patch for
the same:
Thank you for notifying us.
I believe I fixed the issue but it is hard to be certain as the issue
did not arise when running the regression tests locally.
Regards,
We have some (generated) SQL that uses grouping sets to give us the
same data grouped in multiple ways (with sets of groups configurable
by the user), with the ordering of the rows the same as the grouping
set. This generally works fine, except for when one of the grouping
sets contains part of
Robert Haas writes:
> On Fri, Jan 5, 2024 at 11:53 AM Tom Lane wrote:
>> So my thought was that this should be implemented as an (unchangeable)
>> flag bit for a GUC variable, GUC_PROTOCOL_ONLY or something like that,
>> and then we would refuse SQL-based set attempts on that. The behavior
>>
On Fri, 5 Jan 2024 at 17:28, Robert Haas wrote:
> First, I don't see a reason to bump the protocol version. The whole
> reason for adding support for protocol options (_pq_.whatever) is so
> that we wouldn't have to change the protocol version to add new
> message types. At some point we may want
On Fri, Jan 5, 2024 at 12:20 PM Jelte Fennema-Nio wrote:
> They are not fundamentally transactional afaict based on the changes
> that were needed so far. It makes sense too, because e.g. SIGHUP
> should change the GUC value if the config changed no matter if the
> current transaction aborts or
On Fri, Nov 24, 2023 at 10:47 AM Heikki Linnakangas wrote:
> What do you think?
At least for 0001 and 0002, I think we should just add the stack depth checks.
With regard to 0001, CommitTransactionCommand() and friends are hard
enough to understand as it is; they need "goto" like I need an
On Fri, 5 Jan 2024 at 18:08, Robert Haas wrote:
> On Fri, Jan 5, 2024 at 11:53 AM Tom Lane wrote:
> > There is a lot of infrastructure we'll have to re-invent if
> > we make this completely independent of GUCs, notably:
> > * a way to establish the initial/default value
> > * a way to display
On Fri, Jan 5, 2024 at 11:53 AM Tom Lane wrote:
> There is a lot of infrastructure we'll have to re-invent if
> we make this completely independent of GUCs, notably:
> * a way to establish the initial/default value
> * a way to display the active value
>
> So my thought was that this should be
On Thu, Nov 9, 2023 at 10:32 PM Thomas Munro wrote:
> Here is a new attempt to fix this mess. Disclaimer: this based
> entirely on reading the manual and vicariously hacking a computer I
> don't have via CI.
I'd first like to congratulate this thread on reaching its second
birthday. The
On Fri, Jan 05, 2024 at 09:03:39AM +0700, John Naylor wrote:
> On Wed, Jan 3, 2024 at 10:29 PM Nathan Bossart
> wrote:
>> If the requirement is that normal builds use AVX2, then I fear we will be
>> waiting a long time. IIUC the current proposals (building multiple
>> binaries or adding a
Robert Haas writes:
> Second, I don't really like the idea of selectively turning GUCs into
> protocol-managed parameters. I think there are a relatively small
> number of things that we'd ever want to manage on a protocol level,
> but this design would force us to make it work for any GUC
Thanks for reviewing.
On Fri, Jan 05, 2024 at 07:39:39AM +, Bertrand Drouvot wrote:
> Another option could be to create a sub-section for predefined LWLocks that
> are
> part of lwlocknames.txt and then sort both list (the one in the sub-section
> and
> the one in lwlocknames.txt). That
On Fri, Jan 05, 2024 at 04:18:49PM +0900, Michael Paquier wrote:
> Putting that in contrib/ has a lot of extra cost. One is
> documentation and more complexity regarding versioning when it comes
> to upgrading it to a new version. I don't think that it is a good
> idea to deal with this extra
On Fri, Jan 5, 2024 at 10:14 AM Jelte Fennema-Nio wrote:
> New patchset attached, where I split up the patches in smaller logical units.
> Note that the first 4 patches in this series are not making any
> protocol changes. All they do is set up infrastructure in the code
> that allows us to make
On Fri, Jan 05, 2024 at 08:38:22AM +0900, Michael Paquier wrote:
> On Thu, Jan 04, 2024 at 04:31:02PM -0600, Nathan Bossart wrote:
>> Rather than defining a module somewhere that tests would need to load,
>> should we just put the common callbacks in the core server? Unless there's
>> a strong
This thread has gone for about a year here without making any
progress, which isn't great.
On Tue, Feb 7, 2023 at 2:49 PM Andres Freund wrote:
> Hm. It's worrysome to now hold ProcArrayLock exclusively while iterating over
> the slots. ReplicationSlotsComputeRequiredXmin() can be called at a
>
Hi!
I've meant exactly the thing you mentioned -
>
> > By queries you mean particular queries, not transactions? And since
> > they have an assigned ID it means that the query is already executing
> > and we want to enable the tracking in another session, right?
>
> I think that was the idea.
New patchset attached, where I split up the patches in smaller logical units.
Note that the first 4 patches in this series are not making any
protocol changes. All they do is set up infrastructure in the code
that allows us to make protocol changes in the future.
I hope that those 4 should all be
On 01.01.24 06:25, Matthias Kuhn wrote:
It looks like meson does not currently support building for android, the
following output is what I get (but I have actually no experience with
meson):
meson.build:320:2: ERROR: Problem encountered: unknown host system:
android
FWIW, the meson
On 05.01.24 01:00, Matthias Kuhn wrote:
Attached a patch with a (hopefully) better wording of the comment.
I have unsuccessfully tried to find an official source for this policy.
So for reference some discussions about the topic:
-
On Thu, Jan 4, 2024 at 7:00 PM Matthias Kuhn wrote:
> Attached a patch with a (hopefully) better wording of the comment.
>
> I have unsuccessfully tried to find an official source for this policy.
> So for reference some discussions about the topic:
>
> -
>
Hi,
I discovered that my patch to add WAL summarization added two new
SQL-callable functions but failed to document them. 0001 fixes that.
An outstanding item from the original thread was to write a better
test for the not-yet-committed pg_walsummary utility. But I discovered
that I couldn't do
On Thu, Jan 4, 2024 at 6:03 PM Melanie Plageman
wrote:
> When a single page is being processed, page pruning happens in
> heap_page_prune(). Freezing, dead items recording, and visibility
> checks happen in lazy_scan_prune(). Visibility map updates and
> freespace map updates happen back in
On Thu, Jan 4, 2024 at 6:06 PM Andres Freund wrote:
> I think we should add infrastructure to detect bugs like this during
> development, but not PANICing when this happens in production seems completely
> non-viable.
I mean +1 for the infrastructure, but "completely non-viable"? Why?
I've only
On Fri, Jan 5, 2024 at 4:25 PM Dilip Kumar wrote:
>
> On Fri, Jan 5, 2024 at 8:59 AM shveta malik wrote:
> >
> I was going the the patch set again, I have a question. The below
> comments say that we keep the failover option as PENDING until we have
> done the initial table sync which seems
On Fri, Jan 5, 2024 at 6:54 PM John Naylor wrote:
>
> On Thu, Jan 4, 2024 at 10:01 AM jian he wrote:
> >
> > I still cannot git apply your patch cleanly. in
>
> I don't know why you're using that -- the git apply man page even says
>
> "Use git-am(1) to create commits from patches generated by
>
On Wed, Jan 03, 2024 at 12:56:58AM -0500, Tom Lane wrote:
> Yeah. A quick grep shows that we have 16 uses of "vertices" and
> only this one of "vertexes". It's not really wrong, but +1 for
> making it match the others.
Applied this one as 793ecff7df80 on HEAD.
> I'd leave this alone, it's not
On Fri, Jan 5, 2024 at 8:59 AM shveta malik wrote:
>
I was going the the patch set again, I have a question. The below
comments say that we keep the failover option as PENDING until we have
done the initial table sync which seems fine. But what happens if we
add a new table to the publication
On Thu, Jan 4, 2024 at 10:01 AM jian he wrote:
>
> I still cannot git apply your patch cleanly. in
I don't know why you're using that -- the git apply man page even says
"Use git-am(1) to create commits from patches generated by
git-format-patch(1) and/or received by email."
Or, if that fails,
Hi,
On Fri, 5 Jan 2024 at 02:25, Jim Nasby wrote:
>
> On 1/4/24 2:23 PM, Andres Freund wrote:
>
> On 2024-01-02 12:36:18 -0500, Melanie Plageman wrote:
>
> Subject: [PATCH v2 1/6] lazy_scan_skip remove unnecessary local var rel_pages
> Subject: [PATCH v2 2/6] lazy_scan_skip remove unneeded local
On Mon, 20 Nov 2023 at 10:00, Amit Langote wrote:
>
> On Thu, Sep 28, 2023 at 5:26 PM Amit Langote wrote:
> > On Tue, Sep 26, 2023 at 10:06 PM Amit Langote
> > wrote:
> > > After sleeping on this, I think we do need the checks after all the
> > > ExecInitNode() calls too, because we have many
On Fri, Jan 5, 2024 at 1:34 PM Jeff Davis wrote:
>
> On Fri, 2024-01-05 at 12:49 +0530, Ashutosh Bapat wrote:
> > Can you please provide an example using postgres_fdw to create a
> > subscription using this patch. I think we should document it in
> > postgres_fdw and add a test for the same.
>
>
On Tue, 21 Nov 2023 at 01:47, Schoemans Maxime wrote:
>
> On 14/11/2023 20:46, Tom Lane wrote:
> > I took a brief look through this very interesting work. I concur
> > with Tomas that it feels a little odd that range join selectivity
> > would become smarter than scalar inequality join
On Wed, 22 Nov 2023 at 13:01, Kyotaro Horiguchi wrote:
>
> Anyway, this requires rebsaing, and done.
Few tests are failing at [1], kindly post an updated patch:
/tmp/cirrus-ci-build/src/test/recovery --testgroup recovery --testname
039_end_of_wal -- /usr/local/bin/perl -I
Dear Euler,
I love your proposal, so I want to join the review. Here are my first comments.
01.
Should we restrict that `--subscriber-conninfo` must not have hostname or IP?
We want users to execute pg_subscriber on the target, right?
02.
When the application was executed, many outputs filled
Le 04/01/2024 à 23:41, Jim Nasby a écrit :
On 1/3/24 5:57 PM, Cedric Villemain wrote:
for 15 years pgfincore has been sitting quietly and being used in
large setups to help in HA and resources management.
It can perfectly stay as is, to be honest I was expecting to one day
include a windows
On Tue, Dec 12, 2023 at 4:15 PM Michael Paquier wrote:
>
> On Tue, Dec 12, 2023 at 10:27:09AM +0530, Dilip Kumar wrote:
> > Oops, I only included the code changes where I am adding injection
> > points and some comments to verify that, but missed the actual test
> > file. Attaching it here.
>
> I
On Fri, Jan 5, 2024 at 12:05 AM vignesh C wrote:
>
> On Thu, 28 Dec 2023 at 09:27, jian he wrote:
> >
> > On Wed, Dec 20, 2023 at 8:27 PM Masahiko Sawada
> > wrote:
> > >
> > >
> > > Why do we need to use SPI? I think we can form heap tuples and insert
> > > them to the error table. Creating
Hi,
On Fri, Jan 05, 2024 at 10:00:53AM +0530, Amit Kapila wrote:
> On Fri, Jan 5, 2024 at 8:59 AM shveta malik wrote:
> >
> > On Thu, Jan 4, 2024 at 7:24 PM Bertrand Drouvot
> > wrote:
> > >
> > > 4 ===
> > >
> > > Looking closer, the only place where walrcv_connect() is called with
> > >
On Fri, 2024-01-05 at 12:49 +0530, Ashutosh Bapat wrote:
> Can you please provide an example using postgres_fdw to create a
> subscription using this patch. I think we should document it in
> postgres_fdw and add a test for the same.
There's a basic test for postgres_fdw in patch 0003, just
82 matches
Mail list logo
