Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
От | Tom Lane |
---|---|
Тема | Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables |
Дата | |
Msg-id | 21075.1204661075@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Ответы |
Re: "could not open relation 1663/16384/16584: No
such file or directory" in a specific combination of transactions
with temp tables
|
Список | pgsql-hackers |
"Heikki Linnakangas" <heikki@enterprisedb.com> writes: > John Smith wrote: >> [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. > Well, the current behavior is certainly broken, so an application > relying on it is in trouble anyway :-(. Even if we came up with a patch > for 8.4 to relax the limitation, I doubt it would be safe enough to > backport to stable branches. As Heikki pointed out later, PG 8.1 correctly enforces the restriction against preparing a transaction that has dropped a temp table. It's only 8.2.x and 8.3.0 that (appear to) allow this. So I'm not persuaded by backwards-compatibility arguments. I've applied Heikki's new patch, and I think that's as much as we can do for 8.2 and 8.3. Any improvement in the functionality would be new development (and not trivial development, either) for 8.4 or later. regards, tom lane
В списке pgsql-hackers по дате отправления: