Re: Transactions and temp tables

From: Emmanuel Cecchet <manu(at)frogthinker(dot)org>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transactions and temp tables
Date: 2008-10-07 20:57:37
Message-ID: 48EBCD41.7070409@frogthinker.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki,

Here is a new version of the patch using a hash table as you suggested.
I also include the tests that I have added to the regression test suite
to test the various scenarios.
All patches are based on Postgres 8.3.3, let me know if you want me to
generate patch for 8.4.

Thanks in advance for your feedback,
Emmanuel

Emmanuel Cecchet wrote:
> Hi Heikki,
>
>> The patch allows preparing any transaction that has dropped the temp
>> table, even if it wasn't created in the same transaction. Is that sane?
> If you have a temp table created with an 'on commit delete rows'
> option in another transaction, it would be fine to drop it in another
> transaction. If the temp table was created without any on commit
> option, it could only cross prepare commit if it is empty and then it
> could be safely dropped in another transaction. That does not seem to
> insane for me if you need temp tables for a session.
>> Also, even if the table is created and dropped in the same
>> transaction, a subsequent transaction that tries to create and drop
>> the table gets blocked on the lock. I suppose we could just say that
>> that's the way it works, but I'm afraid it will come as a nasty
>> surprise, making the feature a lot less useful.
> I do not get that one, if the table is dropped in the transaction the
> lock is released. Why would another transaction be blocked when trying
> to create/drop another temp table?
> When I run my test cases (see attached file in previous mail), I
> create/drop multiple times the same temp table in different
> transactions and I do not experience any blocking.
>> The fixed-size array of temp table oids is an unnecessary limitation.
>> A list or hash table would be better.
> You are right, I will fix that.
>>> Let me know what you think of the patch and if it could be applied
>>> to 8.3 and 8.4?
>> Not to 8.3. We only back-patch bug-fixes, and this isn't one.
> Ok understood.
>
> Thanks for your feedback and don't hesitate to enlighten me on the
> potential locking issue I did not understand.
> Emmanuel
>

--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: manu(at)frogthinker(dot)org
Skype: emmanuel_cecchet

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2008-10-07 21:08:25 Re: db_user_namespace, md5 and changing passwords
Previous Message Greg Smith 2008-10-07 20:45:52 Open Items/Release (was [HACKERS]: Shouldn't pg_settings.enumvals...)