ora: ORA-28112: failed to execute policy function

Hi! Another trouble 😃 I’m calling the same stored procedure for a number of times. The first 374 runs are OK, but on the run 375 it fails with ORA-28112 Another effect that I observe, is that the memory usage grows constantly. I’ve eliminated all of my code to isolate the case and made sure that only the driver’s code is running. The memory leakage continued… I’ve suspected that the cursors are not getting released and found out in debugger that the line stmt.go#193 (C.OCIHandleFree(unsafe.Pointer(ocistmt), C.OCI_HTYPE_STMT)) isn’t called indeed… It’s just my speculation, but may be this is a reason for this effect?

Here’s the code that eventually fails:

func LoadUState(guid string) (err error) {
	session, err := SessionPool.Get()
	defer SessionPool.Put(session)
	if err != nil {
		panic(err)
	}
	stmt, err := session.Prep("call sp_get_user_state(:i_user_guid, :o_cur_users,:o_cur_auth_users,:o_cur_acct_accounts,:o_cur_settings)")

        defer stmt.Close()
	if err != nil {
		return err
	}
	usersCur := &ora.Rset{}
	authUsersCur := &ora.Rset{}
	accountsCur := &ora.Rset{}
	settingsCur := &ora.Rset{}

	_, err = stmt.Exe(guid, usersCur, authUsersCur, accountsCur, settingsCur)

	if err != nil {
		return err
	}

	
	usersCur.NextRow()
	authUsersCur.NextRow()
	accountsCur.NextRow()
	settingsCur.NextRow()

	return nil
}

With kind regards, LK

About this issue

Commits related to this issue

Most upvoted comments

Tamas, I truly appreciate your effort! You’ve done one hell of the job on this project and AFAIK this is the only solid attempt to give us enterprise Oracle slaves 😃 a way to bring Go to the corporate world. #223 is just a total No Go for us, since 80% of our Oracle code is implemented as a stored procedures that return cursors… I’d really love to contribute to this project since it’s of paramount value in the success of Go in the enterprise, so if you need any help, please, just let me know…

BTW, I’ve observed, that if you return cursors from prepared statement executed from the driver, rather than calling SP, the behaviour is different…

With kind regards, LK