- Архив списков рассылки pgsql-hackers

<div class="WordSection1"><p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">On <span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">10 April 2014 11:18</span><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">,Pavan Deolasee Wrote:</span> <p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">>>Icould think of few  global variables like
transactionproperties related(i.e. read-only mode, isolation level etc). As I plan to keep transaction properties of
autonomoustransaction same as main transaction, so there is no need to have these global variables separately. <p
class="MsoNormal"style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">>>Apart from this there are global
variableslike with-in transaction counters, GUC, xactStartTimeStamp. I think there is no need to maintain these
variablesalso separately. They can continue from previous value for autonomous transaction also similar to as
sub->>transactiondoes. <p class="MsoNormal"> <p class="MsoNormal">>Hmm. Is that in line with what other
databasesdo ? I would have preferred AT to run like a standalone transaction without any influence of the starting
transaction,managing its own resources/locks/visibility/triggers etc.<p class="MsoNormal"> <p class="MsoNormal">To me
itseems it is not very useful to keep the transaction properties separate except the read-only properties (though
oracledoes not share any transaction properties).<p class="MsoNormal"> <p class="MsoNormal">So we can have restriction
thatisolation and deferrable properties of main transaction will be inherited by autonomous transaction but read-only
propertiescan be defined independently by autonomous transaction. Which looks to be fair restriction according to me.<p
class="MsoNormal"> <pclass="MsoNormal">In order to keep read-only properties separate, there is already infrastructure
inPG. Inside the structure TransactionStateData, there is variable prevXactReadOnly (entry-time xact r/o state), which
cankeep the parent transaction read only properties and XactReadOnly can be changed to current transaction
properties.<pclass="MsoNormal">                                Moreover we can take this (transaction properties) as a
featureenhancement also once a basic infrastructure is established, if acceptable to everyone.<p class="MsoNormal"> <p
class="MsoNormal">Autonomoustransaction will not share resource/lock/visibility etc with main transaction. This has
beenalready taken care in WIP patch.<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">>>In-caseof autonomous transaction, only specific
globalvariables initialized are related to resources (similar to sub-transaction), which anyway  gets stored in current
transactionstate.<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">>>Please let me
knowif I am missing something or if you have some specific global variables related issue.<p class="MsoNormal">>No,
Idon't have any specific issues in mind. Mostly all such global state is managed through various AtStart/AtEOX and
relatedroutines. So a careful examination of all those routines will give a good idea what needs to be handled. You
probablywill require to write <p class="MsoNormal">>AtATStart/AtATEOX and similar routines to manage the state at AT
start/commit/rollback.Sorry, I haven't looked at your WIP patch yet.<p class="MsoNormal"> <p class="MsoNormal">For some
ofthe resources, I have already written AtATStart/AtATEOX kind of routines in WIP patch.<p class="MsoNormal"> <p
class="MsoNormal">Comments/feedbacks/doubtsare welcome.  <p class="MsoNormal"> <p class="MsoNormal"><i><span
style="color:black">Thanksand Regards,</span></i><p class="MsoNormal"><i>Kumar Rajeev Rastogi<span style="color:black">
</span></i><pclass="MsoNormal"> </div>