SEO

Hackers,

I'm seeing the following weirdness with the 2PC patch:

alvherre=# begin;
BEGIN
alvherre=# create table a (a int);
CREATE TABLE
alvherre=# insert into a values (1);
INSERT 0 1
alvherre=# prepare transaction 'foo';
PREPARE TRANSACTION
alvherre=# select * from a;


At this point, the backend freezes. However, if I connect in another
session and issue the same "select * from a" query, it correctly returns
"no such relation". Now, because the backend cannot see the table
(because it was created by a transaction that is not yet committed), the
first backend shouldn't freeze but return the same "no such relation".

My guess is that the backend that created the prepared transaction has
its relcache populated with the new table's entry. But given that we
prepared the transaction, we should forget about the table, and only
remember it when we receive the shared inval message that will get sent
when the prepared transaction is committed.


I'm wondering what should happen at prepare time so that "my own cache"
is correct. Do I need to send the inval messages to me? Is this even
possible? Maybe I need to read the messages from the prepare file and
send it to me. Any ideas?

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
Licensee shall have no right to use the Licensed Software
for productive or commercial use. (Licencia de StarOffice 6.0 beta)

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Alvaro Herrera <alvherre@surnet.cl> writes:
> I'm wondering what should happen at prepare time so that "my own cache"
> is correct.

Good point. As far as the local caches are concerned, we probably have
to make it look like the transaction rolled back. I think Heikki
already had code in there to send the right inval messages when the
prepared transaction ultimately commits ... but we'll have to check that
that sequence does the right things ...

> Do I need to send the inval messages to me? Is this even
> possible?

inval.c is less than readable, isn't it :-( But yes, and yes.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Thu, 26 May 2005, Tom Lane wrote:

> Alvaro Herrera <alvherre@surnet.cl> writes:
>> I'm wondering what should happen at prepare time so that "my own cache"
>> is correct.
>
> Good point. As far as the local caches are concerned, we probably have
> to make it look like the transaction rolled back. I think Heikki
> already had code in there to send the right inval messages when the
> prepared transaction ultimately commits ... but we'll have to check that
> that sequence does the right things ...

Looking at the sequence, at least the relcache init file stuff looks if
not broken at least a bit heavy-handed...

BTW: Is there a race condition in the relcache init file invalidation,
even without 2PC?

AtEOXact_Inval does basically this:

1. Unlink init file
2. Send inval messages
3. Unlink the init file again

Now consider this scenario:

backend A: Do updates that cause an init file invalidation
backend A: Commit begins
backend A: unlink init file
backend B starts and recreates init file
backend A: send inval message
backend C starts and reads the now stale init file

The window is admittedly very small, but it just caught my eye. Or am I
missing some lock etc?

- Heikki

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> Looking at the sequence, at least the relcache init file stuff looks if
> not broken at least a bit heavy-handed...

I was planning to change that ;-) ... using separate 2PC action records
for the relcache init file actions would make it much better.

> Now consider this scenario:

> backend A: Do updates that cause an init file invalidation
> backend A: Commit begins
> backend A: unlink init file
> backend B starts and recreates init file
> backend A: send inval message
> backend C starts and reads the now stale init file

No problem, because C will receive A's inval messages after that.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Fri, May 27, 2005 at 11:12:06AM -0400, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
> > Looking at the sequence, at least the relcache init file stuff looks if
> > not broken at least a bit heavy-handed...
>
> I was planning to change that ;-) ... using separate 2PC action records
> for the relcache init file actions would make it much better.

Hum, do you mean separate for 2PC only, or make'em completely separate
invalidation messages?

I fixed the problem I had -- it was very easy to make the messages get
processed locally. However strangeness can still happen. Consider:

create table foo ();

begin;
drop table foo;
prepare transaction 'foo';


Now any backend that tries to access table foo will block, because the
'foo' prepared transaction has acquired a lock on it. However the table
is still visible in the catalogs, as it should be. It can easily be
awakened by other backend doing

