Richard Huxton wrote: > Was it "tuple concurrently updated"? You can reproduce this fairly > simply by issuing BEGIN...CREATE OR REPLACE FUNCTION f... in two > different psql sessions and delaying COMMIT appropriately. AFAIK it's > harmless, but does abort your transaction. I /think/ so, but it was buried deep in custom scripting and (usual story) I was under pressure to get something else done at the time :-) > > in the interim I've set up a transaction with a lock on the table that is > > most likely to be involved noting that by default the lock type is the most > > restrictive. > > You probably want a userlock (see contrib/), or as low-impact a lock as > you can get away with. Perhaps lock your dummy table (row contains > function schema/name?). You'll still want to code your application in > such a way that it copes with errors though - the lock attempt can > always time out (in theory anyway). Thanks, noted. I'm not expecting this to be a regular occurence since in general the only time multiple sessions will be running will be during maintenance. If I might ask a related question- assuming that a client has grabbed a restrictive lock during a transaction that e.g. is create/replacing functions, what happens to other sessions that attempt to run a select or update- will they fail (i.e. an implicit NOWAIT) or will they wait until the lock is released? Does this vary depending on whether a select/update is within an explicit transaction? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
