oundary. Prior to the corrupting action the values were
all unique.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
cted. At least, rerunning the test after
adjusting the expected output, I no longer see problems.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 17, 2024, at 12:10 PM, Mark Dilger
> wrote:
>
>> Amcheck with checkunique option does check uniqueness violation between
>> pages. But it doesn't warranty detection of cross page uniqueness violations
>> in extremely rare cases when the first equal i
t the uniqueness checking code is broken. Can you take a look?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 17, 2024, at 3:11 AM, Alexander Korotkov wrote:
>
> On Mon, May 13, 2024 at 4:42 AM Alexander Korotkov
> wrote:
>> On Mon, May 13, 2024 at 12:23 AM Alexander Korotkov
>> wrote:
>>> On Sat, May 11, 2024 at 4:13 AM Mark Dilger
>>> wrote:
>
n the old and new versions of
the code, and I think I'm within reason to ask if it was wrong before the
patch, wrong after the patch, or something else? Is this a bug being
introduced, being fixed, or ... ?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
otice that the need to reorder this initialization, and depending on
various factors including compiler flags they might not get an error.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
state->target is created, checked, and
free'd, and then the old state->target gets processed in the downlink check and
thereafter. This is either introducing a bug, or fixing one, but the commit
message is totally ambiguous about whether this is a bugfix or a code cleanup
o
oes implement those two functions and does use the
TBMIterateResult *tbmres argument, yes. I would deal with the issue in very
much the same way that your patches modify heapam. I don't really have any
additional comments about that.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
k per block. Thus, this table AM function
> must change its meaning.
>
> I think the way the patches are split up could be improved. I will
> think more about this. There are also probably a few mistakes with
> which comments are updated in which patches in the se
> On Jan 29, 2024, at 7:35 AM, Isaac Morland wrote:
>
> On Mon, 29 Jan 2024 at 10:31, Mark Dilger
> wrote:
>
> -Infinity for refactoring the entire codebase and backpatching.
>
> I don't think anybody is proposing re-working the existing codebase. I
> under
> On Jan 29, 2024, at 7:03 AM, Jelte Fennema-Nio wrote:
>
> So my suggestion is for people to respond with -1, -0.5, +-0, +0.5, or
> +1 to indicate support against/for the change.
-1 for me.
-Infinity for refactoring the entire codebase and backpatching.
—
Mark Dilger
Enterp
> On Jan 8, 2024, at 5:41 AM, Mark Dilger wrote:
>
> The /r modifier defeats the purpose of the patch, at least for my perl
> version, perl 5, version 28, subversion 1 (v5.28.1). With just the /aeg
> modifier, it works fine.
Nevermind. I might be wrong about that. I did
of the patch, at least for my perl
version, perl 5, version 28, subversion 1 (v5.28.1). With just the /aeg
modifier, it works fine.
--
Mark Dilger
st refactor to pass the
minimum amount of state information through the table AM API.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ons for tables and indexes.
This could use some regression tests to exercise the custom reloptions.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
tself, all the test infrastructure can use a
single, shared solution.
As for the implementation, I just briefly scanned the patch.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
not a
rhetorical question. Is there a risk here? Or are we just concerned that most
users will set up replication with superuser or some other high-privilege user,
and we're trying to protect them from the consequences of that choice?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
he publication. I
think you are focused on all the bad actors on the subscription-side database
and what they can do to each other. That's also valid, but I get the
impression that you're losing sight of the risk posed by malicious publishers.
Or maybe you aren't, and can explain?
—
Mark
nstant ROWCOUNT => 17;
> so I just made it a variable.
Seems fair. I certainly don't mind.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
f you had a particular client use case in mind when you added this
block?
The new function pg_encrypted_in() appears totally untested, but I have to
wonder if that's because we're not round-trip testing pg_dump with column
encryption...? The code coverage in pg_dump looks fairly decent, but some
10-12% off the tests. I didn't
> change that, but we also fire off a psql for each tuple for heap_page_items(),
> with offset $N no less. That seems to be another 500ms.
I don't recall the reasoning. Feel free to optimize the tests.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
smetic and comment changes.
>
> I think this is easier to follow and more nearly correct, but what do
> you (and others) think?
Thanks, Robert. Quickly skimming over this patch, it looks like something
reviewable. Your changes to t/004_verify_heapam.pl appear to be consistent
with h
> On Feb 22, 2023, at 10:49 AM, Jeff Davis wrote:
>
> On Wed, 2023-02-22 at 09:27 -0800, Mark Dilger wrote:
>> Another option is to execute under the intersection of their
>> privileges, where both the definer and the invoker need the
>> privileges in orde
still preventing either party from hijacking privileges of the other.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Feb 11, 2023, at 1:54 PM, Mark Dilger wrote:
>
> Here are some observations
I should mention, src/sgml/html/libpq-exec.html needs clarification:
> paramFormats[]Specifies whether parameters are text (put a zero in the array
> entry for the corresponding parameter)
've included appear to do
this (except indirectly when calling test_client); grep'ing for the libpq error
message "parameter with forced encryption is not to be encrypted" in the tests
has no matches. Is it just not possible? I thought you'd mentioned some
syntax for this when
some tables from the
> "locally_controlled_stuff" schema, we'll refuse to replicate that into
> our eponymous schema.
That example is good, though I don't see how "filters" are better than
roles+privileges. Care to elaborate?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
wner to be a non-superuser. That
> seems like two different efforts to me.
I don't have a concrete problem with your patch, and wouldn't object if you
committed it. My concerns were more how you were phrasing things, but it seems
not worth any additional conversation, because it's probably a distinction
without a difference.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e, so you should then have a (nonsuperuser-creator,
nonsuperuser-owner) pair. But you don't. You go the apparently needless extra
step of just squashing them together. I just don't see why it needs to be like
that.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
to defend himself against Alice, and Bob doesn't even seem to
> be trying. Maybe we should rename the users to Samson and Delilah? :-)
No, Atahualpa and Pizarro.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
; those objects to different and especially mutually untrusting users?
When public repositories of data, such as the IANA whois database, publish
their data via postgres publications.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Charlie, not Bob, as the "run-as" user helps somewhere
right around (D).
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
object
rather than a string is that it becomes more plausibly safe to allow the
subscription owner to make changes to that attribute of the subscription.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e at some
point in the future we might extend what things are allowed in that string, and
we have to keep everything that contemplates that string in sync. I may have
been overly hesitant to tackle that problem. Or maybe I just ran short of
round tuits.
—
Mark Dilger
Enterpris
are different ways of solving (1), and Jeff and I discussed them in Dec
2021. My recollection was that idea (3) was the cleanest. Other ideas might
be simpler than (3), or they may just appear simpler but in truth turn into a
can of worms. I don't know, since I never went as far as trying to implemen
> On Jan 10, 2023, at 9:26 AM, Mark Dilger wrote:
>
>-- Cryptographically connected to the encrypted record
>patient_id BIGINT NOT NULL,
>patient_ssn CHAR(11),
>
>-- The encrypted record
>patient_record TEXT ENCRYPTED WITH (colu
ng to discuss the general feature, not get
into the weeds about which cryptographic algorithm to select.
Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t; amcheck/pg_amcheck tests.
Ok, I can confirm that. I find the assertion
Assert(epoch != (uint32)-1);
a bit simpler to reason about, but either way, I agree it is a bug. Thanks for
finding this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
gets used.
Thanks
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
NaN
+(1 row)
+
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 28, 2022, at 12:33 PM, Mark Dilger
> wrote:
>
>> Isn't this just GRANT .. WITH SET FALSE, INHERIT FALSE, ADMIN TRUE? That
>> should allow role administration, without actually granting membership in
>> that role, yet, right?
>
> Can you cla
here? Are you inventing a new syntax?
+GRANT bob TO alice WITH SET FALSE, INHERIT FALSE, ADMIN TRUE;
+ERROR: syntax error at or near "SET"
+LINE 1: GRANT bob TO alice WITH SET FALSE, INHERIT FALSE, ADMIN TRUE...
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
to
de-conflate role membership from role administration, and maybe that's a
non-starter for reasons I don't recall at the moment. I expect Robert has
already contemplated that idea and instead proposed this patch for good
reasons. Robert?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
en
Alice circumvents these settings. Without that bit, the whole thing is inane.
Why make Alice jump through hoops that you are explicitly allowing her to jump
through? Apparently the answer is that you can point a high speed camera at
the hoops.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
gets the behavior she wants? I'm confused now
about who controls these settings.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
have, the bootstrap
> superuser as grantor, it is also only reasonable that superusers get
> to determine what options are used when creating that grant, rather
> than leaving that up to the CREATEROLE user.
Yes, this all makes sense, but does it entail that the CREATE ROLE command must
behave differently on the basis of a setting?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
always
the other. It's just to say that I don't want it to work differently based on
some poorly advertised property of the role executing the command.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
h is well written. Patch 0004 feels like something that won't get
committed. The INHERITCREATEDROLES and SETCREATEDROLES in 0004 seems clunky.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
running. Maybe that's why you haven't seen amcheck fall over?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e article rather than skipping down to that
section.
I hope it helps
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
to have privileges, it sounds like you mean
privileges on the publishing database. But then you talk about CREATE
SUBSCRIPTION granting privileges, which would necessarily be on the subscriber
database. Can you clarify what you have in mind?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ove mention of the
> Asserts. I also tried to form the comment in a way that's more
> understandable about why we always write a "0" in "INSERT 0 ".
Your wording is better. +1
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
) and later return a copy of the
slot's tuple sans any "system columns" (also per the above documentation) and
that's when the core code breaks. It's not the TAM that is broken here, not
according to the interface's documentation as I read it. Am I reading it wrong?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
postgres`ServerLoop at postmaster.c:1745:7
frame #26: 0x00010c68e23a postgres`PostmasterMain(argc=8,
argv=0x7f9edac06440) at postmaster.c:1417:11
frame #27: 0x00010c565249 postgres`main(argc=8,
argv=0x7f9edac06440) at main.c:209:3
frame #28: 0x7fff70d5ecc9 libdyld.dyl
ense?
I'm not a huge fan of the keyword "FUTURE" here, but I found a reference to
another database that uses that keyword for what I think is a similar purpose.
We should choose *something* for this, though, if we want things to be rational
going forward.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
computed then." A user who
diligently consults the documentation for one command to discover what "IN
SCHEMA" means may fairly, but wrongly, assume it means the same thing in
another command.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
confusion, but
created another kind. Per the docs on this feature:
FOR ALL TABLES IN SCHEMA
Marks the publication as one that replicates changes for all tables in the
specified list of schemas, including tables created in the future.
Like you, I wouldn't expect that definition, given th
to
future-proof against surprising behavioral changes.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
y sounds useful, but orthogonal, to this feature.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ed by things that aren't
logically prerequisites. The conversation upthread was useful to determine
that they aren't prerequisites, but if anybody wants to explain to me why they
are
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
se other commands, but don't want
to regret having drawn the line in the wrong place when later we decide to add
more roles like the one you are proposing.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
nd, but our own, and we'd want to debug why
we're pinning the same page twice (or more) while replaying wal. Otherwise,
maybe it's a race condition with some other process that transiently pins a
buffer and occasionally causes this code to panic?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t comments down-thread seem reasonable, so I suspect a new
patch will be needed. Would you like to author it, or would you prefer that I,
as the guilty party, do so?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t is the freedom to design and implement such a third-party TAM
without seeking community approval of the TAM's merits.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s to
route different tuples to different pages? The "current_buf" isn't enough
information, and there's no void *extra field, so you're just sunk.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
and wal? It doesn't
have all the features of heap, but that's not the same thing as violating mvcc
or breaking wal.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
use. Since the user can do this anyway, what's the
security implication in some syntactic sugar?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jun 15, 2022, at 8:18 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 20:10:30 -0700, Mark Dilger wrote:
>>> On Jun 15, 2022, at 7:30 PM, Andres Freund wrote:
>>>> But it's up to the TAM what it wants to do with that boolean, if in fac
rage the existing tests as much
as I can without having to reinvent tests to cover "chicago", and then reinvent
again to cover "detroit", and so forth.
If you develop enough TAMs in parallel, and go with the "using heap" solution,
you eventually have zero coverage for any of
, loose my data, or abort the command. None of those are OK
options for me.
I'm open to different solutions. If a simple callback like
relation_supports_cluster(Relation rel) is too simplistic, and more parameters
with more context information is wanted, then fine, let's do that. But I can't
really
> On Jun 15, 2022, at 7:21 PM, Mark Dilger wrote:
>
>> If a user does that for a table that doesn't support clustering, well, I
>> don't
>> see what's gained by not erroring out.
>
> Perhaps they want to give the TAM information about which index to use for
> On Jun 15, 2022, at 7:14 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 19:07:50 -0700, Mark Dilger wrote:
>>> On Jun 15, 2022, at 6:55 PM, Andres Freund wrote:
>>>
>>> I think nothing would happen in this case - only pre-clustered tables ge
rget is
pre-clustered, and both will run against the table if the user has run an ALTER
TABLE..CLUSTER ON. Now, we could try to catch that latter command with a
utility hook, but since the VACUUM FULL is still problematic, it seems cleaner
to just add the callback I am proposing.
> On Jun 15, 2022, at 6:01 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 17:21:56 -0700, Mark Dilger wrote:
>> While developing various Table Access Methods, I have wanted a callback for
>> determining if CLUSTER (and VACUUM FULL) should be run against a tab
etc., and for a given piece of DDL that
you want to release you only want to say which TAMs not to use, not to nail
down which TAM must be used.
Thoughts? I'll hold off posting a patch until the general idea is debated.
[*] It takes some extra work to get the TAP tests to play along.
—
Mar
ered" interface overly
simplistic?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
not)
back port it. I have had several occasions to want this functionality
recently, but the customers were on pre-v14 servers, so these tools were not
available anyway.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
en you cannot prove the marking is correct?
That would tend to give warnings for polymorphic functions that use functions
or operators over the polymorphic types, or which use dynamic sql, but maybe
that's ok. Those functions probably deserve closer scrutiny anyway.
—
Mark Dilger
EnterpriseDB:
As a simple example, text[] constructed using array_agg over sorted data can be
corrupted by a collation change, and reindex won't fix it.
If we extend the table-AM interface to allow query quals to be pushed down to
the table-AM, we might develop table-AMs that care about sort orde
> On Jun 6, 2022, at 9:02 AM, Tom Lane wrote:
>
> Thoughts?
I think it depends on your mental model of what \dconfig is showing you. Is it
showing you the list of configs that you can SET, or just the list of all
configs?
> On May 10, 2022, at 6:46 PM, Bruce Momjian wrote:
>
> Allow logical replication to run as the owner of the publication
Make that "owner of the subscription". This change operates on the
subscriber-side.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The En
is subject to the table's row-level security policies (Mark Dilger)
... should mention, independent of any RLS considerations, subscriptions are
now applied under the privilege of the subscription owner. I don't think we
can fit it in the release note, but the basic idea is that:
CREATE
> On Apr 27, 2022, at 6:26 PM, Andres Freund wrote:
>
> I'm a bit confused - what's the relation of that failure to this thread / the
> tests / this commit?
None, upon further reflection. It turned out to be unrelated. Sorry for the
noise.
—
Mark Dilger
Enterp
> On Apr 27, 2022, at 10:11 AM, Mark Dilger
> wrote:
>
> I'll try again on master
Still with coverage and dtrace enabled, I get the same thing, except that
master formats the logs a bit differently:
# Postmaster PID for node "primary" is 19797
psql::1: ERROR:
t yet completely narrowed this
down, but I wonder if anybody else is seeing this?
I'll try again on master
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 18, 2022, at 1:19 PM, Andrew Dunstan wrote:
>
> that seems quite separate from the present issue.
Thanks for the clarification. I agree, given your comments, that it is
unrelated to this thread.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
creates a new node, this global variable prevents
the new node from getting the port already assigned to the old stopped node,
except when port assignment wraps around. Without sharing the global,
wrap-around need not happen for port collisions.
Or am I reading the code wrong?
—
Mark Dilger
rebased the
patch to apply cleanly against the current master:
v9-0001-Reject-patterns-with-too-many-parts-or-wrong-db.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ereport(ERROR, ...) or whatever.
It looks like I'll need to post a new version of the patch with an argument
telling the function to ignore dots, but I'm not prepared to say that for sure.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
f parameters. I frequently can't recall the
exact spelling of them.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
oing to kick up a fuss about \dconf.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
build configuration (as in the
"pg_config" tool), text search configuration, etc.
While grep'ing through doc/src/sgml, I see no instances of "conf" ever
referring to configuration parameters. It only ever refers to configuration
files. I'd prefer not adding it to the list of synonyms.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ot;config". If we're going to use a single letter, I'd
prefer /p/.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
.
So yes, +1 from me.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
M generate_series(1, 50) i;
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t
the quotes removed. For example:
\d "robert.haas".accounts.acme
needs to return robert.haas (without the quotes) as the database name.
Likewise, for embedded quotes:
\d "robert""haas".accounts.acme
needs to return robert"haas, and so forth.
I was abl
> On Apr 4, 2022, at 5:12 PM, Tom Lane wrote:
>
> Wrote it already, no need for you to do it.
Thanks!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
unds right. Do you already have something like that coded, or would you
like me to post a patch?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ibpq behavior, so I'm inclined
> to just make it lax.
+1.
I've gotten this test failure only a few times in perhaps the last six months,
so if we narrow the opportunity for test failure without closing it entirely,
we're just making the test failures that much harder to diagnose.
—
Mark D
1 - 100 of 950 matches
Mail list logo
