8 Commits (cecde97577fafddc6b3aa354b9b77a3a54b063a9)

Author	SHA1	Message	Date
Bruce Momjian	0239800893	Update copyright for the year 2010.	16 years ago
Alvaro Herrera	07cefdfb7a	Fix snapshot management, take two. ... Partially revert the previous patch I installed and replace it with a more general fix: any time a snapshot is pushed as Active, we need to ensure that it will not be modified in the future. This means that if the same snapshot is used as CurrentSnapshot, it needs to be copied separately. This affects serializable transactions only, because CurrentSnapshot has already been copied by RegisterSnapshot and so PushActiveSnapshot does not think it needs another copy. However, CommandCounterIncrement would modify CurrentSnapshot, whereas ActiveSnapshots must not have their command counters incremented. I say "partially" because the regression test I added for the previous bug has been kept. (This restores 8.3 behavior, because before snapmgr.c existed, any snapshot set as Active was copied.) Per bug report from Stuart Bishop in 6bc73d4c0910042358k3d1adff3qa36f8df75198ecea@mail.gmail.com	16 years ago
Alvaro Herrera	caa4cfa369	Ensure that a cursor has an immutable snapshot throughout its lifespan. ... The old coding was using a regular snapshot, referenced elsewhere, that was subject to having its command counter updated. Fix by creating a private copy of the snapshot exclusively for the cursor. Backpatch to 8.4, which is when the bug was introduced during the snapshot management rewrite.	16 years ago
Bruce Momjian	d747140279	8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list ... provided by Andrew.	17 years ago
Bruce Momjian	511db38ace	Update copyright for 2009.	17 years ago
Alvaro Herrera	7b640b0345	Fix a couple of snapshot management bugs in the new ResourceOwner world: ... non-writable large objects need to have their snapshots registered on the transaction resowner, not the current portal's, because it must persist until the large object is closed (which the portal does not). Also, ensure that the serializable snapshot is recorded by the transaction resource owner too, even when a subtransaction has changed the current resource owner before serializable is taken. Per bug reports from Pavan Deolasee.	17 years ago
Alvaro Herrera	5da9da71c4	Improve snapshot manager by keeping explicit track of snapshots. ... There are two ways to track a snapshot: there's the "registered" list, which is used for arbitrary long-lived snapshots; and there's the "active stack", which is used for the snapshot that is considered "active" at any time. This also allows users of snapshots to stop worrying about snapshot memory allocation and freeing, and about using PG_TRY blocks around ActiveSnapshot assignment. This is all done automatically now. As a consequence, this allows us to reset MyProc->xmin when there are no more snapshots registered in the current backend, reducing the impact that long-running transactions have on VACUUM.	18 years ago
Alvaro Herrera	78f02ca1f5	Rename snapmgmt.c/h to snapmgr.c/h, for consistency with other files. ... Per complaint from Tom Lane.	18 years ago
Alvaro Herrera	d43b085d57	Separate snapshot management code from tuple visibility code, create a ... snapmgmt.c file for the former. The header files have also been reorganized in three parts: the most basic snapshot definitions are now in a new file snapshot.h, and the also new snapmgmt.h keeps the definitions for snapmgmt.c. tqual.h has been reduced to the bare minimum. This patch is just a first step towards managing live snapshots within a transaction; there is no functionality change. Per my proposal to pgsql-patches on 20080318191940.GB27458@alvh.no-ip.org and subsequent discussion.	18 years ago