Re: In-placre persistance change of a relation

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: Jakub(dot)Wartak(at)tomtom(dot)com
Cc: tsunakawa(dot)takay(at)fujitsu(dot)com, osumi(dot)takamichi(at)fujitsu(dot)com, sfrost(at)snowman(dot)net, masao(dot)fujii(at)oss(dot)nttdata(dot)com, ashutosh(dot)bapat(dot)oss(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: In-placre persistance change of a relation
Date: 2021-12-21 08:13:21
Message-ID: 20211221.171321.738129483211049046.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ugh! I completely forgot about TAP tests.. Thanks for the testing and
sorry for the bugs.

This is a bit big change so I need a bit of time before posting the
next version.

At Mon, 20 Dec 2021 13:38:35 +0000, Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com> wrote in
> 1) check-worlds seems OK but make -C src/test/recovery check shows a couple of failing tests here locally and in https://cirrus-ci.com/task/4699985735319552?logs=test#L807 :
> t/009_twophase.pl (Wstat: 256 Tests: 24 Failed: 1)
> Failed test: 21
> Non-zero exit status: 1

PREPARE TRANSACTION requires uncommited file creation to be
committed. Concretely we need to remove the "mark" files for the
in-transaction created relation file during PREPARE TRANSACTION.

pendingSync is not a parallel mechanism with pendingDeletes so we
cannot move mark deletion to pendingSync.

After all I decided to add a separate list pendingCleanups for pending
non-deletion tasks separately from pendingDeletes and execute it
before insering the commit record. Not only the above but also all of
the following failures vanished by the change.

> t/014_unlogged_reinit.pl (Wstat: 512 Tests: 12 Failed: 2)
> Failed tests: 9-10
> Non-zero exit status: 2
> t/018_wal_optimize.pl (Wstat: 7424 Tests: 0 Failed: 0)
> Non-zero exit status: 29
> Parse errors: Bad plan. You planned 38 tests but ran 0.
> t/022_crash_temp_files.pl (Wstat: 7424 Tests: 6 Failed: 0)
> Non-zero exit status: 29
> Parse errors: Bad plan. You planned 9 tests but ran 6.

> 018 made no sense, I've tried to take a quick look with wal_level=minimal why it is failing , it is mystery to me as the sequence seems to be pretty basic but the outcome is not:

I think this shares the same cause.

> ~> cat repro.sql
> create tablespace tbs1 location '/tbs1';
> CREATE TABLE moved (id int);
> INSERT INTO moved VALUES (1);
> BEGIN;
> ALTER TABLE moved SET TABLESPACE tbs1;
> CREATE TABLE originated (id int);
> INSERT INTO originated VALUES (1);
> CREATE UNIQUE INDEX ON originated(id) TABLESPACE tbs1;
> COMMIT;
..
> ERROR: could not open file "base/32833/32839": No such file or directory

> z3=# \dt+
> List of relations
> Schema | Name | Type | Owner | Persistence | Size | Description
> --------+------------+-------+----------+-------------+---------+-------------
> public | moved | table | postgres | permanent | 0 bytes |
> public | originated | table | postgres | permanent | 0 bytes |
>
> This happens even without placing on tablespace at all {for originated table , but no for moved on}, some major mishap is there (commit should guarantee correctness) or I'm tired and having sloppy fingers.
>
> 2) minor one testcase, still something is odd.
>
> drop tablespace tbs1;
> create tablespace tbs1 location '/tbs1';
> CREATE UNLOGGED TABLE t4 (a int) tablespace tbs1;
> CREATE UNLOGGED TABLE t5 (a int) tablespace tbs1;
> CREATE UNLOGGED TABLE t6 (a int) tablespace tbs1;
> CREATE TABLE t7 (a int) tablespace tbs1;
> insert into t7 values (1);
> insert into t5 values (1);
> insert into t6 values (1);
> \dt+
> List of relations
> Schema | Name | Type | Owner | Persistence | Size | Description
> --------+------+-------+----------+-------------+------------+-------------
> public | t4 | table | postgres | unlogged | 0 bytes |
> public | t5 | table | postgres | unlogged | 8192 bytes |
> public | t6 | table | postgres | unlogged | 8192 bytes |
> public | t7 | table | postgres | permanent | 8192 bytes |
> (4 rows)
>
> ALTER TABLE ALL IN TABLESPACE tbs1 set logged;
> ==> STILL WARNING: unrecognized node type: 349
> \dt+
> List of relations
> Schema | Name | Type | Owner | Persistence | Size | Description
> --------+------+-------+----------+-------------+------------+-------------
> public | t4 | table | postgres | permanent | 0 bytes |
> public | t5 | table | postgres | permanent | 8192 bytes |
> public | t6 | table | postgres | permanent | 8192 bytes |
> public | t7 | table | postgres | permanent | 8192 bytes |
>
> So it did rewrite however this warning seems to be unfixed. I've tested on e2c52beecdea152ca680a22ef35c6a7da55aa30f.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2021-12-21 08:56:06 Re: simplifying foreign key/RI checks
Previous Message Masahiko Sawada 2021-12-21 07:56:07 Re: do only critical work during single-user vacuum?