The first part in the doc about concurrency with Read Commited
transactions (12.2.1 in devel doc) it says:
| Read Committed is the default isolation level in PostgreSQL.
| When a transaction runs on this isolation level, a SELECT query
| sees only data committed before the query began; it never s
=?ISO-8859-1?Q?Dennis_Bj=F6rklund?= <[EMAIL PROTECTED]> writes:
> The first part in the doc about concurrency with Read Commited
> transactions (12.2.1 in devel doc) it says:
> | Read Committed is the default isolation level in PostgreSQL.
> | When a transaction runs on this isolation level, a SEL
On Mon, 25 Aug 2003, Tom Lane wrote:
> No, it doesn't. The critical phrase here is "data committed before the
> *query* began" ... not "data committed before the *transaction* began".
Aah, of course, it says query. Thanks (again).
--
/Dennis
---(end of broadcast)-
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme:
"If we are setting a table level lock
both the blockId and tupleId (in an item pointer this is called
the position) are set to invalid, if it is a page level lock the
blockId is valid, while the tupleId is still invalid. Fi
I replied to Josh thus:
---
You need to be careful using Alan's patch. The reason RH stopped using
this part of it in their errata kernels is that it had conflicts with
other stuff, specifically the rmap stuff (he told me that himself in
email).
I am very wary of advising