pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Euler Taveira <euler@eulerto.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Thomas Munro <thomas.munro@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Euler Taveira <euler.taveira@2ndquadrant.com>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: cleanup temporary files after crash
Date: Thu, 18 Mar 2021 17:06:23 -0300
Message-ID: <54663718-1d87-46f2-a27b-e7edacbfae0d@www.fastmail.com> (raw)
In-Reply-To: <a32a7f28-570c-24a2-aa2a-9f7c96abd88b@enterprisedb.com>
References: <CAH503wDKdYzyq7U-QJqGn=Gm6XmoK+6_6xTJ-Yn5WSvoHLY1Ww@mail.gmail.com>
	<20201028184252.5vpoe65kcfebbmmf@development>
	<CAH503wCg+yne7hKAAFFHsVPe+tPb-aF5VGaWG0ETqyB3GP=Q+g@mail.gmail.com>
	<20201101012555.GC3000@paquier.xyz>
	<1982ee3c-54c3-280a-806a-fd28ad8f19e6@postgrespro.ru>
	<CAH503wBLgLGhqCduqzOBgCYNS5DiJnUJdU+RVCCQoka8Tndndg@mail.gmail.com>
	<363cb85c-3a03-9a49-b830-8b645c1241d9@enterprisedb.com>
	<YEdqlL3Gr3rZ/aC8@paquier.xyz>
	<CA+hUKGJtZqpMZtYtJZ2cAGfQT5ELEZGKpnK_TjV-fNeB=rYSNw@mail.gmail.com>
	<4245d284-97b2-4056-96c2-455792d9b564@www.fastmail.com>
	<8740f056-a7c0-ff12-0a50-de5324a928ee@enterprisedb.com>
	<822e3a60-56a1-219d-c473-365751c3e108@enterprisedb.com>
	<a32a7f28-570c-24a2-aa2a-9f7c96abd88b@enterprisedb.com>

On Thu, Mar 18, 2021, at 4:20 PM, Tomas Vondra wrote:
> I think a better way to test this would be to use a tuple lock:
I predicated such issues with this test. Your suggestion works for me. Maybe
you should use less rows in the session 2 query.

> setup:
> 
>   create table t (a int unique);
> 
> session 1:
> 
>   begin;
>   insert into t values (1);
>   ... keep open ...
> 
> session 2:
> 
>    begin;
>    set work_mem = '64kB';
>    insert into t select i from generate_series(1,10000) s(i);
>    ... should block ...
> 
> Then, once the second session gets waiting on the tuple, kill the
> backend. We might as well test that there actually is a temp file first,
> and then test that it disappeared.
Your suggestion works for me. Maybe you could use less rows in the session 2
query. I experimented with 1k rows and it generates a temporary file.


--
Euler Taveira
EDB   https://www.enterprisedb.com/

view thread (35+ messages)  latest in thread

Message-ID: <54663718-1d87-46f2-a27b-e7edacbfae0d@www.fastmail.com>
Permalink:  ../54663718-1d87-46f2-a27b-e7edacbfae0d@www.fastmail.com/
Also on:    postgresql.org/message-id/54663718-1d87-46f2-a27b-e7edacbfae0d@www.fastmail.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: euler@eulerto.com, tomas.vondra@enterprisedb.com, thomas.munro@gmail.com, michael@paquier.xyz, euler.taveira@2ndquadrant.com, a.lubennikova@postgrespro.ru, tomas.vondra@2ndquadrant.com, pgsql-hackers@lists.postgresql.org, tgl@sss.pgh.pa.us
  Subject: Re: cleanup temporary files after crash
  In-Reply-To: <54663718-1d87-46f2-a27b-e7edacbfae0d@www.fastmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox