You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
When during normal database operation (I mean multi-user database access) procedures are permanently created, altered and dropped under unsuccessful circumstances almost random block of memory may be overwritten with an array of procedure format blocks.
summary: Segfaults when procedures are permanently created, altered and dropped => Segfaults can (sometimes) result when DDL operations are performed against Stored Procedures under active database/multi-user access conditions.
András, program codes are not corrupted (hmm, they are read-only for many years in known to me OSes). Only data pages may be corrupted - what place depends upon current structure of DBB memory pool which after some time of engine operation is close to what we call pseudo-random place. I've never seen such corruption in DB pages cache - but this does not mean it's impossible specially when very small cache size (like default for classic server) is used. With large caches it can hardly happen - big pages used for such cache are placed by MemoryPool in another memory area, i.e. far from procedure format.
I mean program codes == stored procedures BLR codes.
Sometimes we have strange errors, "old" data (surely last edited days or months ago) lost from database (the daily backup and restore shows foreign key error, and we have to insert the parent record back from previous backup).
I'm 100% sure this data pages are frequently used for read, but not write, and we could never reproduce this behavior....
And, we are creating and dropping tables, views and stored procedures.