在Postgres中，如果某个表的大小超过1G就会自动地被分成多个子文件，以XX.1,XX.2....命名。
如果我们删除了一个表的子文件，情况会怎样呢？
测试过程：
表pgbench_accounts对于的文件编号是29507，29507.1，Ok，现在将29507.1 move到上级目录上（相当于删除）
[root@localhost 29494]# ls
112 11492_fsm 14270 14369 2607_vm 2619 2674 2755 2936_vm 3601_vm
113 11492_vm 14272 14370 2608 2619_fsm 2675 2756 2937 3602
11467 11494 14274 174 2608_fsm 2619_vm 2678 2757 29495 3602_fsm
11467_fsm 11496 14275 175 2608_vm 2620 2679 2830 29495_fsm 3602_vm
11467_vm 11497 14277 2328 2609 2620_fsm 2680 2831 29495_vm 3603
11469 11499 14279 2328_fsm 2609_fsm 2620_vm 2681 2832 29498 3603_fsm
11471 11501 14281 2328_vm 2609_vm 2650 2682 2833 29498_fsm 3603_vm
11472 11760 14282 2600 2610 2651 2683 2834 29498_vm 3604
11472_fsm 11760_fsm 14284 2600_fsm 2610_fsm 2652 2684 2835 29507 3605
11472_vm 11760_vm 14286 2600_vm 2610_vm 2653 2685 2836 29507.1 3606
11474 11785 14288 2601 2611 2654 2686 2836_fsm 29507_fsm 3607
11476 11785_fsm 14289 2601_fsm 2612 2655 2687 2836_vm 29507_vm 3608
11477 11785_vm 14291 2601_vm 2612_fsm 2656 2688 2837 29508 3609
11477_fsm 1247 14293 2602 2612_vm 2657 2689 2838 29510 3712
11477_vm 1247_fsm 14295 2602_fsm 2613 2658 2690 2838_fsm 29512 3764
11479 1247_vm 14296 2602_vm 2614 2659 2691 2838_vm 29516 3764_fsm
11481 1249 14298 2603 2615 2660 2692 2839 29516_fsm 3764_vm
11482 1249_fsm 14300 2603_fsm 2615_fsm 2661 2693 2840 2966 3766
11482_fsm 1249_vm 14302 2603_vm 2615_vm 2662 2696 2840_fsm 3008 3767
11482_vm 1255 14304 2604 2616 2663 2699 2840_vm 3009 5000
11484 1255_fsm 14306 2605 2616_fsm 2664 2701 2841 3501 5001
11486 1255_vm 14308 2605_fsm 2616_vm 2665 2702 2893 3502 5002
11487 1259 14310 2605_vm 2617 2666 2703 2893_fsm 3503 548
11487_fsm 1259_fsm 14312 2606 2617_fsm 2667 2704 2893_vm 3600 549
11487_vm 1259_vm 14314 2606_fsm 2617_vm 2668 2753 2903 3600_fsm pg_internal.init
11489 1417 14316 2606_vm 2618 2669 2753_fsm 2904 3600_vm PG_VERSION
11491 1418 14364 2607 2618_fsm 2670 2753_vm 2936 3601
11492 14268 14367 2607_fsm 2618_vm 2673 2754 2936_fsm 3601_fsm
[root@localhost 29494]# mv 29507.1 ../
[root@localhost 29494]# ls
112 11492_fsm 14270 14369 2607_vm 2619 2674 2755 2936_vm 3602
113 11492_vm 14272 14370 2608 2619_fsm 2675 2756 2937 3602_fsm
11467 11494 14274 174 2608_fsm 2619_vm 2678 2757 29495 3602_vm
11467_fsm 11496 14275 175 2608_vm 2620 2679 2830 29495_fsm 3603
11467_vm 11497 14277 2328 2609 2620_fsm 2680 2831 29495_vm 3603_fsm
11469 11499 14279 2328_fsm 2609_fsm 2620_vm 2681 2832 29498 3603_vm
11471 11501 14281 2328_vm 2609_vm 2650 2682 2833 29498_fsm 3604
11472 11760 14282 2600 2610 2651 2683 2834 29498_vm 3605
11472_fsm 11760_fsm 14284 2600_fsm 2610_fsm 2652 2684 2835 29507 3606
11472_vm 11760_vm 14286 2600_vm 2610_vm 2653 2685 2836 29507_fsm 3607
11474 11785 14288 2601 2611 2654 2686 2836_fsm 29507_vm 3608
11476 11785_fsm 14289 2601_fsm 2612 2655 2687 2836_vm 29508 3609
11477 11785_vm 14291 2601_vm 2612_fsm 2656 2688 2837 29510 3712
11477_fsm 1247 14293 2602 2612_vm 2657 2689 2838 29512 3764
11477_vm 1247_fsm 14295 2602_fsm 2613 2658 2690 2838_fsm 29516 3764_fsm
11479 1247_vm 14296 2602_vm 2614 2659 2691 2838_vm 29516_fsm 3764_vm
11481 1249 14298 2603 2615 2660 2692 2839 2966 3766
11482 1249_fsm 14300 2603_fsm 2615_fsm 2661 2693 2840 3008 3767
11482_fsm 1249_vm 14302 2603_vm 2615_vm 2662 2696 2840_fsm 3009 5000
11482_vm 1255 14304 2604 2616 2663 2699 2840_vm 3501 5001
11484 1255_fsm 14306 2605 2616_fsm 2664 2701 2841 3502 5002
11486 1255_vm 14308 2605_fsm 2616_vm 2665 2702 2893 3503 548
11487 1259 14310 2605_vm 2617 2666 2703 2893_fsm 3600 549
11487_fsm 1259_fsm 14312 2606 2617_fsm 2667 2704 2893_vm 3600_fsm pg_internal.init
11487_vm 1259_vm 14314 2606_fsm 2617_vm 2668 2753 2903 3600_vm PG_VERSION
11489 1417 14316 2606_vm 2618 2669 2753_fsm 2904 3601
11491 1418 14364 2607 2618_fsm 2670 2753_vm 2936 3601_fsm
11492 14268 14367 2607_fsm 2618_vm 2673 2754 2936_fsm 3601_vm
[root@localhost bin]# su - enterprisedb
-bash-3.2$ cd bin/
-bash-3.2$ ./psql benchdb
psql (8.4.4.10)
Type "help" for help.
benchdb=# analyze;
ANALYZE
benchdb=# select * from pgbench_accounts order by aid limit 7;
aid | bid | abalance | filler
-----+-----+----------+--------------------------------------------------------------------------------------
1 | 1 | 0 |
2 | 1 | 0 |
3 | 1 | 0 |
4 | 1 | 0 |
5 | 1 | 0 |
6 | 1 | 0 |
7 | 1 | 0 |
(7 rows)
benchdb=# select * from pgbench_accounts order by aid desc limit 7;
错误: 无法读取关系base/29494/29507的块158730:只读取了8192字节的0
benchdb=# vacuum;
VACUUM
[root@localhost 29494]# ll 29507*
-rw------- 1 enterprisedb enterprisedb 1073741824 Aug 27 13:28 29507
-rw------- 1 enterprisedb enterprisedb 0 Aug 27 13:19 29507.1
-rw------- 1 enterprisedb enterprisedb 344064 Aug 27 13:28 29507_fsm
-rw------- 1 enterprisedb enterprisedb 24576 Aug 27 13:28 29507_vm
结论：
从上面的测试中看到，虽然删除了表的某个子文件，我们仍能够正常地进行vacuum，analyze，访问部分数据，并且也可以正常启动/关闭数据库。
Postgresql基于这样的设计有什么好处和坏处呢？
·好处：
如果真出现了如上某些文件误删除的情况，不会影响对数据库其他表的正常访问，数据库不会因此而宕下来。从可用性来说，可以说他提供了更好的高可用性
·坏处：
我们只有访问到这部分丢失的文件相关的数据才能发现此问题，DBA不能提前知道，早早采取措施。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/21778816/viewspace-671997/ ，如需转载，请注明出处，否则将追究法律责任。
