Re: BUG #15990: PROCEDURE throws "SQL Error [XX000]: ERROR: no known snapshots" with PostGIS geometries
От | Tom Lane |
---|---|
Тема | Re: BUG #15990: PROCEDURE throws "SQL Error [XX000]: ERROR: no known snapshots" with PostGIS geometries |
Дата | |
Msg-id | 912290.1620774094@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15990: PROCEDURE throws "SQL Error [XX000]: ERROR: noknown snapshots" with PostGIS geometries (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: BUG #15990: PROCEDURE throws "SQL Error [XX000]: ERROR: no known snapshots" with PostGIS geometries
|
Список | pgsql-bugs |
Andres Freund <andres@anarazel.de> writes: > This looks like it might be a procedure related bug to me. Peter? Somebody reported this same bug again today [1] ... why has it still not been dealt with? After an admittedly cursory look-around, it seems like the problem can be stated as "init_toast_snapshot expects that there already is a transaction snapshot, which there is not because we just committed and nothing has re-established a transaction snapshot". So the question is, where shall we force a new transaction snapshot to be created after a COMMIT/ROLLBACK inside a procedure? The most localized fix would be to let init_toast_snapshot itself do that, but that seems like a bit of a layering violation; plus I'm not quite convinced that's the only place with the issue. (However, it *is* the only caller of GetOldestSnapshot() AFAICS. So maybe everyplace else is calling GetTransactionSnapshot() to begin with, in which case this could do likewise I should think.) It really seems to me like _SPI_commit() should have started a new transaction --- why is it okay to delay that? BTW, why is this not caught by the plpgsql-toast.spec isolation test? Seems like that's doing almost exactly the same thing as the trouble reports. regards, tom lane [1] https://www.postgresql.org/message-id/dae29212-ad31-8701-ef16-dd7420bfaa56%40perfexpert.ch
В списке pgsql-bugs по дате отправления: