Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] Brokenness in Ubuntu upgrade (deb packages)

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] Brokenness in Ubuntu upgrade (deb packages)


Chronological Thread 
    < Chronological >      < Thread >
  • From: Brian Candler <>
  • To: "" <>
  • Subject: Re: [perfsonar-user] Brokenness in Ubuntu upgrade (deb packages)
  • Date: Sat, 12 Oct 2019 14:39:05 +0100
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:from:to :references:message-id:date:mime-version:in-reply-to :content-type; q=dns; s=sasl; b=m3Xn97MBRVFagZGulECmMuivwbe7fQ0g RaEGZAbzfQDLXuGSpy3I/zswI1pefPWWLZH7vHFBx1JXdHOwZGCOFQ9uah+BXHkJ uQGh3RTxXCLf9VAi/c3CYfroU2aXDrkNRYCkW5PQYWZUEKRMCRTtXPWt1Hhod0ra CC9iE0dtrcc=
On 12/10/2019 14:34, Brian Candler wrote:
ERROR: must be owner of function run_can_proceed CONTEXT: SQL statement "DROP FUNCTION run_can_proceed(int8)  │
 │ CASCADE;" PL/pgSQL function drop_function_all(text) line 34 at EXECUTE SQL statement "SELECT                                  │
 │ drop_function_all('run_can_proceed')" PL/pgSQL function inline_code_block line 1 at PERFORM   

Ah... this was probably because I had a locally-changed version of the run_can_proceed() function, and the upgrade decided to put it back how it was.

The fix is here: https://github.com/perfsonar/pscheduler/pull/907

and the discussion of why I found it necessary is here:

https://lists.internet2.edu/sympa/arc/perfsonar-user/2019-09/msg00009.html

But anyway: it looks likely that when I recreated the function, it ended up owned by a different user (i.e. the 'psql' user) and caused the above error.

Sorry for the noise!

Cheers,

Brian.


Archive powered by MHonArc 2.6.19.

Top of Page