Skip site navigation (1) Skip section navigation (2)

Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables

From: "John Smith" <sodgodofall(at)gmail(dot)com>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
Date: 2008-03-03 23:07:34
Message-ID: b88f0d670803031507i4a333f8bk6782f0518ae0fd30@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Mar 3, 2008 at 8:46 AM, Heikki Linnakangas
<heikki(at)enterprisedb(dot)com> wrote:
> Tom Lane wrote:
>  > Do you want to write up a flag-based patch, or shall I?
>
>  I can do that.

BTW, I found a easier way of reproducing this (see attached 2pc.sql).
It might help with debugging or verifying a fix/regression.

Thanks for the attention so far, but I have some questions about the issue:

[1] The data file is reported missing in the second transaction only
if the first transaction was ended using PREPARE TRANSACTION. The
error does not show up if a direct COMMIT is performed (commit.sql)
instead of PREPARE TRANSACTION + COMMIT PREPARED. Why is that so?

[2] From all of the discussion here since my first post, I understand
that there are complications for session-level TEMP tables. But is it
easier to support PREPARE TRANSACTION for transactions that create and
drop their TEMP tables, i.e., so that the tables are not session-level
but just transaction-level?

[3] I am not certain how widespread they might be, but I think there
may be some backward compatibility concerns with the patch you are
proposing. On the one hand, the documentation says, "It is not
currently allowed to PREPARE a transaction that has executed any
operations involving temporary tables or created any cursors WITH
HOLD." But temporary tables that are created ON COMMIT DROP are more
like cursors that do not have WITH HOLD specified. So it does not seem
clear from the documentation that PREPARE TRANSACTION is not
supported, and indeed due to the lack of a check in Postgres today, it
seems as though it is supported. Do you think there is a risk in
breaking applications?

Thanks.
- John

Attachment: commit.sql
Description: application/octet-stream (1.8 KB)
Attachment: 2pc.sql
Description: application/octet-stream (1.8 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Hiroshi SaitoDate: 2008-03-04 00:04:59
Subject: Re: pgsql: Don't build the win32 support files in the all target, only in
Previous:From: Andrew DunstanDate: 2008-03-03 22:55:52
Subject: Re: A couple of PG schedule reminders

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group