Simon Riggs wrote:
The most consistent negative feedback I receive about Postgres is that
we make minor changes from release to release that make it extremely
difficult to upgrade without re-testing the applications. So we write
great software, then make it difficult for people to upgrade to it.
Hi,
I was wondering why -Os is not used in place of -O2 while compiling the
Postgres sources with gcc. I prepared 2 install directories by respectively
using -Os and -O2 flags and in the former case it seems to reduce the
install footprint by about 1MB or so. Agreed this is not significant for
Nikhil Sontakke wrote:
I was wondering why -Os is not used in place of -O2 while compiling the
Postgres sources with gcc. I prepared 2 install directories by respectively
using -Os and -O2 flags and in the former case it seems to reduce the
install footprint by about 1MB or so. Agreed this is
On Wed, 2009-03-11 at 08:33 +0200, Peter Eisentraut wrote:
Simon Riggs wrote:
The most consistent negative feedback I receive about Postgres is that
we make minor changes from release to release that make it extremely
difficult to upgrade without re-testing the applications. So we write
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the category of trying to have more fine-grained
permissions than
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the category of trying to have more
KaiGai Kohei wrote:
Heikki Linnakangas wrote:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so
SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the category of
Hello
I am searching way to extensible parser (actually not bison, only
transformations). I propose parserHook (transformation part). One
Tom's objection is difference between heooked and unhooked parser. It
serious problem.
I have one idea - only preloadable libraries. These libs have to be
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock} permission.
This again falls into the
After all, re-initdb is much easier than re-build the whole package.
And there seems nothing diffcult to implement this. Is that true?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jacky Leng lengjianq...@163.com writes:
And there seems nothing diffcult to implement this. Is that true?
No.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Nikhil Sontakke wrote:
I was wondering why -Os is not used in place of -O2 while compiling the
Postgres sources with gcc.
There's no free lunch.
In any case, this sort of choice is generally something that ought to be
applied at
On Wed, 2009-03-11 at 11:09 +0100, Pavel Stehule wrote:
I am searching way to extensible parser (actually not bison, only
transformations). I propose parserHook (transformation part). One
Tom's objection is difference between heooked and unhooked parser. It
serious problem.
Do you mean
On Wed, Mar 11, 2009 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
And there seems nothing diffcult to implement this. Is that true?
No.
Eh? There's nothing difficult in implementing it.
But there are a lot of other constants dependant on this value which
are currently compile-time
On Wed, Mar 11, 2009 at 12:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As far as I know, though, -Os
is not the preferred choice in any distro, which ought to tell you
something ...
Unless of course you include distributions like ucLinux or emDebian
which only proves the point.
--
greg
--
Greg Stark st...@enterprisedb.com writes:
On Wed, Mar 11, 2009 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
And there seems nothing diffcult to implement this. Is that true?
No.
Eh? There's nothing difficult in implementing it.
But there are a lot of other constants dependant on this
On Wed, Mar 11, 2009 at 12:56 PM, Simon Riggs si...@2ndquadrant.com wrote:
In the longer term it will be very useful to have the ability to support
multiple language variants, including older PostgreSQL syntax to allow
legacy systems to work with Postgres at the same time as allowing new
On Wed, Mar 11, 2009 at 1:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
On Wed, Mar 11, 2009 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
And there seems nothing diffcult to implement this. Is that true?
No.
Eh? There's nothing difficult in
On 3/11/09, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Nikhil Sontakke wrote:
I was wondering why -Os is not used in place of -O2 while compiling the
Postgres sources with gcc.
There's no free lunch.
In any case, this sort of
Gregory Stark escribió:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
KaiGai Kohei wrote:
* ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
checks db_table:{update} permission on SELECT ... FOR SHARE OF,
instead of db_table:{lock}
On Wed, 2009-03-11 at 13:14 +, Greg Stark wrote:
On Wed, Mar 11, 2009 at 12:56 PM, Simon Riggs si...@2ndquadrant.com wrote:
In the longer term it will be very useful to have the ability to support
multiple language variants, including older PostgreSQL syntax to allow
legacy systems
2009/3/11 Simon Riggs si...@2ndquadrant.com:
On Wed, 2009-03-11 at 11:09 +0100, Pavel Stehule wrote:
I am searching way to extensible parser (actually not bison, only
transformations). I propose parserHook (transformation part). One
Tom's objection is difference between heooked and unhooked
On Wed, 2009-03-11 at 08:41 +, Simon Riggs wrote:
On Wed, 2009-03-11 at 08:33 +0200, Peter Eisentraut wrote:
The first step is to record incompatibilities as they occur and record
them somewhere, so that people can say that'll break my app. Often the
first people hear about these things
On Wed, Mar 11, 2009 at 2:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
It would be a huge
maintenance headache since every time we change a structure that the
parser works someone would have to maintain all those compatibility
parsers.
If it's a plugin that someone isn't any concern of
On Wed, 2009-03-11 at 14:45 +, Greg Stark wrote:
On Wed, Mar 11, 2009 at 2:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
It would be a huge
maintenance headache since every time we change a structure that the
parser works someone would have to maintain all those compatibility
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
OK, here 'tis.
Looks fairly reasonable to me, but of course I haven't tested it.
Well, I have to do a blitz of parallel restores next week, so hopefully
that will hit any soft spots.
--Josh
--
Sent via pgsql-hackers mailing list
On 3/7/09, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor rod.tay...@gmail.com wrote:
It wouldn't be so bad if you could assign internal and external column
names.
This is a good point. Uglifying the parameter
Josh Berkus wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
OK, here 'tis.
Looks fairly reasonable to me, but of course I haven't tested it.
Well, I have to do a blitz of parallel restores next week, so
hopefully that will hit any soft spots.
I have a known
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
KaiGai Kohei wrote:
* [..feature description..]
This again falls into the category of trying to have more fine-grained
permissions than vanilla PostgreSQL has
Would it make
Alvaro Herrera alvhe...@commandprompt.com writes:
Gregory Stark escribió:
Would it make sense to instead of removing and deferring pieces bit by bit to
instead work the other way around? Extract just the part of the patch that
maps SELinux capabilities to Postgres privileges as a first patch?
Pavel Stehule pavel.steh...@gmail.com writes:
2009/3/11 Simon Riggs si...@2ndquadrant.com:
I remember I had some differences between the way loading occurs at
session start and as a result of a LOAD command. I think there's
probably already a way of doing this - probably by checking for
On 11 Mar 2009, at 13:51, Marko Kreen wrote:
Linux kernel is moving to use -Os everywhere. AFAIK their argument is
that kernel code should not be doing anything CPU-intensive, thus
minimal cache usage is more important than unrolled loops.
This also seems to hint that -Os is not really
On Mar 11, 2009, at 3:18 PM, Grzegorz Jaskiewicz wrote:
On 11 Mar 2009, at 13:51, Marko Kreen wrote:
Linux kernel is moving to use -Os everywhere. AFAIK their argument
is
that kernel code should not be doing anything CPU-intensive, thus
minimal cache usage is more important than unrolled
I notice that we have in md.c
TRACE_POSTGRESQL_SMGR_MD_READ_DONE(forknum, blocknum,
reln-smgr_rnode.spcNode, reln-smgr_rnode.dbNode, reln-smgr_rnode.relNode,
relpath(reln-smgr_rnode, forknum), nbytes, BLCKSZ);
TRACE_POSTGRESQL_SMGR_MD_WRITE_DONE(forknum, blocknum,
A.M. wrote:
That said, if postgresql is paging out, the DBA probably has postgresql
or the server misconfigured.
Keep in mind that paging in in this context also means moving stuff
from plain RAM into cache.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The
All,
I was just noticing that doing SET ROLE changes the current session's
priviledges, but not any runtime configuration parameters (like work_mem
or statement_timeout) associated with the new role.
This is as documented (although I want to add a line to SET ROLE docs)
but is it the
On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
I was just noticing that doing SET ROLE changes the current session's
priviledges, but not any runtime configuration parameters (like work_mem
or statement_timeout) associated with the new role.
This is as documented (although I want
On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
This is as documented (although I want to add a line to SET ROLE docs)
but is it the behavior we want? I for one would like SET ROLE to change
runtime configs.
--On Mittwoch, März 11, 2009 21:45:00 + Simon Riggs
si...@2ndquadrant.com wrote:
This is as documented (although I want to add a line to SET ROLE docs)
but is it the behavior we want? I for one would like SET ROLE to change
runtime configs.
Sounds good to me, but you may want to explore
I wrote:
Seems that we need to have been quality-checking the dtrace patches
a bit more carefully.
I went over all the existing dtrace probe calls and fixed what seemed
clearly bogus, but there was one issue that seems like a bit of a
judgement call. In ReadBuffer_common() we have
On Wed, Mar 11, 2009 at 11:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Furthermore, an isExtend call doesn't actually do a read(), so lumping
them together with regular reads doesn't seem like quite the right thing
for performance measurement purposes anyway. Maybe we actually ought to
have
Ron Mayer wrote:
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
KaiGai Kohei wrote:
* [..feature description..]
This again falls into the category of trying to have more fine-grained
permissions than vanilla PostgreSQL has
On Fri, Dec 12, 2008 at 3:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2008-12-12 at 13:20 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Solutions can also include
* manual mechanism for setting ndistinct that doesn't keep
Greg Stark st...@enterprisedb.com writes:
On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
This is as documented (although I want to add a line to SET ROLE docs)
but is it the behavior we want? I for one would
* ACL_INSERT
The db_table:{insert} and db_column:{insert} for all the target
columns are checked. The table-level permission does not override
column-level permission, so the client need to have privileges
for both of objects. It is same as other permissions.
* ACL_SELECT
The
OK, I've worked out why I am seeing deadlocks etc. from parallel restore
on FK items.
In my original patch, I looked at all the dependencies of a candidate
item ansd compared them with the dependencies of the running items to
see if there was a potential locking clash. However, Tom in his
On Wed, Mar 11, 2009 at 9:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-03-11 at 14:27 -0700, Josh Berkus wrote:
This is as documented (although I want to add a line to
Robert Haas wrote:
* ACL_INSERT
The db_table:{insert} and db_column:{insert} for all the target
columns are checked. The table-level permission does not override
column-level permission, so the client need to have privileges
for both of objects. It is same as other permissions.
* ACL_SELECT
Andrew Dunstan and...@dunslane.net writes:
OK, I've worked out why I am seeing deadlocks etc. from parallel restore
on FK items.
In my original patch, I looked at all the dependencies of a candidate
item ansd compared them with the dependencies of the running items to
see if there was a
KaiGai Kohei wrote:
I wonder why the vanilla PostgreSQL does not put pg_proc_aclcheck()
on the ExecCallTriggerFunc().
I don't think we can assume any trigger functions are trusted,
because normal users with ACL_TRIGGER privilege can set their
procedures on the allowed tables.
It also means
* Row-Update/Delete trigger mechanism allows user defined triggers
to refer the older tuple updated/deleted.
* The ACL_TRIGGER privilege allows normal users to set up triggers
on the relation allowed.
It means someone with ACL_TRIGGER can set up a trigger which write
out the given older tuple
Is there any way to inspect current running statements (optionally full
stack of these statements)? I've found there is error_context_stack
variable in each backend, but it seems there is no way to get this
variable from another backend. It will be great if Postgres have such
kind of
52 matches
Mail list logo
