On Fri, Feb 04, 2022 at 01:38:14PM -0500, Bruce Momjian wrote:
> On Thu, Feb 3, 2022 at 12:28:05PM +0800, Julien Rouhaud wrote:
>
> > One thing that might help would be to work on a troubleshooting section on
> > the
> > wiki with some common problems and some clear instructions on either how
On Fri, Feb 04, 2022 at 12:45:05PM +0100, Pavel Stehule wrote:
>
> ok, I don't have any problem with it. Then there is not necessarily any
> change, and I'll mark this patch as ready for committer.
Thanks Pavel!
I also realized that the CF entry description wasn't accurate anymore, so I
also
On Fri, Feb 4, 2022 at 10:44 PM Peter Geoghegan wrote:
> Right - it's practically inevitable that you'll need an
> anti-wraparound VACUUM to advance relfrozenxid right now. Technically
> it's possible to advance relfrozenxid in any VACUUM, but in practice
> it just never happens on a large table.
On Fri, Feb 4, 2022 at 10:21 PM Greg Stark wrote:
> On Wed, 15 Dec 2021 at 15:30, Peter Geoghegan wrote:
> > My emphasis here has been on making non-aggressive VACUUMs *always*
> > advance relfrozenxid, outside of certain obvious edge cases. And so
> > with all the patches applied, up to and
On Wed, 15 Dec 2021 at 15:30, Peter Geoghegan wrote:
>
> My emphasis here has been on making non-aggressive VACUUMs *always*
> advance relfrozenxid, outside of certain obvious edge cases. And so
> with all the patches applied, up to and including the opportunistic
> freezing patch, every
On Sat, Feb 5, 2022 at 12:54 PM Robert Haas wrote:
> On Fri, Feb 4, 2022 at 4:24 PM Thomas Munro wrote:
> > I'm not proposing we change our default to this new level, because it
> > doesn't work on non-NTFS, an annoying complication. This patch would
> > just provide something faster to put
+ PG_RETURN_FULLTRANSACTIONID((U64FromFullTransactionId(fxid1) >
U64FromFullTransactionId(fxid2)) ? fxid1 : fxid2);
Shouldn't we use FullTransactionIdFollows() to compare those two fxid
values here, instead?
+ PG_RETURN_FULLTRANSACTIONID((U64FromFullTransactionId(fxid1) <
On Fri, Feb 4, 2022 at 9:06 PM Alvaro Herrera wrote:
>
> I don't have a reason not to commit this patch.
>
It is not very clear to me from this so just checking again, are you
fine with back-patching this as well?
>
> I have some suggestions
> on the comments and docs though.
>
Thanks, your
Hi,
It looks to me as if the transforms feature for PLs was added in
cac7658, and support was added to plperl and plpython at that time,
with documentation added for CREATE FUNCTION, CREATE/DROP TRANSFORM,
and the catalogs, but nothing was added at that time to plhandler.sgml
to clarify that a PL
On Fri, Feb 4, 2022 at 4:24 PM Thomas Munro wrote:
> I'm not proposing we change our default to this new level, because it
> doesn't work on non-NTFS, an annoying complication. This patch would
> just provide something faster to put after "Alternatively".
Hmm. I thought NTFS had kind of won the
Nathan Bossart writes:
> On Fri, Feb 04, 2022 at 05:12:43PM -0500, Tom Lane wrote:
>> On the whole I'm kind of allergic to inventing an entire new concept
>> that has as much overlap with extensions as modules seem to. I'd
>> rather try to understand what functional requirements we're missing
>>
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= writes:
> Tom Lane writes:
>>> We could do something hacky like matching case only when there's
>>> no longer any matching object names, but that might be too magic.
>> I experimented with that, and it actually doesn't seem as weird
>> as I feared. See
On Fri, Feb 04, 2022 at 05:12:43PM -0500, Tom Lane wrote:
> If we invent modules I think they need to work more like extensions
> naming-wise, ie they group objects but have no effect for naming.
> Alternatively, you could insist that a module *is* a schema for naming
> purposes, with some extra
On Fri, Feb 4, 2022 at 5:12 PM Tom Lane wrote:
>
> On the whole I'm kind of allergic to inventing an entire new concept
> that has as much overlap with extensions as modules seem to. I'd
> rather try to understand what functional requirements we're missing
> and see if we can add them to
On Thu, Feb 3, 2022 at 7:30 PM Robert Haas wrote:
>
> That error comes from GetNewTransactionId(), so that function must
> either try to execute DML or do something else which causes an XID to
> be assigned. I think a plain SELECT should work just fine.
It was indeed doing writes, so that much
On Fri, Feb 04, 2022 at 09:17:54AM -0500, Robert Haas wrote:
> On Fri, Feb 4, 2022 at 9:05 AM Ashutosh Bapat
> wrote:
>> And it gives some surprising results as well
>> ---
>> #select pg_walfile_name('0/0'::pg_lsn);
>> pg_walfile_name
>> --
>>
On Fri, Feb 4, 2022 at 4:18 PM Robert Haas wrote:
> On Fri, Feb 4, 2022 at 3:31 PM Peter Geoghegan wrote:
> > Application B will already block pruning by VACUUM operations against
> > application A's table, and so effectively blocks recording of the
> > resultant free space in the FSM in your
Alvaro Herrera writes:
> He said:
>> [ This patch ] [...] allows for 3-part (or 4 with the database name)
>> naming of objects within the module.
> He then showed the following example:
>> CREATE SCHEMA foo;
>> CREATE MODULE foo.bar
>> CREATE FUNCTION hello() [...]
>> SELECT foo.bar.hello();
Justin Pryzby writes:
> On Fri, Feb 04, 2022 at 04:29:19PM -0500, Tom Lane wrote:
>> I'm confused about this bit. Are we still building bogus stats for
>> inheritance parents, or has that stopped?
> To make a long story long:
> - before 859b3003de, an ERROR occurred when a stats object was
On 2022-Feb-04, Swaha Miller wrote:
> The POC patch Jim Mlodgenski had on that thread was similar to your
> proposed way - modules were rows in pg_namespace, with the addition of
> a new column in pg_namespace for the nspkind (module or schema.)
I don't agree that what he proposed was similar to
On Fri, Feb 04, 2022 at 04:29:19PM -0500, Tom Lane wrote:
> > + A previous bug fix disabled building of extended statistics for
> > + old-style inheritance trees, but any existing statistics data was
> > + not removed, and that data would become more and more out-of-date
> > +
Michael Banck writes:
> On Fri, Feb 04, 2022 at 02:58:59PM -0500, Tom Lane wrote:
>> + If this seems to have affected a table, REINDEX
>> + should repair the damage.
> I don't think this is very helpful to the reader, are their indexes
> corrupt or not? If we can't tell them a specific
Justin Pryzby writes:
> On Fri, Feb 04, 2022 at 02:58:59PM -0500, Tom Lane wrote:
>> Please send comments/corrections by Sunday.
[ assorted comments ]
Thanks for the corrections.
> + A previous bug fix disabled building of extended statistics for
> + old-style inheritance trees, but
Christoph Heiss wrote:
As part of a customer project we are looking to implement an reloption for
views which when set, runs the subquery as invoked by the user rather than the
view owner, as is currently the case.
The rewrite rule's table references are then checked as if the user were
On Fri, Feb 04, 2022 at 02:58:59PM -0500, Tom Lane wrote:
> I've pushed the first draft for $SUBJECT at
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ab22eea83169c8d0eb15050ce61cbe3d7dae4de6
>
> Please send comments/corrections by Sunday.
> +
> + Fix
On Fri, Feb 4, 2022 at 1:54 PM Robert Haas wrote:
> > The constantly modified index will be entirely dependent on index
> > vacuuming here, and so an improved VACUUM design that allows that
> > particular index to be vacuumed more frequently could really improve
> > performance.
>
> Thanks for
On Sat, Feb 5, 2022 at 2:10 AM Robert Haas wrote:
> So my impression is that today we ship defaults that are unsafe on
> Windows. I don't really understand much of what you are saying here,
> but if there's a way we can stop doing that, +1 from me, especially if
> it allows us to retain
On Fri, Feb 4, 2022 at 3:31 PM Peter Geoghegan wrote:
> Application B will already block pruning by VACUUM operations against
> application A's table, and so effectively blocks recording of the
> resultant free space in the FSM in your scenario. And so application A
> and application B should be
On Fri, Feb 4, 2022 at 3:18 PM Robert Haas wrote:
> > What about recovery conflicts? Index vacuuming WAL records don't
> > require their own latestRemovedXid field, since they can rely on
> > earlier XLOG_HEAP2_PRUNE records instead. Since the TIDs that index
> > vacuuming removes always point to
On Fri, Feb 4, 2022 at 10:46 AM Bruce Momjian wrote:
> On Wed, Feb 2, 2022 at 06:28:30PM -0800, Swaha Miller wrote:
> > Hi,
> >
> > I'm following up from Jim's POC for adding MODULE to PostgreSQL. [1]
> >
> > My proposal implements modules as schema objects to be stored in a new
> > system
On Fri, Feb 04, 2022 at 02:58:59PM -0500, Tom Lane wrote:
> I've pushed the first draft for $SUBJECT at
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ab22eea83169c8d0eb15050ce61cbe3d7dae4de6
>
> Please send comments/corrections by Sunday.
+
+ Build extended
On Thu, Feb 3, 2022 at 5:42 PM Alvaro Herrera
wrote:
> On 2022-Feb-03, Pavel Stehule wrote:
>
> > The biggest problem is coexistence of Postgres's SEARCH_PATH object
> > identification, and local and public scopes used in MODULEs or in
> Oracle's
> > packages.
> >
> > I can imagine MODULES as
On Fri, Feb 4, 2022 at 2:45 PM Robert Haas wrote:
> While I agree that there's some case to be made for leaving settled
> pages well enough alone, your criterion for settled seems pretty much
> accidental.
I fully admit that I came up with the FSM heuristic with TPC-C in
mind. But you have to
On Fri, Feb 4, 2022 at 3:13 PM Nathan Bossart wrote:
> On Fri, Feb 04, 2022 at 08:46:39AM -0500, Robert Haas wrote:
> > For multixact.c, I think you should invent GetMaxOldestSlot() to avoid
> > confusion. Maybe it could be a static inline rather than a macro.
> >
> > Likewise, I think
On Fri, Feb 4, 2022 at 3:05 PM Greg Stark wrote:
> Whatever happened to the idea to "rotate" the work of vacuum. So all
> the work of the second pass would actually be deferred until the first
> pass of the next vacuum cycle.
>
> That would also have the effect of eliminating the duplicate work,
On Fri, Feb 4, 2022 at 2:16 PM Peter Geoghegan wrote:
> On Thu, Feb 3, 2022 at 12:20 PM Robert Haas wrote:
> > But maybe we should reconsider. What benefit do we get out of dirtying
> > the page twice like this, writing WAL each time? What if we went back
> > to the idea of having the first heap
> On 4 Feb 2022, at 21:03, Stephen Frost wrote:
> I wonder about the 'not in tree' bit since it is in the header files,
> certainly for NSPR which I've been poking at due to this discussion.
What I meant was that the documentation on the website isn't published from
documentation source code
On Fri, Feb 04, 2022 at 08:46:39AM -0500, Robert Haas wrote:
> For multixact.c, I think you should invent GetMaxOldestSlot() to avoid
> confusion. Maybe it could be a static inline rather than a macro.
>
> Likewise, I think PROCARRAY_MAXPROCS, NumProcSignalSlots, and
> NumBackendStatSlots should
On Thu, 3 Feb 2022 at 12:21, Robert Haas wrote:
>
> VACUUM's first pass over the heap is implemented by a function called
> lazy_scan_heap(), while the second pass is implemented by a function
> called lazy_vacuum_heap_rel(). This seems to imply that the first pass
> is primarily an examination
Greetings,
* Daniel Gustafsson (dan...@yesql.se) wrote:
> I am writing done above in quotes, since the documentation also needs to be
> updated, completed, rewritten, organized etc etc. The above is an import of
> what was found, and is in a fairly poor state. Unfortunately, it's still not
> in
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote:
> > As a philosophical matter, I don't think it's great for us - or the
> > Internet in general - to be too dependent on OpenSSL. Software
> > monocultures are not great, and
I've pushed the first draft for $SUBJECT at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=ab22eea83169c8d0eb15050ce61cbe3d7dae4de6
Please send comments/corrections by Sunday.
regards, tom lane
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Feb 3, 2022 at 01:42:53PM -0500, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> > > > There's
> On 4 Feb 2022, at 19:22, Bruce Momjian wrote:
>
> On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote:
>> As a philosophical matter, I don't think it's great for us - or the
>> Internet in general - to be too dependent on OpenSSL. Software
>> monocultures are not great, and OpenSSL has
On Sat, Jan 29, 2022 at 11:43 PM Peter Geoghegan wrote:
> When VACUUM sees that all remaining/unpruned tuples on a page are
> all-visible, it isn't just important because of cost control
> considerations. It's deeper than that. It's also treated as a
> tentative signal from the application
On Fri, Feb 4, 2022 at 2:00 PM John Naylor wrote:
> Without having looked at the latest patches, there was something in
> the back of my mind while following the discussion upthread -- the
> proposed opportunistic freezing made a lot more sense if the
> earlier-proposed open/closed pages concept
Tomas Vondra writes:
> I've been doing some experiments with compilers, and I've noticed that
> when using clang configure still ends up setting
> GCC='yes'
> which seems somewhat strange.
I'm pretty sure that's intentional. clang tries to be a gcc-alike,
and mostly succeeds, other than
Hi,
I've been doing some experiments with compilers, and I've noticed that
when using clang configure still ends up setting
GCC='yes'
which seems somewhat strange. FWIW I've noticed because when building
with "-Ofast" (yeah, I'm just playing with stuff) it fails like this:
checking
On Thu, Feb 3, 2022 at 12:20 PM Robert Haas wrote:
> But maybe we should reconsider. What benefit do we get out of dirtying
> the page twice like this, writing WAL each time? What if we went back
> to the idea of having the first heap pass be read-only?
What about recovery conflicts? Index
On Sat, Jan 29, 2022 at 11:43 PM Peter Geoghegan wrote:
>
> On Thu, Jan 20, 2022 at 2:00 PM Peter Geoghegan wrote:
> > I do see some value in that, too. Though it's not going to be a way of
> > turning off the early freezing stuff, which seems unnecessary (though
> > I do still have work to do
On Fri, Feb 4, 2022 at 1:46 PM Peter Geoghegan wrote:
> That should work. All you need is a table with several indexes, and a
> workload consisting of updates that modify a column that is the key
> column for only one of the indexes. I would expect bottom-up index
> deletion to be 100% effective
On Fri, Feb 4, 2022 at 1:15 PM Robert Haas wrote:
> My second thought was that perhaps we can create a test scenario
> where, in one index, the deduplication and bottom-up index deletion
> and kill_prior_tuple mechanisms are very effective, and in another
> index, it's not effective at all. For
On Wed, Feb 2, 2022 at 06:28:30PM -0800, Swaha Miller wrote:
> Hi,
>
> I'm following up from Jim's POC for adding MODULE to PostgreSQL. [1]
>
> My proposal implements modules as schema objects to be stored in a new
> system catalog pg_module with new syntax for CREATE [OR REPLACE] MODULE,
You
On Fri, Feb 4, 2022 at 01:33:00PM -0500, Robert Haas wrote:
> > I don't think it is fair to be criticizing OpenSSL for its mediocre
> > documentation when the alternative being considered, NSS, has no public
> > documentation. Can the source-code-defined NSS documentation be
> > considered
On Thu, Feb 3, 2022 at 12:28:05PM +0800, Julien Rouhaud wrote:
> Hi,
>
> On Wed, Feb 02, 2022 at 07:35:36PM -0500, Bruce Momjian wrote:
> > The Postgres community is great at diagnosing problems and giving users
> > feedback. In most cases, we can either diagnose a problem and give a
> > fix,
On Wed, Feb 2, 2022 at 07:21:19PM -0700, David G. Johnston wrote:
> On Wed, Feb 2, 2022 at 5:35 PM Bruce Momjian wrote:
>
> I consider these as problems that need digging to find the cause, and
> users are usually unable to do sufficient digging, and we don't have
> time to give
On Fri, Feb 4, 2022 at 1:22 PM Bruce Momjian wrote:
> On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote:
> > As a philosophical matter, I don't think it's great for us - or the
> > Internet in general - to be too dependent on OpenSSL. Software
> > monocultures are not great, and OpenSSL
On Thu, Feb 3, 2022 at 02:33:37PM -0500, Robert Haas wrote:
> As a philosophical matter, I don't think it's great for us - or the
> Internet in general - to be too dependent on OpenSSL. Software
> monocultures are not great, and OpenSSL has near-constant security
> updates and mediocre
On Wed, Jan 26, 2022 at 8:58 AM Dilip Kumar wrote:
> TODO:
> - This is just a POC patch to discuss the design idea and needs a lot
> of improvement and testing.
> - We are using a slightly different format for storing the dead tids
> into the conveyor belt which is explained in the patch but the
On Thu, Feb 3, 2022 at 01:42:53PM -0500, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> > > There's https://hg.mozilla.org/projects/nspr/file/tip/pr/src - which is I
> > > think the upstream
On Sat, Jan 22, 2022 at 4:33 AM Hsu, John wrote:
>
>> I might be missing something but isn’t it okay even if the new primary
>> server is behind the subscribers? IOW, even if two slot's LSNs (i.e.,
>> restart_lsn and confirm_flush_lsn) are behind the subscriber's remote
>> LSN
On Thu, 2022-02-03 at 16:23 +0900, Kyotaro Horiguchi wrote:
> At Wed, 2 Feb 2022 19:46:13 +, Jacob Champion
> wrote in
> > On Mon, 2022-01-31 at 17:29 +0900, Kyotaro Horiguchi wrote:
> > > +#define PGSQL_AF_INET (AF_INET + 0)
> > > +#define PGSQL_AF_INET6 (AF_INET + 1)
> > > +
> > >
> > >
On Fri, Feb 4, 2022 at 11:19 AM Peter Geoghegan wrote:
>
> On Thu, Feb 3, 2022 at 7:08 PM John Naylor
> wrote:
> > Is this a TODO candidate? What would be a succinct title for it?
>
> I definitely think that it's worth working on. I suppose it follows
> that it should go on the TODO list.
On Thu, Feb 3, 2022 at 7:08 PM John Naylor wrote:
> Is this a TODO candidate? What would be a succinct title for it?
I definitely think that it's worth working on. I suppose it follows
that it should go on the TODO list.
--
Peter Geoghegan
On Wed, 2022-02-02 at 18:23 +0100, Christoph Heiss wrote:
> > Huh? "duff" has no permission to insert into "tab"!
> That really should not happen, thanks for finding that and helping me
> investigating on how to fix that!
>
> This is now solved by checking the security_invoker property on the
I don't have a reason not to commit this patch. I have some suggestions
on the comments and docs though.
> @@ -8359,14 +8408,15 @@ log_heap_new_cid(Relation relation, HeapTuple tup)
> * Returns NULL if there's no need to log an identity or if there's no
> suitable
> * key defined.
> *
> -
On 2022/02/03 16:45, Ken Kato wrote:
Hi hackers,
Unlike xid, xid8 increases monotonically and cannot be reused.
This trait makes it possible to support min() and max() aggregate functions for
xid8.
I thought they would be useful for monitoring.
So I made a patch for this.
Thanks for the
On Fri, Feb 04, 2022 at 09:53:09AM -0500, Robert Haas wrote:
> On Fri, Feb 4, 2022 at 9:48 AM Julien Rouhaud wrote:
> > I guess the idea was to have a compromise between letting rmgr authors
> > choose
> > arbitrary ids to avoid any conflicts, especially with private
> > implementations,
> >
On Fri, Feb 4, 2022 at 9:48 AM Julien Rouhaud wrote:
> I guess the idea was to have a compromise between letting rmgr authors choose
> arbitrary ids to avoid any conflicts, especially with private implementations,
> without wasting too much memory. But those approaches would be pretty much
>
Hi,
On Fri, Feb 04, 2022 at 09:10:42AM -0500, Robert Haas wrote:
> On Thu, Feb 3, 2022 at 12:34 AM Julien Rouhaud wrote:
> > I agree that having dozen of custom rmgrs doesn't seem likely, but I also
> > have
> > no idea of how much overhead you get by not doing a direct array access. I
> >
On Fri, Feb 4, 2022 at 9:05 AM Ashutosh Bapat
wrote:
> And it gives some surprising results as well
> ---
> #select pg_walfile_name('0/0'::pg_lsn);
> pg_walfile_name
> --
> 000100FF
> (1 row)
>
Yeah, that seems wrong.
--
Robert Haas
EDB:
On Thu, Feb 3, 2022 at 12:34 AM Julien Rouhaud wrote:
> I agree that having dozen of custom rmgrs doesn't seem likely, but I also have
> no idea of how much overhead you get by not doing a direct array access. I
> think it would be informative to benchmark something like simple OLTP write
>
Hi All,
pg_walfile_name() returns the WAL file name corresponding to the given
WAL location. Per
https://www.postgresql.org/docs/14/functions-admin.html
---
pg_walfile_name ( lsn pg_lsn ) → text
Converts a write-ahead log location to the name of the WAL file
holding that location.
---
The
On Fri, Feb 4, 2022 at 12:55 AM Nathan Bossart wrote:
> Here is a new patch with fewer calls to GetMaxBackends().
For multixact.c, I think you should invent GetMaxOldestSlot() to avoid
confusion. Maybe it could be a static inline rather than a macro.
Likewise, I think PROCARRAY_MAXPROCS,
On Sun, Dec 12, 2021 at 4:32 PM Thomas Munro wrote:
> One reason to consider developing this further is the problem
> discussed in the aptly named thread "Loaded footgun open_datasync on
> Windows"[1] (not the problem that was fixed in pg_test_fsync, but the
> problem with cache control, or lack
On Thu, Feb 3, 2022 at 5:24 PM Amit Kapila wrote:
>
> On Thu, Feb 3, 2022 at 8:18 AM Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > Tom, is it okay for you if I go ahead with this patch after some testing?
> >
> > I've been too busy to get back to it, so sure.
> >
>
> Thanks. I have tested
On Mon, Jan 31, 2022 at 9:03 AM Dilip Kumar wrote:
>
> >
> > I have changed this and various other comments in the patch. I have
> > modified the docs as well to reflect the changes. I thought of adding
> > a test but I think the current test in toast.sql seems sufficient.
> > Kindly let me know
pá 4. 2. 2022 v 10:36 odesílatel Julien Rouhaud napsal:
> Hi,
>
> On Wed, Feb 02, 2022 at 07:49:41PM +0100, Pavel Stehule wrote:
> >
> > I checked this trivial patch, and I don't see any problem. Again I run
> > check-world with success. The documentation for this feature is not
> > necessary.
"David G. Johnston" writes:
> On Monday, November 15, 2021, Tatsuro Yamada
> wrote:
>
> I don't know if this is a good example, but if you look at
> StackOverflow,
> it seems that people who want to see a list of constraints appear
> regularly.
>
>
Hi,
> > Could you please elaborate on this idea ?
> > So we have pgStatActiveTime and pgStatIdleInTransactionTime ultimately
> > used to report respective metrics in pg_stat_database.
> > Now beentry's st_total_active_time / st_total_transaction_idle_time
> > duplicates this info, so one may get
Hi,
On Wed, Feb 02, 2022 at 07:49:41PM +0100, Pavel Stehule wrote:
>
> I checked this trivial patch, and I don't see any problem. Again I run
> check-world with success. The documentation for this feature is not
> necessary. But I am not sure about regress tests. Without any other code,
>
81 matches
Mail list logo
