* Simon Riggs ([EMAIL PROTECTED]) wrote:
> Perhaps we should be implementing "extended privileges" by using one
> additional bit to mean "has extended privilege list". We presumably want
> to implement column level privileges, plus you raise interesting
> thoughts about fine grained security access
On Jan 26, 2008 8:14 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> This two-faced personality is just why we're facing this problem. It looks to
> users like DML but it under the hood it behaves just like DDL.
>
Agreed that it looks like DML. Speaking as a user, I came away from
the documentatio
On 26/01/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > have to have any node read function?
>
> See the comment at the top of outfuncs.c.
>
true, thank you
Pavel
> regards, tom lane
>
---(end of broadc
Hi,
I was wondering how accurate there books are (perhaps not so much) , if one
wants to learn more about the internals?
http://www.postgresql.org/docs/7.3/static/programmer.html
http://www.cs.helsinki.fi/u/laine/postgresql/programmer/
Regards,
Gevik
---(end of broadca
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> have to have any node read function?
See the comment at the top of outfuncs.c.
regards, tom lane
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by do
Hello,
have to have any node read function?
Regards
Pavel Stehule
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Fri, 2008-01-25 at 17:56 +0100, Zdenek Kotala wrote:
> Regarding to Robert Mach's work during Google SOC on data integrity
> check. I would like to improve storage module and implement some
> Robert's code into the core.
>
> I would like to make following modification:
>
> 1) Add ReadBuffer_
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> The simplest fix seems to be to invent an additional flag variable
>> "signalAwaited" which is set/cleared by ProcWaitForSignal and checked by
>> LockWaitCancel. This would make cancelling out of a ProcWaitForSign
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Fri, 2008-01-25 at 14:00 -0500, Tom Lane wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>> > On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
>> >> There are way too many table privilege bits already; to add more you
>> >> need something a lot st
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I would like to make following modification:
1) Add ReadBuffer_noerror (recommend me better name) function which will
accept damaged page without Error. This page will be marked as corrupted
and when ReadBuffer will touch this page th
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Zdenek Kotala <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> This seems like a pretty horrid idea. Bad pages shouldn't be allowed to
>>> get into shared buffers in the first place. Why not have the checking
>>> logic operate outside shared buffers?
>
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The simplest fix seems to be to invent an additional flag variable
> "signalAwaited" which is set/cleared by ProcWaitForSignal and checked by
> LockWaitCancel. This would make cancelling out of a ProcWaitForSignal call
> exactly analogous to cancelling out
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
>> We're already assuming that; otherwise base backups for PITR
>> don't work.
> I think we could, but iirc we did not. We do not need that assumption if
> you don't
> turn off fullpage writes.
Oh, I had forgotten that RestoreBkpBlocks re
> >> This seems like a pretty horrid idea. Bad pages shouldn't be
allowed to
> >> get into shared buffers in the first place. Why not have the
checking
> >> logic operate outside shared buffers?
>
> > It currently works outside the shared buffers, but I afraid about
> > collision due to parall
On Fri, 2008-01-25 at 14:00 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
> >> There are way too many table privilege bits already; to add more you
> >> need something a lot stronger than a "might be nice" argument.
>
> > Pe
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
> >> There are way too many table privilege bits already; to add more you
> >> need something a lot stronger than a "might be nice" argument.
>
> > People use TRUN
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
>> There are way too many table privilege bits already; to add more you
>> need something a lot stronger than a "might be nice" argument.
> People use TRUNCATE whatever we say. If you force people to be ta
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This seems like a pretty horrid idea. Bad pages shouldn't be allowed to
>> get into shared buffers in the first place. Why not have the checking
>> logic operate outside shared buffers?
> It currently works outside the shared buffers
I wrote:
> The issue Steven directly complained of is a potential for undetected
> deadlock via LockBufferForCleanup. Ordinarily, buffer-level locks don't
> pose a deadlock risk because we don't hold one while trying to acquire
> another (except in UPDATE, which uses an ordering rule to avoid the
On Fri, 2008-01-25 at 10:44 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Notes: As the syntax shows, these would be statement-level triggers
> > (only). Requesting row level triggers will cause an error. [As Chris
> > Browne explained, if people really want, they can use the
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I would like to make following modification:
> 1) Add ReadBuffer_noerror (recommend me better name) function which will
> accept damaged page without Error. This page will be marked as corrupted
> and when ReadBuffer will touch this page then it will b
Regarding to Robert Mach's work during Google SOC on data integrity
check. I would like to improve storage module and implement some
Robert's code into the core.
I would like to make following modification:
1) Add ReadBuffer_noerror (recommend me better name) function which will
accept damage
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> What about a feature to set a default tablespace just for indexes?
Well, for one thing it would break existing dumps, since pg_dump expects
that "SET default_tablespace" works for indexes and tables both.
This has been suggested and rejected multiple
Simon Riggs <[EMAIL PROTECTED]> writes:
> Notes: As the syntax shows, these would be statement-level triggers
> (only). Requesting row level triggers will cause an error. [As Chris
> Browne explained, if people really want, they can use these facilities
> to create a Before Statement trigger that e
Florian Weimer wrote:
This doesn't work because '\' is turned into '\\' by PostgreSQL, and
not '\134':
my $arg = shift;
$arg =~ s!\\(\d{3})!chr(oct($1))!ge;
Something like this might be better:
my $arg = shift;
$arg =~ s!\\(?:\\|(\d{3}))!$1 ? chr(oct($1)) : "\\"!ge;
You need
Peter Eisentraut wrote:
What about a feature to set a default tablespace just for indexes? I have
been told that this was originally proposed when tablespaces where designed,
but did not end up being implemented. Does anyone recall the details? I
have had people ask me about this feature.
On Fri, 2008-01-25 at 13:01 +0100, Peter Eisentraut wrote:
> What about a feature to set a default tablespace just for indexes?
Why would we want this particular idea? I'm not against it specifically,
but it seems like there are many similar ideas, so we should think about
what we are trying to
On Jan 25, 2008, at 1:01 PM, Peter Eisentraut wrote:
What about a feature to set a default tablespace just for indexes?
I have
been told that this was originally proposed when tablespaces where
designed,
but did not end up being implemented. Does anyone recall the
details? I
have had p
What about a feature to set a default tablespace just for indexes? I have
been told that this was originally proposed when tablespaces where designed,
but did not end up being implemented. Does anyone recall the details? I
have had people ask me about this feature.
--
Peter Eisentraut
http:
(for 8.4 ...)
I'd like to introduce triggers that fire when we issue a truncate:
CREATE TRIGGER name [BEFORE | AFTER ] TRUNCATE ON table
FOR EACH STATEMENT EXECUTE PROCEDURE function (arguments);
The truncate trigger would fire separately from a statement-level DELETE
statement, to allow us to di
This doesn't work because '\' is turned into '\\' by PostgreSQL, and
not '\134':
my $arg = shift;
$arg =~ s!\\(\d{3})!chr(oct($1))!ge;
Something like this might be better:
my $arg = shift;
$arg =~ s!\\(?:\\|(\d{3}))!$1 ? chr(oct($1)) : "\\"!ge;
You need to do this in one go beca
31 matches
Mail list logo
