"Kevin Grittner" <kevin.gritt...@wicourts.gov> wrote: > so as you haven't read other > data, you would be safe in the particular case you cite. Sorry, that's not true. If you run your bulk data load at serializable isolation level, you could still get rolled back in this scenario, even if you're just writing: (1) A concurrent serializable transaction reads data from a table into which your bulk load will subsequently insert, without there yet being a conflict between that read and your bulk inserts. It also modifies data somewhere. It commits. (2) A serializable transaction concurrent with that mentioned in (1) reads data which conflicts with the modification of (1). It may also commit. (3) Your bulk data load eventually (after the commit of (1)) inserts data which conflicts with the read from (1). (1) is no longer available for rollback. Unless (2) is still active, and preferred for termination based on the bias chosen, your bulk load will be rolled back. That would suck. There are several protections available, like taking an explicit lock to protect the process, running at a less rigorous transaction isolation level, etc., but it could happen. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
