How to isolate the result of SELECT's?

On Sun, Mar 18, 2012 at 6:33 PM, Andre Lopes <lopes80andre@gmail.com> wrote:

Hi,

I need to do an operation that I will use some SELECT's and get the
results, but I want to have sure that those tables have not been
changed with INSERT's or UPDATES during the operation.

Example:

BEGIN OPERATION
Select field from table1;
...
Select other_field from table2;
...
END OPERATION

How can I lock these tables to assure that the tables are not getting
INSERTS's or UPDATE's during the operation?

Best Regards,\

Isn't that what 'begin transaction' and 'commit' are for?
--
Mike Nolan

On 03/18/2012 04:33 PM, Andre Lopes wrote:

Hi,

I need to do an operation that I will use some SELECT's and get the
results, but I want to have sure that those tables have not been
changed with INSERT's or UPDATES during the operation.

Example:

BEGIN OPERATION
Select field from table1;
...
Select other_field from table2;
...
END OPERATION

How can I lock these tables to assure that the tables are not getting
INSERTS's or UPDATE's during the operation?

Rather than replicate the docs in a post, I suggest you take a look at:

http://www.postgresql.org/docs/9.1/interactive/mvcc.html

It explains the various options you have very well.

Best Regards,

--
Adrian Klaver
adrian.klaver@gmail.com

Hi,

I need to do an operation that I will use some SELECT's and get the
results, but I want to have sure that those tables have not been
changed with INSERT's or UPDATES during the operation.

Example:

BEGIN OPERATION
Select field from table1;
...
Select other_field from table2;
...
END OPERATION

How can I lock these tables to assure that the tables are not getting
INSERTS's or UPDATE's during the operation?

If you set transaction isolation level to repeatable, the tables may
undergo changes, but you will get repeatable reads. Explicitly locking the
tables is another option.
http://www.postgresql.org/docs/current/static/explicit-locking.html
Regards,
Jayadevan

DISCLAIMER:

"The information in this e-mail and any attachment is intended only for
the person to whom it is addressed and may contain confidential and/or
privileged material. If you have received this e-mail in error, kindly
contact the sender and destroy all copies of the original communication.
IBS makes no warranty, express or implied, nor guarantees the accuracy,
adequacy or completeness of the information contained in this email or any
attachment and is not liable for any errors, defects, omissions, viruses
or for resultant loss or damage, if any, direct or indirect."

In all likelihood you do not want to do what you described (lock the tables.) You have to have a basic understanding of MVCC and transaction isolation levels to determine if the default behavior of mvcc + 'read committed' is sufficient. In a lot of cases it is.

Kiriakos

On Mar 18, 2012, at 7:33 PM, Andre Lopes wrote: