On 05.08.2016 18:54, Tom Lane wrote:
Alex Ignatov <a.ignatov@xxxxxxxxxxxxxx> 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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
