pg.ddx.io pgsql-sql@postgresql.org mailing list archivehelp / color / mirror / Atom feed
READ COMMITTE without START TRANSACTION? 2+ messages / 2 participants [nested] [flat]
* READ COMMITTE without START TRANSACTION? @ 2006-03-11 01:08 ogjunk-pgjedan@yahoo.com 2006-03-11 03:44 ` Re: READ COMMITTE without START TRANSACTION? Jaime Casanova <systemguards@gmail.com> 0 siblings, 1 reply; 2+ messages in thread From: ogjunk-pgjedan@yahoo.com @ 2006-03-11 01:08 UTC (permalink / raw) To: pgsql-sql Hello, I need to run some SELECT queries that take a while (10+ minutes) to complete, and I'm wondering about the isolation about the results I get. More precisely, while my SELECT is running, the DB is being updated by another application, and I am wondering which, if any, data changes my SELECT will see. Example: If I start my SELECT at 10:00, and it finishes at 10:10, will my results include data that was inserted between 10:00 and 10:10? Similarly, will my result include data that was updated between 10:00 and 10:10? The same question for data that was deleted during that period. If it matters, my SELECT runs from psql client, while concurrent inserts, updates, and deletes are executed from a separate application (webapp). For my purposes in this case I need the SELECT to get the results that represent data right at the beginning of the query - a snapshot. I read this: http://www.postgresql.org/docs/8.1/static/transaction-iso.html and it looks like this is the default PG behaviour (READ COMMITTED) Question: If I do not explicitly START TRANSACTION before the SELECT, will this READ COMMITTED XA behaviour still be in effect? Thanks, Otis ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: READ COMMITTE without START TRANSACTION? 2006-03-11 01:08 READ COMMITTE without START TRANSACTION? ogjunk-pgjedan@yahoo.com @ 2006-03-11 03:44 ` Jaime Casanova <systemguards@gmail.com> 0 siblings, 0 replies; 2+ messages in thread From: Jaime Casanova @ 2006-03-11 03:44 UTC (permalink / raw) To: ogjunk-pgjedan@yahoo.com <ogjunk-pgjedan@yahoo.com>; +Cc: pgsql-sql On 3/10/06, ogjunk-pgjedan@yahoo.com <ogjunk-pgjedan@yahoo.com> wrote: > Hello, > > I need to run some SELECT queries that take a while (10+ minutes) to complete, and I'm wondering about the isolation about the results I get. More precisely, while my SELECT is running, the DB is being updated by another application, and I am wondering which, if any, data changes my SELECT will see. > > Example: > If I start my SELECT at 10:00, and it finishes at 10:10, will my results include data that was inserted between 10:00 and 10:10? > Similarly, will my result include data that was updated between 10:00 and 10:10? > The same question for data that was deleted during that period. > no > If it matters, my SELECT runs from psql client, while concurrent inserts, updates, and deletes are executed from a separate application (webapp). > doesn't really matters > For my purposes in this case I need the SELECT to get the results that represent data right at the beginning of the query - a snapshot. I read this: http://www.postgresql.org/docs/8.1/static/transaction-iso.html and it looks like this is the default PG behaviour (READ COMMITTED) > yes, it is > Question: > If I do not explicitly START TRANSACTION before the SELECT, will this READ COMMITTED XA behaviour still be in effect? > yes. all statements not executed inside a transaction block are in an implicit transaction > Thanks, > Otis > > -- regards, Jaime Casanova "What they (MySQL) lose in usability, they gain back in benchmarks, and that's all that matters: getting the wrong answer really fast." Randal L. Schwartz ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2006-03-11 03:44 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2006-03-11 01:08 READ COMMITTE without START TRANSACTION? ogjunk-pgjedan@yahoo.com 2006-03-11 03:44 ` Jaime Casanova <systemguards@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox