Re: In-placre persistance change of a relation

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: In-placre persistance change of a relation
Дата
Msg-id 20211221.171321.738129483211049046.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на RE: In-placre persistance change of a relation  (Jakub Wartak <Jakub.Wartak@tomtom.com>)
Список 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.Wartak@tomtom.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
thesequence 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
mishapis 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: do only critical work during single-user vacuum?
Следующее
От: "wangw.fnst@fujitsu.com"
Дата:
Сообщение: RE: Failed transaction statistics to measure the logical replication progress