commit transaction 'foo';

But at awakening, the user will get this:

ERROR: relation 66002 deleted while still in use

This is ugly -- I don't think there is a way to get out of it.


Unrelated question: is it intended that the prepared transactions are
visible cross-database through pg_prepared_xacts?

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"No single strategy is always right (Unless the boss says so)"
(Larry Wall)

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Alvaro Herrera <alvherre@surnet.cl> writes:
> But at awakening, the user will get this:
> ERROR: relation 66002 deleted while still in use
> This is ugly -- I don't think there is a way to get out of it.

There had better be a way, since (I suppose) the ERROR is preventing the
commit from succeeding ...

> Unrelated question: is it intended that the prepared transactions are
> visible cross-database through pg_prepared_xacts?

That is a good question. Can a backend running in a different database
execute the COMMIT (or ROLLBACK)? Offhand I'd bet that will not work,
which suggests we'd better make the view per-database. [ thinks a bit
more... ] We might be able to make it work, but there seems like a lot
of potential for bugs/fragility there. Might be best to take the narrow
definition to start with.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Tue, May 31, 2005 at 02:09:56AM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@surnet.cl> writes:
> > But at awakening, the user will get this:
> > ERROR: relation 66002 deleted while still in use
> > This is ugly -- I don't think there is a way to get out of it.
>
> There had better be a way, since (I suppose) the ERROR is preventing the
> commit from succeeding ...

No, the ERROR is in a completely unrelated transaction. The scenario
again is this:

CREATE TABLE foo ();

BEGIN;
DROP TABLE foo;
PREPARE TRANSACTION 'foo';


SELECT * FROM foo;
-- hangs
COMMIT TRANSACTION 'foo';
ERROR, relation deleted while still in
use

So it's a rather contorted situation to begin with.

> > Unrelated question: is it intended that the prepared transactions are
> > visible cross-database through pg_prepared_xacts?
>
> That is a good question. Can a backend running in a different database
> execute the COMMIT (or ROLLBACK)? Offhand I'd bet that will not work,
> which suggests we'd better make the view per-database. [ thinks a bit
> more... ] We might be able to make it work, but there seems like a lot
> of potential for bugs/fragility there. Might be best to take the narrow
> definition to start with.

Ok.

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"El sentido de las cosas no viene de las cosas, sino de
las inteligencias que las aplican a sus problemas diarios
en busca del progreso." (Ernesto Hernández-Novich)

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Alvaro Herrera <alvherre@surnet.cl> writes:
> No, the ERROR is in a completely unrelated transaction. The scenario
> again is this:

> CREATE TABLE foo ();

> BEGIN;
> DROP TABLE foo;
> PREPARE TRANSACTION 'foo';


> SELECT * FROM foo;
> -- hangs
> COMMIT TRANSACTION 'foo';
> ERROR, relation deleted while still in
> use

Oh. Well, you get that now without any use of PREPARE; it's not clear
what else we could do, except possibly make the message a bit more
user-friendly.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

On Tue, May 31, 2005 at 10:44:58AM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@surnet.cl> writes:
> > No, the ERROR is in a completely unrelated transaction. The scenario
> > again is this:
>
> > CREATE TABLE foo ();
>
> > BEGIN;
> > DROP TABLE foo;
> > PREPARE TRANSACTION 'foo';
>
>
> > SELECT * FROM foo;
> > -- hangs
> > COMMIT TRANSACTION 'foo';
> > ERROR, relation deleted while still in
> > use
>
> Oh. Well, you get that now without any use of PREPARE; it's not clear
> what else we could do, except possibly make the message a bit more
> user-friendly.

Ah, you are right, sorry :-) I was imagining I had to cope with that
but evidently not.

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"Granting software the freedom to evolve guarantees only different results,
not better ones." (Zygo Blaxell)

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org