On Thu, 19 Oct 2000, Tom Lane wrote:
> Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> >> SELECT session_data, id
> >> FROM sessions
> >> WHERE id = ?
> >> FOR UPDATE
> >>
> >> I think part of my problem might be that sessions is a view
> >> and not a table,
>
> > Did you create an o
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> SELECT session_data, id
>> FROM sessions
>> WHERE id = ?
>> FOR UPDATE
>>
>> I think part of my problem might be that sessions is a view
>> and not a table,
> Did you create an on update do instead rule ?
> This is currently not done auto
> what happens to sessions is that it does:
>
> SELECT session_data, id
> FROM sessions
> WHERE id = ?
> FOR UPDATE
>
> client does some processing ...
>
> UPDATE sesssions set session_data = ? WHERE id = ?;
>
> (this is where the error happens)
>
> I think part of my problem might
Michael J Schout <[EMAIL PROTECTED]> writes:
> ERROR: RelationClearRelation: relation 1668325 modified while in use
> relation 1668325 is a view named "sessions".
Hm. This message is coming out of the relation cache code when it sees
an invalidate-your-cache-for-this-relation message from anoth
On Tue, 17 Oct 2000, Tom Lane wrote:
> > and we have not had a crash on vacuum since that happened. If this
> > sounds consistent with the problem you think Alfred is having,
>
> Yes, it sure does.
>
> The patch I have applies atop a previous change in the REL7_0_PATCHES
> branch, so what I w
* Michael J Schout <[EMAIL PROTECTED]> [001017 08:50] wrote:
> Tom:
>
> I think I may have been seeing this problem as well. We were getting
> crashes very often with 7.0.2 during VACUUM's if activity was going
> on to our database during the vacuum (even though the activity was
> light). Our
Michael J Schout <[EMAIL PROTECTED]> writes:
> I think I may have been seeing this problem as well. We were getting
> crashes very often with 7.0.2 during VACUUM's if activity was going
> on to our database during the vacuum (even though the activity was
> light). Our solution in the meantime w
Tom:
I think I may have been seeing this problem as well. We were getting
crashes very often with 7.0.2 during VACUUM's if activity was going
on to our database during the vacuum (even though the activity was
light). Our solution in the meantime was to simply disable the
aplications during a v
The Hermit Hacker <[EMAIL PROTECTED]> writes:
>> I will get this patch made up tonight for REL7_0; if Alfred doesn't
>> see more failures after running it for a few days, then let's move
>> forward on a 7.0.3 release.
> that works for me ... I'm in Montreal for the weekend, so if we can get it
>
On Mon, 16 Oct 2000, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > Something to force a v7.0.3 ... ?
>
> Yes. We had plenty to force a 7.0.3 already, actually, but I was
> holding off recommending a release in hopes of finding Alfred's
> problem.
I thought so, about havin
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Something to force a v7.0.3 ... ?
Yes. We had plenty to force a 7.0.3 already, actually, but I was
holding off recommending a release in hopes of finding Alfred's
problem.
I will get this patch made up tonight for REL7_0; if Alfred doesn't
see mor
Something to force a v7.0.3 ... ?
On Mon, 16 Oct 2000, Tom Lane wrote:
> ... with a blinding flash ...
>
> The VACUUM funnies I was complaining about before may or may not be real
> bugs, but they are not what's biting Alfred. None of them can lead to
> the observed crashes AFAICT.
>
> What'
... with a blinding flash ...
The VACUUM funnies I was complaining about before may or may not be real
bugs, but they are not what's biting Alfred. None of them can lead to
the observed crashes AFAICT.
What's biting Alfred is the code that moves a tuple update chain, lines
1541 ff in REL7_0_PAT
13 matches
Mail list logo
