From: | Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: fun fact about temp tables |
Date: | 2016-08-05 15:59:27 |
Message-ID: | e7b1b367-262b-662d-683e-cb3bc24b4fe5@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I can get error anyway on first select because of hint bit write. no?
On 08/05/2016 06:54 PM, Tom Lane wrote:
> Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)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
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2016-08-05 16:18:14 | Re: fun fact about temp tables |
Previous Message | Tom Lane | 2016-08-05 15:54:22 | Re: fun fact about temp tables |