In response to Vlad Arkhipov :
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 P
In response to Vlad Arkhipov :
> 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
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 mechanism,
* 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
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 so
Andrew Dunstan 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 potential lockin
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
On Wed, Mar 11, 2009 at 9:21 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs 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 wa
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
a
> * 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 d
Greg Stark writes:
> On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs 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
On Fri, Dec 12, 2008 at 3:59 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Fri, 2008-12-12 at 13:20 -0500, Tom Lane wrote:
>>> Simon Riggs writes:
Solutions can also include
* manual mechanism for setting ndistinct that doesn't keep getting
overwritten by subsequent ANALYZEs
>>>
Ron Mayer wrote:
Alvaro Herrera wrote:
Gregory Stark escribió:
Heikki Linnakangas 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 sense to instead of r
On Wed, Mar 11, 2009 at 11:50 PM, Tom Lane 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 different probes
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
isExte
--On Mittwoch, März 11, 2009 21:45:00 + Simon Riggs
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 what problems that mi
On Wed, Mar 11, 2009 at 9:45 PM, Simon Riggs 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.
>
> Sounds good to
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 w
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 behavio
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/
T
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,
reln->smg
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
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 approp
Pavel Stehule writes:
> 2009/3/11 Simon Riggs :
>> 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
>> something that would only be there *after
Alvaro Herrera 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? Then
>> discuss any
Alvaro Herrera wrote:
> Gregory Stark escribió:
>> Heikki Linnakangas 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 sense to instead of
Josh Berkus wrote:
Tom Lane wrote:
Andrew Dunstan 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 outstanding bug to do with de
On 3/7/09, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Mar 7, 2009 at 9:08 AM, Rod Taylor wrote:
> >> It wouldn't be so bad if you could assign internal and external column
> names.
>
> > This is a good point. Uglifying the parameter names is sort of OK for
> > input parameters, but i
Tom Lane wrote:
Andrew Dunstan 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 (pgsql-hackers@post
On Wed, 2009-03-11 at 14:45 +, Greg Stark wrote:
> On Wed, Mar 11, 2009 at 2:18 PM, Simon Riggs 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.
>
On Wed, Mar 11, 2009 at 2:18 PM, Simon Riggs 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 ours. Exte
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 thi
2009/3/11 Simon Riggs :
>
> 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
>>
On Wed, 2009-03-11 at 13:14 +, Greg Stark wrote:
> On Wed, Mar 11, 2009 at 12:56 PM, Simon Riggs 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 P
Gregory Stark escribió:
> Heikki Linnakangas 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 f
On 3/11/09, Tom Lane wrote:
> Heikki Linnakangas 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 oug
On Wed, Mar 11, 2009 at 1:13 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Wed, Mar 11, 2009 at 12:38 PM, Tom Lane 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 c
On Wed, Mar 11, 2009 at 12:56 PM, Simon Riggs 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
> development to contin
Greg Stark writes:
> On Wed, Mar 11, 2009 at 12:38 PM, Tom Lane 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 comp
On Wed, Mar 11, 2009 at 12:42 PM, Tom Lane 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
--
Sent via pgsql-hac
On Wed, Mar 11, 2009 at 12:38 PM, Tom Lane 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 constants. The only dow
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 h
Heikki Linnakangas 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 a distro level. If, say, Fedo
"Jacky Leng" 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:
http://www.postgresql.org/mailpref/pgsql-hackers
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
Heikki Linnakangas 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 category of trying to have
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
spec
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 tryin
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 fine-gr
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 van
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 w
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 not
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
nor
53 matches
Mail list logo
