On Sat, Feb 19, 2022 at 1:19 AM Michael Paquier wrote:
> On Fri, Feb 18, 2022 at 06:53:10PM +0000, Robert Haas wrote:
> > Add support for building with ZSTD.
> >
> > This commit doesn't actually add anything that uses ZSTD; that will be
> > done separately. It ju
se surely the pruning code
can't just decide to go into an infinite loop if that happens. Code
that manipulates the states of data pages needs to be as robust
against arbitrary on-disk states as we can reasonably make it, because
pages get garbled on disk all the time.
--
Robert Haas
EDB: http://www.enterprisedb.com
to do better if there
> was a particularly bad case for the 0002 work, if one came to light.)
I think that the idea has potential, but I don't think that I
understand yet what the *exact* algorithm is. Maybe I need to read the
code, when I have some time for that. I can't form an intelligent
opinion at this stage about whether this is likely to be a net
positive.
--
Robert Haas
EDB: http://www.enterprisedb.com
roup of roles but isn't actually a group of roles -- and that thing
> > needs to prohibit self-revocation. Given what I've written above, you
> > may be able to guess my preferred solution: let's call it a TENANT.
> > Then, my pseudo-super-user can have
revoke joshua from admin;
> REVOKE ROLE
>
> =*> \du
> List of roles
> Role name | Attributes |
> Member of
> ---++-
> admin | Cannot login | {}
> employees | Cannot login | {}
> joshua||
> {employees}
> sfrost| Superuser, Create role, Create DB, Replication, Bypass RLS | {}
>
> Even though, in this case, it was 'sfrost' (a superuser) who GRANT'd
> joshua to admin.
Quite so.
--
Robert Haas
EDB: http://www.enterprisedb.com
. TPC-C (or any
benchmark really) is so simple as to be a terrible proxy for what
vacuuming is going to look like on real-world systems. Like, it's nice
that it works, and it shows that something's working, but it doesn't
demonstrate that the patch is making the right trade-offs overall.
--
Robert Haas
EDB: http://www.enterprisedb.com
en discussed a number of times, and Tom has basically
always said that he thinks this would be expensive to plan (which I
think is true) and that we wouldn't get much benefit (which I think is
false).
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Mar 1, 2022 at 5:53 PM Tom Lane wrote:
> Robert Haas writes:
> > This topic has been discussed a number of times, and Tom has basically
> > always said that he thinks this would be expensive to plan (which I
> > think is true) and that we wouldn't get much
It makes it easier to catch
everything if you ever need to update the code.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Mar 1, 2022 at 9:05 PM Tom Lane wrote:
> Robert Haas writes:
> > I agree. My question is: why shouldn't every case where we can deduce
> > an implied inequality be reasonably likely to show a benefit?
>
> Maybe it will be, if we can deal with the issue you alr
On Wed, Mar 2, 2022 at 11:09 AM Tom Lane wrote:
> Robert Haas writes:
> > So the questions in my mind here are all
> > about whether we can detect this stuff cheaply and whether anybody
> > wants to do the work to make it happen, not whether we'd get a benefit
> >
4 seems useful for testing, it's an awfully big hammer. I'm
not sure we should be thinking about committing something like that,
or at least not as a default part of the build. But ... maybe?
--
Robert Haas
EDB: http://www.enterprisedb.com
ink anything like that can work, both
because the two ALTER TABLESPACE commands could be performed in
different sessions, and also because an intervening checkpoint is no
guarantee of safety anyway, IIUC. So I'm just not really seeing a
reasonable strategy that isn't basically the barrier stuff.
--
Robert Haas
EDB: http://www.enterprisedb.com
st in
this patch and therefore it shouldn't be committed. It's the job of
the author to prove that there aren't and it should be. And I don't
think we're close to that at all.
--
Robert Haas
EDB: http://www.enterprisedb.com
d that ends in a segment or any other such
thing, they can use a WHERE clause for that... and if you think they
can't, then that should be good cause to rethink the return value of
the one-and-only SRF that I think you need here.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Mar 2, 2022 at 3:00 PM Andres Freund wrote:
> On 2022-03-02 14:52:01 -0500, Robert Haas wrote:
> > - I am having some trouble understanding clearly what 0001 is doing.
> > I'll try to study it further.
>
> It tests for the various scenarios I could think of tha
be dependent on row size, invalidations
> etc to a significant degree (unless the tables are too small to reach s_b
> etc)? The exact symptoms of failures are highly unstable, but obviously we'd
> fix them in-tree before committing a test. But maybe I'm missing a dependency?
>
> FWIW, the test did pass on freebsd, linux, macos and windows with the
> fix. After a few iterations of improving the fix ;)
Hmm. Well, I admit that's already more than I would have expected
--
Robert Haas
EDB: http://www.enterprisedb.com
didn't seem like we were
making any progress. And then a long time after that people were still
finding many server crashes with relatively simple test cases.
I agree that the feature is desirable, but I think getting there is
going to require a huge amount of effort that may amount to a total
r
sounds like that's not the common practice in
similar cases, and I don't personally see the point.
--
Robert Haas
EDB: http://www.enterprisedb.com
going to make things
any easier for users to grok if zstd is available in different parts
of the system but has different defaults in each place. It wouldn't be
the end of the world if that happened, but neither would it be ideal.
--
Robert Haas
EDB: http://www.enterprisedb.com
ow I might be beating a
dead horse here, comments. Now, admittedly, it does need to know the
size of each archive member up front in order to work, so if we can't
solve the problem then we can't go this route. But if we can't solve
that problem, then we also can't add LZ4 and ZST
ent said plan, we do not then
end up relitigating the whole thing and coming to a different
conclusion the second time. This being a community whose membership
varies from time to time and the opinions of whose members vary from
time to time, such misadventure can never be entirely ruled out.
However, I would like to minimize the chances of such an outcome as
much as we can.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
ot; can SET ROLE to "admin" and revoke it from "sally", and the
superuser has no tool to prevent this.
Now you can imagine a situation where the superuser is totally OK with
either "joe" or "sally" having the ability to lock the other one out,
but I don't think it's right to say that this will be true in all
cases.
--
Robert Haas
EDB: http://www.enterprisedb.com
is really going in that direction. That said, I do entirely
see your point. Are you thinking we'd actually add a GRANTED BY clause
to GRANT/REVOKE, vs. just wrapping it in SET ROLE incantations of some
sort?
--
Robert Haas
EDB: http://www.enterprisedb.com
es
> it would be advisable to use SET ROLE, else we'd be giving up
> an awful lot of backwards compatibility in dump scripts.
> But if we're only talking about role grants then I think
> GRANTED BY would work fine.
OK.
--
Robert Haas
EDB: http://www.enterprisedb.com
membership in said role. And certainly it's not bothersome
that the superuser can change whatever they want. The problem here is
just that a user with NO special privileges on any role, including
their own, can make changes that more privileged users might not like.
--
Robert Haas
EDB: http://www.enterprisedb.com
se way of designating a group of users for some
security critical purpose is threatened if people can make changes to
the membership of that group without being specifically authorized to
do so.
--
Robert Haas
EDB: http://www.enterprisedb.com
path for simple case */ which makes it
appear that it wasn't thought to be a behavior change at all, but it
looks to me like it was. Am I confused?
--
Robert Haas
EDB: http://www.enterprisedb.com
the
grantor-tracking thing discussed earlier, we can get to a place where
the same facility can be used for either purpose. That would, I think,
be a significant step forward over the status quo. In terms of how
things work today, see Joshua Brindle's email about the use of groups
in pg_hba.conf. That is an excellent example of how removing oneself
from a group could enable one to bypass security restrictions intended
by the DBA.
--
Robert Haas
EDB: http://www.enterprisedb.com
aven't had time yet to
investigate the matter.
--
Robert Haas
EDB: http://www.enterprisedb.com
nded, but also the resolution of references to other
objects mentioned in the CREATE COMMAND, as not intended. I don't see
a similar hazard here, but I'm worried that there might be one.
Declarative syntax is a very powerful tool for avoiding those kinds of
mishaps, and I think we should make as much use of it as we can.
--
Robert Haas
EDB: http://www.enterprisedb.com
ill disagree with the idea that LOGIN roles have to be leaf
nodes. We could have a system where that's true, but that's not how
the system we actually have is designed.)
--
Robert Haas
EDB: http://www.enterprisedb.com
ider relfilenode we will have
> this issue. Correct?
I think you are correct.
--
Robert Haas
EDB: http://www.enterprisedb.com
) before we get to this point if we somehow
run out of values, but it might be nice to have a check here as a
backup.
--
Robert Haas
EDB: http://www.enterprisedb.com
t; situation which is not currently supported.
It's been pointed out upthread that this would have undesirable
security implications, because the admin option would be inherited,
and the implicit permission isn't.
--
Robert Haas
EDB: http://www.enterprisedb.com
;
bound. My reasoning for that change is: if the number of bytes
remaining in the buffer is exactly equal to the maximum number we can
write, we don't need to flush it yet. If that sounds correct, we
should fix the LZ4 code the same way.
--
Robert Haas
EDB: http://www.enterprisedb.c
Right now, for LZ4
support we test HAVE_LIBLZ4, but TOAST and XLOG compression are
testing USE_LZ4, so I think we should be doing the same here. And
similarly I think we should be testing USE_ZSTD not HAVE_LIBZSTD.
Patch for that attached.
--
Robert Haas
EDB: http://www.enterprisedb.com
f
k the renaming I'm talking about up above might
help somewhat here, but it seems like it might also be good to change
the one that uses an out parameter by doing Get -> Copy, just to help
the reader get a clue a little more easily.
- GetNewRelNode() needs to error out if we would wrap around
before an angry Andres chases me
down, since I know he's working on the build system...
--
Robert Haas
EDB: http://www.enterprisedb.com
oper sub-page for your version".
It's kind of hard for me to imagine that not being enough for somebody.
--
Robert Haas
EDB: http://www.enterprisedb.com
you can supply your own
copy-function. And the fact that it's got an argument of type
copy_relation_storage and the argument name is copy_storage and the
value is sometimes RelationCopyStorageis a terminological muddle, too.
So I feel like perhaps this needs more thought.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Wed, Mar 9, 2022 at 7:55 AM Peter Eisentraut
wrote:
> Do we have subtractive permissions today?
Not in the GRANT/REVOKE sense, I think, but you can put a user in a
group and then mention that group in pg_hba.conf. And that line might
be "reject" or whatever.
--
Robert H
eis a terminological muddle, too.
> > So I feel like perhaps this needs more thought.
>
> One option is that we can duplicate this loop in dbcommand.c as well
> like we are having it already in tablecmds.c and heapam_handler.c?
Yeah, I think this is also worth considering.
--
Robert Haas
EDB: http://www.enterprisedb.com
nclined to think that the small number of people who may be unhappy
is an acceptable price to pay for removing this wart, but it's a
judgement call and if someone has information to suggest that I'm
wrong, it'd be good to hear about that.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
remove-self-admin.patch
Description: Binary data
t class without the underlying plane ticket. What would
the syntax look even like for this? GRANT foo TO bar WITH ADMIN OPTION
BUT WITHOUT MEMBERSHIP? Yikes.
But do we really have to solve this problem before we can clean up
this session exception? I hope not, because I think that's a much
bigger
f this ought to work. I don't say that we have to have a
> complete patch right away, only that we need a coherent end goal.
I'd like to have a plan, too, but if this behavior is accidental, I
still think we can remove it without making big decisions about future
direction. The perfect is the enemy of the good.
--
Robert Haas
EDB: http://www.enterprisedb.com
ate a separate path which tests the new option as well as the
> existing options.
FWIW, src/bin/scripts/t/020_createdb.pl does a little bit of testing
of this kind.
--
Robert Haas
EDB: http://www.enterprisedb.com
relmap-refactor-rmh.patch
Description: Binary data
rship. Marc invented it. Now Tom has invented it
independently. All sorts of other objects have it already. Trying to
make it out like this is some kind of kooky idea is not believable.
Yeah, it's not the most sophisticated or elegant model and that's why
it's good for us to also have ot
t people configure whichever
behavior they want. My bet is 95% of users would prefer to have it on,
but even if that's wildly wrong, having it as an optional behavior
hurts nobody. Let it be off by default and let those who want it flip
the toggle. On the code quality issue, I haven&#x
ould explain how I could use it to
create the mini-superusers that I'm trying to get out of this thing,
even better.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Mar 10, 2022 at 2:05 PM Peter Eisentraut
wrote:
> On 09.03.22 14:02, Robert Haas wrote:
> > On Wed, Mar 9, 2022 at 7:55 AM Peter Eisentraut
> > wrote:
> >> Do we have subtractive permissions today?
> >
> > Not in the GRANT/REVOKE sense, I think, but y
standard either, exactly, but might not that
allow the database owner to get a peek at what's happening in other
databases?
--
Robert Haas
EDB: http://www.enterprisedb.com
#5 which allows
> us to define user profiles and then grant the ability for a user to
> create a role with a certain profile (but not any arbitrary profile),
> thus making things like the 'bot' even more constrained in terms of
> what it's able to do (maybe it can then create a role that's a member of
> a role without itself being a member of that role or explicitly having
> admin rights in that role, as an example).
Right. I don't object to this either, hypothetically, but I think
we're a long way from understanding how to get there, and I don't want
step #1 to get blocked behind all the rest of this. Particularly the
part where we remove the role self-administration thing.
--
Robert Haas
EDB: http://www.enterprisedb.com
idn't GRANT it (at least, that's my thinking on this).
Agree. I also think that it would be a good idea to attribute grants
performed by any superuser to the bootstrap superuser, or leave them
unattributed somehow. Because otherwise dropping superusers becomes a
pain in the tail for no go
not a
superuser, but doesn't have the replication privilege). How would they
accomplish that in your view?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Thu, Mar 10, 2022 at 5:00 PM Bruce Momjian wrote:
> On Thu, Mar 10, 2022 at 02:22:05PM -0500, Robert Haas wrote:
> > I mean, I didn't design pg_hba.conf, but I think it's part of the
> > database doing a reasonable thing, not an external system doing a
> > nons
lar seems well below the standard that anyone would consider
committable today. On the other hand, even the parts of the code that
are in reasonable shape from a code quality point of view don't
actually do the things that we think users want done.
--
Robert Haas
EDB: http://www.enterprisedb.com
at's an unrecoverable error, because we
will not be able to run any queries at all, so FATAL is appropriate.
--
Robert Haas
EDB: http://www.enterprisedb.com
is being compressed on the server,
then decompressed, and then recompressed again, and the performance of
the resulting pipeline will probably not be very good. So I think we
should just refuse this command. Patch for that attached.
--
Robert Haas
EDB: http://www.enterprisedb.com
reject-compressed-inject.patch
Description: Binary data
m is apparently less convinced, and you know, I
think that's OK. Not everybody has to agree with the way you want to
do it.
--
Robert Haas
EDB: http://www.enterprisedb.com
in the current system. It looks pretty crap to me, but it's
easy to bring too much of one's own bias to such judgements.
--
Robert Haas
EDB: http://www.enterprisedb.com
r the creating superuser or, indeed, every superuser
in the system. Or we can leave it out. The result will be exactly the
same. Here, I would favor leaving it out, because extra catalog
entries that don't do anything are usually a thing that we do not
want. See a49d081235997c67e8aab7a523b17e8
es admin option on a role sufficient to drop the role. I've never
had any luck understanding what the SQL specification is saying about
any topic.
--
Robert Haas
EDB: http://www.enterprisedb.com
th of you are
absolutely bent on having it the way you want it, either one of you is
going to be sad, or we're not going to make any progress.
Never mind the fact that neither of you seem interested in even giving
a hearing to my preferred way of doing it. :-(
--
Robert Haas
EDB: http://www.enterprisedb.com
; make
> them all less magic.
>
> commit 1fb1e21ba7a500bb2b85ec3e65f59130fcdb4a7e
> Author: Justin Pryzby
> Date: Thu Mar 10 21:22:16 2022 -0600
Yeah, your patch looks right. Committed that, too.
--
Robert Haas
EDB: http://www.enterprisedb.com
tead of a relpersistence value. I thought that this problem might
be only cosmetic, but I checked the code that actually does the copy,
and there's no filter there on relpersistence either. And I think
there should be.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, Mar 11, 2022 at 1:10 PM Robert Haas wrote:
> I don't think you've adequately considered temporary relations here.
> It seems to be that ReadBufferWithoutRelcache() could not be safe on a
> temprel, because we'd need a BackendId to access the underlying
&g
On Tue, Feb 15, 2022 at 11:26 AM Robert Haas wrote:
> On Wed, Feb 9, 2022 at 8:41 AM Abhijit Menon-Sen wrote:
> > It took me a while to assimilate these patches, including the backup
> > targets one, which I hadn't looked at before. Now that I've wrapped my
> > he
ames seem kind of generic for what
they're doing. Maybe ScanSourceDatabasePgClass,
ScanSourceDatabasePgClassPage, ScanSourceDatabasePgClassTuple?
--
Robert Haas
EDB: http://www.enterprisedb.com
se we skip over a page
header) or end before the specified end LSN (e.g. because we reach
end-of-WAL) the user can figure it out from looking at the LSNs in the
output rows and comparing them to the LSNs provided as input.
--
Robert Haas
EDB: http://www.enterprisedb.com
f people running into problems quite a lot.
--
Robert Haas
EDB: http://www.enterprisedb.com
overflow a uint32 with that, but exceeding MaxAllocSize seems possible.
I believe that wal_level=logical can generate very large update and
delete records, especially with REPLICA IDENTITY FULL.
--
Robert Haas
EDB: http://www.enterprisedb.com
he whole system down to recover from that seems excessively
painful.
--
Robert Haas
EDB: http://www.enterprisedb.com
em is that the existing code tells the gzip
library to emit the tar header as part of the compressed stream
without actually compressing it, and then it goes back and overwrites
that data later! Unsurprisingly, that's not a feature every
compression library offers.
--
Robert Haas
EDB: http://www.enterprisedb.com
;t written
any.
In short, I think this patch is not really very close to being in
committable shape even if nobody were objecting to the concept.
--
Robert Haas
EDB: http://www.enterprisedb.com
lear. Not sure exactly how to do that,
just saying that we can't add behavior unless it will be clear to
users what the behavior is.
> Sure, I'll add documentation. To be honest I'm not targeting PG15 with
> this, just want to make some progress.
wfm!
--
Robert Haas
EDB: http://www.enterprisedb.com
's
easy to see how this could be generalized to other strategies in the
future.
--
Robert Haas
EDB: http://www.enterprisedb.com
which seems more sensible than the way I had it before.
--
Robert Haas
EDB: http://www.enterprisedb.com
relmap-rmh-refactor-v2.patch
Description: Binary data
On Mon, Mar 14, 2022 at 12:04 PM Robert Haas wrote:
> On Mon, Mar 14, 2022 at 7:51 AM Dilip Kumar wrote:
> > Other than that, I have fixed some mistakes in comments and supported
> > tab completion for the new options.
>
> I was looking at 0001 and 0002 again and realiz
On Mon, Mar 14, 2022 at 12:44 PM Dilip Kumar wrote:
> On Mon, Mar 14, 2022 at 10:04 PM Robert Haas wrote:
> > Regarding 0004, I can't really see a reason for this function to take
> > a LockRelId as a parameter rather than two separate OIDs. I also can't
> > entir
al_compression and pg_dump.
> And libpq, if that patch progresses.
>
> BTW, I think this may be better left for PG16.
Possibly so ... but if we're thinking of any revisions to the
newly-added grammar, we had better take care of that now, before it's
set in stone.
--
Robert Haas
EDB: http://www.enterprisedb.com
tructure there too, maybe one for each compression
> method, or maybe a union{} to handles them all). Most of the ~100 lines to
> support wal_compression='zstd:N' are to parse out the N.
Yes, it's actually a very simple feature now that we've got the rest
of the infrastructure set up correctly for it.
--
Robert Haas
EDB: http://www.enterprisedb.com
ld, appear
> to have survived multiple commits that moved the SubPlan expression
> processing code around.
>
> Attached patch removes those.
Looks right to me. Tom, any comments?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Mon, Mar 14, 2022 at 1:45 PM Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Feb 2, 2022 at 3:08 AM Amit Langote wrote:
> >> Attached patch removes those.
>
> > Looks right to me. Tom, any comments?
>
> I'm pretty sure I left those comments alone on pu
e event that
they have that plan. If, however, no such person exists, I may try my
hand at that myself.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
. And ... everyone else has no idea
what to do.
--
Robert Haas
EDB: http://www.enterprisedb.com
somebody tries to apply
valgrind to this code the useless initializations will just cover up
what valgrind would otherwise detect as an access to uninitialized
memory.
Please let's move on. There are almost 300 patches in this CommitFest
and many of them add nifty features or fix demonstrable bugs. This
does neither.
--
Robert Haas
EDB: http://www.enterprisedb.com
or not. I
think this scheme comes about because there are a couple of different
interfaces to the parameterized query stuff, and in some code paths we
have the values early enough to use them for pre-pruning, and in
others we don't.
--
Robert Haas
EDB: http://www.enterprisedb.com
etty confusing design, but what
the patch does seems to be consistent with that, so it appears correct
to me.
Therefore, I have committed it.
--
Robert Haas
EDB: http://www.enterprisedb.com
this
CommitFest entry open is not in the best interest of the project. The
patch we'd theoretically be committing doesn't exist yet and doesn't
do what the subject line suggests.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
27;ve studied this
afternoon, and, well, none of them have been back-patchable code
defects.
--
Robert Haas
EDB: http://www.enterprisedb.com
tion for that? I'm not saying that we definitely should do it
that way rather than this way, but I think we do take that approach in
some cases.
Thanks,
--
Robert Haas
EDB: http://www.enterprisedb.com
ink every back-branch will require different adjustments.
--
Robert Haas
EDB: http://www.enterprisedb.com
v5-0001-Fix-possible-recovery-trouble-if-TRUNCATE-overlap.patch
Description: Binary data
dling it?
Well, I mean, that function has a special case for
GLOBALTABLESPACE_OID, but GLOBALTABLESPACE_OID is 1664, and InvalidOid
is 0.
> I think we can shorten these function names to probably
> ScanSourceDBPgClassRel(), ScanSourceDBPgClassTuple() and likewise?
We could, but I don't think it's an improvement.
--
Robert Haas
EDB: http://www.enterprisedb.com
On Tue, Mar 15, 2022 at 12:58 PM Peter Eisentraut
wrote:
> On 14.03.22 19:57, Robert Haas wrote:
> > 1. What will happen if I set the ICU collation to something that
> > doesn't match the libc collation? How bad are the consequences?
>
> These are unrelated, so there are
ESPACE_OID, but GLOBALTABLESPACE_OID is 1664, and InvalidOid
> > is 0.
> >
>
> Wouldn't this be true only in case of a shared map file (when dbOid is
> Invalid and tblspcOid is globaltablespace_oid) or am I missing
> something?
*facepalm*
Good catch, sorry that I'm slow on the uptake today.
v3 attached.
--
Robert Haas
EDB: http://www.enterprisedb.com
relmap-refactor-rmh-v3.patch
Description: Binary data
not
> supported, should we instead just throw a warning and fall back to
> non-parallel behavior?
I don't think so. I think it's better for the user to get an error and
then change their mind and request something we can do.
--
Robert Haas
EDB: http://www.enterprisedb.com
Continuing my pass through the "bug fixes" section of the CommitFest,
I came upon this patch, which is contested. Here is my attempt to
summarize where things stand. As I understand it:
- Tom wants to revert to the previous behavior of accepting arbitrary
garbage, so that \d slkgjskld.jgdsjhgjklsd
t in a position to tell Tom that he has to go write a different fix
instead, or even that such a fix is possible. Unless somebody else
wants to comment, which IMHO would be good, I think it's up to Tom to
make a decision here on how he'd like to proceed and then, probably,
jus
that we don't have
meaningful downsides and we don't have tunables for users to fiddle
with, it might be worth it.
--
Robert Haas
EDB: http://www.enterprisedb.com
1 - 100 of 7889 matches
Mail list logo
