Heikki Linnakangas napsal(a):
Attached is a revamped version of the FSM rewrite. WAL-logging is now
gone. Any inconsistencies between levels of the FSM is fixed during
vacuum, and by searchers when they run into a dead end because of a
discrepancy. Corruption within FSM pages is likewise fixed
On Wed, 2008-09-24 at 21:19 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
2. Master ignores Standby's OldestXmin
Effects:
* Long running queries on standby...
Have no effect on primary
Can delay apply of WAL records on standby
* Queries on standby give consistent answers in
Hi,
Markus Wanner wrote:
As mentioned in above, regression tests, documentation updates,
dependency handling, and actually implementing the permission checks all
remain. What I'm looking for feedback on are the changes to the
grammer, parser, catalog changes, psql output, etc.
Aha, good. So
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
I'm testing this version now and I got core dump in initdb phase:
08047558 pgstat_count_heap_insert+0x20(840b120, 842d738, 80, 8047580)
snip
Let me know if you need more info. (I'm not using fresh CVS snapshot
but two weeks old)
On Tue, 2008-09-16 at 00:10 -0400, Greg Smith wrote:
Attached is an updated and separate version of my patch exposing the
internal GUC boot_val as default_val, which failed to attach itself to the
already committed changes to the pg_settings view.
Brief reminder of what it does:
Gevik Babakhani napsal(a):
Dear PG hackers,
Has there been any idea to port PG to a more modern programming language
like C++? Of course there are some minor obstacles like a new OO design,
this being a gigantic task to perform and rewriting almost everything etc...
I am very interested to hear
Simon Riggs wrote:
2. Master ignores Standby's OldestXmin
Effects:
* Long running queries on standby...
Have no effect on primary
Can delay apply of WAL records on standby
* Queries on standby give consistent answers in all cases.
Just for clarification, if you set a
Advantage of C++ is that it reduce lot of OO code written in
C in PostgreSQL, but it is so big effort to do that without
small gain. It will increase number of bugs. Do not forget
also that C++ compiler is not so common (so good) on
different platforms. If somebody interesting in that yes
On Thu, 2008-09-25 at 11:14 +0200, Zeugswetter Andreas OSB sIT wrote:
Simon Riggs wrote:
2. Master ignores Standby's OldestXmin
Effects:
* Long running queries on standby...
Have no effect on primary
Can delay apply of WAL records on standby
* Queries on standby give
On Wed, 2008-09-24 at 21:22 -0400, Bruce Momjian wrote:
Bruce Momjian wrote:
Simon Riggs wrote:
2. Master ignores Standby's OldestXmin
Effects:
* Long running queries on standby...
Have no effect on primary
Can delay apply of WAL records on standby
* Queries on standby
Gevik Babakhani napsal(a):
Better idea is to start to use C99 in PostgreSQL ;-).
I have not investigated this yet. But I am very interested to know what the
advantages would be to upgrade the code to C99 standards.
I think replace macros with inline functions. It brings to ability to
I wonder whether the cancel can be delayed until a tuple/page is actually
accessed
that shows a too new xid.
Yes, its feasible and is now part of the design.
This is all about what happens *if* we need to remove rows that a query
can still see.
I was describing a procedure for
Are you saying the performance penalty when full functionalities are
enabled?
(The meaning of bells and whistles is unclear for me.)
Yes, that's what I meant. (Sorry.)
We can show it on the page.22 of my presentation in PGcon2008.
Zdenek Kotala [EMAIL PROTECTED] writes:
Gevik Babakhani napsal(a):
I have not investigated this yet. But I am very interested to know what the
advantages would be to upgrade the code to C99 standards.
I think replace macros with inline functions. It brings to ability to
monitor them for
On Thu, 2008-09-25 at 12:34 +0200, Zeugswetter Andreas OSB sIT wrote:
I wonder whether the cancel can be delayed until a tuple/page is actually
accessed
that shows a too new xid.
Yes, its feasible and is now part of the design.
This is all about what happens *if* we need to
Simon Riggs [EMAIL PROTECTED] writes:
We have an RESET command which returns parameter to its default
setting. But what this means is return it to the value set in current
the postgresql.conf, if overriden therein from its default value. So it
would be useful to have a column that meant if I
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We have an RESET command which returns parameter to its default
setting. But what this means is return it to the value set in current
the postgresql.conf, if overriden therein from its default value. So it
would be useful to have a column
On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote:
If both are interesting to different audiences, perhaps we should be
exposing both as separate columns?
That seems best. It will make things much clearer.
Having
one column named reset_val and one named boot_val should work, no?
Simon Riggs wrote:
On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote:
Having
one column named reset_val and one named boot_val should work, no?
Yes, those names seem very appropriate to me.
Finding the reset_val isn't that tough, IIRC the way the guc assignment
works with its doit
Magnus Hagander [EMAIL PROTECTED] writes:
It sounds like you are making the case for what I write above? Having
one column named reset_val and one named boot_val should work, no?
Well, that's what I've been saying right along, but the previous
discussion was all about what to call the columns
On 9/25/08, Tom Lane [EMAIL PROTECTED] wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Gevik Babakhani napsal(a):
I have not investigated this yet. But I am very interested to know what the
advantages would be to upgrade the code to C99 standards.
I think replace macros with inline
On Thu, 2008-09-25 at 14:52 +0200, Magnus Hagander wrote:
Simon Riggs wrote:
On Thu, 2008-09-25 at 14:42 +0200, Magnus Hagander wrote:
Having
one column named reset_val and one named boot_val should work, no?
Yes, those names seem very appropriate to me.
Finding the reset_val
On Thu, 2008-09-25 at 09:15 -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
It sounds like you are making the case for what I write above? Having
one column named reset_val and one named boot_val should work, no?
Well, that's what I've been saying right along, but the
Gevik Babakhani wrote:
Advantage of C++ is that it reduce lot of OO code written in
C in PostgreSQL, but it is so big effort to do that without
small gain. It will increase number of bugs. Do not forget
also that C++ compiler is not so common (so good) on
different platforms. If somebody
Hi there,
Following up a report on the PostGIS bugtracker (also submitted to
pgsql-bugs here:
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00086.php), I'm
wondering if there is a bug in the way that GiST indexes interact with
scroll cursors.
I've managed to reproduce the bug using
On Thu, 25 Sep 2008, Simon Riggs wrote:
I would suggest we either alter pg_settings so that we display value
*only* when source=default (set NULL otherwise) or we do some extra work
to derive what the setting would be if we ran RESET. The latter would be
preferred approach.
Since getting the
On Mon, 2008-09-22 at 18:41 +0100, Gregory Stark wrote:
The easiest way to fix this seems like also the best way, instead of storing a
boolean store the pointer to the release function.
Implemented as suggested. v5 enclosed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL
Mark Cave-Ayland [EMAIL PROTECTED] writes:
Following up a report on the PostGIS bugtracker (also submitted to
pgsql-bugs here:
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00086.php), I'm
wondering if there is a bug in the way that GiST indexes interact with
scroll cursors.
I
Tom Lane wrote:
I think adding a subobject column to pg_shdepend is probably the best
answer --- we only didn't do that to start with because we thought it
wasn't needed.
Yep. I did consider adding it, but there was no use for it at the time
so I just left it out. It's not like it's very
No problem, I have time for clearing. But are these functions
guaranteed to be included in the contrib? If there is no guarantee,
seems the time of clearing will be wasted. (5 years ago I have already
cleaned one open-source library on demand and after that it was not
approved for PEAR repository,
On Thu, 2008-09-25 at 12:27 -0400, Tom Lane wrote:
Mark Cave-Ayland [EMAIL PROTECTED] writes:
Following up a report on the PostGIS bugtracker (also submitted to
pgsql-bugs here:
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00086.php), I'm
wondering if there is a bug in the way
Simon Riggs [EMAIL PROTECTED] writes:
Seems like GIST should be able to fake a backwards scan if needed.
Well, it tries --- there is logic in there that pays attention to the
scan direction. Like I say, I don't know the extent of the difficulty.
If we were to decide that it's unfixable, the
KaiGai Kohei wrote:
Bruce Momjian wrote:
2) Do we want row-level permissions at the SQL level?
Now I'm working for it and will submit patches due to the end of Oct,
if it is really required to make progress reviewing of SE-PostgreSQL
on the v8.4 development cycle.
However,
Simon Riggs [EMAIL PROTECTED] writes:
Version 7
After reading this for awhile, I realized that there is a rather
fundamental problem with it: it switches into consistent recovery
mode as soon as it's read WAL beyond ControlFile-minRecoveryPoint.
In a crash recovery situation that typically is
Bruce Momjian [EMAIL PROTECTED] writes:
Here is how I think SQL-level row permissions would work:
We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW SECURITY) called security_context which
This is just a different syntax for KaiGai's label storage
implementation. It doesn't really answer any of the hard questions,
like what the heck is the behavior of foreign keys.
What do you find inadequate about KaiGai's answers to those hard questions?
...Robert
--
Sent via pgsql-hackers
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Here is how I think SQL-level row permissions would work:
We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW SECURITY) called
Here is how I think SQL-level row permissions would work:
We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW SECURITY) called security_context which would store the
oid of the role that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Here is how I think SQL-level row permissions would work:
We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW SECURITY) called
Robert Haas [EMAIL PROTECTED] writes:
This is just a different syntax for KaiGai's label storage
implementation. It doesn't really answer any of the hard questions,
like what the heck is the behavior of foreign keys.
What do you find inadequate about KaiGai's answers to those hard questions?
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Here is how I think SQL-level row permissions would work:
We already have an optional OID system column that can be specified
during table creation (WITH OIDS). We could have another optional oid
column (WITH ROW
Robert Haas [EMAIL PROTECTED] writes:
I like the idea of a WITH ROW SECURITY option to enable row-level
security - that way, tables that don't need it don't have to pay for
it, but I like the idea of storing a full ACL, as KaiGai proposed,
rather than just a single role. Seems much more
Tom Lane wrote:
4. User charlie revokes alice's membership in admin.
Now what? Alice's FK constraint is violated, according to the rules
KaiGai proposes. Shall REVOKE have to grovel through every table in the
database looking for possible violations ... and of course locking the
entire DB
Good:
regression=# select 'T' ilike 't';
?column?
--
t
(1 row)
Not so good:
regression=# select 'T' ilike E'\\t';
?column?
--
f
(1 row)
ISTM backslash is only supposed to turn off the pattern-language
specialness of characters, not render them case sensitive. The reason
Tom Lane wrote:
Robert Haas [EMAIL PROTECTED] writes:
This is just a different syntax for KaiGai's label storage
implementation. It doesn't really answer any of the hard questions,
like what the heck is the behavior of foreign keys.
What do you find inadequate about KaiGai's answers to
I like the idea of a WITH ROW SECURITY option to enable row-level
security - that way, tables that don't need it don't have to pay for
it, but I like the idea of storing a full ACL, as KaiGai proposed,
rather than just a single role. Seems much more powerful.
... and even more ill-defined.
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
4. User charlie revokes alice's membership in admin.
Now what? Alice's FK constraint is violated, according to the rules
KaiGai proposes. Shall REVOKE have to grovel through every table in the
database looking for possible violations
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
4. User charlie revokes alice's membership in admin.
Now what? Alice's FK constraint is violated, according to the rules
KaiGai proposes. Shall REVOKE have to grovel through every table in the
database looking
Robert Haas [EMAIL PROTECTED] writes:
I think you have to resign yourself to the fact that a user who can
see only a subset of the rows in a table may very well see apparent
foreign-key violations. But so what?
So you're leaking information about the rows that they're not supposed
to be able
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
4. User charlie revokes alice's membership in admin.
Now what? Alice's FK constraint is violated, according to the rules
KaiGai proposes. Shall REVOKE have to grovel through every table in the
database looking for
Tom Lane wrote:
Good:
regression=# select 'T' ilike 't';
?column?
--
t
(1 row)
Not so good:
regression=# select 'T' ilike E'\\t';
?column?
--
f
(1 row)
ISTM backslash is only supposed to turn off the pattern-language
specialness of characters, not render them case
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You mean her data just disappears? Doesn't sound very reasonable to me.
Well, she actually gets an error rather than a query with missing data,
which is proabably the best we are going to do, unless we don't
implement row-level
You mean her data just disappears? Doesn't sound very reasonable to me.
In reference cases, we can consider she looks the tables via something
like VIEWs implicitly. The VIEW can hide several tuple, but it does
not break any reference consistency in the raw level.
I don't understand what
Andrew Dunstan [EMAIL PROTECTED] writes:
The docs actually don't state what are the semantics of escape followed
by something that is not escape or a metachar. Does the spec say
anything about that?
The spec says it's an error, per the SQL92 excerpt I quoted in the
previous thread. (SQL99
Robert Haas wrote:
You mean her data just disappears? Doesn't sound very reasonable to me.
In reference cases, we can consider she looks the tables via something
like VIEWs implicitly. The VIEW can hide several tuple, but it does
not break any reference consistency in the raw level.
I don't
I think you have to resign yourself to the fact that a user who can
see only a subset of the rows in a table may very well see apparent
foreign-key violations. But so what?
So you're leaking information about the rows that they're not supposed
to be able to see. This is not what I would
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The docs actually don't state what are the semantics of escape followed
by something that is not escape or a metachar. Does the spec say
anything about that?
The spec says it's an error, per the SQL92 excerpt I quoted in the
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
So I'm for the definition that escape-anything means exactly anything,
without any special treatment that it would otherwise have. And in
the case of ILIKE it seems like no special treatment should mean
case insensitive match.
Well,
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
2) Do we want row-level permissions at the SQL level?
Now I'm working for it and will submit patches due to the end of Oct,
if it is really required to make progress reviewing of SE-PostgreSQL
on the v8.4 development cycle.
On Sep 25, 2008, at 20:45, Tom Lane wrote:
Well, there are two possible interpretations: (1) it's a bug, or (2)
it's an intentional, about-to-be-documented feature that
backslashing a
letter makes it case-sensitive in ILIKE.
I do not care for interpretation #2 ... especially in view of your
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
You mean her data just disappears? Doesn't sound very reasonable to me.
Well, she actually gets an error rather than a query with missing data,
which is proabably the best we are going to do, unless we don't
implement
61 matches
Mail list logo
