On Mon, Jan 28, 2019 at 04:06:11PM +0900, Michael Paquier wrote:
> If you really intend to drop any trace of the objects at PREPARE
> phase, that does not seem completely impossible to me, still you would
> also need handling for the case where the temp table created also
> creates the temporary
On Sat, Jan 19, 2019 at 10:39:43AM +0900, Michael Paquier wrote:
> I have not looked at the patch in details, but we should really be
> careful that if we do that the namespace does not remain behind when
> performing such transactions so as it cannot be dropped. On my very
> recent lookups of
On Fri, Jan 18, 2019 at 10:39:46AM -0500, Robert Haas wrote:
> Huh. Well, in that case, I'm not sure I understand we really need to
> do beyond removing the error checks for the case where all tables are
> on-commit-drop.
I have not looked at the patch in details, but we should really be
careful
On Fri, Jan 18, 2019 at 4:50 AM Vik Fearing wrote:
> Isn't that what happens already? PrepareTransaction() calls
> PreCommit_on_commit_actions() from what I can tell.
Huh. Well, in that case, I'm not sure I understand we really need to
do beyond removing the error checks for the case where all
On 16/01/2019 17:44, Robert Haas wrote:
> On Mon, Jan 14, 2019 at 1:41 PM Dimitri Fontaine
> wrote:
>> One idea would be that if every temp table in the session belongs to the
>> transaction, and their namespace too (we could check through pg_depend
>> that the namespace doesn't contain anything
On Mon, Jan 14, 2019 at 1:41 PM Dimitri Fontaine wrote:
> One idea would be that if every temp table in the session belongs to the
> transaction, and their namespace too (we could check through pg_depend
> that the namespace doesn't contain anything else beside the
> transaction's tables), then
On Mon, Jan 14, 2019 at 07:41:18PM +0100, Dimitri Fontaine wrote:
> Thanks for the review here Tom, and for linking with the other
> discussion (Álvaro did that too, thanks!). I've been reviewing it
> too.
If you can look at the patch, reviews are welcome. There are quite a
couple of patterns I
Hi,
Tom Lane writes:
> I'm afraid that this patch is likely to be, if not completely broken,
> at least very much less useful than one could wish by the time we get
> done closing the holes discussed in this other thread:
>
>
Michael Paquier writes:
> Being able to relax a bit the case is better than nothing, so that's
> nice to see incremental improvements. Thanks Dimitri.
I'm afraid that this patch is likely to be, if not completely broken,
at least very much less useful than one could wish by the time we get
done
Alvaro Herrera writes:
> Glad to see you submitting patches again.
Thanks!
> I suggest to add in your regression tests a case where the prepared
> transaction commits, and ensuring that the temp table is gone from
> catalogs.
Please find such a revision attached.
Regards,
--
dim
commit
Hi Dimitri
On 2018-Dec-28, Dimitri Fontaine wrote:
> Please find attached a patch to enable support for temporary tables in
> prepared transactions when ON COMMIT DROP has been specified.
Glad to see you submitting patches again.
I suggest to add in your regression tests a case where the
On 28/12/2018 12:46, Dimitri Fontaine wrote:
> Hi,
>
> Please find attached a patch to enable support for temporary tables in
> prepared transactions when ON COMMIT DROP has been specified.
The comments I made on IRC have been addressed in this version of the
patch, so it looks good to me.
--
Hi,
Please find attached a patch to enable support for temporary tables in
prepared transactions when ON COMMIT DROP has been specified.
The comment in the existing code around this idea reads:
* Don't allow PREPARE TRANSACTION if we've accessed a temporary table
in
* this
13 matches
Mail list logo
