Tom Lane wrote:
I'd suggest that we publish an official policy, with the following dates
for EOL:
But on the whole I think we should NOT have such a policy, at all.
[...]
If someone wants a guaranteed EOL date, they ought to be contracting
with a commercial support company and paying
Implementing index-only scans requires a few changes:
1. indexam API changes
There's currently no way to return data from an index scan. You only get
TID pointers to heap tuples.
2. Make visibility map crash-safe
After crash, the visibility map can currently be left in state where it
has some
At the moment, amgettuple only returns pointers to heap tuples. There is
no way to return data from the index tuples. That needs to be changed to
support index-only scans.
I propose that we split index_getnext into two steps: fetching the next
match from the index (index_next()), and fetching the
On Mon, Jul 13, 2009 at 8:19 AM, Heikki
Linnakangasheikki.linnakan...@enterprisedb.com wrote:
I propose that we split index_getnext into two steps: fetching the next
match from the index (index_next()), and fetching the corresponding heap
tuple (index_fetch()).
A pretty trivial concern, but
On Friday 10 July 2009 19:35:56 Stefan Kaltenbrunner wrote:
https support is now available on that jail (maybe we should simply
always redirect to the https url on all pages).
Yeah, at least the login page should be redirected to https. Right now, you
have to detect the SSL support by
Heikki Linnakangas wrote:
Even if we don't solve the visibility
map problem, just allowing the executor to evaluate quals that are not
directly indexable using data from the index, would be useful. For
example, SELECT * FROM foo WHERE textcol LIKE '%bar%', and you have a
b-tree index on
Josh Berkus j...@agliodbs.com wrote:
after the final minor release date, there is no guarantee
INAL, but that *seems* like it might open the community or its members
to lawsuits based on an implied guarantee up to the final minor
release date.
-Kevin
--
Sent via pgsql-hackers mailing list
On Saturday 11 July 2009 17:37:03 andrzej barszcz wrote:
Well, best to write this way:
Goal : query splitted to base elements
Result : xml response from server
Client : select pg_reparse_query(query);
Target: 8.4 version
How : modification of ruleutiles.c
Not done : UNION etc.
Not done :
Michael Meskes írta:
On Sat, Jul 04, 2009 at 03:39:14PM +0200, Boszormenyi Zoltan wrote:
The attached patch is built upon our previous patch supporting
dynamic cursor and SQLDA.
Please don't do this unless the new patch relies on some changes made in the
older one.
Michael
On Mon, Jul 13, 2009 at 8:47 AM, Peter Eisentrautpete...@gmx.net wrote:
On Friday 10 July 2009 19:35:56 Stefan Kaltenbrunner wrote:
https support is now available on that jail (maybe we should simply
always redirect to the https url on all pages).
Yeah, at least the login page should be
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
At the moment, amgettuple only returns pointers to heap tuples. There is
no way to return data from the index tuples. That needs to be changed to
support index-only scans.
What are you going to do for index types that don't store
Michael Meskes írta:
On Sat, Jul 04, 2009 at 05:09:04PM +0200, Boszormenyi Zoltan wrote:
OK, let me retry. This version treats string as a non-reserved word,
and also discovers whether the PGC contains this construct below,
as in ecpg/tests/preproc/type.pgc:
exec sql type string is
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
At the moment, amgettuple only returns pointers to heap tuples. There is
no way to return data from the index tuples. That needs to be changed to
support index-only scans.
What are you going to do for index types
Is that is the wished behavoir?
template1=# SELECT 1='1';
?column?
--
t
(1 row)
*template1=# SELECT 1 LIKE '1';
ERROR: operator does not exist: integer ~~ unknown at character 10*
HINT: No operator matches the given name and argument type(s). You
might need to add explicit type
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
What are you going to do for index types that don't store the original
data (e.g. hash)?
They will obviously not be able to regurgitate index tuples. I have not
yet decided how that's going to be signaled.
Well,
Tom Lane wrote:
One thought here is that an AM call isn't really free, and doing two of
them instead of one mightn't be such a good idea. I would suggest
either having a separate AM entry point to get both bits of data
(amgettupledata?) or adding an optional parameter to amgettuple.
I'm
Tom Lane t...@sss.pgh.pa.us wrote:
Now this disappears into the noise as soon as you include parse
analysis (let alone planning and execution)
No need to go for silly options to avoid a performance issue at that
level. Time wasted dealing with subsequent silliness would almost
certainly
Daniel Schuchardt wrote:
Is that is the wished behavoir?
template1=# SELECT 1='1';
?column?
--
t
(1 row)
Yes. See also this:
alvherre=# select 1 = '1'::text;
ERROR: operator does not exist: integer = text
LÍNEA 1: select 1 = '1'::text;
^
SUGERENCIA: No
In some cases, we have SQL being submitted that has superfluous
self-joins. An example would be
select count(*)
from foo1 a, foo1 b
where a.c1 = b.c1 /* PK join */
and a.c2 = 5
and b.c2 = 10;
We can recognise that a and b are the same table because they are
joined on the PK. PK is never
Andrew Dunstan wrote:
Tom Lane wrote:
I see that a good-sized
fraction of the buildfarm is still on flex 2.5.4 and will therefore go
red when this goes in. Should I hold off a bit longer, or is committing
the best way to get their attention?
Probably the latter. I will update my
Simon Riggs si...@2ndquadrant.com wrote:
select count(*)
from foo1 a, foo1 b
where a.c1 = b.c1 /* PK join */
You may well ask who would be stupid enough to write SQL like that.
The answer is of course that it is automatically generated by an
ORM.
We had to do something like that to
Simon Riggs si...@2ndquadrant.com writes:
In some cases, we have SQL being submitted that has superfluous
self-joins. An example would be
select count(*)
from foo1 a, foo1 b
where a.c1 = b.c1 /* PK join */
and a.c2 = 5
and b.c2 = 10;
You may well ask who would be stupid enough to
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Simon Riggs si...@2ndquadrant.com wrote:
select count(*)
from foo1 a, foo1 b
where a.c1 = b.c1 /* PK join */
We had to do something like that to get acceptable performance from
Sybase ASE.
Writing a join for a single-table query? Why,
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Implementing index-only scans requires a few changes:
I'm happy to see this work! Now that the EXISTS predicates have been
optimized to consider semi-join and anti-join techniques, I believe
that these index issues (evaluating quals
On Mon, 2009-07-13 at 13:33 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
In some cases, we have SQL being submitted that has superfluous
self-joins. An example would be
select count(*)
from foo1 a, foo1 b
where a.c1 = b.c1 /* PK join */
and a.c2 = 5
and
On Mon, Jul 13, 2009 at 1:33 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
In some cases, we have SQL being submitted that has superfluous
self-joins. An example would be
select count(*)
from foo1 a, foo1 b
where a.c1 = b.c1 /* PK join */
and a.c2 = 5
and
Hi,
This is a preliminary request for comments on obtaining a function call
stack. I've been trying to dodge the issue by exporting elog.c internal
state (errcontext), but that turns out to be unfeasible and it's such a
horrid kludge anyway.
So, the idea is to have a stack maintained by the
Alvaro Herrera alvhe...@commandprompt.com writes:
So, the idea is to have a stack maintained by the function manager; each
called function enters an element in it containing the interesting
information about the function. We'd have another function that would
return this stack as a result
Tom Lane t...@sss.pgh.pa.us wrote:
Writing a join for a single-table query? Why, in heavens name?
(Or have you mercifully blotted the details from your memory?)
Actually, I had only the vaguest recollection of why, but I found an
email where I was explaining the problem to Sybase.
On Mon, Jul 13, 2009 at 01:22:30PM +0900, Itagaki Takahiro wrote:
Sam Mason s...@samason.me.uk wrote:
As others have said, handling encryption client side would seem to offer
many more benefits (transparently within libpq offering easy adoption).
Libpq is not the only driver. Do we need to
Hello
I did some similar (but Oracle like) in orafce - so it can help. I
thing, so this should be very useful, but result set isn't best
format. Usually you would to print to log and you have to iterate via
set. So maybe better format could be some structured text.
regards
Pavel Stehule
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
So, the idea is to have a stack maintained by the function manager; each
called function enters an element in it containing the interesting
information about the function. We'd have another function that would
return this
Pavel Stehule escribió:
Hello
I did some similar (but Oracle like) in orafce - so it can help. I
thing, so this should be very useful, but result set isn't best
format. Usually you would to print to log and you have to iterate via
set. So maybe better format could be some structured text.
On Jul 13, 2009, at 2:02 PM, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
So, the idea is to have a stack maintained by the function
manager; each
called function enters an element in it containing the interesting
information about the function. We'd have another
For those of you who weren't involved in the Ottawa developer meeting, I think
we should start by explaining that beginning with the 8.5 development cycle,
we are planning to make regular alpha releases, to make early testing easier
for more users. This will happen at the end of every commit
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
The performance and error recovery implications are unfavorable.
Just how badly do you need this, and for what?
Mainly for debugging. The situation is such that there is a lot of
functions and very high load. The functions
2009/7/13 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
Hello
I did some similar (but Oracle like) in orafce - so it can help. I
thing, so this should be very useful, but result set isn't best
format. Usually you would to print to log and you have to iterate via
set. So
Alvaro Herrera wrote:
This is a preliminary request for comments on obtaining a function call
stack. I've been trying to dodge the issue by exporting elog.c internal
state (errcontext), but that turns out to be unfeasible and it's such a
horrid kludge anyway.
So, the idea is to have a
Peter Eisentraut pete...@gmx.net wrote:
It will mostly look like a beta release
No pgindent run I assume?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
== Release preparation ==
src/tools/RELEASE_CHANGES applies
No library soname bumps, right?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers
Peter Eisentraut wrote:
* Release notes [Note: We'll have to work out exactly how to do this one as
we
go.]
I am not planning to assist with this item for alpha releases.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
It will mostly look like a beta release
No pgindent run I assume?
I don't think so.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If
Alvaro Herrera wrote:
Peter Eisentraut wrote:
== Release preparation ==
src/tools/RELEASE_CHANGES applies
No library soname bumps, right?
No, I doubt it.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Peter Eisentraut pete...@gmx.net wrote:
It will mostly look like a beta release
No pgindent run I assume?
No, that would tend to break pending patches.
There's been some talk of pgindenting just new code added by patches
at the time they're
On Monday 13 July 2009 22:49:21 Bruce Momjian wrote:
Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net wrote:
It will mostly look like a beta release
No pgindent run I assume?
I don't think so.
No, certainly not.
--
Sent via pgsql-hackers mailing list
On Monday 13 July 2009 22:47:40 Alvaro Herrera wrote:
Peter Eisentraut wrote:
== Release preparation ==
src/tools/RELEASE_CHANGES applies
No library soname bumps, right?
The soname, which is name + major version number, is only bumped when the ABI
changes.
Perhaps you refer to the minor
I have been looking at getting rid of the way we currently ship the
documentation as a tarball within the tarball.
The first issue I encountered is that when you ship prebuilt files in a
tarball, you want to make sure the make dependencies are correctly satisfied.
For example, we prebuild
Peter Eisentraut pete...@gmx.net writes:
I think I have finally figured out a way to do this correctly now.
Yay. The existing method completely sucks --- I find that it *never*
does one run on a rebuild, but at least two and sometimes three.
I don't know whether it's feasible to implement
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I think I have finally figured out a way to do this correctly now.
Yay. The existing method completely sucks --- I find that it *never*
does one run on a rebuild, but at least two and sometimes three.
I don't know whether it's
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I think I have finally figured out a way to do this correctly now.
Yay. The existing method completely sucks --- I find that it *never*
does one run on a rebuild, but at least two and sometimes three.
I don't know whether it's
Alvaro Herrera wrote:
BTW I discovered a couple of years ago that if you set the DSSSL stuff
to build only the index and not output the HTML, the first pass is
*very* fast. It required patching some lispy file however, so I'm not
sure if we can usefully take advantage of that. I can find
On Mon, 2009-07-13 at 10:16 +0300, Heikki Linnakangas wrote:
Implementing index-only scans requires a few changes:
I would like to see a clear exposition of the use cases and an an
analysis of the costs and benefits of doing this. It sounds cool, but I
want to know it is cool before we spend
2009/7/14 Robert Haas robertmh...@gmail.com:
+1 for redirecting the whole site. I don't think the extra CPU load
of SSL is going to bother anyone for the amount of traffic we're
likely to have on that site. Simplicity is good.
+1 for SSL on all pages from me also.
Cheers,
BJ
--
Sent via
On Jul 13, 2009, at 1:06 PM, Simon Riggs wrote:
Not just because of this but I wonder if we might benefit from an
optimizer setting specifically aimed at the foolishnesses of
automatically generated SQL.
+1. And it's not just ORMs that do stupid things, I've seen crap like
this come out of
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
The performance and error recovery implications are unfavorable.
Just how badly do you need this, and for what?
Mainly for debugging. The situation is such that there is a lot of
On Mon, Jul 13, 2009 at 3:48 PM, decibeldeci...@decibel.org wrote:
On Jul 13, 2009, at 1:06 PM, Simon Riggs wrote:
Not just because of this but I wonder if we might benefit from an
optimizer setting specifically aimed at the foolishnesses of
automatically generated SQL.
+1. And it's not
On Jul 13, 2009, at 4:51 PM, decibel wrote:
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Tom Lane wrote:
The performance and error recovery implications are unfavorable.
Just how badly do you need this, and for what?
Mainly for debugging.
On Mon, Jul 13, 2009 at 4:00 PM, A.M.age...@themactionfaction.com wrote:
How would I go about generating a meaningful backtrace for a plpgsql
function that calls a plperl function? One would also expect a C function
which calls a plpgsql function to appear, too, no? Shouldn't there be a
Folks,
As previously announced, CommitFest 2009-07 will begin on July 15th.
For the sake of clarity, I'd like to propose that the deadline for
patch submission be fixed at:
Wed Jul 15 00:00:00 UTC 2009
...which is just under 26.5 hours from now. Barring objections, at
that time, I (or someone)
On Friday 05 December 2008 11:16:37 Kurt Harriman wrote:
Just a few additional header files are mentioned in the PostgreSQL
Reference Manual for add-on developers to use: fmgr.h, funcapi.h,
and spi.h. This patch adds bookends within those three files for
the benefit of
On Mon, Jul 13, 2009 at 3:57 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Peter Eisentraut pete...@gmx.net wrote:
It will mostly look like a beta release
No pgindent run I assume?
No, that would tend to break pending patches.
There's been some
On Friday 05 December 2008 11:18:46 Kurt Harriman wrote:
This patch adds C++ support to the PostgreSQL build system.
Unless you can provide a significant specific use case, I think this patch is
rejected. Building part of PostgreSQL sometimes with C++ would just add too
much uncertainty
On Friday 05 December 2008 11:13:37 Kurt Harriman wrote:
Fortunately, there are not many instances which are likely
to be encountered by our C++ guests, and these can easily
be changed. In memnodes.h, parsenodes.h, and primnodes.h,
this patch changes the following field
Robert Haas escribió:
What would be really nice is to provide an easy and PORTABLE way for
patch submitters to run pgindent themselves. Then you can pgindent on
every commit, and if you break somebody's patch series, it's there own
fault for not pgindenting it correctly before they submitted
On Mon, Jul 13, 2009 at 7:04 PM, Kevin
Grittnerkevin.gritt...@wicourts.gov wrote:
As far as our production queries go, based on our experience with
several other products against this schema, this is the area where the
biggest performance gains remain to be realized.
There's a logical fallacy
Greg Stark gsst...@mit.edu wrote:
On Mon, Jul 13, 2009 at 7:04 PM, Kevin
Grittnerkevin.gritt...@wicourts.gov wrote:
As far as our production queries go, based on our experience with
several other products against this schema, this is the area where
the biggest performance gains remain to be
Jamie Fox wrote:
Hi -
After what seemed to be a normal successful pg_migrator migration from 8.3.7
to 8.4.0, in either link or copy mode, vacuumlo fails on both our production
and qa databases:
Jul 1 11:17:03 db2 postgres[9321]: [14-1] LOG: duration: 175.563 ms
statement: DELETE FROM
Forwarded to hackers.
---
Jamie Fox wrote:
Hi -
This is probably more helpful - the pg_largeobject table only changed after
vacuumlo, not before. When comparing pre- and post- pg_migrator databases
(no vacuum or
Tilmann Singer wrote:
I tried the latest pg_migrator
(http://pgfoundry.org/frs/download.php/2291/pg_migrator-8.4.tgz) to
migrate a database from an 8.3.7 to an 8.4.0 cluster. It finished with
a success message, and the schema and all tables seem to have been
migrated correctly.
However,
Bruce Momjian wrote:
Jamie Fox wrote:
I can also see that the pg_largeobject table is different, in the pg_restore
version the Rows (estimated) is 316286 and Rows (counted) is the same, in
the pg_migrator version the Rows (counted) is only 180507.
Wow, I didn't test large objects
Alvaro Herrera wrote:
Bruce Momjian wrote:
Jamie Fox wrote:
I can also see that the pg_largeobject table is different, in the
pg_restore
version the Rows (estimated) is 316286 and Rows (counted) is the same, in
the pg_migrator version the Rows (counted) is only 180507.
Wow, I
Robert Haas robertmh...@gmail.com writes:
What would be really nice is to provide an easy and PORTABLE way for
patch submitters to run pgindent themselves.
AFAIK it's just BSD indent plus some private patches of Bruce's, so
there's no good reason we couldn't distribute pgindent in source form.
On Monday 13 July 2009 23:37:10 Alvaro Herrera wrote:
Alvaro Herrera wrote:
BTW I discovered a couple of years ago that if you set the DSSSL stuff
to build only the index and not output the HTML, the first pass is
*very* fast. It required patching some lispy file however, so I'm not
sure
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
What would be really nice is to provide an easy and PORTABLE way for
patch submitters to run pgindent themselves.
AFAIK it's just BSD indent plus some private patches of Bruce's, so
there's no good reason we couldn't distribute
Tom Lane escribió:
Robert Haas robertmh...@gmail.com writes:
What would be really nice is to provide an easy and PORTABLE way for
patch submitters to run pgindent themselves.
AFAIK it's just BSD indent plus some private patches of Bruce's, so
there's no good reason we couldn't distribute
Alvaro Herrera wrote:
Tom Lane escribi?:
Robert Haas robertmh...@gmail.com writes:
What would be really nice is to provide an easy and PORTABLE way for
patch submitters to run pgindent themselves.
AFAIK it's just BSD indent plus some private patches of Bruce's, so
there's no good
Bruce Momjian br...@momjian.us writes:
Tilmann Singer wrote:
However, all of the sequences were at the initial values and not
bumped up to the last used value as I would have expected. The first
nextval call on any sequence in the migrated 8.4 database always
returned 1.
Wow, that is also
Robert,
The sepgsql/avc.c provides a facility to cache access control decisions
in userspace, and enables to reduce time of kernel invocations.
However, its size is the largest one in the SE-PgSQL patch.
[kai...@saba gram]$ wc -l src/backend/security/sepgsql/avc.c
829
Andrew Dunstan wrote:
OK, the fly in this ointment turns out to be MSVC. The latest flex
from GnuWin32 is 2.5.4a, and building 2.5.35 for Windows is turning
out to be quite a pain. Luckily, MinGW has a pre-built modified 2.5.33
available, and I have installed this (also needed msys-regex),
Does PG have an intermediate execution node to sort/batch index entries (heap
tuple ptrs) by heap page prior to lookup? Something mssql does ...
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Bruce Momjian
Sent:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Jamie Fox wrote:
I can also see that the pg_largeobject table is different, in the
pg_restore
version the Rows (estimated) is 316286 and Rows (counted) is the same,
in
the pg_migrator version the Rows
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Jamie Fox wrote:
I can also see that the pg_largeobject table is different, in the
pg_restore
version the Rows (estimated) is 316286 and Rows (counted) is the
same, in
the
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tilmann Singer wrote:
However, all of the sequences were at the initial values and not
bumped up to the last used value as I would have expected. The first
nextval call on any sequence in the migrated 8.4 database always
returned 1.
Andrew Dunstan and...@dunslane.net writes:
Well, it looks like there's a reason GnuWin32 hasn't advanced beyond
2.5.4a - after that the flex developers proceeded to make flex use a
filter chain methodology that requires the use of fork(). Making it run
on Windows without the support of
Alvaro Herrera wrote:
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Jamie Fox wrote:
I can also see that the pg_largeobject table is different, in the
pg_restore
version the Rows (estimated) is 316286 and Rows (counted) is the
same, in
the
2009/7/13 KaiGai Kohei kai...@ak.jp.nec.com:
The sepgsql/avc.c provides a facility to cache access control decisions
in userspace, and enables to reduce time of kernel invocations.
However, its size is the largest one in the SE-PgSQL patch.
I think that caching access control decisions in
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Well, it looks like there's a reason GnuWin32 hasn't advanced beyond
2.5.4a - after that the flex developers proceeded to make flex use a
filter chain methodology that requires the use of fork(). Making it run
on Windows without
Pavel Stehule escribió:
2009/7/13 Alvaro Herrera alvhe...@commandprompt.com:
Pavel Stehule escribió:
Hello
I did some similar (but Oracle like) in orafce - so it can help. I
thing, so this should be very useful, but result set isn't best
format. Usually you would to print to log and
On Mon, Jul 13, 2009 at 5:38 PM, Mischa
Sandbergmischa.sandb...@sophos.com wrote:
Does PG have an intermediate execution node to sort/batch index entries (heap
tuple ptrs) by heap page prior to lookup? Something mssql does ...
it sounds a lot like a bitmap index scan
--
Atentamente,
Jaime
Robert Haas wrote:
2009/7/13 KaiGai Kohei kai...@ak.jp.nec.com:
The sepgsql/avc.c provides a facility to cache access control decisions
in userspace, and enables to reduce time of kernel invocations.
However, its size is the largest one in the SE-PgSQL patch.
I think that caching access
2009/7/14 KaiGai Kohei kai...@ak.jp.nec.com:
Robert Haas wrote:
2009/7/13 KaiGai Kohei kai...@ak.jp.nec.com:
The sepgsql/avc.c provides a facility to cache access control decisions
in userspace, and enables to reduce time of kernel invocations.
However, its size is the largest one in the
Robert Haas wrote:
If so, I can postpone some of permission checks outside of the
pg_xxx_aclcheck(). However, SELinux's security model often
requires different criteria to make its decision.
(Please note that I never say either of them is better or worse.)
Thus, we will need to add security
On Mon, May 11, 2009 at 11:49 PM, Itagaki
Takahiroitagaki.takah...@oss.ntt.co.jp wrote:
Hi,
The attached is a WIP patch add a support of '*' for FORCE QUOTE
and FORCE NOT NULL options. I'd like to submit it for the next
commit fest (8.5). Comments welcome.
this patch applies almost cleanly
93 matches
Mail list logo
