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
