On Sat, Jan 24, 2009 at 1:17 AM, 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
I'm really not convinced by that. Is it required by the standard? It's
really far from being compliant with the principle
On Sat, 2009-01-24 at 21:58 +0200, Heikki Linnakangas wrote:
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.
That sounds like you think there another
Simon Riggs wrote:
On Sat, 2009-01-24 at 21:58 +0200, Heikki Linnakangas wrote:
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.
That sounds like you think
--On Sonntag, Januar 25, 2009 09:41:14 +0100 Guillaume Smet
guillaume.s...@gmail.com wrote:
I think that we probably want the rules to show up automatically during
an upgrade from an older version
I'm really not convinced by that. Is it required by the standard? It's
really far from being
On 2009-01-25, at 09:04, Simon Riggs wrote:
On Sat, 2009-01-24 at 21:58 +0200, Heikki Linnakangas wrote:
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.
Koichi Suzuki koichi@gmail.com writes:
Please find enclosed 2nd patch of pg_readahead which include a patch
to bufer manager to skip prefetch of pages already in shared buffer.
I'm a bit confused by this comment. PrefetchBuffer already checks if the page
is in shared buffers.
What is
Robert Haas wrote:
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]
The patch set of SE-PostgreSQL and related stuff were updated (r1467).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1467.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1467.patch
[3/5]
On Sun, Jan 25, 2009 at 12:28 AM, Bruce Momjian br...@momjian.us wrote:
Well, also consider 8.3 was released in February, so we had 9 months of
development before the last commit-fest started.
Yes - that was good. But what will happen for 8.5?
Also, one thing we have always known is that
Robert Haas wrote:
On Sun, Jan 25, 2009 at 12:28 AM, Bruce Momjian br...@momjian.us wrote:
Well, also consider 8.3 was released in February, so we had 9 months of
development before the last commit-fest started.
Yes - that was good. But what will happen for 8.5?
Probably the same.
--On 24. Januar 2009 20:47:20 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
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
Yeah... I'm not sure what to do about that, but as Tom pointed out,
it has the disadvantage that all of these massive changes are getting
put into the tree just before we start beta.
Well, it is less a problem than in previous releases, so things are
getting better.
Well, that is good.
I
On Sun, Jan 25, 2009 at 1:07 PM, Bernd Helmle maili...@oopsware.de wrote:
I didn't find such a notion in the standard. A view is automatically
updatable if it meets the criteria of updatability). If you don't want your
view writable, you have to GRANT the necessary ACLs.
Perhaps I'm a bit old
On Sun, 2009-01-25 at 11:28 +0200, Heikki Linnakangas wrote:
You then call
ResolveRecoveryConflictWithVirtualXIDs to kill such transactions, and
try removing the directory again. But
ResolveRecoveryConflictWithVirtualXIDs doesn't wait for the target
transaction to die anymore (or
On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote:
Ok, then I think we have a little race condition. The startup process
doesn't get any reply indicating that the target backend has
processed
the SIGINT and set the cached conflict LSN. The target backend might
move ahead using
Bernd Helmle maili...@oopsware.de writes:
I originally had the idea of a GUC which controls wether automatic rules
will be generated or not. But I abonded this idea, since this has some kind
of parametrized SQL standard functionality.
We have GUCs like that already, for exactly the same
Bruce Momjian br...@momjian.us writes:
Robert Haas wrote:
Yeah... I'm not sure what to do about that, but as Tom pointed out,
it has the disadvantage that all of these massive changes are getting
put into the tree just before we start beta.
Well, it is less a problem than in previous
Tom Lane wrote:
Bernd Helmle maili...@oopsware.de writes:
I originally had the idea of a GUC which controls wether automatic rules
will be generated or not. But I abonded this idea, since this has some kind
of parametrized SQL standard functionality.
We have GUCs like that already,
--On 25. Januar 2009 12:16:56 -0500 Andrew Dunstan and...@dunslane.net
wrote:
Maybe something like CREATE VIEW WITHOUT UPDATE;
I actually like the idea of being able to turn update on and off for a
view.
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer
Simon Riggs wrote:
2. Kill all connections by given user. Hmm, not used for anything,
actually. Should remove the roleId argument from GetConflictingVirtualXIDs.
No, because we still need to add code to kill-connected-users if we drop
role.
Oh, I see, that's still a todo item. But we don't
2009/1/25 Bernd Helmle maili...@oopsware.de:
--On 25. Januar 2009 12:16:56 -0500 Andrew Dunstan and...@dunslane.net
wrote:
Maybe something like CREATE VIEW WITHOUT UPDATE;
I actually like the idea of being able to turn update on and off for a
view.
Or what about
CREATE [OR
Bernd Helmle maili...@oopsware.de writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you proposing
CREATE [OR REPLACE] [[NOT]
On Sun, Jan 25, 2009 at 12:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
and I'm beginning to think that we need to invoke that provision.
Particularly with regard to hot standby, which by any sane reading was
not close to being committable on 1 November (a fortiori from the fact
that it's
Hi Amit,
I overlooked the fact that you dropped composite partitions and
subpartitions template from the proposal presented in
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php.
Is it because this is too hard to support? or you don't see any
immediate need for it?
Thanks,
Tom Lane escribió:
The main question in my mind is whether we should have a turn-off
feature that is global (GUC) or per-view (reloption). One difficulty
with a reloption is that there's no way to set it on a view until after
you've done CREATE VIEW, whereupon it's too late --- the auto
On Mon, Jan 19, 2009 at 15:26, Brendan Jurd dire...@gmail.com wrote:
From the better-late-than-never department, comes a patch to improve
the handling of AM/PM and AD/BC markers in to_timestamp(), and up the
ante on error reporting for various kinds of invalid input.
Ok cool I tried this out
On Sun, Jan 25, 2009 at 11:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This would all be a little easier to accomplish if the behavior were
made to be implicit in the rewriter (ie, rewrite instead of throwing a
no rule error), since then there is no persistent state that a GUC or
reloption
Where I work they make extensive use of Postgresql. One of the things
they typically want to know about are lock waits. Out of the box in
there is not much in the way of tracking for such, particularly in older
versions. The view pg_stats is fine for stuff happening *now*, but
typically I find
Here is a patch to surpress compiler warnings in pg_locale.c and pg_regress.c.
There are following warnings if nls is enabled:
pg_locale.c: In function `pg_perm_setlocale':
pg_locale.c:161: warning: assignment discards qualifiers from pointer
target type
and if nls is disabled:
On Sat, Jan 10, 2009 at 01:36:25PM -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
I ran 5 times on both old and new code, eliminating the top and bottom
and taking the average of the remaining 3, and I got a 6.9% performance
improvement with the new code.
The question that
Tom Lane wrote:
and I'm beginning to think that we need to invoke that provision.
Particularly with regard to hot standby, which by any sane reading was
not close to being committable on 1 November (a fortiori from the fact
that it's *still* not committable despite large amounts of later
Robert Haas wrote:
I would, however, like to see us make a commitment to actually review
SE-PostgreSQL. There was some talk that we might not want to include
this feature in core at all, and if that is the case then I think it
is long past time to make that decision. Assuming that isn't the
Simon Riggs wrote:
In various places in current HEAD we throw a checkpoint when we want to
be certain that all buffers have been flushed.
In recovery, a checkpoint isn't always a restartpoint for two reasons:
timing and rmgr state. This gives both a cause for the error and an
explanation of why
Hi,
It's simply because we should not refer to system catalog during the recovery.
2009/1/25 Gregory Stark st...@enterprisedb.com:
Koichi Suzuki koichi@gmail.com writes:
Please find enclosed 2nd patch of pg_readahead which include a patch
to bufer manager to skip prefetch of pages
34 matches
Mail list logo
