If we add a field on pg_ to store security label in text form,
it is necessary to attach a default one at the following points.
* pg_class
- InsertPgClassTuple() at heap.c
* pg_attribute
- InsertPgAttributeTuple() at heap.c
* pg_proc
- ProcedureCreate() at pg_proc.c
* pg_database
-
Bruce Momjian wrote:
Joshua Brindle wrote:
The big problem is that the security value on system tables controls the
_object_ represented by the row, while on user tables the security value
represents access to the row. That is just an odd design, and why a
regular system table security value ma
Robert Haas writes:
> I'm interested, but I need maybe a 1GB data set, or smaller. The
> thing that we are benchmarking is the planner, and planning times are
> related to the complexity of the database and the accompanying
> queries, not the raw volume of data.
In fact, the only reason to care
* Robert Haas (robertmh...@gmail.com) wrote:
> I'm interested, but I need maybe a 1GB data set, or smaller. The
> thing that we are benchmarking is the planner, and planning times are
> related to the complexity of the database and the accompanying
> queries, not the raw volume of data. (It's not
> A good data set, plus complex queries against it, might be the data from
> the US Census, specifically the TIGER data and the TIGER geocoder. I've
> been following this thread with the intention of putting together a
> large-data test set, but I just havn't found the time to yet. Right now
> th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > Yikes! The impact of the patch is about what I'd expect, but the fact
> > that planning time has nearly tripled is... way poor.
>
> We're going to need to see the test case, because I don't see that in
> some simple tests here.
A
Tom, all,
In the attached patch-
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> * Some of the information_schema views are specified to respond to
> per-column privileges; the column_privileges and columns views
> certainly need work now to meet spec, and there might be others.
Done.
> * It might be
Robert Haas writes:
> Yikes! The impact of the patch is about what I'd expect, but the fact
> that planning time has nearly tripled is... way poor.
We're going to need to see the test case, because I don't see that in
some simple tests here.
regards, tom lane
--
Sent v
>> Running a complex query (posted in previous threads, runs about
>> 300,000 time per day in a production web application), I got these
>> timings on a production quality machine (4 quad CPU chips, that is 16
>> CPUs like this: Intel(R) Xeon(R) CPU X7350 @ 2.93GHz, 128 GB RAM, big
>> RAID with BB
Bruce Momjian wrote:
> The fundamental behavior above is that the S1 transaction is adding
> _and_ removing rows from the S2 query's result set; S2 is seeing the
> pre-query values that don't match its criteria and ignoring them and
> blocking on a later row that does match its criteria. Once S1
Joshua Brindle wrote:
> > The big problem is that the security value on system tables controls the
> > _object_ represented by the row, while on user tables the security value
> > represents access to the row. That is just an odd design, and why a
> > regular system table security value makes sens
Tom Lane wrote:
Ruzsinszky Attila writes:
The DB is the same except the character coding. Source is LATIN2 and
the target DB is UTF8.
We wrote a trigger to copy the data from source to target with dblink.
The problem is the
different DB character coding! PGSQL complains about wrong byte order.
On Mon, Feb 2, 2009 at 8:10 PM, Kevin Grittner
wrote:
Robert Haas wrote:
>> running this 5 times each on several queries,
>> dropping top and bottom results.
>
> Running a complex query (posted in previous threads, runs about
> 300,000 time per day in a production web application), I got the
Bruce Momjian wrote:
KaiGai Kohei wrote:
Why an OID? We store acl items now without a lookup table; I think
there will be at most the same number of SE-Linux entries. Also, by
using text we avoid the problem of cleaning out unreferenced pg_security
rows, improve performance (no lookups), and
Looked at this a bit ... do you think it's really a good idea to remove
the strategy number argument of comparePartial? The argument given in
the docs for it is that it might be needed to determine when to end the
scan, and that still seems plausible to me.
The description of extractQuery's extra
Teodor Sigaev writes:
> I'm very sorry, but v0.24 has a silly bug with not initialized value :(.
> New version is attached
I looked at this a little bit --- it needs proofreading ("VACUUME"?).
Do we really need an additional column in pgstat table entries in
order to store something that looks l
Kevin Grittner wrote:
> >>> Tom Lane wrote:
> > Jeff Davis writes:
> >> There you see a snapshot of the table that never existed. Either
> the
> >> snapshot was taken before the UPDATE, in which case i=3 should be
> >> included, or it was taken after the UPDATE, in which case i=4 should
> be
> >
Bruce Momjian wrote:
At least, we cannot apply this scheme on the next phase (row-level)
due to the storage consumption and others. So, I don't think it is
a preferable way to design the first step without ignoring upcoming
expandability.
The big problem is that the security value on system tab
>>> Robert Haas wrote:
> running this 5 times each on several queries,
> dropping top and bottom results.
Running a complex query (posted in previous threads, runs about
300,000 time per day in a production web application), I got these
timings on a production quality machine (4 quad CPU chips,
>> Why an OID? We store acl items now without a lookup table; I think
>> there will be at most the same number of SE-Linux entries. Also, by
>> using text we avoid the problem of cleaning out unreferenced pg_security
>> rows, improve performance (no lookups), and simplify the code.
>
> In additi
KaiGai Kohei wrote:
> > Why an OID? We store acl items now without a lookup table; I think
> > there will be at most the same number of SE-Linux entries. Also, by
> > using text we avoid the problem of cleaning out unreferenced pg_security
> > rows, improve performance (no lookups), and simplify
Bruce Momjian wrote:
Robert Haas wrote:
IANAC, but that's my impression too. The simplified patch shouldn't
assume that row-level security in its current form is going to end up
getting put back in. AFAICS, there's no reason why the security ID
for tables can't be a regular attribute in pg_cla
>> We don't really have space to document every little niggling detail in
>> two places; if we did that, the main docs would become unreadably dense.
>
> What, disk space? What do you mean by "space"?
Brain space.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On Feb 2, 2009, at 1:10 PM, Tom Lane wrote:
"David E. Wheeler" writes:
On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:
Seems to me that the SELECT reference page is a more appropriate
place
for this type of detail. I've applied a patch there.
What about both?
We don't really have space t
"David E. Wheeler" writes:
> On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:
>> Seems to me that the SELECT reference page is a more appropriate place
>> for this type of detail. I've applied a patch there.
> What about both?
We don't really have space to document every little niggling detail in
t
On Feb 2, 2009, at 12:43 PM, Tom Lane wrote:
Yeah, it's very useful. Here's a patch for the docs about it.
Seems to me that the SELECT reference page is a more appropriate place
for this type of detail. I've applied a patch there.
What about both? The LIMIT page is the first page I'd look f
"David E. Wheeler" writes:
> On Feb 2, 2009, at 10:17 AM, Tom Lane wrote:
>> It's worked the way it does now since 7.1, and no one has complained;
>> in fact we've gotten bug reports when it was broken by the int8-limit
>> patch. So there are people depending on the behavior.
> Yeah, it's very u
Tom Lane wrote:
And here 'tis. I didn't commit because I have no way to test whether
I broke the Windows code path. Please test, and commit if OK.
Tested and committed.
Thanks to the people who reviewed and tested this - it was quite a
difficult piece of work, much more difficult than
To summarize where I think we are, release-wise:
> o Log streaming
hold for 8.5
> o Hot standby
if committable for 8.4, fine, if not, 8.5, Heikki decides
> o SE-PostgreSQL
no row-level security, if committable for 8.4, fine, if not, 8.5
> o Others
We will focus o
CVS HEAD is producing
execute.c: In function 'ecpg_store_result':
execute.c:394: warning: 'act_tuple' may be used uninitialized in this function
It looks to me like this is an actual bug, not just the compiler being
insufficiently smart to prove the variable is set before use.
On Feb 2, 2009, at 1:31 PM, Tom Lane wrote:
Ruzsinszky Attila writes:
The situation:
We've got two machines. The source database (DB) is running on an
RHEL
5.x machine
with PSQL 8.1.11. The destination DB is running on SuSE 11.0 with
PSQL 8.3.x.
The mechines are relative far away each
On Feb 2, 2009, at 10:17 AM, Tom Lane wrote:
It's worked the way it does now since 7.1, and no one has complained;
in fact we've gotten bug reports when it was broken by the int8-limit
patch. So there are people depending on the behavior.
Yeah, it's very useful. Here's a patch for the docs ab
Ruzsinszky Attila writes:
> The situation:
> We've got two machines. The source database (DB) is running on an RHEL
> 5.x machine
> with PSQL 8.1.11. The destination DB is running on SuSE 11.0 with PSQL 8.3.x.
> The mechines are relative far away each other and there is a 2Mbps WAN
> line between
Andrew Dunstan writes:
> Tom Lane wrote:
>> There is an unfinished TODO item here: we really ought to make it work
>> for tar-format archives. That's probably not hugely difficult, but
>> I didn't look into it, and don't think we should hold up applying the
>> existing patch for it.
> Right. Wer
Tom Lane wrote:
I wrote:
I'm almost done reviewing the patch, and will send along an updated
version shortly.
And here 'tis.
Many many thanks. Your edits look very sensible, as always.
I didn't commit because I have no way to test whether
I broke the Windows code path. Please
Bruce Momjian writes:
> Uh, I figure LIMIT NULL should return no rows.
It's worked the way it does now since 7.1, and no one has complained;
in fact we've gotten bug reports when it was broken by the int8-limit
patch. So there are people depending on the behavior.
regard
Tested and it looks good.
See
http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=gothic_moth&br=HEAD
thanks Zdenek
Andrew Dunstan píše v po 02. 02. 2009 v 11:34 -0500:
>
> Zdenek Kotala wrote:
> > Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
> >
> >> There is a new releas
>>> Bruce Momjian wrote:
> David E. Wheeler wrote:
>> Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`?
> Uh, I figure LIMIT NULL should return no rows.
Why? Since the normal meaning of NULL is "value unknown or does not
apply" it would seem to be most reasonable, if it's goi
On Feb 2, 2009, at 9:58 AM, Bruce Momjian wrote:
Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
so, I'd like to submit a patch to document it, because I've found it
useful in SQL functions:
http://justatheory.com/computers/databases/postgresql/dynamic-limit.html
Uh, I
On Mon, Feb 2, 2009 at 12:58 PM, Bruce Momjian wrote:
> David E. Wheeler wrote:
>> Howdy,
>>
>> Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
>> so, I'd like to submit a patch to document it, because I've found it
>> useful in SQL functions:
>>
>>http://justatheory.com/
David E. Wheeler wrote:
> Howdy,
>
> Is it intentional that `LIMIT NULL` means the same as `LIMIT ALL`? If
> so, I'd like to submit a patch to document it, because I've found it
> useful in SQL functions:
>
>http://justatheory.com/computers/databases/postgresql/dynamic-limit.html
Uh, I f
Heikki Linnakangas píše v so 31. 01. 2009 v 21:56 +0200:
> Robert Haas wrote:
> >> Ofcourse, the simplest way to me for handling type changes seems to be
> >> to keep the old type OID reserved and have the new version of the type
> >> with a new OID. Then the entire problem vanishes. But it was de
Robert Haas wrote:
> >> IANAC, but that's my impression too. The simplified patch shouldn't
> >> assume that row-level security in its current form is going to end up
> >> getting put back in. AFAICS, there's no reason why the security ID
> >> for tables can't be a regular attribute in pg_class,
Gregory Stark píše v pá 30. 01. 2009 v 16:56 +:
> Heikki Linnakangas writes:
>
> > Zdenek Kotala wrote:
> >> Bruce Momjian píše v pá 30. 01. 2009 v 10:41 -0500:
> >>> Well, I was thinking the new pg_class column would allow the upgrade to
> >>> verify the pre-upgrade script was run properly,
I wrote:
> I'm almost done reviewing the patch, and will send along an updated
> version shortly.
And here 'tis. I didn't commit because I have no way to test whether
I broke the Windows code path. Please test, and commit if OK.
There is an unfinished TODO item here: we really ought to make it
Zdenek Kotala wrote:
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release of the buildfarm client code. It can be
downloaded from
http://pgfoundry.org/frs/download.php/2069/build-farm-3_2.tgz
I installed it on ghotic_moth and it look likes that there is proble
On 1/30/09 5:43 PM, "Josh Berkus" wrote:
> Joshua, Kohei-san,
>
> So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
> features *except* row-level security, would it still be useful to the
> SELinux community?
>
Yes, it's definitely still useful. While many of the use cases
Euler Taveira de Oliveira wrote:
> Alvaro Herrera escreveu:
> > New patch attached, with pg_dump support (thanks to Tom for the SQL
> > heads-up).
> >
> Great! We're close. Just two minor gripes:
>
> + char *validnsps[] = { "toast" };
>
> Surely, you forgot to add a NULL at the end. Pa
On 2 Feb 2009, at 14:50, Robert Haas wrote:
well, true - but also, statically allocated table, without any
predefined
size (with #DEFINE) , and no boundary check - is bad as well.
I suppose , this code is easy enough to let it be with your
changes, but I
would still call it not pretty.
W
Josh Berkus wrote:
Joshua, Kohei-san,
So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all
features *except* row-level security, would it still be useful to the
SELinux community?
I think we're just not going to work out the headache-inducing issues
around row-level securi
Peter Eisentraut writes:
> Andrew Dunstan wrote:
>> I didn't know such a thing even existed. What causes it to happen? I
>> agree it should be forbidden.
> It was the only way to switch users before we had SET SESSION
> AUTHORIZATION and SET ROLE and such. But the pg_restore man page says
> t
"Tao Ma" writes:
> When I read the postgresql codes, I noticed that the FunctionCallInfoData
> structure(declared in the src/include/fmgr.h) contains two arrays 'arg' and
> 'argnull'.
> Why don't you declare it as a pointer and allocate the memory from
> heap?
Speed. We spend enough cycles in
> well, true - but also, statically allocated table, without any predefined
> size (with #DEFINE) , and no boundary check - is bad as well.
> I suppose , this code is easy enough to let it be with your changes, but I
> would still call it not pretty.
Well, it might merit a comment.
> Actually - i
Bruce Momjian wrote:
Andrew Chernow wrote:
I am using a library that links with and initializes libcrypto (ie.
CRYPTO_set_locking_callback) but not SSL. This causes problems even
when using PQinitSSL(FALSE) because things like SSL_library_init(); are
not called (unless I manually call them, c
On 1 Feb 2009, at 21:35, Robert Haas wrote:
On Sun, Feb 1, 2009 at 3:25 PM, Grzegorz Jaskiewicz > wrote:
I don't like the fact that you hardcoded that here. I know that you
are
trying to pass on few calls in one go here, but still... ugly.
Well, I think you'll find that using a dynamically
Andrew Dunstan wrote:
Zdenek Kotala wrote:
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release of the buildfarm client code. It can be
downloaded from
http://pgfoundry.org/frs/download.php/2069/build-farm-3_2.tgz
I installed it on ghotic_moth and it look li
Zdenek Kotala wrote:
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
There is a new release of the buildfarm client code. It can be
downloaded from
http://pgfoundry.org/frs/download.php/2069/build-farm-3_2.tgz
I installed it on ghotic_moth and it look likes that there is proble
Andrew Dunstan píše v ne 01. 02. 2009 v 16:38 -0500:
> There is a new release of the buildfarm client code. It can be
> downloaded from
> http://pgfoundry.org/frs/download.php/2069/build-farm-3_2.tgz
I installed it on ghotic_moth and it look likes that there is problem
with other locales proces
On Mon, Feb 02, 2009 at 11:29:51AM -0200, Fernando Ike wrote:
> Hi,
>
>
> On Fri, Jan 30, 2009 at 3:03 PM, Fernando Ike wrote:
> > Hi,,
> >
> >My job, I maintainer some postgres server for clients. We have
> > many PL/(Java, Perl, Ruby, Python, R) and to more easy
> > administration, I work
Hi,
On Fri, Jan 30, 2009 at 3:03 PM, Fernando Ike wrote:
> Hi,,
>
>My job, I maintainer some postgres server for clients. We have
> many PL/(Java, Perl, Ruby, Python, R) and to more easy
> administration, I worked new little psql attribute to list languages
> com shorcurt/function \dL.
[..]
Magnus Hagander wrote:
Hmm. Actually, if I look at how things were before, I think we only
called SetEnvironmentVariable() in case we set a variable, and never if
we removed one. I'm not sure that's correct behavior, but it's
apparently non-crashing behavior. Perhaps we need to restore that one
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>> Andrew Dunstan wrote:
>>
>>> Hiroshi Inoue wrote:
>>>
Eventually does the crash come from the call SetEnvironemntVariable
(.., NULL) on mingw-XP(or older?)?
I'm also interested in this issue and want to know the cause.
>>>
Andrew Dunstan wrote:
Still, that's not a 100% solution because of the cases where we use
reconnections to change user IDs --- the required password would
(usually) vary. It might be sufficient to forbid that case with
parallel restore, though; I think it's mostly a legacy thing anyway.
I didn
On Fri, 2009-01-23 at 12:09 -0500, Robert Haas wrote:
> > Could also be something like "allow_connections_during_recovery".
>
> +1 (should we say "continuous recovery?")
Rather than a boolean, it seems more useful to specify a parameter that
has some additional usefulness, if we are going to hav
2009/2/2 Tao Ma :
> hi,
>
> When I read the postgresql codes, I noticed that the FunctionCallInfoData
> structure(declared in the src/include/fmgr.h) contains two arrays 'arg' and
> 'argnull'.
> Why don't you declare it as a pointer and allocate the memory from heap? It
> saves more momery if 'arg'
On Mon, Feb 02, 2009 at 03:16:01PM +0800, Tao Ma wrote:
> hi,
>
> When I read the postgresql codes, I noticed that the FunctionCallInfoData
> structure(declared in the src/include/fmgr.h) contains two arrays 'arg' and
> 'argnull'.
> Why don't you declare it as a pointer and allocate the memory f
hi,
When I read the postgresql codes, I noticed that the FunctionCallInfoData
structure(declared in the src/include/fmgr.h) contains two arrays 'arg' and
'argnull'.
Why don't you declare it as a pointer and allocate the memory from heap? It
saves more momery if 'arg' and 'argnull' declares as p
67 matches
Mail list logo
