mm. Perhaps we are not careful enough with the calls of
msvc_gendef.pl in meson.build, missing some spots?
--
Michael
signature.asc
Description: PGP signature
e is not careful with the
query ID reporting.
I'm planning to look at that again at the beginning of next week.
--
Michael
From 6921a7b6e25c2471d64f05ce136af741598381c0 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Fri, 13 Sep 2024 14:54:17 +0900
Subject: [PATCH v6 1/2] Add missing query I
d make sure that
one record exists. The data in the page does not really matter.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 12, 2024 at 09:10:44AM +0300, Nazir Bilal Yavuz wrote:
> This should be fixed in 65c310b310a6.
Thanks for the confirmation.
--
Michael
signature.asc
Description: PGP signature
ect that depends on an OID should still use an OID, and
anything that's generic enough to be used for all stats kinds had
better use a uint64. I was wondering if it would be better hiding
that behind a dedicated type, but decided to stick with uint64.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 12, 2024 at 08:12:30AM +0900, Michael Paquier wrote:
> It looks like my mind was wondering away when I wrote this part.
> Sorry for the useless noise.
I was looking at all that, and this is only moving code around. While
the part for heap_xlog_logical_rewrite in rewriteheap.
(DEADCODE)
>
> Trivial patch attached.
I am not sure to understand what you mean here and if this is still
relevant as of Noah's latest commit in 65c310b310a6.
--
Michael
signature.asc
Description: PGP signature
ect it automatically.
Note that I'm not much worried about the dependency with
pg_stat_statements. We already rely on it for query jumbling
normalization for some parse node patterns like DISCARD, and query
jumbling requires query IDs to be around. So that's not new.
--
Michael
signature.asc
Description: PGP signature
7;t already exist.
>
> As for patch v3, that seems fine with me.
+1 from here as well, after looking at what v3 is doing for these two
modules.
--
Michael
signature.asc
Description: PGP signature
s, what should we do with the other
things? It does not seem to me that we have a clear consensus on if
we are going to do something about some epoch:xid -> 64b XID switch,
and what are the arguments in play here. The thread has been long, so
I may be just missing the details but a summary would be nice.
--
Michael
signature.asc
Description: PGP signature
e shape of a catalog that's able to represent at SQL level all
the SLRUs that exist in a backend.
--
Michael
signature.asc
Description: PGP signature
On Wed, Sep 11, 2024 at 02:29:49PM -0700, Jacob Champion wrote:
> On Mon, Sep 9, 2024 at 10:30 PM Michael Paquier wrote:
>> No. My question was about splitting pgstat_bestart() and
>> pgstat_bestart_pre_auth() in a cleaner way, because authenticated
>> connections finish by
On Wed, Sep 11, 2024 at 04:41:49PM +0900, Michael Paquier wrote:
> +#include "access/heapam_xlog.h"
>
> This is included in heapam.h, but missing from the patch. I guess
> that you fat-fingered a `git add`.
It looks like my mind was wondering away when I wrote this part.
tom stats APIs.
> I am not sure how we can add tests for RevalidateCachedQuery though using
> pg_stat_statements. We could skip testing this scenario, maybe??
Perhaps. I'd need to think through this one. Let's do things in
order and see about the reports for the bind/execute messages, first,
please?
--
Michael
signature.asc
Description: PGP signature
by `vacuum`, the startup process will raise error 'could not
> access status of transaction xxx', due to it could not found the
> transaction's status file in dir `pg_xact`.
Hmm. I've not seen that in the field. Let me check that..
--
Michael
signature.asc
Description: PGP signature
Thanks for the feedback.
On Tue, 10 Sept 2024 at 22:03, torikoshia wrote:
> Regarding the addition of partition descendant tables, should we also
> update the below comment on expand_vacuum_rel? Currently it refers only
> partitions:
>
> | * Given a VacuumRelation, fill in the table OID if it wa
to
WAL records.
+#include "access/heapam_xlog.h"
This is included in heapam.h, but missing from the patch. I guess
that you fat-fingered a `git add`.
--
Michael
signature.asc
Description: PGP signature
On Mon, Sep 02, 2024 at 10:11:43AM +0900, Michael Paquier wrote:
> I need to spend a bit more time with my head down for this thread, but
> couldn't we use these commands with various query patterns in
> pg_stat_statements and look at the shmem counters reported through its
> vi
g by adding
different problems into the mix that require different analysis and
actions. Let's only focus on the issue that the query ID reporting
in pg_stat_activity is missing for the extended query protocol here.
--
Michael
signature.asc
Description: PGP signature
in the authentication process, it is
going to offer a much better hint than having to guess which part of
the authentication step is slow, like in LDAP.
Wait event additions are also kind of cheap in terms of maintenance in
core, creating a new translation cost. So I also think there are more
upsides to be wilder here with more points and more granularity.
--
Michael
signature.asc
Description: PGP signature
On Tue, Sep 10, 2024 at 10:44:42AM +0200, Daniel Gustafsson wrote:
> This change will be committed together with the TLSv1.3 cipher suite pathcset,
> just wanted to bring it up here and not hide it in another thread.
As you wish ;)
--
Michael
signature.asc
Description: PGP signature
ive flag instead? I haven't looked at the code, but
from the documentation ("If false, the index is in process of being
dropped, and
should be ignored for all purposes") it sounds like we made be able to
piggy-back on that instead?
Michael
ing them to be added to shared_preload_libraries,
i.e. saving the organization an instance restart/downtime.
That seems important enough for end-users to know, even if they will
need to wait for extension authors to catch up to this (but I guess a
lot will).
Michael
On Tue, Sep 03, 2024 at 02:47:57PM -0700, Jacob Champion wrote:
> On Sun, Sep 1, 2024 at 5:10 PM Michael Paquier wrote:
>> that gets also used by pgstat_bestart() in
>> the case of the patch where !pre_auth?
>
> To clarify, do you want me to just add the new boolean directl
On Mon, Sep 09, 2024 at 03:56:14PM +0900, Michael Paquier wrote:
> How about inventing a new ATT_PARTITIONED_TABLE and make a clean split
> between both relkinds? I'd guess that blocking both SET LOGGED and
> UNLOGGED for partitioned tables is the best move, even if it is
> possi
ANIC, allow things with a DEBUG2 or something else, and
XLogFileReadAnyTLI()'s sole caller used DEBUG2. Applied.
--
Michael
signature.asc
Description: PGP signature
board
about your argument with SSL_CTX_set_ciphersuites() to drop 1.1.0 and
simplify the other feature.
I was wondering about HAVE_SSL_CTX_SET_NUM_TICKETS for a few seconds,
but morepork that relies on LibreSSL 3.3.2 disagrees with me.
--
Michael
signature.asc
Description: PGP signature
On Mon, Sep 09, 2024 at 11:24:28AM -0400, Robert Haas wrote:
> That's interesting, but it sort of seems like it's reinventing the
> wheel, vs. the one-line change that I proposed.
Probably. I'll try to look at all that this week (with some automated
tests!).
--
Mi
this feature (i.e. Use streaming read API in
ANALYZE) is being mentioned in the release announcement and that was
just frozen for translations.
Michael
Thanks for the feedback David.
On Mon, 9 Sept 2024 at 11:27, David Rowley wrote:
> You've written "was" (past tense), but then the existing text uses
> "will" (future tense). I guess if the point in time is after parse and
> before work has been done, then that's correct, but I think using "is"
>
ITIONED_TABLE and make a clean split
between both relkinds? I'd guess that blocking both SET LOGGED and
UNLOGGED for partitioned tables is the best move, even if it is
possible to block only one or the other, of course.
--
Michael
signature.asc
Description: PGP signature
>
> IIRC, HEAD *was* the technically correct term back when we were
> using CVS. Old habits die hard.
Even if it's a new habit from a new technology. I began getting
involved with upstream the year when the moved from CVS to git
happened, and just inherited this habit from everybody
m these functions. I've atached the patch.
It's true that the last relevant caller of XLogFileReadAnyTLI() that
required an emode is abf5c5c9a4f1, as you say, that's also what I am
tracking down. Any objections to that?
--
Michael
signature.asc
Description: PGP signature
ns for the callbacks. If
there are voices in favor of something different, we still have a good
chunk of the development and beta cycle for that.
--
Michael
signature.asc
Description: PGP signature
;s intended to be a fastpath, with checks happening if we have
no data pending for any variable-numbered stats.
--
Michael
signature.asc
Description: PGP signature
with a NOTICE set when the safe flag is true. Anyway, what you have
is more than enough to prove your point. Thanks for that.
--
Michael
signature.asc
Description: PGP signature
On Fri, Sep 06, 2024 at 08:29:52AM +0900, Michael Paquier wrote:
> Looks OK at quick glance. I'll take care of that as I've done the
> other one.
And done.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 05, 2024 at 10:56:34PM +0200, Jelte Fennema-Nio wrote:
> LGTM now. Added it to the commitfest here:
> https://commitfest.postgresql.org/50/5241/
Looks OK at quick glance. I'll take care of that as I've done the
other one.
--
Michael
signature.asc
Description: PGP signature
e have not found
previously, as per the knowledge that these would be compiled with the
code for the builtin code, or added at startup for the custom ones.
I'd suggest to study the code a bit more. Perhaps more documentation
is required, not sure about that yet.
--
Michael
signature.asc
On Thu, Sep 05, 2024 at 12:41:09PM +0900, Michael Paquier wrote:
> Not sure which one is better than the other, TBH. Either way, we
> still have a full release cycle to finalize that, and I am OK to
> switch the name to something else if there are more folks in favor of
> one, the o
e to finalize that, and I am OK to
switch the name to something else if there are more folks in favor of
one, the other or even something entirely different but descriptive
enough.
--
Michael
signature.asc
Description: PGP signature
./configure does not apply to meson, so I'm not sure what we
should do here, except perhaps inventing a new option switch that
reports the options that have been used with the meson command, or
something like that.
--
Michael
signature.asc
Description: PGP signature
n be
very easy to mess up things depending on the code path you're
manipulating, speaking with some.. Experience on the matter. And an
RC1 is kind of something to be cautious with.
--
Michael
signature.asc
Description: PGP signature
spot that, and missed the
two I have noticed considering that we're dealing with the same code
paths. The community coverity did not complain on any of them, AFAIK.
--
Michael
diff --git a/src/backend/utils/activity/pgstat.c b/src/backend/utils/activity/pgstat.c
index b2ca3f39b7..612158f2b9 10064
n't have
to, and we would go through the whole flush dance as long as we detect
some stats activity in at least one stats kind. I mean, that's cheap
enough to keep around.
--
Michael
signature.asc
Description: PGP signature
name of
the callbacks, which is why I chose this naming. If you feel strongly
about "backend_init_cb", that's also fine by me; you are the original
author of this code area with Andres.
--
Michael
signature.asc
Description: PGP signature
ve an opinion that could drive to a consensus.
[1]: https://www.postgresql.org/message-id/2162891.1715890...@sss.pgh.pa.us
--
Michael
signature.asc
Description: PGP signature
. Fixed this one with 08b9b9e043bb, as the tag for
17rc1 has been pushed.
Picking f747bc18f7f2 and 75c5231a00f3 on REL_17_STABLE leads to the
attached, I think, without the conflicts.
--
Michael
From f747bc18f7f205795177cce6a93e19169bd0467f Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue,
On Mon, Sep 02, 2024 at 09:53:30AM +0900, Michael Paquier wrote:
> REL_17_STABLE is frozen for a few more days, so I'll address all the
> items of this thread that once the release of this week is tagged: the
> export duplicates and the installcheck issue. These are staged on a
>
On Mon, Sep 02, 2024 at 08:35:15PM -0500, Nathan Bossart wrote:
> On Tue, Sep 03, 2024 at 09:22:58AM +0900, Michael Paquier wrote:
>> Okay. This is going to be disruptive if we do nothing about pg_dump,
>> unfortunately. How about tweaking dumpTableSchema() so as we'd never
&
e about doing
something here, at least.
--
Michael
signature.asc
Description: PGP signature
would not work
> anymore?
Yes. Folks are not going to do that, but changing PG_TBLSPC_DIR would
change the decision-making when streaming from versions older than
v17 with clients tools from v18~.
--
Michael
signature.asc
Description: PGP signature
tra maintenance and
there's already a mention of src/include/utils/pgstat_internal.h
telling where the callbacks are described.
--
Michael
signature.asc
Description: PGP signature
On Tue, Sep 03, 2024 at 02:24:32PM +0900, Michael Paquier wrote:
> On Mon, Sep 02, 2024 at 09:00:00PM +0300, Alexander Lakhin wrote:
> > I've gathered another bunch of defects with the possible substitutions.
> > Please take a look:
> > pgstat_add_kind -> pgstat
This one is
on me so I'll go fix that in a bit, with the rest while on it.
--
Michael
signature.asc
Description: PGP signature
going its own ways sometimes.
Thanks,
--
Michael
From e98f8d50c17cd8fc521bffb4bdc73ef58b7fa430 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 3 Sep 2024 13:36:10 +0900
Subject: [PATCH] Add callbacks to control flush of fixed-numbered stats
This commit adds two callbacks in pgstats
le to initialize some static backend state.
I wanted to get that sent for the current commit fest, but did not get
back in time to it. Anyway, here it is. This gives the simple patch
attached.
Thanks,
--
Michael
From 1e41a5155fb689f1d4ae8a5cfb244b824e913bae Mon Sep 17 00:00:00 2001
From: Mi
cuum()). How bad would it be to re-introduce that? Or can
> we make it more watertight so that there are no leaks?
Not sure about this part, TBH. Doing that again in autovacuum does
not excite me much as it has a cost.
> I think it's failing to flush the stats file at the end of recov
ing about pg_dump,
unfortunately. How about tweaking dumpTableSchema() so as we'd never
issue UNLOGGED for a partitioned table? We could filter that out as
there is tbinfo->relkind.
--
Michael
signature.asc
Description: PGP signature
With the comment in relpath.h suggesting to not change that, the
current state of HEAD is fine by me.
--
Michael
signature.asc
Description: PGP signature
proposal for per backend I/O statistics [1].
>
> [1]:
> https://www.postgresql.org/message-id/ZtXR%2BCtkEVVE/LHF%40ip-10-97-1-34.eu-west-3.compute.internal
Cool, thanks!
--
Michael
signature.asc
Description: PGP signature
s with various query patterns in
pg_stat_statements and look at the shmem counters reported through its
view?
--
Michael
signature.asc
Description: PGP signature
of this thread that once the release of this week is tagged: the
export duplicates and the installcheck issue. These are staged on a
local branch for now.
--
Michael
signature.asc
Description: PGP signature
On Thu, Aug 29, 2024 at 10:06:32AM +0900, Michael Paquier wrote:
> +1 for your suggestion, as you are suggesting. The original intention
> when PG_Locale_Strategy got introduced was to have everything named as
> PG_REGEX_LOCALE_*, but with the built-in part coming in play in this
>
th two different code paths. But perhaps my gut feeling is
just wrong reading your paragraph.
--
Michael
signature.asc
Description: PGP signature
tarting"" state instead that gets also used by pgstat_bestart() in
the case of the patch where !pre_auth?
The addition of the new wait event states in 0004 is a good idea,
indeed, and these can be seen in pg_stat_activity once we get out of
PGSTAT_END_WRITE_ACTIVITY() (err.. Right?).
--
Michael
signature.asc
Description: PGP signature
ks in sequence.c like manipulations of
t_infomask, and I can be good to check for its status on corrupted
systems.
--
Michael
signature.asc
Description: PGP signature
fields - for 'reviewer' should
I have put the people who have provided feedback on this thread?
Is there anything else I need to do?
Thanks again
Cheers
Mike
On Fri, 30 Aug 2024 at 18:44, David Rowley wrote:
>
> Hi Michael,
>
> On Fri, 23 Aug 2024 at 22:01, Michael Harris
Hello Atsushi & Melih
Thank you both for your further feedback.
On Thu, 29 Aug 2024 at 21:31, Melih Mutlu wrote:
> I believe moving "[ ONLY ]" to the definitions of table_and_columns below, as
> you did with "[ * ]", might be better to be consistent with other places (see
> [1])
Agreed. I hav
overall, so I have left this part
out.
In 0006, I am not sure that RELATIVE_PG_TBLSPC_DIR is really something
we should have. Sure, that's a special case for base backups when
sending a directory, but we have also pg_wal/ and its XLOGDIR so
that's inconsistent. Perhaps this part should be left as-is.
--
Michael
signature.asc
Description: PGP signature
On Thu, Aug 29, 2024 at 09:28:49AM -0500, Nathan Bossart wrote:
> On Thu, Aug 29, 2024 at 02:11:22PM +0900, Michael Paquier wrote:
> > Okay, here is a v2 of the patch using this name for the function.
>
> LGTM
Thanks, applied that, after one tweak for the #define name.
--
Michael
even if it is perhaps accidental? relpersistence is marked correctly
for partitioned tables, it's just useless. Expanding the
documentation sounds fine to me, one way or the other, to tell what
happens with partitioned tables.
By the way, I was looking at this patch series, and still g
On Wed, Aug 28, 2024 at 08:28:03PM -0500, Nathan Bossart wrote:
> On Thu, Aug 29, 2024 at 08:00:52AM +0900, Michael Paquier wrote:
>> Indeed, pg_sequence_read_tuple() would not reflect the reality, some
>> ideas:
>> - pg_sequence_read_data
>> - pg_sequence_get_data
>
+1 for your suggestion, as you are suggesting. The original intention
when PG_Locale_Strategy got introduced was to have everything named as
PG_REGEX_LOCALE_*, but with the built-in part coming in play in this
code adding "STRATEGY" is cleaner than just "LOCALE".
--
Michael
signature.asc
Description: PGP signature
ables.
How does that help if using a Leading hint to force a join order?
That's something people like a lot. But perhaps that's just the part
of upthread where we'd need a extra hook? I am not completely sure to
get the portion of the proposal for that. add_paths_to_joinrel()
use in the record.
> One idea is to store the uint64 as two uint32's.
Nice, we could just do that. This idea makes me feel much better than
sticking more aligment macros in the paths where the record is built.
Attached is an updated patch doing that. ubsan is silent with th
ture and 2) it no longer returns everything in the sequence tuple?
Indeed, pg_sequence_read_tuple() would not reflect the reality, some
ideas:
- pg_sequence_read_data
- pg_sequence_get_data
- pg_sequence_data
- More consistent with other catalog functions: pg_get_sequence_data,
as we have already i
y. That's on my
TODO spreadsheet of things to look at, but I did not come back to it
yet.
A backpatch would be adapted for that, yep. I'd like to see tests on
HEAD at least.
--
Michael
signature.asc
Description: PGP signature
ignificantly more useful.
JFTR, hypopg can also mask away/hide indexes since version 1.4.0:
https://github.com/HypoPG/hypopg/commit/351f14a79daae8ab57339d2367d7f2fc639041f7
I haven't looked closely at the implementation though, and maybe you
meant something else in the above entirely.
Michael
On Fri, Aug 02, 2024 at 02:11:34AM +0900, Michael Paquier wrote:
> Applied 0003 for now to add the redo LSN to the pgstats file, adding
> the redo LSN to the two DEBUG2 entries when reading and writing while
> on it, that I forgot. (It was not 01:57 where I am now.)
>
> Attached
efined, of course. My point is that the use of WAL
is something that should be optional, but log_cnt in this function
makes it a mandatory concept that all sequence AMs would need to deal
with.
Comments?
--
Michael
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index
eek or so.
Anyway, I'm attaching that to the next CF for discussion for now, as
there could be objections about this whole idea, as well.
Thoughts or comments?
--
Michael
From a33ded084b9855e00a588963bd24ed2a453bdd03 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Mon, 26 Aug 2024 08:19:22
Thanks for the feedback Melih,
On Thu, 22 Aug 2024 at 21:26, Melih Mutlu wrote:
> It seems like extended_relation_expr allows "tablename *" syntax too. That
> should be added in docs as well. (Same for VACUUM doc)
I had included it in the parameter description but had missed it from
the synopsi
ts are enabled or not, no? Well, it is true that we
could also do something like a scan of pg_config.h in the installation
path, but this is consistent with what ./configure uses.
--
Michael
From 7441e32d8d7a4737a1c37dbb9e8b8f1a51a5f5c3 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Fri, 23
On Thu, Aug 22, 2024 at 10:36:38AM -0400, Alvaro Herrera wrote:
> On 2024-Aug-22, Michael Paquier wrote:
>> I'm not sure that we need to get down to that until somebody has a
>> case where they want to rely on stats of injection points for their
>> stuff. At this stage
ly on HEAD due to the dependency with the other
things you are proposing, and I would have hardcoded failures to check
that the reports are correct, but that looks neat on read.
--
Michael
signature.asc
Description: PGP signature
On Thu, Aug 22, 2024 at 01:16:37PM -0400, Yogesh Sharma wrote:
> On 8/18/24 20:09, Michael Paquier wrote:
>> I'm tempted to propose a separate improvement for the template of the
>> fixed-numbered stats. We could do like pgstatfuncs.c where we use a
>> macro to define th
On Thu, Aug 22, 2024 at 11:13:15PM +0200, Daniel Gustafsson wrote:
> On 22 Aug 2024, at 02:31, Michael Paquier wrote:
>> Just do it :)
>
> That's my plan, I wanted to wait a bit to see if anyone else chimed in with
> concerns.
Cool, thanks!
--
Michael
signature.asc
Description: PGP signature
22 Aug 2024 at 13:38, Michael Harris wrote:
> > Would we want to apply that change to VACUUM too? That might be a
> > bit drastic, especially if you had a multi-level inheritance structure
> > featuring
> > large tables.
>
> I think they'd need to work the same
used uninitialized[1].
>
> [1] https://cirrus-ci.com/task/6207675187331072
Ah, thanks! I've missed this one. I see where my mistake was.
--
Michael
signature.asc
Description: PGP signature
On Wed, Aug 21, 2024 at 03:18:49PM +0200, Tomas Vondra wrote:
> +1 to just close it
Sounds good to me. Thanks.
--
Michael
signature.asc
Description: PGP signature
On Mon, Aug 19, 2024 at 03:21:30PM +0900, Michael Paquier wrote:
> I won't hide that I've wanted that in the past..
And I have bumped into a case where this has been helpful today, so
applied. Thanks!
--
Michael
signature.asc
Description: PGP signature
Tom Lane wrote:
> Yeah, my thought was to change the behavior so it's consistent in
> that case too. This doesn't seem to me like a change that'd
> really cause anybody serious problems: ANALYZE without ONLY would
> do more than before, but it's work you probably want done anyway.
Would we want
FWIW consider my
> reservations withdrawn ;-)
Just do it :)
I am pretty sure that Daniel is just on vacations and that this will
happen sooner than later during the next commit fest, so I'd rather
wait for him for an update on this thread first.
--
Michael
signature.asc
Description: PGP signature
ection. Do you mean to say that the
> injection point runs inside a critical section?
Yes.
> No issues with this, feel free to go ahead.
Cool, thanks.
--
Michael
signature.asc
Description: PGP signature
Thank you all for the replies & discussion.
It sounds like more are in favour of using the ONLY syntax attached to
the tables is the best way to go, with the main advantages being:
- consistency with other commands
- flexibility in allowing to specify whether to include partitions
for individual
On Wed, Aug 21, 2024 at 12:46:31PM +0900, Michael Paquier wrote:
> Sorry, I should have split that for clarity (one patch for the GUC,
> one to change the test to use CACHED/LOAD). It is not an error
> though: if we don't have a controlled way to disable the stats of the
> modu
wo
macros in the tree, so as these can be used as a reference in the
future when developing new tests.
--
Michael
signature.asc
Description: PGP signature
is able
to work correctly. Please see attached.
Thoughts?
--
Michael
From db4b4601a6e930a374f6d03b622f66589d620fe2 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Wed, 21 Aug 2024 08:17:19 +0900
Subject: [PATCH] Refactor injection point test with loading
This relies on the two macro
ints available. (We could then remove some of
> the makefile hackery that's supporting the current behavior.)
> Probably the same needs to happen in each other test script
> that's using injection_points --- I imagine that Maxim's
> test is simply failing here first.
Yeah, we could do that.
--
Michael
signature.asc
Description: PGP signature
1 - 100 of 1301 matches
Mail list logo
