Hi,
It's simply because we should not refer to system catalog during the recovery.
2009/1/25 Gregory Stark :
>
> Koichi Suzuki 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 c
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
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
cas
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 wo
On Sat, Jan 10, 2009 at 01:36:25PM -0500, Tom Lane wrote:
> Jeff Davis 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 has been c
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:
pg_loc
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
On Sun, Jan 25, 2009 at 11:47 AM, Tom Lane 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 would have to tr
On Mon, Jan 19, 2009 at 15:26, Brendan Jurd 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 and gave it a lo
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 r
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,
Emm
On Sun, Jan 25, 2009 at 12:06 PM, 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 committa
Bernd Helmle 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] UPDATABLE] VIEW .
2009/1/25 Bernd Helmle :
>
>
> --On 25. Januar 2009 12:16:56 -0500 Andrew Dunstan
> 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
> 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 work).
> I'm also
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 do
--On 25. Januar 2009 12:16:56 -0500 Andrew Dunstan
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 to TEMP|TEMPORARY VIE
Tom Lane wrote:
Bernd Helmle 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 sa
Bruce Momjian 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 releases, so th
Bernd Helmle 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 reason: backwards
co
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 us
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
On Sun, Jan 25, 2009 at 1:07 PM, Bernd Helmle 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 school on this one
>> 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 g
--On 24. Januar 2009 20:47:20 -0500 Tom Lane wrote:
Bernd Helmle 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 ;-)
Of course, i'
Robert Haas wrote:
> On Sun, Jan 25, 2009 at 12:28 AM, Bruce Momjian 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.
> > Also, one t
On Sun, Jan 25, 2009 at 12:28 AM, Bruce Momjian 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 many of the compl
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]
http://sepgsql.googlecode.com/files/sepostgresql
Robert Haas wrote:
On Fri, Jan 23, 2009 at 12:30 AM, KaiGai Kohei 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]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8
Koichi Suzuki 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 tricky to avoid is pr
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.
--On Sonntag, Januar 25, 2009 09:41:14 +0100 Guillaume Smet
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 principl
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 th
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 con
On Sat, Jan 24, 2009 at 1:17 AM, Tom Lane 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 of least surprise
35 matches
Mail list logo
