Re: fun fact about temp tables
От | Alex Ignatov |
---|---|
Тема | Re: fun fact about temp tables |
Дата | |
Msg-id | 8a9e33db-b37a-fb38-612d-59663de10b5e@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: fun fact about temp tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On 05.08.2016 18:54, Tom Lane wrote: > Alex Ignatov <a.ignatov@postgrespro.ru> writes: >> On 05.08.2016 17:51, Tom Lane wrote: >>> Sure. Just like it reserves space for ordinary tables right away, >>> long before there's any need to push the data out of shared_buffers. >>> Otherwise, you might find yourself having to throw an "out of disk >>> space" error after having already committed the relevant INSERTs. >> How about out of space when we filling WAL files? > What about it? That will be reported before committing, too. > > What Grigory wants would imply committing and then sometime later > saying "oh, wait ... remember that data we told you we'd committed? > We lied." > > Temp tables do indeed disappear at session end (and a fortiori after > a crash), but that doesn't create an excuse for them not to have > normal transactional behavior within the session. > > regards, tom lane If temp table fits in temp_buffer why do we have to reserve disk space for that table? If we commit after filling temp table ok=> Not enough temp_buffers for the new one temp table write the first one to disk=> Not enough space for temp file ok - our system in any way cant work further. Cant see any problems in writing temp table data to disk only when temp_buffer is full. Any arguments against that behavior? Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-general по дате отправления: