e documented but couldn't find. If not yet, I think
> it’s a good time to document that.
I agree. That's just how TIDs are.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
detached. Hopefully
nobody should be surprised that if you don't specify
BGWORKER_SHMEM_ACCESS, you can't access data stored in shared memory.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
wasn't a pointer to
shared memory, but rather, say, an integer, like max_safe_fds or
MyCancelKey, I think you'd find that the value was preserved just
fine. I think you're confusing the pointer with the data to which it
points.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
difference as compared to the heap.
> The biggest problem that amcheck currently has is that it isn't used
> enough, because it isn't positioned as a general purpose tool at all.
> I'm hoping that the work from Mark helps with that.
Agreed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
restore_command reloadable as
> attached?
I don't see the problem here, either. Does anyone else see a problem,
or some reason not to press forward with this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
to an actual
> test-and-elog, too, but didn't do so here.
I was thinking about that, too. +1 for taking that step.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
dify_page"? Then you could initialize it to false and set it to
true just before doing the page modifications.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ould also use that tool
to look for things in the TOAST table that ought to also be
force-killed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
till works.
That's an interesting idea. I don't know exactly how it would work,
but I agree that it would allow useful testing that we can't do today.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ot;result cache"; also,
an experienced PostgreSQL user might be more likely to guess how a
"Parameterized Cache" is different from a "Materialize" node than they
would be if it were called a "Result Cache".
Just my $0.02,
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
SELECT pg_advisory_unlock(n);
>
> ... query executes with now-stale plan
Very sneaky!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e things.
That's the user's problem. If they don't have a plan for that, they
shouldn't use this tool. I don't think we can or should try to handle
it in this code.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
this topic to death at this point; I don't
think we are really in any sort of meaningful disagreement, and the
next steps in this particular case seem clear enough.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Jul 30, 2020 at 8:11 AM Robert Haas wrote:
> Unless somebody complains pretty soon, I'm going to go ahead and do
> what is described above.
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
cause it'd not be hard to reintroduce once we need
> it.
I think we should nuke it. It's trivial to reintroduce the flag if we
need it later, if and when somebody's willing to do the associated
work. In the meantime, it adds confusion.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
#x27;s an extremely common case,
though by no means universal.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ine fix
in StartBackgroundWorker(), to just unblock signals while handling
errors, looks better.
Adding Alvaro to the CC line, since I think he wrote this code
originally. Not sure if he or anyone else might have an opinion.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
as "less accurate." Tuples that are
invisible to a query often have performance consequences very similar
to visible tuples, in terms of the query run time.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
we are not actually unblocking SIQUIT and quickdie() will never
> get called in these processes if (sigsetjmp(local_sigjmp_buf, 1) !=
> 0){}
Yeah, maybe so. This code has been around for a long time and I'm not
sure what the thought process behind it was, but I don't see a flaw in
rs
depending on the relation size (which could also be preserved in the
hash table).
Just brainstorming here...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
is ~20% less, the WAL processing speed
> is ~1.25x).
Dang, that's pretty nice, especially for the relatively small amount
of code that it seems to require.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ity check should permit RELKIND_MATVIEW also.
It's unclear to me why the freeze logic here shouldn't do this part
what heap_prepare_freeze_tuple() does when freezing xmax:
frz->t_infomask2 &= ~HEAP_HOT_UPDATED;
frz->t_infomask2 &= ~HEAP_KEYS_UPDATED;
Likew
#x27;t do anything about rewriting the bogus comment just
> above the sigsetjmp call, but I agree that that should happen too.
I am not sure whether the difference between this and v1 matters,
because in postgres.c it's effectively happening inside sigsetjmp, so
the earlier unblock must not be that bad. But I don't mind putting it
in the place you suggest.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
the problem on the primary, because the primary can do
other things while one process sits there and thinks about
shared_buffers for a long time, but the standby can't, because the
startup process is all there is.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
- * removed. (We could work harder but there is no need for
- * current uses.)
+ * callback. We only look at the latest entry for removal, as we
+ * expect the caller to use before_shmem_exit callback mechanism
+ * in the LIFO order.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
d up non-empty reaches NBuffers, the process wanting to do
the next eviction gets handed the job of cleaning it out. Or maybe the
background writer could help; it's not like it does much anyway, zing.
It's possible that a dedicated process is the right solution, but we
might want to at
lso be true if the sigdelset() call were absent.
> Anyway, the bottom line is that that code's been like
> that for a decade or two without complaints, so I'm disinclined to
> mess with it on the strength of nothing much.
Really? Have you reversed your policy of wanting the comme
ther we ought to change the function to complain if the
> last list entry doesn't match. We'd have caught this bug sooner
> if it did, and it's not very clear why silently doing nothing is
> a good idea when there's no match.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ibility can
change very quickly, much faster than the inter-ANALYZE interval. And
sometimes tuples can be pruned away very quickly, too, and the index
pointers may be opportunistically removed very quickly, too.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
repeat, though,
> that I'm disinclined to change that without some evidence that there's
> actually a problem with the way it works now.
I've also already explained why I don't agree with this perspective.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s and years ago whenever it was first
proposed. In fact, I'd go so far as to say that the latter is a
slightly better option. However, doing nothing is clearly worst.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hat
they think about the above ideas for improving things, and if they've
got any other suggestions.
Thanks,
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
could have a separate stack for #1 that is explicitly
LIFO and not intended for any other use. But then again maybe that's
overkill. What I do think we should do, after thinking about it more,
is discourage the casual use of before_shmem_exit() for things where
on_shmem_exit() or on_pro
On Mon, Aug 10, 2020 at 3:41 PM Tom Lane wrote:
> Robert Haas writes:
> > Perhaps we really have four categories here:
> > (1) Temporary handlers for PG_ENSURE_ERROR_CLEANUP().
> > (2) High-level cleanup that needs to run after aborting out of the
> > current transac
one.
> Extension pg_stat_sql_plans (github) propose a function called
> pg_backend_queryid(pid),
> that gives the expected queryid (that is stored in shared memory for each
> backend) ...
That'd help people using pg_stat_statements, but not others.
--
Robert Haas
EnterpriseDB: http://w
tup process had already used the new one, or the other way around.
However, it doesn't seem like that should confuse anything inside the
server, and therefore I'm not sure we need to code around it.
If you or someone else thinks we do, then it'd be nice to hear why,
and what guaran
he same
> thing is executed multiple times concurrently.
True. You could find that you have a queryId that had already been
evicted from the table.
I think it's better to look for a more direct solution to this problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
't
seem super-common or super-difficult to figure out.
What kinds of scenarios motivate you to propose this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
"Call dynamic shared memory callbacks." It
seemed to me that I needed the re-entrancy behavior that is described
there, but for a set of callbacks that needed to run before some of
the existing callbacks and after others.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
skipping tid (%u, %u) for relation "%s" because it is marked unused
>
> Please let me know if you are okay with the above changes or not?
That seems broadly reasonable, but I would suggest phrasing the first
message like this:
skipping block %u for relation "%s" because
g. Think there should be a single define for all catalog bulk
> > inserts.
>
> Unlikely so, but I kept them separate to potentially lower the
> threshold of 64kB for catalog rows that have a lower average size than
> pg_attribute.
Uh, why would we want to do that?
--
Robert Haas
E
y is synchronous and expects a
transaction committing afterward to provoke a wait, but really it
doesn't. Now the user is unhappy, feeling that the system didn't
perform according to expectations.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
lease, it's not easy to do
that. Like if we needed to quote something we weren't previously
quoting, for example.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
l?
It seems like it should be consistent, but I'm not sure the proposed
change is really an improvement.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
oying otherwise. I could go either way on the question of
automation.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ch is auto-generated by the entire build farm, remember) it's
likely to mess up a patch that's otherwise properly formatted. We'd
either need to insist that people include updates to typedefs.list in
the patch, or else have the cfbot take a stab at doing those updates
itsel
real advantage in having synonyms for
the same thing, but there can be an advantage to letting users choose
the behavior they want.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
worlds from this standpoint --- too long for people to wait
> before rebasing their patch, yet short enough that they'd have
> to do so repeatedly.
Yeah, I get the point. It depends somewhat on how often you think
people will rebase. The main thing against more frequent pgindent runs
is that
rtainly *strongly recommend* to do VACUUM DISABLE_PAGE_SKIPPING,
> but if users fail to do so, then leaving the VM bit set just means that
> we know *for certain* that there will be further corruption as soon as
> the XID counter advances sufficiently.
+1.
--
Robert Haas
EnterpriseDB: h
built in. Now, as I said upthread, it's also true that you
could do #5 before #3 and #4. I don't think that's insane. But I
prefer it in the other order, because I think having #5 without #3 and
#4 wouldn't be too much fun for users.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t all in a backward-compatible way as you
propose, then we're likely to keep reintroducing code that does it the
old way for a really long time. I'm not sure that actually makes a lot
of sense. It might be better to just bite the bullet and make a hard
break.
--
Robert Haas
s on the target relation, and in
many cases it would be fine to do so. Users who can afford to take the
table off-line to repair the problem don't really need this tool in
the first place.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ompatibility.
I don't know exactly how you'd go about implementing that, but I am
not against compatibility. I *am* against coding rules that require a
lot of manual enforcement.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ension authors who want the
compatibility interface can define that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
difficulty with telling people what
specifically they ought to avoid doing is that experts will be annoyed
to be told that something is not safe when they know that it is fine,
and non-experts will think that some uses are safer than they really
are.
--
Robert Haas
EnterpriseDB: http://
specific patch for that?
Like, exactly what are we proposing that this deprecation warning is
going to say?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
alue is
specified as a fraction but works out to an integer when converted to
the base unit. That is a completely different thing from letting
people configure 5.4 parallel workers.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
user is hoping that we will be good enough to round the
value off so as to spare them the trouble. My own view is that the
former is vastly more probably than the latter.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hink we should also add
something to the documentation of the factorial operator, mentioning
that it will be going away. Perhaps we can advise people to write !!3
instead of 3! for forward-compatibility, or maybe we should instead
suggest numeric_fac(3).
--
Robert Haas
EnterpriseDB: http://www.enterp
= on 60276345
> 6390
> HDD, full_page_writes = off 738 275
> 192
The regression on HDD with full_page_writes=on is interesting. I don't
know why that should happen, and I wonder if there is anything that
can be done t
how other systems work? I would think that people
would expect to pass, say, a package variable, and expect that it will
get updated.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ator comment, which probably not many
people look at. But I don't see a problem updating the documentation
now to say:
- !! is going away, use factorial()
- ! is going away, use factorial()
- postfix operators are going away
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
a problem if the server crashes in between (which
> is the scenario I had in mind when doing the FINALIZE thing), because of
> course no transaction can continue to run across a crash.
Yeah, it sounds like this will require some solution, but I agree that
just waiting "longer" seems acceptable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
are proposing would make
it behave more like it's the same thing after all, which seems like it
might be missing the point.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
additional tests to improve code coverage. There are now
only a handful of lines not covered.
* Reorganized the test cases somewhat.
New patch attached.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
v9-0001-pg_surgery-rmh-based-on-ashutosh-sharma-v8.patch
Description: Binary data
sn't seem to be any reason why it doesn't make sense in
theory.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
et to a good outcome
here, but I think it's worth some careful consideration.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
probably a bunch more, and I don't think it's
practical to allow this tool to continue after arbitrary stuff goes
wrong. It'll be too much code and impossible to maintain. In the case
you mention, I think we should view that as a problem with clog rather
than a problem with the
not warn us about it. Perhaps there is some case where
the performance gains would be sufficiently to justify those risks,
but this is certainly not that case.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t they are mostly independent of each other. We should not
recommend that people run VACUUM "just in case." That kind of fuzzy
thinking seems relatively prevalent already, and it leads to people
spending a lot of time running slow maintenance commands that do
nothing to help them,
describes ! and !!
as deprecated. It looked too wordy to me to recommend what should be
used instead, so I have not done that.
Comments?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
postfix-and-factorial-deprecate.patch
Description: Binary data
On Fri, Aug 28, 2020 at 11:00 AM Robert Haas wrote:
> On Fri, Aug 28, 2020 at 4:44 AM John Naylor
> wrote:
> > On Thu, Aug 27, 2020 at 5:04 PM Tom Lane wrote:
> > > I'm a bit inclined to kill them both off and standardize on factorial()
> > > (not numeric_fac
operator.sgml
seem like improvements, so I'd keep those.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
instead of just one? Why do we
not treat projection as a separate node type even when we're not
projecting a set? In general, I've never really understood why we
choose to include some functionality in other nodes and keep other
things separate. Is there even an organizing principle, or is it just
historical baggage?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s entry or something.
The new arguments to heap_prepare_freeze_tuple() need to be documented
in its header comment.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
id
or relminmxid) shouldn't be the default behavior. I mean, if it
actually corrupts your data, then it clearly shouldn't be, and
probably shouldn't even be an optional behavior, but I still don't see
why it would do that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
a right-unary operator vs. a left-unary operator, but I
venture to guess that anyone smart enough to make any sort of
effective use of DROP OPERATOR could probably draw the necessary
inferences anyway.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
oint. But why would we do
this unconditionally in all cases where we just went to a read-write
state?
There's probably quite a bit more to say about 0003 but I think I'm
running too low on mental energy to say more now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
elfrozenxid and < nextxid?
TransactionIdDidCommit() does not have a suppress-errors flag, adding
one would be quite invasive, yet we cannot safely perform a
significant number of checks without knowing whether the inserting
transaction committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.c
I don't think "we need the data for forensics" is a sufficient
justification for "if you end up with one corrupted XID in a
billion-row table, your entire table will bloat out the wazoo, and
there is no option to get any other behavior."
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
>
> This passes check-world, for what little that's worth.
Seems totally reasonable from here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
obability that by the time either
> timeout fires, we're going to be blocked on a semaphore.
Yeah, I'm not sure these are so bad. In fact, in the deadlock case, I
believe the old coding was designed to make sure we *had to* be
blocked on a semaphore, but I'm not sure whe
On Fri, Aug 28, 2020 at 5:55 AM Ashutosh Sharma wrote:
> Please have a look into the attached patch for the changes and let me know
> for any other concerns. Thank you.
I have committed this version.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Sep 10, 2020 at 12:56 PM Tom Lane wrote:
> Also, man that CHECK_FOR_INTERRUPTS() looks like trouble.
> Could we take that out?
Maybe I'm missing something, but why wouldn't that be a horrible idea?
We do not want to have long waits where we refuse to respond to
interru
ding gibberish. Saying, as Tom did, that nobody has
complained about that behavior is just another way of saying that
nobody tested it. Surely if someone had, it wouldn't be like this.
--
Robert Haas
EDB: http://www.enterprisedb.com
better, pretty much by definition, and as explained
> in publications by NIST.
I mean I don't have anything against that appendix, but I think we
need to understand - with confidence - what the expectations are
specifically around XTS, and that appendix seems much more general
than that.
--
Robert Haas
EDB: http://www.enterprisedb.com
SN counter from
overtaking the real end-of-WAL, and if that should happen, then the
buffer manager would get confused. Maybe that can be fixed by doing
some sort of surgery on the buffer manager, but it doesn't seem to be
a trivial or ignorable problem.
--
Robert Haas
EDB: http://www.enterprisedb.com
\d foo.bar, or that they would even prefer that behavior over an
error message. You're carefully avoiding addressing that question in
favor of having a discussion of backward compatibility, but a better
term for what we're talking about here would be bug-compatibility.
--
Robert Haas
EDB: http://www.enterprisedb.com
ly be missing something here.
Oh, FlushBuffer has a guard against this case in it. I hadn't realized that.
Sorry for the noise.
--
Robert Haas
EDB: http://www.enterprisedb.com
ne. On my system, configure takes about
33 seconds, and a full rebuild with 'make -j8' takes 14.5 seconds (I
am using ccache). Moreover, most of the time when I run make, I'm only
doing a partial rebuild, so it's near-instantaneous.
--
Robert Haas
EDB: http://www.enterprisedb.com
ing the bugs is superior to either.
--
Robert Haas
EDB: http://www.enterprisedb.com
year, then that's okay.
This might work, but I fear that 0001 would end up being substantially
more complicated than a combined patch that solves both problems
together.
--
Robert Haas
EDB: http://www.enterprisedb.com
= 0;
How about instead using memset() to zero the whole thing and then
omitting the zero initializations? That seems like it would be less
fragile, if the upstream structure definition ever changes.
--
Robert Haas
EDB: http://www.enterprisedb.com
dots in the name portion are not treated as special.)"
I thought there was some reason why it needed to work that way.
--
Robert Haas
EDB: http://www.enterprisedb.com
nly test for a literal string
match. And I already said what I thought was wrong with (1). But none
of these are horrible, and I don't think it really matters which one
we adopt. I don't even know if I can really rank the choices I just
listed against each other. Before I was arguing for (3a) but I'm not
sure I actually like that one particularly better.
--
Robert Haas
EDB: http://www.enterprisedb.com
do it with macro tricks, it might be
worth considering, but I'm not sure there is, or that it would be less
confusing.
--
Robert Haas
EDB: http://www.enterprisedb.com
someone may or may not
want a non-superuser to be able to execute, let's just let them do
that. It doesn't need to be tied to a predefined role, and in fact
it's more flexible if it isn't.
--
Robert Haas
EDB: http://www.enterprisedb.com
e names as a pattern, and
then we could complain only if it doesn't match exactly and only the
current DB. But I don't like adding a bunch of extra code to
accomplish nothing useful, so if we're going to match it all I think
it should just strcmp().
But I'm still no
: argument to \d should be of the form
[schema-name-pattern.]relation-name-pattern
Would that have been better or worse for you than accepting a third
part of the pattern as a database name if and only if it matched the
current database name exactly?
--
Robert Haas
EDB: http://www.enterprisedb.com
do, and I like this. Advanced Server accidentally dodges this problem
at present by shipping with a different FUNC_MAX_ARGS value, but this
is much cleaner.
Would it be reasonable to consider something similar for the control
file, for the benefit of distributions that are not the same on disk?
-
501 - 600 of 8046 matches
Mail list logo
