[2/4] - sepostgresql-sepgsql-8.4devel-3.patch.gz
This patch provides SE-PostgreSQL facilities based on PGACE.
Security-Enhanced PostgreSQL (SE-PostgreSQL) is a security extension
built in PostgreSQL, to provide system-wide consistency in access
controls. It enables to apply a single unigied
Zdenek Kotala wrote:
Kohei KaiGai napsal(a):
It seems to me some of SE-PostgreSQL patches are not delivered yet,
although [3/4] and [4/4] were already done.
Does anti-spam system caught my previous three messages?
If necessary, I will send them again.
There is a file size limitation. If
On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
The idea that's becoming attractive to me while contemplating the
multiple-maps problem is that we should adopt something similar to
the old Mac OS idea of multiple forks in a relation. In addition
to the main
Kohei KaiGai napsal(a):
It seems to me some of SE-PostgreSQL patches are not delivered yet,
although [3/4] and [4/4] were already done.
Does anti-spam system caught my previous three messages?
If necessary, I will send them again.
There is a file size limitation. If your patch is too big (I
Greg Smith wrote:
On Sun, 16 Mar 2008, Bruce Momjian wrote:
Oh, what I would really like is to be able to pull up
archives.postgresql.org emails based on message id so I can link to
the entire thread. Unfortunately, it doesn't work there, nor does
Google or any of the other Postgres email
Request Overview
Add a function to return the current PGConn used within ecpg..
Background
--
For years now within the Aubit4GL project we've been able to access the PGConn
record used by ecpg by the highly dubious means of accessing an internal
record within ecpg
2. If you've got lots of equal keys, it's conceivable that having the
index entries sorted by TID offers some advantage in indexscan speed.
I'm dubious that that's useful, mainly because the planner should
prefer
a bitmap scan in such a case; and anyway the ordering is unlikely to
be
Tom Lane wrote:
There are several places in tuplesort.c (and perhaps elsewhere) where
we explicitly work around limitations of various platforms' qsort()
functions. Notably, there's this bit in comparetup_index_btree
/*
* If key values are equal, we sort on ItemPointer. This does
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
We currently execute a lot of joins as Nested Loops which would be more
efficient if we could batch together all the outer keys and execute a single
inner bitmap index scan for all of them together.
Please give an
Hannu Krosing [EMAIL PROTECTED] writes:
On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
The idea that's becoming attractive to me while contemplating the
multiple-maps problem is that we should adopt something similar to
the old Mac OS idea of multiple forks in a
Zeugswetter Andreas OSB SD [EMAIL PROTECTED] writes:
How about always adding the TID as last key when using qsort for create
index ?
I think you misunderstood: that's what we do now. I'm proposing
removing it because I think it's probably useless.
regards, tom lane
--
Magnus Hagander wrote:
Log Message:
---
Some cleanups of enum-guc code, per comments from Tom.
These bits seem to have broken --describe-config:
LC_ALL=C postmaster --describe-config /dev/null
internal error: unrecognized run-time parameter type
internal error: unrecognized run-time
Tom Lane wrote:
Another possibility (though not a back-patchable solution) is that
we could just dispense with the heuristic size estimate and trust a
zero-sized table to stay zero-sized. This would be relying on the
assumption that autovacuum will kick in and update the stats, leading
to
Alvaro Herrera wrote:
Kohei KaiGai wrote:
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can
I'll submit the proposal of SE-PostgreSQL patches again, because some of
previous
messages are filtered due to attachment and I cannot provide whole of patches
yet.
Please refer the pointed URL, as follows.
--
The series of patches are the proposal of Security-Enhanced PostgreSQL
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
You're cavalierly waving away a whole boatload of problems that will
arise as soon as you start trying to make the index AMs play along
with this :-(.
It doesn't seem very hard.
The problem is that the index AMs are no longer in
On Mon, 2008-03-17 at 09:29 -0400, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
The idea that's becoming attractive to me while contemplating the
multiple-maps problem is that we should adopt something
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I've started working on revamping Free Space Map, using the approach
where we store a map of heap pages on every nth heap page. What we need
now is discussion on the details of how exactly it should work.
You're cavalierly waving
Kohei KaiGai wrote:
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can it be licensed under BSD
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Please give an example of what you're talking about that you think we
can't do now.
Note that we're doing a full sequential scan of a even though we've already
finished hashing b and know full well which keys we'll
KaiGai Kohei wrote:
Alvaro Herrera wrote:
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can it be licensed under BSD terms?
All of SE-PostgreSQL works are licensed unser BSD terms.
We are considering to push SE-PostgreSQL into
Alvaro Herrera wrote:
KaiGai Kohei wrote:
Alvaro Herrera wrote:
Before we go any further, is this work derived from SELinux? If so, is
it covered under the GPL? If so, can it be licensed under BSD terms?
All of SE-PostgreSQL works are licensed unser BSD terms.
We are considering to push
Alvaro Herrera [EMAIL PROTECTED] writes:
These bits seem to have broken --describe-config:
(Perhaps they were already broken in the previous patch, not sure).
It was already broken :-(. Not sure how both Magnus and I missed
the switch in help_config.c --- I know I grepped for references to
the
Hi All,
Is it me or none of the mirror names can be resolved?
ftp.fr.postgresql.org host unknown
ftp.fr4.postgresql.org host unknown
Regards
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
15, Chemin des Monges+33-5-61-50-97-01 (Fax)
31190 AUTERIVE
Magnus Hagander wrote:
I was thinking of writing something that scraped the archives building a
lookup table out of this information. What would be nice is if the
X-Message-Id and X-Reference were both put into the regular HTML for
future archived messages so that it's more likely
Greg Smith wrote:
On Sun, 16 Mar 2008, Bruce Momjian wrote:
Oh, what I would really like is to be able to pull up
archives.postgresql.org emails based on message id so I can link to the
entire thread. Unfortunately, it doesn't work there, nor does Google or
any of the other Postgres
I'm getting the same here...
Just went to download 8.3 (if anyone has an alternate mirror...)
On Monday 17 March 2008 15:07:58 [EMAIL PROTECTED] wrote:
Hi All,
Is it me or none of the mirror names can be resolved?
ftp.fr.postgresql.org host unknown
ftp.fr4.postgresql.org host unknown
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Please give an example of what you're talking about that you think we
can't do now.
Note that we're doing a full sequential scan of a even though we've already
finished hashing b
On Mon, Mar 17, 2008 at 3:07 PM, [EMAIL PROTECTED] wrote:
Hi All,
Is it me or none of the mirror names can be resolved?
ftp.fr.postgresql.org host unknown
ftp.fr4.postgresql.org host unknown
Should be OK now:
snake:~ dpage$ nslookup ftp.fr.postgresql.org
Server: 172.24.32.2
On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
Tom Lane wrote:
The idea that's becoming attractive to me while contemplating the
multiple-maps problem is that we should adopt something similar to
the old Mac OS idea of multiple forks in a relation. In addition
to the main
Pavan Deolasee [EMAIL PROTECTED] writes:
[ patch to reduce probability of deadlock of CREATE INDEX CONCURRENTLY
with other things ]
This patch no longer applies because of the VirtualXid changes.
Looking at it again, I'm fairly dissatisfied with it anyway;
I really don't like moving the
Tom Lane [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] writes:
My original thought was to have a separate RelFileNode for each of the
maps. That would require no smgr or xlog changes, and not very many
changes in the buffer manager, though I guess you'd more catalog
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
We are sucking a lot of this data down to the db on
search.postgresql.org already. Does it make sense to do it there
perhaps? Is there need for anything more than a unique-messageid-hit? If
that's all we need, we could easily
Gregory Stark [EMAIL PROTECTED] writes:
It would be ideal if it could scan the invoices using an index, toss them all
in a hash, then do a bitmap index scan to pull out all the matching detail
records. If there are multiple batches it can start a whole new index scan for
the each of the
Peter Eisentraut [EMAIL PROTECTED] writes:
... I'm not sure about the terminology position and instance; they're
just two coordinates to get at the problem.
None of this will help if you have multiple unrelated clauses that
invoke select_common_type(), but that might be better handled using
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Heikki Linnakangas [EMAIL PROTECTED] writes:
My original thought was to have a separate RelFileNode for each of the
maps. That would require no smgr or xlog changes, and not very many
changes in the buffer manager, though I
Regarding to discussion about large segment size of table files a test
pathconf function (see
http://www.opengroup.org/onlinepubs/009695399/functions/pathconf.html).
You can see output there:
_PC_FILESIZEBITS - 3rd column
_PC_LINK_MAX - 4th column
_PC_NAME_MAX - 5th column
_PC_PATH_MAX
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
We are sucking a lot of this data down to the db on
search.postgresql.org already. Does it make sense to do it there
perhaps? Is there need for anything more than a unique-messageid-hit? If
that's all we
On Mon, 17 Mar 2008, KaiGai Kohei wrote:
I'll submit the proposal of SE-PostgreSQL patches again, because some of
previous
messages are filtered due to attachment and I cannot provide whole of patches
yet.
This is actually what you should have done from the beginning. And it
only should
All,
First, the new comment interface doesn't work on Konqueror/Safari, which is
the problem I think many people are having. Use firefox instead.
Second, I plan to do a wiki-level summary of pending patches for the 2nd
commit fest. For the first one, raw data wasn't available before the
Gregory Stark [EMAIL PROTECTED] writes:
It would be ideal if it could scan the invoices using an index, toss them all
in a hash, then do a bitmap index scan to pull out all the matching detail
records. If there are multiple batches it can start a whole new index scan for
the each of the
KaiGai,
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Since I'm (Finally!) expecting the TrustedSolaris folks to put some work into
PostgreSQL as well this year, I'm going to ask them to look over
On Mon, 17 Mar 2008, Magnus Hagander wrote:
We are sucking a lot of this data down to the db on search.postgresql.org
already. Does it make sense to do it there perhaps?
No, using the database for this sort of thing is so old-school at this
point. Didn't you hear that good web applications
Gregory Stark [EMAIL PROTECTED] writes:
One advantage of using separate relfilenodes would be that if we need to
regenerate a map we could do it in a new relfilenode and swap it in like we do
with heap rewrites.
You could probably do that using a temporary fork number, if the
situation ever
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
The idea that's becoming attractive to me while contemplating the
multiple-maps problem is that we should adopt something similar to
the old Mac OS idea of multiple forks in a relation.
Can we call them maps or metadata maps? forks sounds
Magnus Hagander wrote:
Gregory Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
We are sucking a lot of this data down to the db on
search.postgresql.org already. Does it make sense to do it there
perhaps? Is there need for anything more than a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
These bits seem to have broken --describe-config:
(Perhaps they were already broken in the previous patch, not sure).
It was already broken :-(. Not sure how both Magnus and I missed
the switch in help_config.c --- I know I grepped for
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
It would be ideal if it could scan the invoices using an index, toss them all
in a hash, then do a bitmap index scan to pull out all the matching detail
records. If there are multiple batches it can start a whole new
On Mon, 2008-03-17 at 13:23 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
The idea that's becoming attractive to me while contemplating the
multiple-maps problem is that we should adopt something similar to
the old Mac OS idea of multiple forks in a
Am Samstag, 15. März 2008 schrieb Tom Lane:
I found that when I added a new .o file in backend/access/hash while
working in an already-built source tree, the objfiles.txt file in that
directory got updated, but the one in backend/access did not, leading to
link failure. Seems there's a
On Mon, Mar 17, 2008 at 01:23:46PM -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Tom Lane wrote:
The idea that's becoming attractive to me while contemplating
the multiple-maps problem is that we should adopt something
similar to the old Mac OS idea of multiple forks in a
Greg Smith [EMAIL PROTECTED] writes:
On Mon, 17 Mar 2008, KaiGai Kohei wrote:
I'll submit the proposal of SE-PostgreSQL patches again, because some of
previous
messages are filtered due to attachment and I cannot provide whole of
patches yet.
This is actually what you should have done
On Mon, Mar 17, 2008 at 6:23 PM, Tom Lane wrote:
Simon Riggs writes:
Can we call them maps or metadata maps? forks sounds weird.
I'm not wedded to forks, that's just the name that was used in the
only previous example I've seen. Classic Mac had a resource fork
and a data fork within
On Mon, 2008-03-17 at 13:23 -0400, Tom Lane wrote:
I'm not wedded to forks, that's just the name that was used in the
only previous example I've seen. Classic Mac had a resource fork
and a data fork within each file.
Don't think I like maps though, as (a) that prejudges what the
alternate
Added to TODO:
o Allow Kerberos to disable stripping of realms so we can
check the [EMAIL PROTECTED] against multiple realms
http://archives.postgresql.org/pgsql-hackers/2007-11/msg9.php
Tom Lane [EMAIL PROTECTED] writes:
I'm not wedded to forks, that's just the name that was used in the
only previous example I've seen. Classic Mac had a resource fork
and a data fork within each file.
fwiw forks are not unique to MacOS, c.f.:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
You're cavalierly waving away a whole boatload of problems that will
arise as soon as you start trying to make the index AMs play along
with this :-(.
It doesn't seem very hard.
The problem is that the index
On Mon, Mar 17, 2008 at 6:23 PM, Tom Lane [EMAIL PROTECTED] wrote:
I'm not wedded to forks, that's just the name that was used in the
only previous example I've seen. Classic Mac had a resource fork
and a data fork within each file.
Don't think I like maps though, as (a) that prejudges
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I don't understand which part of we can do that now isn't clear to you.
Uh, except we can't.
I already demonstrated that we could. If the problem is that the
planner is cutting over from one plan type to the other at
Josh Berkus [EMAIL PROTECTED] writes:
First, the new comment interface doesn't work on Konqueror/Safari, which is
the problem I think many people are having. Use firefox instead.
Can't say about Konqueror, but the comments work fine in Safari (as
long as you don't turn off Javascript).
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
First, the new comment interface doesn't work on Konqueror/Safari, which is
the problem I think many people are having. Use firefox instead.
Can't say about Konqueror, but the comments work fine in Safari (as
long as you don't turn
On Mon, 17 Mar 2008, Gregory Stark wrote:
Some people shout any time you send patches to -hackers.
Right, but if you note the improved version I give the thumbs-up to didn't
include any patches--just links to where you could get them. There's
little reason to include any code as an
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I don't understand which part of we can do that now isn't clear to you.
Uh, except we can't.
I already demonstrated that we could. If the problem is that the
planner is cutting
Added to TODO:
o Fix server restart problem when the server was shutdown during
a PITR backup
http://archives.postgresql.org/pgsql-hackers/2007-11/msg00800.php
---
Albe Laurenz wrote:
If the
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I think if they can run Gen_fmgrtab, they can get this to work.
They can't.
They can't run Gen_fmgrtab or they can't get this to work?
They can't run Gen_fmgrtab.
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I already demonstrated that we could.
We seem to be talking past each other. The plan you showed is analogous but
using a plain old index scan.
That's only because that seemed like the appropriate thing for the given
Added to TODO:
o Remove pre-7.3 pg_dump code that assumes pg_depend does not exit
---
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
Whether there's any need to support the old protocol in the server
I wrote:
Were there any objections to changing this patch so that it reports
the second expression's parser location, instead of some arbitrary
numbers? The way I'm envisioning doing it is:
1. Invent an exprLocation() function (comparable to, say, exprType)
that knows how to get the parser
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I already demonstrated that we could.
We seem to be talking past each other. The plan you showed is analogous but
using a plain old index scan.
That's only because that seemed
尊敬的公司领导负责人(经理／财务)您们好！
我是深圳市益鹏湾实业有限公司的，由于我司进项较多，
实力雄厚！现有多余的进项发票可以对外代开。具体有广东
省统一发票;（有商品销售、服务、广告、建筑安装、运输
电脑票）以及增值税电脑票和海关代征增值税发票都可代开
！一切票可等贵公司验征后付款．我司采取最优惠的点数来
向外代开，可为贵公司节约一部份资金．
贵公司如有需要欢迎来电咨询。本邮件设置定时发送，
如有打扰敬请原谅！
祝
商祺！
Tom Lane [EMAIL PROTECTED] writes:
Or we could apply Peter's patch more or less as-is, but I don't like
that. I don't think it solves the stated problem: if you know that CASE
branches 3 and 5 don't match, that still doesn't help you in a monster
query with lots of CASEs. I think we can and
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Nested Loop (cost=5.39..198.81 rows=51 width=244)
- HashAggregate (cost=1.06..1.11 rows=5 width=4)
- Seq Scan on int4_tbl b (cost=0.00..1.05 rows=5 width=4)
- Bitmap Heap Scan on tenk1 a (cost=4.33..39.41
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Or we could apply Peter's patch more or less as-is, but I don't like
that. I don't think it solves the stated problem: if you know that CASE
branches 3 and 5 don't match, that still doesn't help you in a monster
query
I have posted proposed patches to pgsql-patches.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
I would like to propose new large object client side API for 8.4.
Currently we have:
Oid lo_import(PGconn *conn, const char *filename);
But we do not have an API which imports a large object
Josh Berkus wrote:
KaiGai,
The series of patches are the proposal of Security-Enhanced PostgreSQL
(SE-PostgreSQL) for the upstreamed PostgreSQL 8.4 development cycle.
Since I'm (Finally!) expecting the TrustedSolaris folks to put some work into
PostgreSQL as well this year, I'm going to
Greg Smith wrote:
On Mon, 17 Mar 2008, KaiGai Kohei wrote:
I'll submit the proposal of SE-PostgreSQL patches again, because some
of previous
messages are filtered due to attachment and I cannot provide whole of
patches yet.
This is actually what you should have done from the beginning. And
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 18 Mar 2008 10:41:42 +0900
KaiGai Kohei [EMAIL PROTECTED] wrote:
GPL is a perfectly good license, but it's far from clear whether
code derived from it can be incorporated into PostgreSQL even if
you wrote all of it yourself. I just
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 18 Mar 2008 10:41:42 +0900
KaiGai Kohei [EMAIL PROTECTED] wrote:
GPL is a perfectly good license, but it's far from clear whether
code derived from it can be incorporated into PostgreSQL even if
you wrote all of it
Added to TODO:
o Recreate pg_xlog/archive_status/ if it doesn't exist after
restoring from a PITR backup
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00487.php
---
Simon Riggs
Joshua D. Drake [EMAIL PROTECTED] writes:
Everything that I read says that libselinux is GPL.
What exactly did you read? The LICENSE file in the source tarball
says
: This library (libselinux) is public domain software, i.e. not copyrighted.
:
: Warranty Exclusion
: --
: You
Tom,
I believe you were the one to object to this proposal pre 8.3 ?
To me it seems innocuous. Most high level db abstractions allow access
to the underlying connection.
Dave
On 17-Mar-08, at 7:26 AM, Mike Aubury wrote:
Request Overview
Add a function to return the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 17 Mar 2008 22:45:14 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Everything that I read says that libselinux is GPL.
What exactly did you read? The LICENSE file in the source tarball
says
I was
KaiGai,
A flexible framework is worthwhile for both operating systems.
Please confirm it to the TS folks.
Yep, that's the idea. Glenn was fine with your stuff last year, I expect
it'll still be fine.
Other than SELinux and TrustedSolaris, does anyone know of other role-based or
Gregory Stark wrote:
Greg Smith [EMAIL PROTECTED] writes:
On Mon, 17 Mar 2008, KaiGai Kohei wrote:
I'll submit the proposal of SE-PostgreSQL patches again, because some of
previous
messages are filtered due to attachment and I cannot provide whole of patches
yet.
This is actually what you
Tom Lane wrote
Pavan Deolasee [EMAIL PROTECTED] writes:
I am sure this must have been discussed before.
Indeed. Apparently you didn't find the threads in which the idea of
having transactions enter delta entries was discussed? Solves both
the locking and the MVCC problems, at the cost
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Nested Loop (cost=5.39..198.81 rows=51 width=244)
- HashAggregate (cost=1.06..1.11 rows=5 width=4)
- Seq Scan on int4_tbl b (cost=0.00..1.05 rows=5 width=4)
- Bitmap Heap
Stephen Denne [EMAIL PROTECTED] writes:
I initially thought that what you meant by having transactions enter delta
entries was that I have a trigger that would create a row each time it was
called, writing how many records where inserted or deleted. I didn't
understand how this would be
87 matches
Mail list logo
