On Thu, Jan 22, 2009 at 07:03:45PM -0500, Tom Lane wrote:
BTW, something else I'd meant to bring up for discussion is whether
anyone likes the formatting of column privileges in \dp:
regression=# create table foo(bar int, baz int);
CREATE TABLE
regression=# grant select on foo to joe;
On Fri, 2009-01-23 at 16:49 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2009-01-23 at 10:33 -0500, Tom Lane wrote:
Right, the WAL-record-processing API is not really at issue, since it's
been proven internally to the core code. My concern is with the other
That doesn't look like duplicated tables so much as duplicated
pg_namespace rows --- try doing \d's query by hand and adding display
of pg_class.ctid and pg_namespace.ctid. However, if that theory is
correct then the next question is what you were doing to pg_namespace...
The bug was
On Sat, 2009-01-24 at 17:24 +1300, Mark Kirkwood wrote:
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
I'm seeing an off-by-one error on xmax, in some cases. That then causes
the flat file update
Andrew Dunstan píše v pá 23. 01. 2009 v 23:57 -0500:
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Sure, we can easily have buildfarm's initdb step set any locale (and
encoding, for that matter) we like. That's a simple change.
Will be
Tom Lane píše v pá 23. 01. 2009 v 10:19 -0500:
Zdenek Kotala zdenek.kot...@sun.com writes:
Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
Do you have an example use case for this?
I use it in my space reservation patch. I going to send it soon.
Haven't we been over that ground
Bruce Momjian wrote:
Now that we are two months into the final commit fest, it is time to
finalize all the open patches so we can target a February beta.
The two major outstanding patches are:
o SE-PostgreSQL: The author has done an outstanding job of
reworking the patch so the
On Sat, 2009-01-24 at 11:20 +, Simon Riggs wrote:
On Sat, 2009-01-24 at 17:24 +1300, Mark Kirkwood wrote:
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
I'm seeing an off-by-one error
On Sat, 2009-01-24 at 09:57 +, Simon Riggs wrote:
I agree we need an external module and I learned that lesson from the
earier API proposal you mentioned. The supplied WAL filter plugin was/is
a valid use for this and, as discussed, is the only practical way of
doing WAL filtering. As I
Teodor Sigaev escreveu:
That doesn't look like duplicated tables so much as duplicated
pg_namespace rows --- try doing \d's query by hand and adding display
of pg_class.ctid and pg_namespace.ctid. However, if that theory is
correct then the next question is what you were doing to
KaiGai Kohei wrote:
Bruce Momjian wrote:
Now that we are two months into the final commit fest, it is time to
finalize all the open patches so we can target a February beta.
The two major outstanding patches are:
o SE-PostgreSQL: The author has done an outstanding job of
On 2009-01-24, at 15:33, Bruce Momjian wrote:
The PostgreSQL community is considering including security
enhancements
in Postgres 8.4, e.g. row-level permissions and SE-Linux security.
However, to evaluate the patch and its usefulness, we need security
experts who want to use this
Bruce Momjian wrote:
KaiGai Kohei wrote:
Bruce Momjian wrote:
Now that we are two months into the final commit fest, it is time to
finalize all the open patches so we can target a February beta.
The two major outstanding patches are:
o SE-PostgreSQL: The author has done an
--On 23. Januar 2009 21:18:19 -0500 Robert Haas robertmh...@gmail.com
wrote:
In the future, I think we should have an expectation that resubmits
within the same CommitFest should happen within a week, and that if no
revision is forthcoming within two weeks the patch is declared dead
(and
This post is a follow-up of an off-list discussion with Nathan Boley.
All references to FOR UPDATE apply to FOR SHARE as well.
create table a(i int, j int);
insert into a values(1, 10);
insert into a values(2, 10);
insert into a values(3, 10);
insert into a values(4, 20);
insert into a values(5,
I wrote:
... It seems to me that the rule engine
has probably got all the infrastructure needed to convert the query the
way we'd like, we just don't have a suitable API to tell it to do that.
I have in mind a couple of quite different approaches to this, and wanted
to solicit some feedback
There already is quite an extensive discussion of how FOR UPDATE
behaves including these kinds of violations.
What you propose is interesting though. It would have been impossible
before subtransactions but it's doable now. Still the performance
might be unusable for complex queries. It's
On Sat, 2009-01-24 at 13:51 +, Simon Riggs wrote:
On Sat, 2009-01-24 at 09:57 +, Simon Riggs wrote:
I agree we need an external module and I learned that lesson from the
earier API proposal you mentioned. The supplied WAL filter plugin was/is
a valid use for this and, as
When replaying a DROP TABLE SPACE, you first try to remove the
directory, and if that fails, you assume that it's because it's in use
as a temp tablespace in a read-only transaction. You then call
ResolveRecoveryConflictWithVirtualXIDs to kill such transactions, and
try removing the directory
Continuing http://archives.postgresql.org/pgsql-hackers/2009-01/msg01762.php
Bruce Momjian wrote:
Well, this helps explain why were are getting these problems reports
only now. How many hacks do you have that we don't support, aside from
the threading one for HPUX?
Compiling threaded
Tom Lane t...@sss.pgh.pa.us writes:
ON UPDATE DO INSTEAD SUBSTITUTE base_table [ (base_column_name, ...) ]
[ WHERE ... ]
ON UPDATE DO INSTEAD
UPDATE base_table SET base_col_1 = new.derived_col_1, base_col_2 ...
WHERE CURRENT OF VIEW;
What would happen with these if the view is
--On Samstag, Januar 24, 2009 14:17:58 -0500 Tom Lane t...@sss.pgh.pa.us
wrote:
ON UPDATE DO INSTEAD
UPDATE base_table SET base_col_1 = new.derived_col_1, base_col_2 ...
WHERE CURRENT OF VIEW;
and the rewriter would interpret this appropriately. You'd end up with
essentially the same
Grzegorz Jaskiewicz wrote:
On 2009-01-24, at 15:33, Bruce Momjian wrote:
The PostgreSQL community is considering including security
enhancements
in Postgres 8.4, e.g. row-level permissions and SE-Linux security.
However, to evaluate the patch and its usefulness, we need security
Simon Riggs wrote:
On Sat, 2009-01-24 at 11:20 +, Simon Riggs wrote:
On Sat, 2009-01-24 at 17:24 +1300, Mark Kirkwood wrote:
version 9g - please use this for testing now
I'm doing some test runs with this now. I notice an old flatfiles
related bug has reappeared:
On Sat, 2009-01-24 at 19:45 +, Greg Stark wrote:
There already is quite an extensive discussion of how FOR UPDATE
behaves including these kinds of violations.
Not in the documentation, that I can see. And I think it's important
that it be there for the reasons I mentioned.
Can you refer
Something happened about 80 hours ago that caused my mingw buildfarm
member (gcc 3.4.2 on Win XP Pro SP2) to hang at the check stage. It
looks like it's hung in initdb.
I wonder if it could be this commit:
Log Message:
---
Make win32 builds always do SetEnvironmentVariable() when
On Fri, Jan 23, 2009 at 12:30 AM, KaiGai Kohei kai...@ak.jp.nec.com wrote:
The patch set of SE-PostgreSQL and related stuff were updated (r1460).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1460.patch
[2/5]
Gregory Stark st...@enterprisedb.com writes:
Tom Lane t...@sss.pgh.pa.us writes:
ON UPDATE DO INSTEAD SUBSTITUTE base_table [ (base_column_name, ...) ]
[ WHERE ... ]
ON UPDATE DO INSTEAD
UPDATE base_table SET base_col_1 = new.derived_col_1, base_col_2 ...
WHERE CURRENT OF VIEW;
What
Bernd Helmle maili...@oopsware.de writes:
What i'm missing is some notion about CHECK OPTION. We
surely want to support that in way.
Feel free to insist on that, if you want to make dead certain that
updatable views don't make it into 8.4 ;-)
My recollection of the discussion two years ago is
Jeff Davis pg...@j-davis.com writes:
There you see a snapshot of the table that never existed. Either the
snapshot was taken before the UPDATE, in which case i=3 should be
included, or it was taken after the UPDATE, in which case i=4 should be
included. So atomicity is broken for WHERE.
This
Jeff Davis pg...@j-davis.com writes:
On Sat, 2009-01-24 at 19:45 +, Greg Stark wrote:
There already is quite an extensive discussion of how FOR UPDATE
behaves including these kinds of violations.
Not in the documentation, that I can see. And I think it's important
that it be there for
You're suggestion doesn't help with the problem that (like Joshua already
mentioned) core developers are too busy with reviewing stuff during the
CommitFest. Because of this it's really hard to get the necessary time of
somebody who is able to evaluate the architecture of a new feature and
Robert Haas wrote:
On the other hand, it's easy to draw a line from the lax criteria for
resubmitting patches to the length of this CommitFest. It now appears
that this CommitFest will be something like 3.5 months long and that
the next one will not occur before May. That means we're
On Fri, Jan 23, 2009 at 7:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think that we probably want the rules to show up automatically during
an upgrade from an older version, but it does not follow that they
should come back after being intentionally removed from an 8.4
installation.
[...]
34 matches
Mail list logo
