Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I assume this breakage is from the recent RELKIND_VIEW change;
>> probably psql didn't get updated to know about the new relkind.
> Probably psql uses pg_views though I don't remember correctly.
> It seemd that pg_views(initdb) should
Tom Lane wrote:
> psql has some problems with views in current CVS: \d doesn't show views,
> and if you do \d on a specific view, it doesn't identify it as a view
> and doesn't show the view definition rule.
>
> I assume this breakage is from the recent RELKIND_VIEW change;
> probably psql didn'
> I believe the correct fix for this problem is for bufmgr.c to grab
> a read lock (BUFFER_LOCK_SHARED) on any page that it is writing out.
> A read lock is sufficient since there's no need to prevent other
> backends from reading the page, we just need to prevent them from
> changing it during th
At 19:22 24/09/00 -0500, Dominic J. Eidson wrote:
>
>In these cases, is NULL = 0? - What if it returns the UID for "root"
>(typically UID 0)... I think an error message should/would be better in
>this case.
>
No NULL is NULL, a special value that usually means 'nothing found'.
-
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> This seems to be almost same as I posted 4 months ago(smgrwrite()
> without LockBuffer(was RE: ...).
You are right, this was already a known issue (and I had it buried in
my to-do list, in fact). I rediscovered it while puzzling over some
of the corrup
Tom Lane wrote:
[snip]
>
> The window of vulnerability is considerably wider in 7.0 than in prior
> releases, because in prior releases *any* transaction commit will write
> all dirty pages. In 7.0 the dirtied page will not get written out until
> we commit a transaction that modified that par
On Sun, 24 Sep 2000, Philip Warner wrote:
> Two routines do eccentric things when they can't find required supporting
> data:
>
> pg_get_userbyid
>
> returns 'unknown (UID=)' when the UID does not exist.
[Snip]
> The proposal is to return NULL in the above cases - in the final case,
> pro
The comments for bufmgr.c's BufferSync routine point out that it's a
bad thing for some other backend to be modifying a page while it is
written out. The following text has gone unchanged since Postgres95:
*Also, we need to be sure that no other transaction is
*modifying the page as we
Philip Warner <[EMAIL PROTECTED]> writes:
> pg_get_viewdef
> returns 'Not a view' when passed a non-existant or non-view table
> it also signals errors when the underlying metadata can not be found.
> The proposal is to return NULL in the above cases - in the final case,
> probably also
On the documentation
http://www.postgresql.org/users-lounge/docs/7.0/postgres/mvcc4646.htm what
does mean "...Postgres doesn't remember any information about modified rows
in memory and so has no limit to the number of rows locked without lock
escalation."?
Following you find "How
10 matches
Mail list logo
