| 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: | Whole Thread | Raw Message | 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 |