but I don't insist ;)
Thanks for looking into it. Stylistically, I prefer the style without
the cast, but the effect is the same.
--
Robert Haas
EDB: http://www.enterprisedb.com
just install an unrelated extension in the same
schema and then drop the first extension and, whoops.
--
Robert Haas
EDB: http://www.enterprisedb.com
row)
I seriously doubt that this will be stable across the entire
buildfarm. You're going to need a different approach here.
Is there any real reason to rename regress_log_memory to
regress_log_function, vs. just introducing a separate regress_log_plan
role?
--
Robert Haas
EDB: http://www.enterprisedb.com
2)
}
:jpath.innerjoinpath
{PATH
:parent_relids (b 4)
}
}
}
So, for the assertion to pass, the more deeply nested merge join would
need to have ojrelids = {} and the less-deeply nested one would need
ojrelids={3,5}.
--
Robert Haas
EDB: http://www.enterprisedb.com
ite fiddly and hard to understand.
> I noticed that the patchset was failing in cfbot because we've since
> grown another regression test case whose output is affected by 0002.
> So here's a v3 that incorporates that additional change. I did a
> little bit of wordsmith
haven't done the
experiments, but it seems to me that the downsides of this kind of
strategy switch might be pretty minimal even when things work out
anti-optimally.
--
Robert Haas
EDB: http://www.enterprisedb.com
-world for me on a 32-bit FreeBSD
> image.
Sorry for not responding to this thread sooner, but thanks, Tom. I
think this is a great change and I appreciate you doing the legwork.
--
Robert Haas
EDB: http://www.enterprisedb.com
t; requires the schema to not exist yet. (And even then as explained
> above the accidental drop only happens when the user uses CASCADE.)
Sure.
--
Robert Haas
EDB: http://www.enterprisedb.com
eaning
to values <0, and the current coding seems to assume that sizes are
fixed regardless of how many inputs are supplied. Maybe we could
define aggtransspace<0 to mean that the number of bytes used per input
value is the additive inverse of the value, or something like that.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Sep 16, 2025 at 4:12 PM Robert Haas wrote:
> On Fri, Sep 5, 2025 at 4:19 PM Robert Haas wrote:
> > While mulling this over, I realized that this only works if you don't
> > mind propagating information into the final plan regardless without
> > knowing whether o
ve more
people time to bikeshed the list, too, if anyone is inclined to do
that.
--
Robert Haas
EDB: http://www.enterprisedb.com
tasks should
get completed; and if you or whoever don't think you're going to be
able to make those timelines, then we can either decide on someone
else to do it or we can decide to move the deadline. Either way, if we
do that, we're operating by consensus and a shared set of
expectations.
--
Robert Haas
EDB: http://www.enterprisedb.com
t then other people should have
the right to present their own survey results and so on in that
conversation too.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Sep 18, 2025 at 12:09 PM Jonathan S. Katz wrote:
> Please see attached draft for the major features of PostgreSQL 18.
I like Nathan's version better. I suggest we go with that one.
--
Robert Haas
EDB: http://www.enterprisedb.com
that's not very clear from the wording and (b) why the
XXX?
I think this is the fault of
https://git.postgresql.org/pg/commitdiff/393e0d2314050576c9c039853fdabe7f685a4f47
--
Robert Haas
EDB: http://www.enterprisedb.com
pdated, but there isn't that a great a benefit that we should be
> waiting until the last few days to complete this.
I complained about this same problem yesterday on another thread.
--
Robert Haas
EDB: http://www.enterprisedb.com
real scheduling
system for autovacuum, I don't see this area improving very much.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Sep 12, 2025 at 1:44 PM Tom Lane wrote:
> Robert Haas writes:
> > But, I also can't commit either v4-0003 or v5-0003 or any variant
> > thereof until we agree on what to do about 0001, and you're the
> > holdout there.
>
> Yeah, I owe you a revie
e. v5-0001 adds a result_type field to the Result node in
response to your previous review comments, so knowing whether that
looks like what you want or whether you would prefer something else is
the blocker for me as of this moment.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
e documentation when we're supposed to wrap in 5
days, and 2 of those are weekend days.
--
Robert Haas
EDB: http://www.enterprisedb.com
are there, but each AM still has to do the custom code
> anyway.
Unless I misunderstand, that seems like the worst of all possible situations.
--
Robert Haas
EDB: http://www.enterprisedb.com
s to use it. I removed the
> elog_bitmapset() as it isn't being used and now that it's easy to output
> the set in SQL why keep it for debugging?
How about using outBitmapset() which already exists?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Sep 17, 2025 at 8:04 AM Marcos Pegoraro wrote:
> Em ter., 16 de set. de 2025 às 23:01, Robert Haas
> escreveu:
>> I think RETABLE is not a proposal to be taken seriously. That's
>> extremely confusing.
>
> This feature could be used in a future version to r
Ms in sync is not ideal.
--
Robert Haas
EDB: http://www.enterprisedb.com
agree with Álvaro that having one verb for both of those things
makes a lot more sense than the status quo.
--
Robert Haas
EDB: http://www.enterprisedb.com
ld
look like here, but we want the common parts like worker setup to use
common code, while allowing each AM to insert its own logic in the
places where that is needed. The challenge in my view is to figure out
how best to arrange things so as to make that possible.
--
Robert Haas
EDB: http://www.enterprisedb.com
e that we should prefer foo != NULL, but if the surrounding code
in a particular location just tests if (foo), then it may be better in
that case to go that route.
--
Robert Haas
EDB: http://www.enterprisedb.com
makes a lot more sense than the status quo, which is a
confusing historical accident.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Sep 5, 2025 at 4:19 PM Robert Haas wrote:
> While mulling this over, I realized that this only works if you don't
> mind propagating information into the final plan regardless without
> knowing whether or not EXPLAIN was actually used. That's pretty sad,
[...]
>
r *replacement_type = "???";
...in the hopes of still producing a warning here if somebody adds
another label to the enum.
--
Robert Haas
EDB: http://www.enterprisedb.com
be stable across the entire
> > buildfarm. You're going to need a different approach here.
>
> Changed it to the following query:
>
>WITH t AS MATERIALIZED (SELECT pg_log_query_plan(pg_backend_pid()))
> SELECT * FROM t;
I don't see why that wouldn't have a race condition?
> Also since when the target query is using CTE, pg_log_query_plan() had
> few chance to log the plan, attached patch added T_CteScan handling.
Shouldn't all node types be handled equally?
--
Robert Haas
EDB: http://www.enterprisedb.com
expressions
more than I like revising the naming convention for partition-child
indexes vs. indexes created directly on a child table. But of course,
these are all arguable positions.
--
Robert Haas
EDB: http://www.enterprisedb.com
e:
1. Did I miss anything you wanted fixed in 0001?
2. Should 0001 be combined with 0002 or kept separate?
3. Do you have a preference between this version of 0003 and the older
revision that just ignored outer-join relids?
--
Robert Haas
EDB: http://www.enterprisedb.com
v6-0002-Consider-a-Result-n
On Tue, Sep 16, 2025 at 2:04 AM Michael Paquier wrote:
> one SQL function mapping to each C function we are testing?
Yes, I think we should do this, if possible.
--
Robert Haas
EDB: http://www.enterprisedb.com
really sure we want to do what Tom proposes here because, as
Pavel says, it would result in a lot of indexes containing special
characters in the name. But I do want us to try to find some way of
giving indexes on different expressions different names.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Sep 15, 2025 at 5:12 PM Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Sep 15, 2025 at 4:01 PM Tom Lane wrote:
> >> The primary error message is not varying, only the DETAIL/HINT, so
> >> I find this concern pretty far-fetched. Also, I believe that the
>
> and I omitted the hint/detail because it seems to add nothing,
Yeah, OK, that's fair.
--
Robert Haas
EDB: http://www.enterprisedb.com
this node is not
> + * generating anything in that case, just acting on tuples generated by the
> + * subplan. Otherwise, it contains the relids of the planner relation that
> + * the Result represents.
OK.
--
Robert Haas
EDB: http://www.enterprisedb.com
ge. All this verifies is that you caught an error. If you
let the error escape to the client you could have the expected output
test that you got the expected message.
I think it would be a better idea to structure this as a set of
SQL-callable functions and move a bunch of the logic int
lt_jsa_mask is set, so another thing this hook
can do is adjust that value. Or, for example, you can write a patch
that uses this infrastructure to associate state with each RelOptInfo,
and then you can use that state to decide how to set jsa_mask in
join_path_setup_hook. In other words, it's easier to make effective
use of those patches if you have the infrastructure provided by these
patches.
--
Robert Haas
EDB: http://www.enterprisedb.com
in a separate patch.
I'm not sure. To me, the munging of everything together under the name
"expr" is the root of the problem here, and since this patch isn't
really addressing that problem, it's kind of to one side of what I see
as the main point. However, that's a judgement call, and if you or
others see it differently, then so be it.
--
Robert Haas
EDB: http://www.enterprisedb.com
re going to expose that information.
--
Robert Haas
EDB: http://www.enterprisedb.com
tial_grouping_paths() passes a
relids set when creating UPPERREL_PARTIAL_GROUP_AGG; and
generate_union_paths() and generate_nonunion_paths() in prepunion.c
bubble up the underlying relids. AFAICS, a non-parallel,
non-partitionwise aggregate ends up with an empty relid set, and even
those cases end up with an empty relid set for the topmost grouping
rel, even if they create some other upper rels that do have non-empty
relid sets.
--
Robert Haas
EDB: http://www.enterprisedb.com
e is the most horribly idea anyone's
ever had, or anything remotely close to that. It could be that you
don't agree (perhaps rightly) or it could be that you agree in a
theoretical world but don't want to do the work to get there. So don't
understand this as a vigorous attempt to block the patch, just as me
giving my view of how I see it.
--
Robert Haas
EDB: http://www.enterprisedb.com
it's not what I was suggesting: I was suggesting
trying to do a calculation like space_used = -aggtransspace *
rowcount, not just using a <0 value as a sentinel.
--
Robert Haas
EDB: http://www.enterprisedb.com
ndant, doesn't it?
>
> What do you mean that the extensibility approach differs? Like that
> the type of extension_state is different?
I suspect the question here is about why not use the
index-by-planner-extension-ID approach for 0004. That could maybe
work, but here everything has to be a Node, so I feel like it would be
more contorted than the existing cases.
--
Robert Haas
EDB: http://www.enterprisedb.com
re" and authentication
> error) they need to connect to understand what is going on.
Would it address your concern if we reworded that error message to be
more clear that the file is going to be ignored? I think that proposal
would have a better chance of success than this o
On Fri, Sep 12, 2025 at 2:28 PM Robert Haas wrote:
> Is there a real need to pass XLogDumpPrivate to astreamer_wal_read or
> astreamer_archive_read? The only things that they need are archive_fd,
> archive_name, archive_streamer, archive_streamer_buf, and
> archive_streamer_read_p
But of course, in both error and non-error paths, we rely
on memory context cleanup to free memory for us, except in cases where
there's some specific reason to believe that's not good enough. I
doubt that there is any such reason in this case.
See src/backend/utils/mmgr/
uffer. That would require also moving the stuff out of
astreamer_wal_read() that knows about XLogRecPtr, but why does that
function need to know about XLogRecPtr? Couldn't the caller figure out
that part and just tell this function how many bytes are needed?
--
Robert Haas
EDB: http://www.enterprisedb.com
tting pulled a bit further down the garden path than
I really want to go trying to satisfy your desire to perform a
cross-check that I don't really understand and/or expose information
for which I don't see a clear need in my own work. What I need is for
all the baserels that appear in the final Plan tree to be properly
labelled.
--
Robert Haas
EDB: http://www.enterprisedb.com
LT_IMPLEMENTS_MINMAX_AGGREGATE?
That's a bit verbose; shorter alternatives welcome. The first two
could be merged, since the cardinality of the relid set should
distinguish them. Or it could be more like RESULT_REPLACES_SCAN,
RESULT_REPLACES_JOIN, RESULT_REPLACES_AGGREGATE,
RESULT_IMPLEMENTS_MINMAX_AGGREGATE, to more closely match what we
would presumably show in the EXPLAIN output.
Thoughts?
--
Robert Haas
EDB: http://www.enterprisedb.com
to assert that the
RTIs of a joinrel are the union of the RTIs we see in the plan tree,
the assertion is going to fail, because now the Whatever Join sees
RTIs 2 and 4 through its children and RTI 3 through its own ojrelid,
but the joinrel's RTIs are {2,4}, not {2,3,4}.
--
Robert Haas
EDB: http://www.enterprisedb.com
o crash and burn, but maybe it will do
so in such a way that I have some idea what to propose instead.
--
Robert Haas
EDB: http://www.enterprisedb.com
v5-0003-Ensure-that-all-joinrel-RTIs-are-discoverable-fro.patch
Description: Binary data
v5-0001-Keep-track-of-what-RTIs-a-Result-node-is-scan
On Wed, Sep 10, 2025 at 5:11 AM Amit Kapila wrote:
> The test for this case is added in commit
> 6456c6e2c4ad1cf9752e09cce37bfcfe2190c5e0.
Thanks!
--
Robert Haas
EDB: http://www.enterprisedb.com
;re doing instead is splitting half of those functions
off into a helper function while keeping the other half where they are
without cleaning up any of the logic. Now, maybe that's OK: I'm far
from having grokked the whole patch set. But it is not any more clear
than what we have now, IMHO, and perhaps even a bit less so.
--
Robert Haas
EDB: http://www.enterprisedb.com
{
+ PageSetAllVisible(page);
+ MarkBufferDirty(buf);
+ }
I really hate this. Maybe you're going to argue that it's not the job
of this patch to fix the awfulness here, but surely marking a buffer
dirty in case some other function decides to WAL-log it is a
ridiculous plan.
--
Robert Haas
EDB: http://www.enterprisedb.com
hat we should try to come up with a unified
approach here. I'm not sure exactly what it should look like, though.
I think the strongest part of your proposal is the fact that it
connects each Path node to the corresponding Plan node in a very clear
way, and I think that the weakest part of
On Tue, Sep 9, 2025 at 12:00 PM Robert Haas wrote:
> On Tue, Sep 9, 2025 at 11:12 AM Tom Lane wrote:
> > I think what would make a ton more sense is to add
> > an enum field to Result that explicitly identifies why it's there.
> > We've got at least "apply one
n trees with more
> information.
Oh, that seems quite elegant! Then we could reasonably expect to
re-find all the relevant RTIs and no others with an appropriate tree
traversal.
--
Robert Haas
EDB: http://www.enterprisedb.com
t; Anyway, I will add some test cases in eager_aggregate.sql with
> geqo_threshold set to 2.
Sounds good. I think GEQO is mostly-unmaintained these days, but if
we're updating the code, I think it is good to add tests. Being that
the code is so old, it probably lacks adequate test coverage.
--
Robert Haas
EDB: http://www.enterprisedb.com
only okay to set the VM bits without holding the heap page lock
+* because we can expect no other writers of this page.
It is not exactly clear to me whether "this page" here refers to the
heap page or the VM page. If it means the heap page, why should that
be so if we haven't got any kind of lock? If it means the VM page,
then why is the heap page even relevant?
--
Robert Haas
EDB: http://www.enterprisedb.com
ve been stored into joinpath->ojrelids at whatever
earlier stage we had the information available to do so, and it should
be equal to bms_intersect(joinrel->relids, root->outer_join_rels),
which I think would have to be already initialized before we can think
of building a join path.
Please feel free to correct me if I am misunderstanding.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
because if you make it errmsg_internal() then they
won't see it until somebody complains about it not getting translated.
However, I suspect different committers would pursue different
strategies here.
--
Robert Haas
EDB: http://www.enterprisedb.com
rd than the all-visible flag on the
page itself. It's a little hard for me to make that statement too
conclusively without studying more of the patches than I've had time
to do today, but off the top of my head it seems to make sense.
However, I'm not sure you've taken
ng on the error code.
That kibitzing aside, I think this is pretty clearly the right thing to do.
--
Robert Haas
EDB: http://www.enterprisedb.com
nd do that before this creates any more
confusion.
--
Robert Haas
EDB: http://www.enterprisedb.com
inux ACLs or SELinux security constraints, so that idea that we
can force "safe" permissions is a little bit laughable.
--
Robert Haas
EDB: http://www.enterprisedb.com
waste of code to me. If there's a way to calculate
outerjoin_relids using a different methodology than what we used when
populating the joinrelids, that would be interesting. It would be
similar to how the existing code recomputes the outer and inner relids
in a way that can potentially find issues that otherwise would not
have been spotted (such as the Result node case).
Do you have a proposal?
--
Robert Haas
EDB: http://www.enterprisedb.com
r_join_rels. Therefore, I'm not sure we can rely
on outer_join_rels in this scenario.
--
Robert Haas
EDB: http://www.enterprisedb.com
f it does go wrong, it will
not be too difficult for someone to understand why it has gone wrong,
which is very desirable.
> I think this heuristic serves as a good starting point, and we can
> look into extending it with more advanced strategies as the feature
> evolves.
So IOW, +1 to what you say here.
--
Robert Haas
EDB: http://www.enterprisedb.com
but
aggregating on the join column of the fact table has a good chance of
being useful. If we consider only one of those strategies, we want it
to be the right one. This threshold could be the thing that helps us
to get it right.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Sep 5, 2025 at 12:00 PM Tom Lane wrote:
> Plain (not-outer) joins will never be included in a relid set in the
> first place.
Ah, well then Richard's idea might work! Let me try it and see what happens...
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Aug 25, 2025 at 3:46 PM Robert Haas wrote:
> 0005 is a demo, not for commit, just to show how these pieces fit
> together. It uses the hooks from 0001 to count the number of times
> set_join_pathlist_hook is called and the number of those that are for
> distinct joinrels.
there were actually free
buffers remaining, it would prewarm less in that case.
I'm not saying that was the perfect idea, I'm just telling you what I
was thinking at the time.
--
Robert Haas
EDB: http://www.enterprisedb.com
ge it. But I feel like we need a clear reason to believe either
that we made the wrong decision back then, or that the situation is
different now, and at the moment I'm not really seeing one. AFAIK this
is similar to what other tools do, as in the ssh example above.
--
Robert Haas
EDB: http://www.enterprisedb.com
t on this strategy before discarding it? That might be a
good way to get a sense of whether the patch is too aggressive, not
aggressive enough, a mix of the two, or just right.
--
Robert Haas
EDB: http://www.enterprisedb.com
tial aggregation
> anyway.
This strategy seems fairly unfriendly towards out-of-core code. Can
you come up with something that allows the author of a SQL-callable
function to include or exclude the function by a choice that is under
their control, rather than hard-coding something in PostgreSQL itself?
--
Robert Haas
EDB: http://www.enterprisedb.com
hat we should just let objects be created
freely in the owned schema. Document the consequences of this and
blame any problems on user error.
(6) Your superior idea goes here!
--
Robert Haas
EDB: http://www.enterprisedb.com
doesn't for me. I understand it probably requires an injection
point to be certain of hitting the race condition, but I think that
would be worth doing. Otherwise, if something gets broken here by
accident, it might be a long time before anyone notices.
--
Robert Haas
EDB: http://www.enterprisedb.com
d do: ACCESS SHARE, SHARE, SHARE UPDATE EXCLUSIVE, EXCLUSIVE,
ACCESS EXCLUSIVE.
I've always thought that a pin was a lot like an access share lock and
a cleanup lock was a lot like an access exclusive lock.
But then again, using the same terminology for two different things
might be
ly argue that the nearest parallel to this level is
ShareUpdateExclusive: a self-exclusive lock level that permits
ordinary table access to continue while blocking exclusive locks, used
for an in-flight maintenance operation. But that's arguable, of
course.
--
Robert Haas
EDB: http://www.enterprisedb.com
f this than I do.
> DOES ANYBODY HAVE A BETTER NAME THAN SHARE-EXCLUSIVE???!?
AFAIK "share exclusive" or "SX" is standard terminology. While I'm not
wholly hostile to the idea of coming up with something else, I don't
think our tendency to invent our own way to d
dditional impulse.
See
http://postgr.es/m/CA+TgmoY=53ywd4dk4bpzco6h3dc0e8pdedtz_p2anm77ql0...@mail.gmail.com
for my proposal to address this issue.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Aug 20, 2025 at 3:13 PM Robert Haas wrote:
> Here's v2. 0001 is what you saw before with an attempt to fix the
> memory context handling. 0002 removes join_search_private. All I've
> tested is that the tests pass.
Here's v3 with a few more patches. I'm no
m. We don't have read support for these structs, so maybe it's fine.
> It looks weird though.
Left this one as-is for now.
Here's v2. 0001 is what you saw before with an attempt to fix the
memory context handling. 0002 removes join_search_private. All I've
tested is th
if extension_state etc is read_write_ignore, then
> extension_state_allocated etc had better be as well? I don't
> understand the rationale for preserving one without the other.
I figured we can't print a void** but we can print an integer and the
user might want to see it. Wrong idea?
--
Robert Haas
EDB: http://www.enterprisedb.com
le testing and
polishing. If people do not like this design, then I would like to
know what alternative they would prefer.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
v1-0001-Allow-private-state-in-certain-planner-data-struc.patch
Description: Binary data
cannot work, for the same reason. But manual slot operations can work,
so I do not think it is good to arbitrarily prohibit them. We do not
need a reason to specifically allow them; it is enough that there is
no good reason for them to be blocked.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Aug 11, 2025 at 1:55 PM Robert Haas wrote:
> [ some review ]
Another thing that's occurring to me here is that nothing prevents
other objects from making their way into the owned schema. Sure, if we
create a new schema with nobody having any permissions, then only the
creating
ionality because of an assertion failure that might just be
slightly sloppy coding.
--
Robert Haas
EDB: http://www.enterprisedb.com
s in AlterExtensionNamespace. In
the context of the patch, it's possible to puzzle out what is
happening, but I think the picture is not going to be clear to later
readers. It seems to me that this either needs some restructuring to
make the logical flow clearer, or a few well-written comments.
--
Robert Haas
EDB: http://www.enterprisedb.com
e exception for a couple valid changes under REPEATABLE
> READ and SERIALIZE, but I think they are expected and not a bug. (I
> think you would see the same thing outside of FKs.)
0001 and 0003 look OK to me on a quick read-through. 0002 seems to do
something horrible to isolation_schedul
t; 3. Change nothing. (This would be the choice if one is maximally concerned
>about deviating from the freeze and unconcerned about --enable-cassert
>builds of releases.)
>
> I am inclined to make today's change be (1).
Sounds right to me.
--
Robert Haas
EDB: http://www.enterprisedb.com
7;re doing
some kind of index scan and the contention is probably focused on the
upper-level index pages rather than the heap pages. You could maybe
imagine some crazy corner case where there's heap contention created
by TID scans, but that's too obscure a situation to justify adding
machinery of this kind.
--
Robert Haas
EDB: http://www.enterprisedb.com
bert didn't like 2a.
I think I like this a little better than your 2a. It's not a big deal, anyway.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Jul 28, 2025 at 2:42 PM Nathan Bossart wrote:
> On Mon, Jul 28, 2025 at 11:22:49AM -0400, Robert Haas wrote:
> > Committed. I removed the changes from the .po files since we don't
> > routinely update those, and I rewrote your proposal commit message.
>
> nitpick
mild preference so I am more than fine if
you want to just go ahead and do #2a as you proposed.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, May 26, 2025 at 7:40 AM Jakub Wartak
wrote:
> v2 attached, rebased and tested.
Committed. I removed the changes from the .po files since we don't
routinely update those, and I rewrote your proposal commit message.
--
Robert Haas
EDB: http://www.enterprisedb.com
raightforward enough that a
separate review was not required.
--
Robert Haas
EDB: http://www.enterprisedb.com
1 - 100 of 2163 matches
Mail list logo
