KaiGai Kohei writes:
> Is it an expected behavior that PostgreSQL tries to execute foo() with
> privileges of the owner of language call handler because of its security
> definer property? This server crash is just a result.
A language call handler has no function properties of its own --- which
I have completed the 9.0 release notes:
http://developer.postgresql.org/pgdocs/postgres/release-9-0.html
I kept the 9.0-alpha release notes in the SGML because people might want
to compare them with the release notes I did, and because the
introductory text will be needed for the next alp
On Fri, Mar 19, 2010 at 10:29 PM, KaiGai Kohei wrote:
> Is it an expected behavior that PostgreSQL tries to execute foo() with
> privileges of the owner of language call handler because of its security
> definer property? This server crash is just a result.
I'm inclined to feel (and Tom's respons
On 3/19/10 5:18 AM, Tom Lane wrote:
>> When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
>> > it makes server process crashed.
>
> So don't do that. Whatever possessed you to think that's a sensible
> idea anyway?
PATIENT: Doctor, it hurts when I do this!
DOCTOR: So stop do
(2010/03/20 11:17), Robert Haas wrote:
On Fri, Mar 19, 2010 at 8:11 PM, Tom Lane wrote:
Robert Haas writes:
On Fri, Mar 19, 2010 at 8:18 AM, Tom Lane wrote:
KaiGai Kohei writes:
When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
it makes server process crashed.
So do
On Fri, Mar 19, 2010 at 8:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 19, 2010 at 8:18 AM, Tom Lane wrote:
>>> KaiGai Kohei writes:
When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
it makes server process crashed.
>>>
>>> So don't do that. Whatev
Robert Haas writes:
> On Fri, Mar 19, 2010 at 8:18 AM, Tom Lane wrote:
>> KaiGai Kohei writes:
>>> When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
>>> it makes server process crashed.
>>
>> So don't do that. Whatever possessed you to think that's a sensible
>> idea anywa
On Thu, Mar 18, 2010 at 1:21 PM, Yeb Havinga wrote:
> Tom Lane wrote:
>>
>> Yeb Havinga writes:
>>
>>>
>>> What if the default operation of e.g. php using libpq would be as
>>> follows: set some default fetchsize (e.g. 1000 rows), then just issue
>>> getrow. In the php pg handling, a function lik
On Fri, Mar 19, 2010 at 8:18 AM, Tom Lane wrote:
> KaiGai Kohei writes:
>> When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
>> it makes server process crashed.
>
> So don't do that. Whatever possessed you to think that's a sensible
> idea anyway?
It might not be sensible,
In anticipation of the release of PostgreSQL 9.0, it is once again time
to update the message translations. We are not very near a string
freeze yet, which has traditionally been associated with the first
release candidate, but I feel that things are already stable enough to
begin this work now.
Hi all,
explain
select v from (
select array(
select 1
union all
select 2) as v
from (select 1) ) as s
where v is not null;
The plan looks like:
QUERY PLAN
Result (cost=0.08..0.10 rows=1 wid
Howdy folks,
I'm very happy to announce that the Postgres project has been selected
to
participate in this years Google Summer of Code program. Over the next couple
weeks we'll be looking to solidify our mentor base; if you work on Postgres
and would be willing to mentor a student, p
On Fri, 2010-03-19 at 08:41 -0400, Tom Lane wrote:
> sri...@postgresql.org (Simon Riggs) writes:
> > Log Message:
> > ---
> > Reset btpo.xact following recovery of btree delete page. Add btpo_xact
> > field into WAL record and reset it from there, rather than using
> > FrozenTransactionId w
Alvaro Herrera wrote:
> Heikki Linnakangas escribió:
>
>> When recovery reaches an invalid WAL record, typically caused by a
>> half-written WAL file, it closes the file and moves to the next source.
>> If an error is found in a file restored from archive or in a portion
>> just streamed from mast
Heikki Linnakangas escribió:
> When recovery reaches an invalid WAL record, typically caused by a
> half-written WAL file, it closes the file and moves to the next source.
> If an error is found in a file restored from archive or in a portion
> just streamed from master, however, a PANIC is thrown
Hi all,
On Thu, 2010-03-18 at 10:18 -0700, Josh Berkus wrote:
> Or, let's put it another way: I've made my opinion clear in the past
> that I think that we ought to ship with a minimal postgresql.conf with
> maybe 15 items in it. If we are going to continue to ship with
> postgresql.conf "kitchen
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Simon Riggs wrote:
>>> We might also have written half a file many times. The files in pg_xlog
>>> are suspect whereas the files in the archive are not. If we have both we
>>> should prefer the archive.
>
>> Yep.
>
> Really? That will result in a
Heikki Linnakangas writes:
> Simon Riggs wrote:
>> We might also have written half a file many times. The files in pg_xlog
>> are suspect whereas the files in the archive are not. If we have both we
>> should prefer the archive.
> Yep.
Really? That will result in a change in the longstanding be
sri...@postgresql.org (Simon Riggs) writes:
> Log Message:
> ---
> Reset btpo.xact following recovery of btree delete page. Add btpo_xact
> field into WAL record and reset it from there, rather than using
> FrozenTransactionId which can lead to some corner case bugs.
Simon, you can't just
KaiGai Kohei writes:
> When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
> it makes server process crashed.
So don't do that. Whatever possessed you to think that's a sensible
idea anyway?
regards, tom lane
--
Sent via pgsql-hackers mailing list (p
Simon Riggs wrote:
> On Thu, 2010-03-18 at 23:27 +0900, Fujii Masao wrote:
>
>> I agree that this is a bigger problem. Since the standby always starts
>> walreceiver before replaying any WAL files in pg_xlog, walreceiver tries
>> to receive the WAL files following the REDO starting point even if t
Tom Lane wrote:
Robert Haas writes:
So I guess there are two issues here: (1) somehow I feel like we
should be telling the user what expression is being used to initialize
$0, $1, etc. when they are PARAM_EXEC parameters;
Maybe, but the only reasonable place to put it would be within
On Sat, 2010-03-13 at 16:58 +, Simon Riggs wrote:
> On Fri, 2010-03-12 at 22:28 -0500, Bruce Momjian wrote:
>
> > Where are we in getting to beta1? I know people are looking to me for
> > 9.0 release notes and I will have them done in about a week, but what
> > about open issues? I don't see
On Thu, 2010-02-18 at 14:23 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Introduce WAL records to log reuse of btree pages, allowing conflict
> > resolution during Hot Standby. Page reuse interlock requested by Tom.
> > Analysis and patch by me.
>
> There's still a theoretical possibi
Hello
I wrote some small patch, that allow preloading of selected ispell
dictionary. It solve the problem with slow tsearch initialisation with
some language configuration.
This patch is most simple - simpler than variant with shared memory
and it is usable on Linux platform.
I registered some
On Thu, 2010-03-18 at 23:27 +0900, Fujii Masao wrote:
> I agree that this is a bigger problem. Since the standby always starts
> walreceiver before replaying any WAL files in pg_xlog, walreceiver tries
> to receive the WAL files following the REDO starting point even if they
> have already been in
It is a bug report in a corner case.
When we assign "SECURITY DEFINER" attribute on plpgsql_call_handler(),
it makes server process crashed.
postgres=# ALTER FUNCTION plpgsql_call_handler() security definer;
ALTER FUNCTION
postgres=# CREATE FUNCTION foo(text) RETURNS text AS $$
BEGIN
R
27 matches
Mail list logo
