Search Postgresql Archives

multiple SAVEPOINTs without RELEASE SAVEPOINT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Is there any penalty for repeatedly doing 
    SAVEPOINT eugene
without a corresponding 
   RELEASE SAVEPOINT
?

In my case, I have a table with a unique index constraint.  Multiple
processes will be trying to "create or lookup" a record, so trapping the
unique index constraint seems the most robust way to detect if the record
already exists.  The overall structure I'm using (in pseudo-Ruby syntax):

  begin
    response = execute("SAVEPOINT eugene;
                                 INSERT INTO symbols (name) VALUES
('#{name}') RETURNING id")
  rescue
    # arrive here on a constraint violation if the name already existed
    response = execute("ROLLBACK TO SAVEPOINT eugene;
                                 SELECT id FROM symbols WHERE symbols.name =
'#{name}'")
  ensure
    # is this RELEASE strictly required?
    execute("RELEASE SAVEPOINT eugene")
  end

(On a related note, would I be better off using advisory locks?  And would
that be sufficient in the face of multiple processes?)


--
View this message in context: http://postgresql.1045698.n5.nabble.com/multiple-SAVEPOINTs-without-RELEASE-SAVEPOINT-tp5716594.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux