Thread: AW: The lightbulb just went on...
> 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 be that sessions is a view > and not a table, Did you create an on update do instead rule ? This is currently not done automatically for views, thus views without additional "create rule"s are select only. But, I am wondering whether the "for update" places the correct lock ? Andreas
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> 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 automatically for views,
> thus views without additional "create rule"s are select only.
> But, I am wondering whether the "for update" places the correct lock ?
Hmm, good point! I'm not sure what "select for update" on a view ought
to do, but I am pretty sure that the code will not do anything useful
or sensible for this case...
regards, tom lane
On Thu, 19 Oct 2000, Tom Lane wrote: > Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> 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 ? Yes actually :). But Ive since elimintated the rule and figured out I could get the equivalent functionality I was getting the the RULE/VIEW by just using a simple PL/pgSQL trigger. Since doing that, the "relation XXXXX modified while in use" errors have gone away, but I'm still not sure I trust VACUUM ANALYZE enough to run it on a non-idle production database :). I want to do more testing before I get that brave :). Mike