/usr/share/doc/pgpool2/pgpool-ja.html is in pgpool2 3.3.2-1ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923
3924
3925
3926
3927
3928
3929
3930
3931
3932
3933
3934
3935
3936
3937
3938
3939
3940
3941
3942
3943
3944
3945
3946
3947
3948
3949
3950
3951
3952
3953
3954
3955
3956
3957
3958
3959
3960
3961
3962
3963
3964
3965
3966
3967
3968
3969
3970
3971
3972
3973
3974
3975
3976
3977
3978
3979
3980
3981
3982
3983
3984
3985
3986
3987
3988
3989
3990
3991
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031
4032
4033
4034
4035
4036
4037
4038
4039
4040
4041
4042
4043
4044
4045
4046
4047
4048
4049
4050
4051
4052
4053
4054
4055
4056
4057
4058
4059
4060
4061
4062
4063
4064
4065
4066
4067
4068
4069
4070
4071
4072
4073
4074
4075
4076
4077
4078
4079
4080
4081
4082
4083
4084
4085
4086
4087
4088
4089
4090
4091
4092
4093
4094
4095
4096
4097
4098
4099
4100
4101
4102
4103
4104
4105
4106
4107
4108
4109
4110
4111
4112
4113
4114
4115
4116
4117
4118
4119
4120
4121
4122
4123
4124
4125
4126
4127
4128
4129
4130
4131
4132
4133
4134
4135
4136
4137
4138
4139
4140
4141
4142
4143
4144
4145
4146
4147
4148
4149
4150
4151
4152
4153
4154
4155
4156
4157
4158
4159
4160
4161
4162
4163
4164
4165
4166
4167
4168
4169
4170
4171
4172
4173
4174
4175
4176
4177
4178
4179
4180
4181
4182
4183
4184
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199
4200
4201
4202
4203
4204
4205
4206
4207
4208
4209
4210
4211
4212
4213
4214
4215
4216
4217
4218
4219
4220
4221
4222
4223
4224
4225
4226
4227
4228
4229
4230
4231
4232
4233
4234
4235
4236
4237
4238
4239
4240
4241
4242
4243
4244
4245
4246
4247
4248
4249
4250
4251
4252
4253
4254
4255
4256
4257
4258
4259
4260
4261
4262
4263
4264
4265
4266
4267
4268
4269
4270
4271
4272
4273
4274
4275
4276
4277
4278
4279
4280
4281
4282
4283
4284
4285
4286
4287
4288
4289
4290
4291
4292
4293
4294
4295
4296
4297
4298
4299
4300
4301
4302
4303
4304
4305
4306
4307
4308
4309
4310
4311
4312
4313
4314
4315
4316
4317
4318
4319
4320
4321
4322
4323
4324
4325
4326
4327
4328
4329
4330
4331
4332
4333
4334
4335
4336
4337
4338
4339
4340
4341
4342
4343
4344
4345
4346
4347
4348
4349
4350
4351
4352
4353
4354
4355
4356
4357
4358
4359
4360
4361
4362
4363
4364
4365
4366
4367
4368
4369
4370
4371
4372
4373
4374
4375
4376
4377
4378
4379
4380
4381
4382
4383
4384
4385
4386
4387
4388
4389
4390
4391
4392
4393
4394
4395
4396
4397
4398
4399
4400
4401
4402
4403
4404
4405
4406
4407
4408
4409
4410
4411
4412
4413
4414
4415
4416
4417
4418
4419
4420
4421
4422
4423
4424
4425
4426
4427
4428
4429
4430
4431
4432
4433
4434
4435
4436
4437
4438
4439
4440
4441
4442
4443
4444
4445
4446
4447
4448
4449
4450
4451
4452
4453
4454
4455
4456
4457
4458
4459
4460
4461
4462
4463
4464
4465
4466
4467
4468
4469
4470
4471
4472
4473
4474
4475
4476
4477
4478
4479
4480
4481
4482
4483
4484
4485
4486
4487
4488
4489
4490
4491
4492
4493
4494
4495
4496
4497
4498
4499
4500
4501
4502
4503
4504
4505
4506
4507
4508
4509
4510
4511
4512
4513
4514
4515
4516
4517
4518
4519
4520
4521
4522
4523
4524
4525
4526
4527
4528
4529
4530
4531
4532
4533
4534
4535
4536
4537
4538
4539
4540
4541
4542
4543
4544
4545
4546
4547
4548
4549
4550
4551
4552
4553
4554
4555
4556
4557
4558
4559
4560
4561
4562
4563
4564
4565
4566
4567
4568
4569
4570
4571
4572
4573
4574
4575
4576
4577
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594
4595
4596
4597
4598
4599
4600
4601
4602
4603
4604
4605
4606
4607
4608
4609
4610
4611
4612
4613
4614
4615
4616
4617
4618
4619
4620
4621
4622
4623
4624
4625
4626
4627
4628
4629
4630
4631
4632
4633
4634
4635
4636
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650
4651
4652
4653
4654
4655
4656
4657
4658
4659
4660
4661
4662
4663
4664
4665
4666
4667
4668
4669
4670
4671
4672
4673
4674
4675
4676
4677
4678
4679
4680
4681
4682
4683
4684
4685
4686
4687
4688
4689
4690
4691
4692
4693
4694
4695
4696
4697
4698
4699
4700
4701
4702
4703
4704
4705
4706
4707
4708
4709
4710
4711
4712
4713
4714
4715
4716
4717
4718
4719
4720
4721
4722
4723
4724
4725
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762
4763
4764
4765
4766
4767
4768
4769
4770
4771
4772
4773
4774
4775
4776
4777
4778
4779
4780
4781
4782
4783
4784
4785
4786
4787
4788
4789
4790
4791
4792
4793
4794
4795
4796
4797
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818
4819
4820
4821
4822
4823
4824
4825
4826
4827
4828
4829
4830
4831
4832
4833
4834
4835
4836
4837
4838
4839
4840
4841
4842
4843
4844
4845
4846
4847
4848
4849
4850
4851
4852
4853
4854
4855
4856
4857
4858
4859
4860
4861
4862
4863
4864
4865
4866
4867
4868
4869
4870
4871
4872
4873
4874
4875
4876
4877
4878
4879
4880
4881
4882
4883
4884
4885
4886
4887
4888
4889
4890
4891
4892
4893
4894
4895
4896
4897
4898
4899
4900
4901
4902
4903
4904
4905
4906
4907
4908
4909
4910
4911
4912
4913
4914
4915
4916
4917
4918
4919
4920
4921
4922
4923
4924
4925
4926
4927
4928
4929
4930
4931
4932
4933
4934
4935
4936
4937
4938
4939
4940
4941
4942
4943
4944
4945
4946
4947
4948
4949
4950
4951
4952
4953
4954
4955
4956
4957
4958
4959
4960
4961
4962
4963
4964
4965
4966
4967
4968
4969
4970
4971
4972
4973
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983
4984
4985
4986
4987
4988
4989
4990
4991
4992
4993
4994
4995
4996
4997
4998
4999
5000
5001
5002
5003
5004
5005
5006
5007
5008
5009
5010
5011
5012
5013
5014
5015
5016
5017
5018
5019
5020
5021
5022
5023
5024
5025
5026
5027
5028
5029
5030
5031
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042
5043
5044
5045
5046
5047
5048
5049
5050
5051
5052
5053
5054
5055
5056
5057
5058
5059
5060
5061
5062
5063
5064
5065
5066
5067
5068
5069
5070
5071
5072
5073
5074
5075
5076
5077
5078
5079
5080
5081
5082
5083
5084
5085
5086
5087
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098
5099
5100
5101
5102
5103
5104
5105
5106
5107
5108
5109
5110
5111
5112
5113
5114
5115
5116
5117
5118
5119
5120
5121
5122
5123
5124
5125
5126
5127
5128
5129
5130
5131
5132
5133
5134
5135
5136
5137
5138
5139
5140
5141
5142
5143
5144
5145
5146
5147
5148
5149
5150
5151
5152
5153
5154
5155
5156
5157
5158
5159
5160
5161
5162
5163
5164
5165
5166
5167
5168
5169
5170
5171
5172
5173
5174
5175
5176
5177
5178
5179
5180
5181
5182
5183
5184
5185
5186
5187
5188
5189
5190
5191
5192
5193
5194
5195
5196
5197
5198
5199
5200
5201
5202
5203
5204
5205
5206
5207
5208
5209
5210
5211
5212
5213
5214
5215
5216
5217
5218
5219
5220
5221
5222
5223
5224
5225
5226
5227
5228
5229
5230
5231
5232
5233
5234
5235
5236
5237
5238
5239
5240
5241
5242
5243
5244
5245
5246
5247
5248
5249
5250
5251
5252
5253
5254
5255
5256
5257
5258
5259
5260
5261
5262
5263
5264
5265
5266
5267
5268
5269
5270
5271
5272
5273
5274
5275
5276
5277
5278
5279
5280
5281
5282
5283
5284
5285
5286
5287
5288
5289
5290
5291
5292
5293
5294
5295
5296
5297
5298
5299
5300
5301
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322
5323
5324
5325
5326
5327
5328
5329
5330
5331
5332
5333
5334
5335
5336
5337
5338
5339
5340
5341
5342
5343
5344
5345
5346
5347
5348
5349
5350
5351
5352
5353
5354
5355
5356
5357
5358
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378
5379
5380
5381
5382
5383
5384
5385
5386
5387
5388
5389
5390
5391
5392
5393
5394
5395
5396
5397
5398
5399
5400
5401
5402
5403
5404
5405
5406
5407
5408
5409
5410
5411
5412
5413
5414
5415
5416
5417
5418
5419
5420
5421
5422
5423
5424
5425
5426
5427
5428
5429
5430
5431
5432
5433
5434
5435
5436
5437
5438
5439
5440
5441
5442
5443
5444
5445
5446
5447
5448
5449
5450
5451
5452
5453
5454
5455
5456
5457
5458
5459
5460
5461
5462
5463
5464
5465
5466
5467
5468
5469
5470
5471
5472
5473
5474
5475
5476
5477
5478
5479
5480
5481
5482
5483
5484
5485
5486
5487
5488
5489
5490
5491
5492
5493
5494
5495
5496
5497
5498
5499
5500
5501
5502
5503
5504
5505
5506
5507
5508
5509
5510
5511
5512
5513
5514
5515
5516
5517
5518
5519
5520
5521
5522
5523
5524
5525
5526
5527
5528
5529
5530
5531
5532
5533
5534
5535
5536
5537
5538
5539
5540
5541
5542
5543
5544
5545
5546
5547
5548
5549
5550
5551
5552
5553
5554
5555
5556
5557
5558
5559
5560
5561
5562
5563
5564
5565
5566
5567
5568
5569
5570
5571
5572
5573
5574
5575
5576
5577
5578
5579
5580
5581
5582
5583
5584
5585
5586
5587
5588
5589
5590
5591
5592
5593
5594
5595
5596
5597
5598
5599
5600
5601
5602
5603
5604
5605
5606
5607
5608
5609
5610
5611
5612
5613
5614
5615
5616
5617
5618
5619
5620
5621
5622
5623
5624
5625
5626
5627
5628
5629
5630
5631
5632
5633
5634
5635
5636
5637
5638
5639
5640
5641
5642
5643
5644
5645
5646
5647
5648
5649
5650
5651
5652
5653
5654
5655
5656
5657
5658
5659
5660
5661
5662
5663
5664
5665
5666
5667
5668
5669
5670
5671
5672
5673
5674
5675
5676
5677
5678
5679
5680
5681
5682
5683
5684
5685
5686
5687
5688
5689
5690
5691
5692
5693
5694
5695
5696
5697
5698
5699
5700
5701
5702
5703
5704
5705
5706
5707
5708
5709
5710
5711
5712
5713
5714
5715
5716
5717
5718
5719
5720
5721
5722
5723
5724
5725
5726
5727
5728
5729
5730
5731
5732
5733
5734
5735
5736
5737
5738
5739
5740
5741
5742
5743
5744
5745
5746
5747
5748
5749
5750
5751
5752
5753
5754
5755
5756
5757
5758
5759
5760
5761
5762
5763
5764
5765
5766
5767
5768
5769
5770
5771
5772
5773
5774
5775
5776
5777
5778
5779
5780
5781
5782
5783
5784
5785
5786
5787
5788
5789
5790
5791
5792
5793
5794
5795
5796
5797
5798
5799
5800
5801
5802
5803
5804
5805
5806
5807
5808
5809
5810
5811
5812
5813
5814
5815
5816
5817
5818
5819
5820
5821
5822
5823
5824
5825
5826
5827
5828
5829
5830
5831
5832
5833
5834
5835
5836
5837
5838
5839
5840
5841
5842
5843
5844
5845
5846
5847
5848
5849
5850
5851
5852
5853
5854
5855
5856
5857
5858
5859
5860
5861
5862
5863
5864
5865
5866
5867
5868
5869
5870
5871
5872
5873
5874
5875
5876
5877
5878
5879
5880
5881
5882
5883
5884
5885
5886
5887
5888
5889
5890
5891
5892
5893
5894
5895
5896
5897
5898
5899
5900
5901
5902
5903
5904
5905
5906
5907
5908
5909
5910
5911
5912
5913
5914
5915
5916
5917
5918
5919
5920
5921
5922
5923
5924
5925
5926
5927
5928
5929
5930
5931
5932
5933
5934
5935
5936
5937
5938
5939
5940
5941
5942
5943
5944
5945
5946
5947
5948
5949
5950
5951
5952
5953
5954
5955
5956
5957
5958
5959
5960
5961
5962
5963
5964
5965
5966
5967
5968
5969
5970
5971
5972
5973
5974
5975
5976
5977
5978
5979
5980
5981
5982
5983
5984
5985
5986
5987
5988
5989
5990
5991
5992
5993
5994
5995
5996
5997
5998
5999
6000
6001
6002
6003
6004
6005
6006
6007
6008
6009
6010
6011
6012
6013
6014
6015
6016
6017
6018
6019
6020
6021
6022
6023
6024
6025
6026
6027
6028
6029
6030
6031
6032
6033
6034
6035
6036
6037
6038
6039
6040
6041
6042
6043
6044
6045
6046
6047
6048
6049
6050
6051
6052
6053
6054
6055
6056
6057
6058
6059
6060
6061
6062
6063
6064
6065
6066
6067
6068
6069
6070
6071
6072
6073
6074
6075
6076
6077
6078
6079
6080
6081
6082
6083
6084
6085
6086
6087
6088
6089
6090
6091
6092
6093
6094
6095
6096
6097
6098
6099
6100
6101
6102
6103
6104
6105
6106
6107
6108
6109
6110
6111
6112
6113
6114
6115
6116
6117
6118
6119
6120
6121
6122
6123
6124
6125
6126
6127
6128
6129
6130
6131
6132
6133
6134
6135
6136
6137
6138
6139
6140
6141
6142
6143
6144
6145
6146
6147
6148
6149
6150
6151
6152
6153
6154
6155
6156
6157
6158
6159
6160
6161
6162
6163
6164
6165
6166
6167
6168
6169
6170
6171
6172
6173
6174
6175
6176
6177
6178
6179
6180
6181
6182
6183
6184
6185
6186
6187
6188
6189
6190
6191
6192
6193
6194
6195
6196
6197
6198
6199
6200
6201
6202
6203
6204
6205
6206
6207
6208
6209
6210
6211
6212
6213
6214
6215
6216
6217
6218
6219
6220
6221
6222
6223
6224
6225
6226
6227
6228
6229
6230
6231
6232
6233
6234
6235
6236
6237
6238
6239
6240
6241
6242
6243
6244
6245
6246
6247
6248
6249
6250
6251
6252
6253
6254
6255
6256
6257
6258
6259
6260
6261
6262
6263
6264
6265
6266
6267
6268
6269
6270
6271
6272
6273
6274
6275
6276
6277
6278
6279
6280
6281
6282
6283
6284
6285
6286
6287
6288
6289
6290
6291
6292
6293
6294
6295
6296
6297
6298
6299
6300
6301
6302
6303
6304
6305
6306
6307
6308
6309
6310
6311
6312
6313
6314
6315
6316
6317
6318
6319
6320
6321
6322
6323
6324
6325
6326
6327
6328
6329
6330
6331
6332
6333
6334
6335
6336
6337
6338
6339
6340
6341
6342
6343
6344
6345
6346
6347
6348
6349
6350
6351
6352
6353
6354
6355
6356
6357
6358
6359
6360
6361
6362
6363
6364
6365
6366
6367
6368
6369
6370
6371
6372
6373
6374
6375
6376
6377
6378
6379
6380
6381
6382
6383
6384
6385
6386
6387
6388
6389
6390
6391
6392
6393
6394
6395
6396
6397
6398
6399
6400
6401
6402
6403
6404
6405
6406
6407
6408
6409
6410
6411
6412
6413
6414
6415
6416
6417
6418
6419
6420
6421
6422
6423
6424
6425
6426
6427
6428
6429
6430
6431
6432
6433
6434
6435
6436
6437
6438
6439
6440
6441
6442
6443
6444
6445
6446
6447
6448
6449
6450
6451
6452
6453
6454
6455
6456
6457
6458
6459
6460
6461
6462
6463
6464
6465
6466
6467
6468
6469
6470
6471
6472
6473
6474
6475
6476
6477
6478
6479
6480
6481
6482
6483
6484
6485
6486
6487
6488
6489
6490
6491
6492
6493
6494
6495
6496
6497
6498
6499
6500
6501
6502
6503
6504
6505
6506
6507
6508
6509
6510
6511
6512
6513
6514
6515
6516
6517
6518
6519
6520
6521
6522
6523
6524
6525
6526
6527
6528
6529
6530
6531
6532
6533
6534
6535
6536
6537
6538
6539
6540
6541
6542
6543
6544
6545
6546
6547
6548
6549
6550
6551
6552
6553
6554
6555
6556
6557
6558
6559
6560
6561
6562
6563
6564
6565
6566
6567
6568
6569
6570
6571
6572
6573
6574
6575
6576
6577
6578
6579
6580
6581
6582
6583
6584
6585
6586
6587
6588
6589
6590
6591
6592
6593
6594
6595
6596
6597
6598
6599
6600
6601
6602
6603
6604
6605
6606
6607
6608
6609
6610
6611
6612
6613
6614
6615
6616
6617
6618
6619
6620
6621
6622
6623
6624
6625
6626
6627
6628
6629
6630
6631
6632
6633
6634
6635
6636
6637
6638
6639
6640
6641
6642
6643
6644
6645
6646
6647
6648
6649
6650
6651
6652
6653
6654
6655
6656
6657
6658
6659
6660
6661
6662
6663
6664
6665
6666
6667
6668
6669
6670
6671
6672
6673
6674
6675
6676
6677
6678
6679
6680
6681
6682
6683
6684
6685
6686
6687
6688
6689
6690
6691
6692
6693
6694
6695
6696
6697
6698
6699
6700
6701
6702
6703
6704
6705
6706
6707
6708
6709
6710
6711
6712
6713
6714
6715
6716
6717
6718
6719
6720
6721
6722
6723
6724
6725
6726
6727
6728
6729
6730
6731
6732
6733
6734
6735
6736
6737
6738
6739
6740
6741
6742
6743
6744
6745
6746
6747
6748
6749
6750
6751
6752
6753
6754
6755
6756
6757
6758
6759
6760
6761
6762
6763
6764
6765
6766
6767
6768
6769
6770
6771
6772
6773
6774
6775
6776
6777
6778
6779
6780
6781
6782
6783
6784
6785
6786
6787
6788
6789
6790
6791
6792
6793
6794
6795
6796
6797
6798
6799
6800
6801
6802
6803
6804
6805
6806
6807
6808
6809
6810
6811
6812
6813
6814
6815
6816
6817
6818
6819
6820
6821
6822
6823
6824
6825
6826
6827
6828
6829
6830
6831
6832
6833
6834
6835
6836
6837
6838
6839
6840
6841
6842
6843
6844
6845
6846
6847
6848
6849
6850
6851
6852
6853
6854
6855
6856
6857
6858
6859
6860
6861
6862
6863
6864
6865
6866
6867
6868
6869
6870
6871
6872
6873
6874
6875
6876
6877
6878
6879
6880
6881
6882
6883
6884
6885
6886
6887
6888
6889
6890
6891
6892
6893
6894
6895
6896
6897
6898
6899
6900
6901
6902
6903
6904
6905
6906
6907
6908
6909
6910
6911
6912
6913
6914
6915
6916
6917
6918
6919
6920
6921
6922
6923
6924
6925
6926
6927
6928
6929
6930
6931
6932
6933
6934
6935
6936
6937
6938
6939
6940
6941
6942
6943
6944
6945
6946
6947
6948
6949
6950
6951
6952
6953
6954
6955
6956
6957
6958
6959
6960
6961
6962
6963
6964
6965
6966
6967
6968
6969
6970
6971
6972
6973
6974
6975
6976
6977
6978
6979
6980
6981
6982
6983
6984
6985
6986
6987
6988
6989
6990
6991
6992
6993
6994
6995
6996
6997
6998
6999
7000
7001
7002
7003
7004
7005
7006
7007
7008
7009
7010
7011
7012
7013
7014
7015
7016
7017
7018
7019
7020
7021
7022
7023
7024
7025
7026
7027
7028
7029
7030
7031
7032
7033
7034
7035
7036
7037
7038
7039
7040
7041
7042
7043
7044
7045
7046
7047
7048
7049
7050
7051
7052
7053
7054
7055
7056
7057
7058
7059
7060
7061
7062
7063
7064
7065
7066
7067
7068
7069
7070
7071
7072
7073
7074
7075
7076
7077
7078
7079
7080
7081
7082
7083
7084
7085
7086
7087
7088
7089
7090
7091
7092
7093
7094
7095
7096
7097
7098
7099
7100
7101
7102
7103
7104
7105
7106
7107
7108
7109
7110
7111
7112
7113
7114
7115
7116
7117
7118
7119
7120
7121
7122
7123
7124
7125
7126
7127
7128
7129
7130
7131
7132
7133
7134
7135
7136
7137
7138
7139
7140
7141
7142
7143
7144
7145
7146
7147
7148
7149
7150
7151
7152
7153
7154
7155
7156
7157
7158
7159
7160
7161
7162
7163
7164
7165
7166
7167
7168
7169
7170
7171
7172
7173
7174
7175
7176
7177
7178
7179
7180
7181
7182
7183
7184
7185
7186
7187
7188
7189
7190
7191
7192
7193
7194
7195
7196
7197
7198
7199
7200
7201
7202
7203
7204
7205
7206
7207
7208
7209
7210
7211
7212
7213
7214
7215
7216
7217
7218
7219
7220
7221
7222
7223
7224
7225
7226
7227
7228
7229
7230
7231
7232
7233
7234
7235
7236
7237
7238
7239
7240
7241
7242
7243
7244
7245
7246
7247
7248
7249
7250
7251
7252
7253
7254
7255
7256
7257
7258
7259
7260
7261
7262
7263
7264
7265
7266
7267
7268
7269
7270
7271
7272
7273
7274
7275
7276
7277
7278
7279
7280
7281
7282
7283
7284
7285
7286
7287
7288
7289
7290
7291
7292
7293
7294
7295
7296
7297
7298
7299
7300
7301
7302
7303
7304
7305
7306
7307
7308
7309
7310
7311
7312
7313
7314
7315
7316
7317
7318
7319
7320
7321
7322
7323
7324
7325
7326
7327
7328
7329
7330
7331
7332
7333
7334
7335
7336
7337
7338
7339
7340
7341
7342
7343
7344
7345
7346
7347
7348
7349
7350
7351
7352
7353
7354
7355
7356
7357
7358
7359
7360
7361
7362
7363
7364
7365
7366
7367
7368
7369
7370
7371
7372
7373
7374
7375
7376
7377
7378
7379
7380
7381
7382
7383
7384
7385
7386
7387
7388
7389
7390
7391
7392
7393
7394
7395
7396
7397
7398
7399
7400
7401
7402
7403
7404
7405
7406
7407
7408
7409
7410
7411
7412
7413
7414
7415
7416
7417
7418
7419
7420
7421
7422
7423
7424
7425
7426
7427
7428
7429
7430
7431
7432
7433
7434
7435
7436
7437
7438
7439
7440
7441
7442
7443
7444
7445
7446
7447
7448
7449
7450
7451
7452
7453
7454
7455
7456
7457
7458
7459
7460
7461
7462
7463
7464
7465
7466
7467
7468
7469
7470
7471
7472
7473
7474
7475
7476
7477
7478
7479
7480
7481
7482
7483
7484
7485
7486
7487
7488
7489
7490
7491
7492
7493
7494
7495
7496
7497
7498
7499
7500
7501
7502
7503
7504
7505
7506
7507
7508
7509
7510
7511
7512
7513
7514
7515
7516
7517
7518
7519
7520
7521
7522
7523
7524
7525
7526
7527
7528
7529
7530
7531
7532
7533
7534
7535
7536
7537
7538
7539
7540
7541
7542
7543
7544
7545
7546
7547
7548
7549
7550
7551
7552
7553
7554
7555
7556
7557
7558
7559
7560
7561
7562
7563
7564
7565
7566
7567
7568
7569
7570
7571
7572
7573
7574
7575
7576
7577
7578
7579
7580
7581
7582
7583
7584
7585
7586
7587
7588
7589
7590
7591
7592
7593
7594
7595
7596
7597
7598
7599
7600
7601
7602
7603
7604
7605
7606
7607
7608
7609
7610
7611
7612
7613
7614
7615
7616
7617
7618
7619
7620
7621
7622
7623
7624
7625
7626
7627
7628
7629
7630
7631
7632
7633
7634
7635
7636
7637
7638
7639
7640
7641
7642
7643
7644
7645
7646
7647
7648
7649
7650
7651
7652
7653
7654
7655
7656
7657
7658
7659
7660
7661
7662
7663
7664
7665
7666
7667
7668
7669
7670
7671
7672
7673
7674
7675
7676
7677
7678
7679
7680
7681
7682
7683
7684
7685
7686
7687
7688
7689
7690
7691
7692
7693
7694
7695
7696
7697
7698
7699
7700
7701
7702
7703
7704
7705
7706
7707
7708
7709
7710
7711
7712
7713
7714
7715
7716
7717
7718
7719
7720
7721
7722
7723
7724
7725
7726
7727
7728
7729
7730
7731
7732
7733
7734
7735
7736
7737
7738
7739
7740
7741
7742
7743
7744
7745
7746
7747
7748
7749
7750
7751
7752
7753
7754
7755
7756
7757
7758
7759
7760
7761
7762
7763
7764
7765
7766
7767
7768
7769
7770
7771
7772
7773
7774
7775
7776
7777
7778
7779
7780
7781
7782
7783
7784
7785
7786
7787
7788
7789
7790
7791
7792
7793
7794
7795
7796
7797
7798
7799
7800
7801
7802
7803
7804
7805
7806
7807
7808
7809
7810
7811
7812
7813
7814
7815
7816
7817
7818
7819
7820
7821
7822
7823
7824
7825
7826
7827
7828
7829
7830
7831
7832
7833
7834
7835
7836
7837
7838
7839
7840
7841
7842
7843
7844
7845
7846
7847
7848
7849
7850
7851
7852
7853
7854
7855
7856
7857
7858
7859
7860
7861
7862
7863
7864
7865
7866
7867
7868
7869
7870
7871
7872
7873
7874
7875
7876
7877
7878
7879
7880
7881
7882
7883
7884
7885
7886
7887
7888
7889
7890
7891
7892
7893
7894
7895
7896
7897
7898
7899
7900
7901
7902
7903
7904
7905
7906
7907
7908
7909
7910
7911
7912
7913
7914
7915
7916
7917
7918
7919
7920
7921
7922
7923
7924
7925
7926
7927
7928
7929
7930
7931
7932
7933
7934
7935
7936
7937
7938
7939
7940
7941
7942
7943
7944
7945
7946
7947
7948
7949
7950
7951
7952
7953
7954
7955
7956
7957
7958
7959
7960
7961
7962
7963
7964
7965
7966
7967
7968
7969
7970
7971
7972
7973
7974
7975
7976
7977
7978
7979
7980
7981
7982
7983
7984
7985
7986
7987
7988
7989
7990
7991
7992
7993
7994
7995
7996
7997
7998
7999
8000
8001
8002
8003
8004
8005
8006
8007
8008
8009
8010
8011
8012
8013
8014
8015
8016
8017
8018
8019
8020
8021
8022
8023
8024
8025
8026
8027
8028
8029
8030
8031
8032
8033
8034
8035
8036
8037
8038
8039
8040
8041
8042
8043
8044
8045
8046
8047
8048
8049
8050
8051
8052
8053
8054
8055
8056
8057
8058
8059
8060
8061
8062
8063
8064
8065
8066
8067
8068
8069
8070
8071
8072
8073
8074
8075
8076
8077
8078
8079
8080
8081
8082
8083
8084
8085
8086
8087
8088
8089
8090
8091
8092
8093
8094
8095
8096
8097
8098
8099
8100
8101
8102
8103
8104
8105
8106
8107
8108
8109
8110
8111
8112
8113
8114
8115
8116
8117
8118
8119
8120
8121
8122
8123
8124
8125
8126
8127
8128
8129
8130
8131
8132
8133
8134
8135
8136
8137
8138
8139
8140
8141
8142
8143
8144
8145
8146
8147
8148
8149
8150
8151
8152
8153
8154
8155
8156
8157
8158
8159
8160
8161
8162
8163
8164
8165
8166
8167
8168
8169
8170
8171
8172
8173
8174
8175
8176
8177
8178
8179
8180
8181
8182
8183
8184
8185
8186
8187
8188
8189
8190
8191
8192
8193
8194
8195
8196
8197
8198
8199
8200
8201
8202
8203
8204
8205
8206
8207
8208
8209
8210
8211
8212
8213
8214
8215
8216
8217
8218
8219
8220
8221
8222
8223
8224
8225
8226
8227
8228
8229
8230
8231
8232
8233
8234
8235
8236
8237
8238
8239
8240
8241
8242
8243
8244
8245
8246
8247
8248
8249
8250
8251
8252
8253
8254
8255
8256
8257
8258
8259
8260
8261
8262
8263
8264
8265
8266
8267
8268
8269
8270
8271
8272
8273
8274
8275
8276
8277
8278
8279
8280
8281
8282
8283
8284
8285
8286
8287
8288
8289
8290
8291
8292
8293
8294
8295
8296
8297
8298
8299
8300
8301
8302
8303
8304
8305
8306
8307
8308
8309
8310
8311
8312
8313
8314
8315
8316
8317
8318
8319
8320
8321
8322
8323
8324
8325
8326
8327
8328
8329
8330
8331
8332
8333
8334
8335
8336
8337
8338
8339
8340
8341
8342
8343
8344
8345
8346
8347
8348
8349
8350
8351
8352
8353
8354
8355
8356
8357
8358
8359
8360
8361
8362
8363
8364
8365
8366
8367
8368
8369
8370
8371
8372
8373
8374
8375
8376
8377
8378
8379
8380
8381
8382
8383
8384
8385
8386
8387
8388
8389
8390
8391
8392
8393
8394
8395
8396
8397
8398
8399
8400
8401
8402
8403
8404
8405
8406
8407
8408
8409
8410
8411
8412
8413
8414
8415
8416
8417
8418
8419
8420
8421
8422
8423
8424
8425
8426
8427
8428
8429
8430
8431
8432
8433
8434
8435
8436
8437
8438
8439
8440
8441
8442
8443
8444
8445
8446
8447
8448
8449
8450
8451
8452
8453
8454
8455
8456
8457
8458
8459
8460
8461
8462
8463
8464
8465
8466
8467
8468
8469
8470
8471
8472
8473
8474
8475
8476
8477
8478
8479
8480
8481
8482
8483
8484
8485
8486
8487
8488
8489
8490
8491
8492
8493
8494
8495
8496
8497
8498
8499
8500
8501
8502
8503
8504
8505
8506
8507
8508
8509
8510
8511
8512
8513
8514
8515
8516
8517
8518
8519
8520
8521
8522
8523
8524
8525
8526
8527
8528
8529
8530
8531
8532
8533
8534
8535
8536
8537
8538
8539
8540
8541
8542
8543
8544
8545
8546
8547
8548
8549
8550
8551
8552
8553
8554
8555
8556
8557
8558
8559
8560
8561
8562
8563
8564
8565
8566
8567
8568
8569
8570
8571
8572
8573
8574
8575
8576
8577
8578
8579
8580
8581
8582
8583
8584
8585
8586
8587
8588
8589
8590
8591
8592
8593
8594
8595
8596
8597
8598
8599
8600
8601
8602
8603
8604
8605
8606
8607
8608
8609
8610
8611
8612
8613
8614
8615
8616
8617
8618
8619
8620
8621
8622
8623
8624
8625
8626
8627
8628
8629
8630
8631
8632
8633
8634
8635
8636
8637
8638
8639
8640
8641
8642
8643
8644
8645
8646
8647
8648
8649
8650
8651
8652
8653
8654
8655
8656
8657
8658
8659
8660
8661
8662
8663
8664
8665
8666
8667
8668
8669
8670
8671
8672
8673
8674
8675
8676
8677
8678
8679
8680
8681
8682
8683
8684
8685
8686
8687
8688
8689
8690
8691
8692
8693
8694
8695
8696
8697
8698
8699
8700
8701
8702
8703
8704
8705
8706
8707
8708
8709
8710
8711
8712
8713
8714
8715
8716
8717
8718
8719
8720
8721
8722
8723
8724
8725
8726
8727
8728
8729
8730
8731
8732
8733
8734
8735
8736
8737
8738
8739
8740
8741
8742
8743
8744
8745
8746
8747
8748
8749
8750
8751
8752
8753
8754
8755
8756
8757
8758
8759
8760
8761
8762
8763
8764
8765
8766
8767
8768
8769
8770
8771
8772
8773
8774
8775
8776
8777
8778
8779
8780
8781
8782
8783
8784
8785
8786
8787
8788
8789
8790
8791
8792
8793
8794
8795
8796
8797
8798
8799
8800
8801
8802
8803
8804
8805
8806
8807
8808
8809
8810
8811
8812
8813
8814
8815
8816
8817
8818
8819
8820
8821
8822
8823
8824
8825
8826
8827
8828
8829
8830
8831
8832
8833
8834
8835
8836
8837
8838
8839
8840
8841
8842
8843
8844
8845
8846
8847
8848
8849
8850
8851
8852
8853
8854
8855
8856
8857
8858
8859
8860
8861
8862
8863
8864
8865
8866
8867
8868
8869
8870
8871
8872
8873
8874
8875
8876
8877
8878
8879
8880
8881
8882
8883
8884
8885
8886
8887
8888
8889
8890
8891
8892
8893
8894
8895
8896
8897
8898
8899
8900
8901
8902
8903
8904
8905
8906
8907
8908
8909
8910
8911
8912
8913
8914
8915
8916
8917
8918
8919
8920
8921
8922
8923
8924
8925
8926
8927
8928
8929
8930
8931
8932
8933
8934
8935
8936
8937
8938
8939
8940
8941
8942
8943
8944
8945
8946
8947
8948
8949
8950
8951
8952
8953
8954
8955
8956
8957
8958
8959
8960
8961
8962
8963
8964
8965
8966
8967
8968
8969
8970
8971
8972
8973
8974
8975
8976
8977
8978
8979
8980
8981
8982
8983
8984
8985
8986
8987
8988
8989
8990
8991
8992
8993
8994
8995
8996
8997
8998
8999
9000
9001
9002
9003
9004
9005
9006
9007
9008
9009
9010
9011
9012
9013
9014
9015
9016
9017
9018
9019
9020
9021
9022
9023
9024
9025
9026
9027
9028
9029
9030
9031
9032
9033
9034
9035
9036
9037
9038
9039
9040
9041
9042
9043
9044
9045
9046
9047
9048
9049
9050
9051
9052
9053
9054
9055
9056
9057
9058
9059
9060
9061
9062
9063
9064
9065
9066
9067
9068
9069
9070
9071
9072
9073
9074
9075
9076
9077
9078
9079
9080
9081
9082
9083
9084
9085
9086
9087
9088
9089
9090
9091
9092
9093
9094
9095
9096
9097
9098
9099
9100
9101
9102
9103
9104
9105
9106
9107
9108
9109
9110
9111
9112
9113
9114
9115
9116
9117
9118
9119
9120
9121
9122
9123
9124
9125
9126
9127
9128
9129
9130
9131
9132
9133
9134
9135
9136
9137
9138
9139
9140
9141
9142
9143
9144
9145
9146
9147
9148
9149
9150
9151
9152
9153
9154
9155
9156
9157
9158
9159
9160
9161
9162
9163
9164
9165
9166
9167
9168
9169
9170
9171
9172
9173
9174
9175
9176
9177
9178
9179
9180
9181
9182
9183
9184
9185
9186
9187
9188
9189
9190
9191
9192
9193
9194
9195
9196
9197
9198
9199
9200
9201
9202
9203
9204
9205
9206
9207
9208
9209
9210
9211
9212
9213
9214
9215
9216
9217
9218
9219
9220
9221
9222
9223
9224
9225
9226
9227
9228
9229
9230
9231
9232
9233
9234
9235
9236
9237
9238
9239
9240
9241
9242
9243
9244
9245
9246
9247
9248
9249
9250
9251
9252
9253
9254
9255
9256
9257
9258
9259
9260
9261
9262
9263
9264
9265
9266
9267
9268
9269
9270
9271
9272
9273
9274
9275
9276
9277
9278
9279
9280
9281
9282
9283
9284
9285
9286
9287
9288
9289
9290
9291
9292
9293
9294
9295
9296
9297
9298
9299
9300
9301
9302
9303
9304
9305
9306
9307
9308
9309
9310
9311
9312
9313
9314
9315
9316
9317
9318
9319
9320
9321
9322
9323
9324
9325
9326
9327
9328
9329
9330
9331
9332
9333
9334
9335
9336
9337
9338
9339
9340
9341
9342
9343
9344
9345
9346
9347
9348
9349
9350
9351
9352
9353
9354
9355
9356
9357
9358
9359
9360
9361
9362
9363
9364
9365
9366
9367
9368
9369
9370
9371
9372
9373
9374
9375
9376
9377
9378
9379
9380
9381
9382
9383
9384
9385
9386
9387
9388
9389
9390
9391
9392
9393
9394
9395
9396
9397
9398
9399
9400
9401
9402
9403
9404
9405
9406
9407
9408
9409
9410
9411
9412
9413
9414
9415
9416
9417
9418
9419
9420
9421
9422
9423
9424
9425
9426
9427
9428
9429
9430
9431
9432
9433
9434
9435
9436
9437
9438
9439
9440
9441
9442
9443
9444
9445
9446
9447
9448
9449
9450
9451
9452
9453
9454
9455
9456
9457
9458
9459
9460
9461
9462
9463
9464
9465
9466
9467
9468
9469
9470
9471
9472
9473
9474
9475
9476
9477
9478
9479
9480
9481
9482
9483
9484
9485
9486
9487
9488
9489
9490
9491
9492
9493
9494
9495
9496
9497
9498
9499
9500
9501
9502
9503
9504
9505
9506
9507
9508
9509
9510
9511
9512
9513
9514
9515
9516
9517
9518
9519
9520
9521
9522
9523
9524
9525
9526
9527
9528
9529
9530
9531
9532
9533
9534
9535
9536
9537
9538
9539
9540
9541
9542
9543
9544
9545
9546
9547
9548
9549
9550
9551
9552
9553
9554
9555
9556
9557
9558
9559
9560
9561
9562
9563
9564
9565
9566
9567
9568
9569
9570
9571
9572
9573
9574
9575
9576
9577
9578
9579
9580
9581
9582
9583
9584
9585
9586
9587
9588
9589
9590
9591
9592
9593
9594
9595
9596
9597
9598
9599
9600
9601
9602
9603
9604
9605
9606
9607
9608
9609
9610
9611
9612
9613
9614
9615
9616
9617
9618
9619
9620
9621
9622
9623
9624
9625
9626
9627
9628
9629
9630
9631
9632
9633
9634
9635
9636
9637
9638
9639
9640
9641
9642
9643
9644
9645
9646
9647
9648
9649
9650
9651
9652
9653
9654
9655
9656
9657
9658
9659
9660
9661
9662
9663
9664
9665
9666
9667
9668
9669
9670
9671
9672
9673
9674
9675
9676
9677
9678
9679
9680
9681
9682
9683
9684
9685
9686
9687
9688
9689
9690
9691
9692
9693
9694
9695
9696
9697
9698
9699
9700
9701
9702
9703
9704
9705
9706
9707
9708
9709
9710
9711
9712
9713
9714
9715
9716
9717
9718
9719
9720
9721
9722
9723
9724
9725
9726
9727
9728
9729
9730
9731
9732
9733
9734
9735
9736
9737
9738
9739
9740
9741
9742
9743
9744
9745
9746
9747
9748
9749
9750
9751
9752
9753
9754
9755
9756
9757
9758
9759
9760
9761
9762
9763
9764
9765
9766
9767
9768
9769
9770
9771
9772
9773
9774
9775
9776
9777
9778
9779
9780
9781
9782
9783
9784
9785
9786
9787
9788
9789
9790
9791
9792
9793
9794
9795
9796
9797
9798
9799
9800
9801
9802
9803
9804
9805
9806
9807
9808
9809
9810
9811
9812
9813
9814
9815
9816
9817
9818
9819
9820
9821
9822
9823
9824
9825
9826
9827
9828
9829
9830
9831
9832
9833
9834
9835
9836
9837
9838
9839
9840
9841
9842
9843
9844
9845
9846
9847
9848
9849
9850
9851
9852
9853
9854
9855
9856
9857
9858
9859
9860
9861
9862
9863
9864
9865
9866
9867
9868
9869
9870
9871
9872
9873
9874
9875
9876
9877
9878
9879
9880
9881
9882
9883
9884
9885
9886
9887
9888
9889
9890
9891
9892
9893
9894
9895
9896
9897
9898
9899
9900
9901
9902
9903
9904
9905
9906
9907
9908
9909
9910
9911
9912
9913
9914
9915
9916
9917
9918
9919
9920
9921
9922
9923
9924
9925
9926
9927
9928
9929
9930
9931
9932
9933
9934
9935
9936
9937
9938
9939
9940
9941
9942
9943
9944
9945
9946
9947
9948
9949
9950
9951
9952
9953
9954
9955
9956
9957
9958
9959
9960
9961
9962
9963
9964
9965
9966
9967
9968
9969
9970
9971
9972
9973
9974
9975
9976
9977
9978
9979
9980
9981
9982
9983
9984
9985
9986
9987
9988
9989
9990
9991
9992
9993
9994
9995
9996
9997
9998
9999
10000
10001
10002
10003
10004
10005
10006
10007
10008
10009
10010
10011
10012
10013
10014
10015
10016
10017
10018
10019
10020
10021
10022
10023
10024
10025
10026
10027
10028
10029
10030
10031
10032
10033
10034
10035
10036
10037
10038
10039
10040
10041
10042
10043
10044
10045
10046
10047
10048
10049
10050
10051
10052
10053
10054
10055
10056
10057
10058
10059
10060
10061
10062
10063
10064
10065
10066
10067
10068
10069
10070
10071
10072
10073
10074
10075
10076
10077
10078
10079
10080
10081
10082
10083
10084
10085
10086
10087
10088
10089
10090
10091
10092
10093
10094
10095
10096
10097
10098
10099
10100
10101
10102
10103
10104
10105
10106
10107
10108
10109
10110
10111
10112
10113
10114
10115
10116
10117
10118
10119
10120
10121
10122
10123
10124
10125
10126
10127
10128
10129
10130
10131
10132
10133
10134
10135
10136
10137
10138
10139
10140
10141
10142
10143
10144
10145
10146
10147
10148
10149
10150
10151
10152
10153
10154
10155
10156
10157
10158
10159
10160
10161
10162
10163
10164
10165
10166
10167
10168
10169
10170
10171
10172
10173
10174
10175
10176
10177
10178
10179
10180
10181
10182
10183
10184
10185
10186
10187
10188
10189
10190
10191
10192
10193
10194
10195
10196
10197
10198
10199
10200
10201
10202
10203
10204
10205
10206
10207
10208
10209
10210
10211
10212
10213
10214
10215
10216
10217
10218
10219
10220
10221
10222
10223
10224
10225
10226
10227
10228
10229
10230
10231
10232
10233
10234
10235
10236
10237
10238
10239
10240
10241
10242
10243
10244
10245
10246
10247
10248
10249
10250
10251
10252
10253
10254
10255
10256
10257
10258
10259
10260
10261
10262
10263
10264
10265
10266
10267
10268
10269
10270
10271
10272
10273
10274
10275
10276
10277
10278
10279
10280
10281
10282
10283
10284
10285
10286
10287
10288
10289
10290
10291
10292
10293
10294
10295
10296
10297
10298
10299
10300
10301
10302
10303
10304
10305
10306
10307
10308
10309
10310
10311
10312
10313
10314
10315
10316
10317
10318
10319
10320
10321
10322
10323
10324
10325
10326
10327
10328
10329
10330
10331
10332
10333
10334
10335
10336
10337
10338
10339
10340
10341
10342
10343
10344
10345
10346
10347
10348
10349
10350
10351
10352
10353
10354
10355
10356
10357
10358
10359
10360
10361
10362
10363
10364
10365
10366
10367
10368
10369
10370
10371
10372
10373
10374
10375
10376
10377
10378
10379
10380
10381
10382
10383
10384
10385
10386
10387
10388
10389
10390
10391
10392
10393
10394
10395
10396
10397
10398
10399
10400
10401
10402
10403
10404
10405
10406
10407
10408
10409
10410
10411
10412
10413
10414
10415
10416
10417
10418
10419
10420
10421
10422
10423
10424
10425
10426
10427
10428
10429
10430
10431
10432
10433
10434
10435
10436
10437
10438
10439
10440
10441
10442
10443
10444
10445
10446
10447
10448
10449
10450
10451
10452
10453
10454
10455
10456
10457
10458
10459
10460
10461
10462
10463
10464
10465
10466
10467
10468
10469
10470
10471
10472
10473
10474
10475
10476
10477
10478
10479
10480
10481
10482
10483
10484
10485
10486
10487
10488
10489
10490
10491
10492
10493
10494
10495
10496
10497
10498
10499
10500
10501
10502
10503
10504
10505
10506
10507
10508
10509
10510
10511
10512
10513
10514
10515
10516
10517
10518
10519
10520
10521
10522
10523
10524
10525
10526
10527
10528
10529
10530
10531
10532
10533
10534
10535
10536
10537
10538
10539
10540
10541
10542
10543
10544
10545
10546
10547
10548
10549
10550
10551
10552
10553
10554
10555
10556
10557
10558
10559
10560
10561
10562
10563
10564
10565
10566
10567
10568
10569
10570
10571
10572
10573
10574
10575
10576
10577
10578
10579
10580
10581
10582
10583
10584
10585
10586
10587
10588
10589
10590
10591
10592
10593
10594
10595
10596
10597
10598
10599
10600
10601
10602
10603
10604
10605
10606
10607
10608
10609
10610
10611
10612
10613
10614
10615
10616
10617
10618
10619
10620
10621
10622
10623
10624
10625
10626
10627
10628
10629
10630
10631
10632
10633
10634
10635
10636
10637
10638
10639
10640
10641
10642
10643
10644
10645
10646
10647
10648
10649
10650
10651
10652
10653
10654
10655
10656
10657
10658
10659
10660
10661
10662
10663
10664
10665
10666
10667
10668
10669
10670
10671
10672
10673
10674
10675
10676
10677
10678
10679
10680
10681
10682
10683
10684
10685
10686
10687
10688
10689
10690
10691
10692
10693
10694
10695
10696
10697
10698
10699
10700
10701
10702
10703
10704
10705
10706
10707
10708
10709
10710
10711
10712
10713
10714
10715
10716
10717
10718
10719
10720
10721
10722
10723
10724
10725
10726
10727
10728
10729
10730
10731
10732
10733
10734
10735
10736
10737
10738
10739
10740
10741
10742
10743
10744
10745
10746
10747
10748
10749
10750
10751
10752
10753
10754
10755
10756
10757
10758
10759
10760
10761
10762
10763
10764
10765
10766
10767
10768
10769
10770
10771
10772
10773
10774
10775
10776
10777
10778
10779
10780
10781
10782
10783
10784
10785
10786
10787
10788
10789
10790
10791
10792
10793
10794
10795
10796
10797
10798
10799
10800
10801
10802
10803
10804
10805
10806
10807
10808
10809
10810
10811
10812
10813
10814
10815
10816
10817
10818
10819
10820
10821
10822
10823
10824
10825
10826
10827
10828
10829
10830
10831
10832
10833
10834
10835
10836
10837
10838
10839
10840
10841
10842
10843
10844
10845
10846
10847
10848
10849
10850
10851
10852
10853
10854
10855
10856
10857
10858
10859
10860
10861
10862
10863
10864
10865
10866
10867
10868
10869
10870
10871
10872
10873
10874
10875
10876
10877
10878
10879
10880
10881
10882
10883
10884
10885
10886
10887
10888
10889
10890
10891
10892
10893
10894
10895
10896
10897
10898
10899
10900
10901
10902
10903
10904
10905
10906
10907
10908
10909
10910
10911
10912
10913
10914
10915
10916
10917
10918
10919
10920
10921
10922
10923
10924
10925
10926
10927
10928
10929
10930
10931
10932
10933
10934
10935
10936
10937
10938
10939
10940
10941
10942
10943
10944
10945
10946
10947
10948
10949
10950
10951
10952
10953
10954
10955
10956
10957
10958
10959
10960
10961
10962
10963
10964
10965
10966
10967
10968
10969
10970
10971
10972
10973
10974
10975
10976
10977
10978
10979
10980
10981
10982
10983
10984
10985
10986
10987
10988
10989
10990
10991
10992
10993
10994
10995
10996
10997
10998
10999
11000
11001
11002
11003
11004
11005
11006
11007
11008
11009
11010
11011
11012
11013
11014
11015
11016
11017
11018
11019
11020
11021
11022
11023
11024
11025
11026
11027
11028
11029
11030
11031
11032
11033
11034
11035
11036
11037
11038
11039
11040
11041
11042
11043
11044
11045
11046
11047
11048
11049
11050
11051
11052
11053
11054
11055
11056
11057
11058
11059
11060
11061
11062
11063
11064
11065
11066
11067
11068
11069
11070
11071
11072
11073
11074
11075
11076
11077
11078
11079
11080
11081
11082
11083
11084
11085
11086
11087
11088
11089
11090
11091
11092
11093
11094
11095
11096
11097
11098
11099
11100
11101
11102
11103
11104
11105
11106
11107
11108
11109
11110
11111
11112
11113
11114
11115
11116
11117
11118
11119
11120
11121
11122
11123
11124
11125
11126
11127
11128
11129
11130
11131
11132
11133
11134
11135
11136
11137
11138
11139
11140
11141
11142
11143
11144
11145
11146
11147
11148
11149
11150
11151
11152
11153
11154
11155
11156
11157
11158
11159
11160
11161
11162
11163
11164
11165
11166
11167
11168
11169
11170
11171
11172
11173
11174
11175
11176
11177
11178
11179
11180
11181
11182
11183
11184
11185
11186
11187
11188
11189
11190
11191
11192
11193
11194
11195
11196
11197
11198
11199
11200
11201
11202
11203
11204
11205
11206
11207
11208
11209
11210
11211
11212
11213
11214
11215
11216
11217
11218
11219
11220
11221
11222
11223
11224
11225
11226
11227
11228
11229
11230
11231
11232
11233
11234
11235
11236
11237
11238
11239
11240
11241
11242
11243
11244
11245
11246
11247
11248
11249
11250
11251
11252
11253
11254
11255
11256
11257
11258
11259
11260
11261
11262
11263
11264
11265
11266
11267
11268
11269
11270
11271
11272
11273
11274
11275
11276
11277
11278
11279 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<link rel="stylesheet" href="./pgpool.css" type="text/css">
<title>pgpool-II ユーザマニュアル</title>
</head>
<body>
<!-- hhmts start -->
Last modified: Tue Aug 13 08:28:45 JST 2013
<!-- hhmts end -->
<body bgcolor="#ffffff">
<div id="top" class="header_text">Welcome to pgpool -II page</div>
<div id="menu">
<div id="navcontainer">
<ul id="navlist">
<li id="active"><a href="#Whatis" id="current">pgpool-IIとは</a></li>
<li><a href="#license">ライセンス</a></li>
<li><a href="#platform">pgpool-IIの稼働環境</a></li>
<li><a href="#install">pgpool-IIのインストール</a></li>
<li><a href="#config">pgpool-IIの設定</a></li>
<li><a href="#common">共通設定項目</a></li>
<li><a href="#connection_pool_mode">コネクションプールモード</a></li>
<li><a href="#replication_mode">レプリケーションモード</a></li>
<li><a href="#master_slave_mode">マスタースレーブモード</a></li>
<li><a href="#stream">Streaming Replicationへの対応</a></li>
<li><a href="#parallel">パラレルモード</a></li>
<li><a href="#hba">クライアント認証(HBA)のための pool_hba.conf 設定方法</a></li>
<li><a href="#query_cache">クエリキャッシュの設定方法</a></li>
<li><a href="#memqcache">オンメモリクエリキャッシュの設定方法</a></li>
<li><a href="#start">pgpool-IIの起動と停止</a></li>
<li><a href="#reload">pgpool-IIの設定ファイルの再読み込み</a></li>
<li><a href="#show-commands">SHOWコマンド</a></li>
<li><a href="#online-recovery">オンラインリカバリ</a></li>
<li><a href="#backup">バックアップ</a></li>
<li><a href="#deploy">pgpool-IIの配置について</a></li>
<li><a href="#watchdog">watchdog</a></li>
<li><a href="#pcp_command">PCP コマンド</a></li>
<li><a href="#troubleshooting">トラブルシューティング</a></li>
<li><a href="#restriction">制限事項</a></li>
<li><a href="#internal">内部情報</a></li>
<li><a href="#release">リリースノート</a></li>
</ul>
</div>
<div class="header_small" align="center">
[<a href="pgpool-en.html">English page</a>]
</div>
</div>
<div id="manual">
<!-- ================================================================================ -->
<h1 style="margin-top: 20px">pgpool-IIとは<a name="whatis"></a></h1>
<p>
pgpool-IIはPostgreSQL専用のミドルウェアで、PostgreSQLのデータベースクライアントと
PostgreSQLサーバの間に割り込む形で動作し、PostgrSQLに以下のような機能を追加します。
</p>
<ul>
<li>コネクションプーリング
<p>
PostgreSQLへの接続を保存しておき、同じ属性(ユーザ名、データベース、プロトコルバージョン)を持つ接続を
受け付けたときに再利用することによって
PostgreSQLへの接続オーバヘッドを低減し、システム全体のスループットを向上することができます。
</p>
</li>
<li>レプリケーション
<p>
pgpool-IIは複数のPostgreSQLサーバを管理することができます。レプリケーション機能を使用することにより、
物理的に2台以上のDBサーバにリアルタイムでデータを保存することができ、
万が一どれかのDBサーバに障害が発生しても運用を継続することができます。
</p>
</li>
<li>負荷分散
<p>
レプリケーションまたマスタースレーブモードで運用している場合、どのサーバに問い合わせても同じ結果が返ってきます。
多数の検索リクエストをそれぞれのサーバで分担して負荷を軽減させ、システム全体の性能を向上させることができます。
最良の場合にはサーバ台数に比例した性能向上が見込めます。
</p>
<p>
特に多数のユーザが大量の問い合わせを投げるような環境で威力を発揮します。
</p>
</li>
<li>接続数の制限
<p>
PostgreSQLに接続可能なセッション数には上限があり、それを超えて接続することはできません。
かと言って、同時セッション数をむやみに多くすると、メモリーなどのリソースが多く消費されて
パフォーマンスに影響があります。
</p>
<p>
pgpool-IIでもクライアントからの接続数には上限がありますが、それを超えてもただちにエラーになることはなく、
一定の間待たされるようになっています。
したがって、pgpool-IIはPostgreSQLへの接続要求を実質的にキューイングし、
PostgreSQLへの過大な接続数を制限することが可能です。
</p>
</li>
<li>パラレルクエリ
<p>
複数のサーバにデータを分割して受け持たせ、それぞれのサーバに同時に検索問い合わせを投げて、
問い合わせの処理時間を短縮するパラレルクエリが利用できます。
特に大規模なデータベースに対して検索を実行するときに威力を発揮します。
</p>
</li>
</ul>
<p>
pgpool-IIはPostgreSQLバックエンドとフロントエンドの通信プロトコルを理解してその間を中継します。
すなわち、PostgreSQLのデータベースアプリケーションからはPostgreSQLサーバに、
PostgreSQLからはデータベースアプリケーションに見えるように設計されています。
</p>
<p>
そのため、PostgreSQLそのものはもちろん、アプリケーションの開発言語によらず、
PostgreSQLのデータベースアプリケーションにほとんど手を加えることなく、
pgpool-IIの機能が利用できます。
</p>
<p><strong>一部のSQLには<a href="#restriction">制限事項</a>があります。</strong></p>
<p class="top_link"><a href="#Top">back to top</a></p>
<!-- ================================================================================ -->
<h1>License<a name="license"></a></h1>
<p>Copyright (c) 2003-2013 PgPool Global Development Group</p>
<p><br></p>
<p>
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both that copyright notice and this permission
notice appear in supporting documentation, and that the name of the
author not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission. The author makes no representations about the
suitability of this software for any purpose. It is provided "as
is" without express or implied warranty.
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1>pgpool-II の稼働環境<a name="platform"></a></h1>
<p>pgpool-II は、Linux をはじめ、Solaris や FreeBSD などのほとんどの UNIX 環境で動作します。
Windows では動きません。</p>
<p>
対応する PostgreSQL のバージョンは、PostgreSQL の 6.4 以降です。
ただしパラレルクエリモードを使用するときは PostgreSQL 7.4 以降をお使いください。
また、PostgreSQL 7.4 より前のバージョンでは、使用できる機能に制限事項があります。
もっとも、そのような古いバージョンの PostgreSQL はそもそも使うべきではありません。
</p>
<p>
pgpool-II 配下で利用する PostgreSQL サーバのメジャーバージョン、
OS やハードウェアアーキテクチャを同じものにしなければなりません。
また、バージョンが同じであっても、PostgreSQL のビルド方法が違うものを混ぜている場合の動作は保証できません。
たとえば、SSL サポートの有無、日付型の実装方法 (--disable-integer-datetimes)、
ブロックサイズの違いなどは、pgpool-II の一部の機能に影響を与えるでしょう。
PostgreSQL のマイナーバージョンが違う場合は大抵の場合問題になりませんが、
すべての PostgreSQL のマイナーバージョンを検証したわけではないので、
できればマイナーバージョンを合わせておくことをお勧めします。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1>pgpool-II のインストール<a name="install"></a></h1>
<p>
Linux 用の RPM パッケージは、CentOS、RedHat Enterprise Linux、Fedora、Debian 用などが提供されています。
該当リポジトリをチェックしてみてください。
</p>
<p>
pgpool-II のソースコードは <a href="http://pgpool.net/mediawiki/index.php/Downloads">pgpool 開発ページ</a> から
ダウンロードできます。
</p>
<p>pgpool-II のソースコードからのインストールには、gcc 2.9 以上、および GNU make が必要です。
また、pgpool-II は libpq（PostgreSQL 付属のクライアントライブラリ）を使用するので、
ビルドを行うマシン上に libpq がインストールされていることが必要です。</p>
<p>また、OpenSSL サポートを有効にする場合は、OpenSSL ライブラリと開発用のヘッダーファイルが必要です。</p>
<h2 id="install_pgpool">pgpool-II のインストール</h2>
<dl>
<dt>configureの実行</dt>
<dd>
<p>ソースコードのtar ballを展開したら、configureを実行します。</p>
<pre>
./configure
</pre>
<p>configureに指定できるオプションは以下です。</p>
<table border>
<tr><th class="nodec"><code>--prefix=path</code></th>
<td>pgpool-II 本体や関連ファイルをインストールするトップディレクトリを指定します。
デフォルトは /usr/local です。
</td></tr>
<tr><th class="nodec"><code>--with-pgsql=path</code></th>
<td>PostgreSQL のクライアントライブラリなどがインストールされているトップディレクトリを指定します。
デフォルトは<code>pg_config</code>コマンドで取得できるパスです。
</td></tr>
<tr><th class="nodec"><code>--with-openssl</code></th>
<td>pgpool-II を OpenSSL サポート付で作成します。
デフォルトでは OpenSSL サポートは無効です。
<span class="version">V2.3 〜</span>
</td></tr>
<tr><th class="nodec"><code>--enable-sequence-lock</code></th>
<td>pgpool-II 3.0シリーズ (3.0.4まで) 互換の insert_lock を使用します。
pgpool-II は、シーケンステーブルの行に対してロックを行います。
これは、2011 年 06 月より後にリリースされた PostgreSQL 8.2 以降では使用できません。
<span class="version">V3.1 〜</span>
</td></tr>
<tr><th class="nodec"><code>--enable-table-lock</code></th>
<td>pgpool-II 2.2 と 2.3 シリーズ互換の insert_lock を使用します。
pgpool-II は、挿入対象のテーブルに対してロックを行ないます。
これは、ロックが VACUUM と競合するため非推奨です。
<span class="version">V3.1 〜</span>
</td></tr>
<tr><th class="nodec"><code>--with-memcached=path</code>
</th>
<td>キャッシュストレージに <a href="memcached_params">memcached</a> を利用し、
<a href="#memqcache">オンメモリクエリキャッシュ</a>機能を
利用したい場合に指定します。
<a href="http://libmemcached.org/libMemcached.html">libMemcached</a>のインストールが必要です。
<span class="version">V3.2 〜</span>
</td></tr>
</table>
</dd>
<dt>makeの実行</dt>
<dd>
<pre>
make
make install
</pre>
</dd>
</dl>
<h2 id="install_functions">関数の登録</h2>
<h3 id="pgpool_regclass">pgpool_regclass のインストール（推奨） <span class="version">V3.0 〜</span></h3>
<p>PostgreSQL 8.0 以降を使用している場合は、pgpool-II が内部で使用する C 関数
pgpool_regclass をインストールします。</p>
<h4>pgpool_regclass とは？</h4>
<p>
この関数がインストールされていなくても pgpool-II は動作しますが、違うスキーマで同じテーブル名を定義していて、
SQL 文の中でスキーマ名を省略している場合に、不具合が生じることがあります（一時テーブルを除く）。
したがって、可能ならば pgpool_regclass をインストールすることをお勧めします。
</p>
<h4>関数のインストール</h4>
<p>このインストールは、pgpool-II がアクセスする予定のすべての PostgreSQL サーバで実施してください。</p>
<pre>
$ cd pgpool-II-x.x.x/sql/pgpool-regclass
$ make
$ make install
</pre>
<p>この後に以下か、</p>
<pre>
$ psql -f pgpool-regclass.sql template1
</pre>
<p>または</p>
<pre>
$ psql template1
=# CREATE EXTENSION pgpool_regclass;
</pre>
<p>を実行します。</p>
<h4>備考</h4>
<p>
pgpool-regclass.sql または <code>CREATE EXTENSION</code> の実行は、
pgpool-II 経由で利用するデータベース毎に必要になります。
ただし、template1 データベースに対して "<code>psql -f pgpool-regclass.sql template1</code>" または
<code>CREATE EXTENSION</code> を実行後に作成されたデータベースでは、
新たに pgpool-regclass.sql または <code>CREATE EXTENSION</code> を実行する必要はありません。
</p>
<h3 id="insert_lock_table">insert_lock テーブルの作成 <span class="version">V3.0 〜</span></h3>
<h4>レプリケーションモードでの insert_lock</h4>
<p>
レプリケーションモードで insert_lock を利用したい場合は、排他制御用のテーブル
pgpool_catalog.insert_lock を作成します。
</p>
<p>
insert_lock テーブルが存在しなくても今のところ insert_lock は動作しますが、
その場合は、挿入対象のテーブルに対してロックが行われます。
これは pgpool-II 2.2 と 2.3 シリーズの動作と同じです。挿入対象のテーブルに対するロックは、
VACUUM と競合して INSERT 処理が長時間が待たされる可能性があります。
</p>
<p>
したがって、insert_lock テーブルを作成することをお勧めします。
テーブルの作成は、pgpool-II がアクセスする予定のすべての PostgreSQL サーバで実施してください。
</p>
<h4>テーブルの作成</h4>
<pre>
$ cd pgpool-II-x.x.x/sql
$ psql -f insert_lock.sql template1
</pre>
<h4>備考</h4>
<p>
insert_lock.sqlの実行は、pgpool-II経由で利用するデータベース毎に必要になります。
ただし、"<code>psql -f insert_lock.sql template1</code>" を実行後に作成されたデータベースでは
自動的に insert_lock.sql の内容が反映されているので、新たに insert_lock.sql を実行する必要はありません。
</p>
<h3 id="pgpool_recovery">pgpool_recovery のインストール</h3>
<p>後述の <a href="#online_recovery_in_stream_mode">オンラインリカバリ</a> の機能を使う場合には、
pgpool_recovery, pgpool_remote_start, pgpool_switch_xlog という関数が必要です。</p>
<p>また管理ツールである pgpoolAdmin の画面上から、バックエンドノードの PostgreSQL を停止・再起動・
設定再読み込みを行なうことができますが、これには pgpool_pgctl という関数が使われます。</p>
<p>これらの機能を使いたい場合には、上記の pgpool_regclass と同様の手順でこれらの C 関数を登録します。
なお、この 4 つの関数は、すべてのデータベースにインストールされている必要はなく、template1 にだけで
構いません。</p>
<pre>
$ cd pgpool-II-x.x.x/sql/pgpool-recovery
$ make
$ make install
</pre>
<p>この後に以下か、</p>
<pre>
$ psql -f pgpool-recovery.sql template1
</pre>
<p>または</p>
<pre>
$ psql template1
=# CREATE EXTENSION pgpool_recovery;
</pre>
<p>を実行します。</p>
<h4 id="pgpool_pgctl">pgpool.pg_ctl の設定 <span class="version">V3.3 〜</span></h4>
<p>pgpool_pgctl 関数は、バックエンドノードの PostgreSQL の 「pgpool.pg_ctl」という
カスタムパラメータに書かれたコマンドを実行します。
この関数を使うには、このパラメータに pg_ctl コマンドのパスを指定します。</p>
<pre>
ex)
$ cat >> /usr/local/pgsql/postgresql.conf
pgpool.pg_ctl = '/usr/local/pgsql/bin/pg_ctl'
$ pg_ctl reload -D /usr/local/pgsql/data
</pre>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1>pgpool-IIの設定<a name="config"></a></h1>
<p>
pgpool-IIの設定ファイルはデフォルトでは/usr/local/etc/pgpool.confおよび
/usr/local/etc/pcp.confです。pgpool-IIは動作モードによって使用できる機能と、
必要な設定項目が異なります。
</p>
<table border>
<tr class="header">
<th>使用できる機能/モード</th><th>rawモード(*3)</th><th>レプリケーションモード</th>
<th>マスタスレーブモード</th><th>パラレルクエリモード</th>
</tr>
<tr>
<th>コネクションプーリング</th><td align="center">×</td><td align="center">○</td>
<td align="center">○</td><td align="center">○</td>
</tr>
<tr>
<th>レプリケーション</th><td align="center">×</td><td align="center">○</td>
<td align="center">×</td><td align="center">△(*1)</td>
</tr>
<tr>
<th>負荷分散</th><td align="center">×</td><td align="center">○</td>
<td align="center">○</td><td align="center">△(*1)</td>
</tr>
<tr>
<th>フェイルオーバ</th><td align="center">○</td><td align="center">○</td>
<td align="center">○</td><td align="center">×</td>
</tr>
<tr>
<th>オンラインリカバリ</th><td align="center">×</td><td align="center">○</td>
<td align="center">△(*2)</td><td align="center">×</td>
</tr>
<tr>
<th>パラレルクエリ</th><td align="center">×</td><td align="center">×</td>
<td align="center">×</td><td align="center">○</td>
</tr>
<tr>
<th>サーバ台数</th><td align="center">1以上</td><td align="center">2以上</td>
<td align="center">2以上</td><td align="center">2以上</td>
</tr>
<tr>
<th>システムDB</th><td align="center">不要</td><td align="center">不要</td>
<td align="center">不要</td><td align="center">必要</td>
</tr>
</table>
<ul>
<li>(*1)パラレルクエリモードでは、レプリケーションまたは負荷分散を有効にする必要があります。
ただし、分割して保存しているテーブルに対しては、レプリケーションならびに負荷分散の機能は使用されません。
</li>
<li>(*2)マスタースレーブモードでは、Streaming Replicationと併用するときにのみ
オンラインリカバリが可能です。
</li>
<li>(*3)単にpgpool-IIを経由して接続するだけのモードです。
レプリケーションモードもマスタースレーブモードも有効にしていないときの動作です。
PostgreSQLサーバへの接続セッション数を制限したり、2台以上のPostgreSQLサーバを用意して
フェイルオーバ動作をさせたいときに利用します。
</li>
</ul>
<!-- ================================================================================ -->
<h1 id="pcp_conf">pcp.confの設定</h1>
<p>
どの動作モードでも、pcp.confの設定は必要です。pgpool-IIには管理者がpgpool-IIの
停止や情報取得などの管理操作を行うためのインターフェイスが用意されています。
そのインターフェイスを利用するためにはユーザ認証が必要になるので、
そのユーザ名とパスワードをpcp.confに登録します。
pgpool-IIをインストールすると、$prefix/etc/pcp.conf.sampleができるので、それを
$prefix/etc/pcp.confという名前でコピーします。
</p>
<pre>
cp $prefix/etc/pcp.conf.sample $prefix/etc/pcp.conf
</pre>
<p>
pcp.confでは空白行や#で始まる行はコメントと見なされます。
ユーザとパスワードは、
</p>
<pre>
ユーザ名:[md5暗号化したパスワード]
</pre>
<p>
のように指定します。
[md5暗号化したパスワード]は、$prefix/bin/pg_md5コマンドで作成できます。
</p>
<pre>
./pg_md5 foo
acbd18db4cc2f85cedef654fccc4a4d8
</pre>
<p>
パスワードを引数に渡したくない場合は pg_md5 -p を実行してください。
</p>
<pre>
./pg_md5 -p
password: <パスワードを入力>
</pre>
<p>
pcp.confは、pgpool-IIを動作させるユーザIDで読み取り可能になっていなければ
なりません。
</p>
<!-- ================================================================================ -->
<h1 id="pgpool_conf">pgpool.confの設定</h1>
<h2 id="pgpool_conf_sample">サンプルファイル <span class="version">V2.3 〜</span></h2>
<p>
pgpool-IIをインストールすると、インストール先ディレクトリ(デフォルトでは/usr/local)
/etc/pgpool.conf.sampleができるので、それを
インストール先ディレクトリ/etc/pgpool.confという名前でコピーします。
</p>
<pre>
cp インストール先ディレクトリ/etc/pgpool.conf.sample $prefix/etc/pgpool.conf
</pre>
<p>
また、各動作モード用のサンプルpgpool.confが用意されています。
こちらもご利用下さい。
</p>
<p>
<table border>
<tr class="header"><th>動作モード</th><th>サンプルファイル名</th></tr>
<tr><th>レプリケーションモード</th><td>pgpool.conf.sample-replication</td></tr>
<tr><th>マスタースレーブモード(Slony-I)</th><td>pgpool.conf.sample-master-slave</td></tr>
<tr><th>マスタースレーブモード(Streaming replication)</th><td>pgpool.conf.sample-stream</td></tr>
</table>
</p>
<h2>コメントの扱い</h2>
<p>
pgpool.confでは空白行や#で始まる行はコメントと見なされます。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="common"></a>共通設定項目</h1>
<p>
各動作モードで共通する設定項目を説明します。
</p>
<h3>Connections</h3>
<dl>
<dt><a name="LISTEN_ADDRESS"></a>listen_addresses</dt>
<dd>
<p>
pgpool-IIがTCP/IPコネクションを受け付けるアドレスをホスト名またはIPアドレスで指定します。
「*」を指定するとすべてのIPインタフェースからのコネクションを受け付けます。
「''」を指定するとTCP/IPコネクションを受け付けません。デフォルト値は「localhost」です。
UNIXドメインソケット経由のコネクションは常に受け付けます。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="PORT"></a>port</dt>
<dd>
<p>
pgpool-IIがコネクションを受け付けるポート番号です。デフォルト値は9999
です。
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="SOCKET_DIR"></a>socket_dir</dt>
<dd>
<p>
pgpool-IIがコネクションを受け付けるUNIXドメインソケットを置くディレクトリです。
デフォルト値は'/tmp'です。
このソケットは、cronによって削除されることがあるので注意してください。
<code>'/var/run'</code>などのディレクトリに変更することをお勧めします。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="PCP_PORT"></a>pcp_port</dt>
<dd>
<p>
pcpが使用するポート番号です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="PCP_SOCKET_DIR"></a>pcp_socket_dir</dt>
<dd>
<p>
pcpがコネクションを受け付けるUNIXドメインソケットを置くディレクトリです。
デフォルト値は'/tmp'です。
このソケットは、cronによって削除されることがあるので注意してください。
<code>'/var/run'</code>などのディレクトリに変更することをお勧めします。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="BACKEND_SOCKET_DIR"></a>backend_socket_dir <span class="version">〜 V3.0</span></dt>
<dd>
<p class="version_notice">
<em class="caution">DEPRECATED（〜 3.0）</em>
このパラメータは、libpqのポリシーに合わせて削除されます。
代わりに <a href=#BACKEND_HOSTNAME">backend_hostname</a> パラメータを使ってください。
</p>
<p>
UNIXドメインソケット経由でpgpool-IIがPostgreSQLと接続する際に使用する
PostgreSQLのUNIXドメインソケットが置かれているディレクトリです。デフォルト値は/tmpです。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h3>Pools</h3>
<dl>
<dt><a name="NUM_INIT_CHILDREN"></a>num_init_children</dt>
<dd>
<p>
preforkするpgpool-IIのサーバプロセスの数です。デフォルト値は32になっています。
これが、pgpool-IIに対してクライアントが同時に接続できる上限の数になります。
これを超えた場合は、そのクライアントは、pgpool-IIのどれからのプロセスへのフロントエンドの接続が終了するまで
待たされます(PostgreSQLと違ってエラーになりません)。
待たされる数の上限は、2 * num_init_children です。
</p>
<p>
基本的に後述のmax_pool * num_init_children分だけPostgreSQLへのコネクションが張られますが、
他に以下の考慮が必要です。
</p>
<ul>
<li>問い合わせのキャンセルを行うと通常のコネクションとは別に新たなコネクションが張られます。
したがって、すべてのコネクションが使用中の場合は問い合わせのキャンセルができなくなってしまうので、
ご注意下さい。
問い合わせのキャンセルを必ず保証したい場合は、想定されるコネクション数の倍の値を
設定することをおすすめします。
</li>
<li>一般ユーザでPostgreSQLに接続できるのは、
max_connections - superuser_reserved_connections 分だけです。
</li>
</ul>
<p>
以上をまとめると、
</p>
<table border>
<tr><th>クエリのキャンセルを考慮しない場合</th>
<td>max_pool * num_init_children <=<br>
(max_connections - superuser_reserved_connections)</td></tr>
<tr><th>クエリのキャンセルを考慮する場合</th>
<td>max_pool * num_init_children * 2 <=<br>
(max_connections - superuser_reserved_connections)</td></tr>
</table>
<p>
のどちらかを満たすように設定してください。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="CHILD_LIFE_TIME"></a>child_life_time</dt>
<dd>
<p>
pgpool-IIの子プロセスの寿命です。アイドル状態になってから
child_life_time秒経過すると、一旦終了して新しいプロセスを起動します。
メモリーリークその他の障害に備えた予防措置です。
child_life_timeのデフォルト値は300秒、すなわち5分です。
0を指定するとこの機能は働きません（すなわち起動しっ放し）。
なお、まだ一度もコネクションを受け付けていないプロセスにはchild_life_timeは適用されません。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="CHILD_MAX_CONNECTIONS"></a>child_max_connections</dt>
<dd>
<p>
各pgpool-II子プロセスへの接続回数がこの設定値を超えると、その子プロセスを終了します。
<a href="#CHILD_LIFE_TIME">child_life_time</a> や <a href="#CONNECTION_LIFE_TIME">connection_life_time</a>が
効かないくらい忙しいサーバで、
PostgreSQLバックエンドが肥大化するのを防ぐのに有効です。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="CLIENT_IDLE_LIMIT"></a>client_idle_limit</dt>
<dd>
<p>
前回クライアントから来たクエリから、client_idle_limit 秒越えても次の
クエリが届かない場合は、クライアントへの接続を強制的に切断し、
クライアントからの次のコネクションを待つようにします。
この設定は、だらしないクライアントプログラムや、クライアントとpgpoolの間の
TCP/IPコネクションが不調なことによって、
pgpoolの子プロセスが占有されてしまう問題を回避するのに役立ちます。
デフォルト値は 0(無効)です。このパラメータは、オンラインリカバリのセカンドステージでは無視されます。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="ENABLE_POOL_HBA"></a>enable_pool_hba</dt>
<dd>
<p>
trueならば、pool_hba.confに従ってクライアント認証を行います。
詳細は<a href="#hba">クライアント認証(HBA)のためのpool_hba.conf設定方法</a>を参照してください。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="POOL_PASSWD"></a>pool_passwd</dt>
<dd>
<p>
md5 認証で用いる認証ファイルのファイル名を指定します。
デフォルト値は "pool_passwd" です。
空文字列（""）を指定すると 認証ファイルの読込は無効になります。
詳細は<a href="#md5">認証・アクセス制御方式</a>を参照してください。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="AUTHENTICATION_TIMEOUT"></a>authentication_timeout</dt>
<dd>
<p>
認証処理のタイムアウト時間を秒単位で指定します。0 を指定するとタイムアウトを無効にします。
authentication_timeout のデフォルト値は60です。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
</dl>
<h3>Logs</h3>
<dl>
<dt><a name="LOG_DESTINATION"></a>log_destination <span class="version">V3.1 〜</span></dt>
<dd>
<p>
pgpool-IIは、stderrかsyslogのどちらかにログを書くことができます。デフォルトはstderrです。
</p>
<p>
注意:syslogを使う場合は、syslogデーモンの設定を変更する必要があります。
</p>
<p>
pgpool-IIは、syslog ファシリティ LOCAL0 から LOCAL7 までにログを書くことができます
(syslog_facilityをご覧ください)。
しかし、ほとんどのデフォルトのsyslog設定は、そのようなメッセージを廃棄してしまいます。
そこで、syslogデーモンの以下のような設定が必要になります。
</p>
<pre>
local0.* /var/log/pgpool.log
</pre>
</dd>
<dt><a name="PRINT_TIMESTAMP"></a>print_timestamp</dt>
<dd>
<p>
trueならばpgpool-IIのログにタイムスタンプを追加します。デフォルトはtrueです。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="LOG_CONNECTIONS"></a>log_connections</dt>
<dd>
<p>
trueならば、全てのクライアント接続をログへ出力します。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="LOG_HOSTNAME"></a>log_hostname</dt>
<dd>
<p>
trueならば、psコマンドでの状態表示時にIPアドレスではなく、ホスト名を表示します。
また、<a href="#LOG_CONNECTIONS">log_connections</a>が有効な場合にはログにホスト名を出力します。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
<dt><a name="LOG_STATEMENT"></a>log_statement</dt>
<dd>
<p>
trueならばSQL文をログ出力します。この役目はPostgreSQLのlog_statementオプションと似ていて、
デバッグオプションがないときでも問い合わせをログ出力して調べることができるので便利です。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="LOG_PER_NODE_STATEMENT"></a>log_per_node_statement <span class="version">V2.3 〜</span></dt>
<dd>
<p>
<a href="#LOG_STATEMENT">log_statement</a>と似ていますが、DBノード単位でログが出力されるので、
レプリケーションや負荷分散の確認が容易です。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="SYSLOG_FACILITY"></a>syslog_facility <span class="version">V3.1 〜</span></dt>
<dd>
<p>
syslogが有効な場合、このパラメータによってsyslogの「ファシリティ」を設定します。
LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7から選択します。
デフォルトは LOCAL0 です。
併せてsyslogデーモンのドキュメントもご覧ください。
</p>
</dd>
<dt><a name="SYSLOG_IDENT"></a>syslog_ident <span class="version">V3.1 〜</span></dt>
<dd>
<p>
syslogが有効な場合、このパラメータによってsyslogのメッセージにあらわれるプログラム名を設定します。
デフォルトは"pgpool"です。
</p>
</dd>
<dt><a name="DEBUG_LEVEL"></a>debug_level <span class="version">V3.0 〜</span></dt>
<dd>
<p>
デバッグメッセージの詳細レベル。0でデバッグメッセージの出力なし。
1以上でデバッグメッセージを出力します。
数字が大きければより詳細なメッセージが出力されるようになります
(3.0では今のところメッセージの詳細度は変りません)。
デフォルト値は0です。
</p>
</dd>
</dl>
<h3>File locations</h3>
<dl>
<dt><a name="PID_FILE_NAME"></a>pid_file_name <span class="version">V2.2 〜</span></dt>
<dd>
<p>
pgpool-IIのpid file(プロセスIDを格納したファイル)のフルパス名です。
デフォルト値は'/var/run/pgpool/pgpool.pid'です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="LOGDIR"></a>logdir</dt>
<dd>
<p>
このディレクトリ下に、pgpool-IIのDBノードの状態を記録するpgpool_statusファイルが書かれます。
</p>
</dd>
</dl>
<h3>Connction pooling</h3>
<dl>
<dt><a name="CONNECTION_CACHE"></a>connection_cache</dt>
<dd>
<p>
trueならPostgreSQLへのコネクションをキャッシュします。デフォルトはtrueです。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h3>Health check</h3>
<dl>
<dt><a name="HEALTH_CHECK_TIMEOUT"></a>health_check_timeout</dt>
<dd>
<p>
pgpool-IIはサーバ障害やネットワーク障害を検知するために、定期的にバックエンドに接続を試みます。
これを「ヘルスチェック」と言います。障害が検知されると、フェイルオーバや縮退運転を試みます。
</p>
<p>
この パラメータは、ネットワークケーブルが抜けた際などにヘルスチェックが長時間待たされるのを防ぐための
タイムアウト値を秒単位で指定します。
デフォルトは20秒です。0を指定するとタイムアウト処理をしません
(すなわち TCP/IP のタイムアウトまで待つことになります)。
</p>
<p>
なお、ヘルスチェックを有効にすると、ヘルスチェックのための余分の接続が1つ必要になりますので、
PostgreSQLのpostgresql.confの設定項目のmax_connectionsを少くとも1増やすようにしてください。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="HEALTH_CHECK_PERIOD"></a>health_check_period</dt>
<dd>
<p>
ヘルスチェックを行う間隔を秒単位で指定します。0を指定するとヘルスチェックを行いません。
デフォルトは0です(つまりヘルスチェックを行いません)。
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="HEALTH_CHECK_USER"></a>health_check_user</dt>
<dd>
<p>
ヘルスチェックを行うためのPostgreSQLユーザ名です。
このユーザ名はPostgreSQLに登録済みでなければなりません。
さもないと、ヘルスチェックがエラーとなります。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="HEALTH_CHECK_PASSWORD"></a>health_check_password <span class="version">V3.1 〜</span></dt>
<dd>
<p>
ヘルスチェックを行うためのPostgreSQLパスワードです。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="HEALTH_CHECK_MAX_RETRIES"></a>health_check_max_retries <span class="version">V3.2 〜</span></dt>
<dd>
<p>
ヘルスチェックに失敗した後(したがってフェイルオーバする前に)リトライする回数を指定します。
この設定は動作にむらのあるネットワーク環境において、マスタが正常であるにも関わらず
たまにヘルスチェックが失敗することが予想される場合に有用です。
デフォルト値は0で、この場合はリトライをしません。
この設定を有効にする場合は、併せて<a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a>を
offにすることをお勧めします。
</p>
<p>
health_check_max_retriesを変更した場合は、pgpool.confの再読込が必要です。
</p>
</dd>
<dt><a name="HEALTH_CHECK_RETRY_DELAY"></a>health_check_retry_delay <span class="version">V3.2 〜</span></dt>
<dd>
<p>
ヘルスチェックのリトライの間の秒数を指定します(health_check_max_retries > 0でなければ有効になりません)。
0を指定すると、待ちなしに直ちにリトライします。
</p>
<p>
<a href="#HEALTH_CHECK_RETRY_DELAY">health_check_retry_delay</a>を変更した場合は、pgpool.confの再読込が必要です。
</p>
</dd>
<dt><a name="SEARCH_PRIMARY_NODE_TIMEOUT"></a>search_primary_node_timeout <span class="version">V3.3 -</span></dt>
<dd>
<p>このパラメータはフェイルオーバーが起きた時にプライマリノードを検索する際のタイムアウト時間を秒単位で指定します。
デフォルト値は10です。
pgpool-IIは、フェイルオーバの際にここで指定した時間プライマリノードを検索し続けます。
0を指定すると、永久に検索し続けます。
このパラメータはストリーミングレプリケーションモードで運用している場合以外は無視されます。
</p>
<p>
search_primary_node_timeoutを変更した場合は、pgpool.confの再読込が必要です。
</p>
</dd>
</dl>
<h3>Failover and failback</h3>
<dl>
<dt><a name="FAILOVER_COMMAND"></a>failover_command</dt>
<dd>
<p>
ノードが切り離された時に実行するコマンドを指定します。特殊文字を指定すると、
pgpool が必要な情報に置き換えてコマンドを実行します。
</p>
<center>
<table border>
<tr class="header"><th>文字</th><th>意味</th></tr>
<tr><td>%d</td><td>切り離されたノード番号</td></tr>
<tr><td>%h</td><td>切り離されたノードのホスト名</td></tr>
<tr><td>%H</td><td>新しいマスターのホスト名</td></tr>
<tr><td>%p</td><td>切り離されたノードのポート番号</td></tr>
<tr><td>%D</td><td>切り離されたノードのデータベースクラスタパス</td></tr>
<tr><td>%M</td><td>古いマスターのノード番号</td></tr>
<tr><td>%m</td><td>新しいマスターのノード番号</td></tr>
<tr><td>%P</td><td>古いプライマリノード番号</td></tr>
<tr><td>%r</td><td>新しいマスターのポート番号</td></tr>
<tr><td>%R</td><td>新しいマスターのデータベースクラスタパス</td></tr>
<tr><td>%%</td><td>'%'文字</td></tr>
</table>
</center>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
<p>
フェイルオーバー時には、pgpoolはまず子プロセスを切断します(結果として、すべてのセッションが切断されます)。
次に、pgpoolはフェイルオーバコマンドを実行し、その完了を待ちます。
そのあとで新しいpgpoolの子プロセスが起動され、クライアントからの接続を受け付けられる状態になります。
</p>
</dd>
<dt><a name="FAILBACK_COMMAND"></a>failback_command</dt>
<dd>
<p>
ノードが復帰した時に実行するコマンドを指定します。特殊文字を指定すると、
pgpool が必要な情報に置き換えてコマンドを実行します。
</p>
<center>
<table border>
<tr class="header"><th>文字</th><th>意味</th></tr>
<tr><td>%d</td><td>復帰したノード番号</td></tr>
<tr><td>%h</td><td>復帰したノードのホスト名</td></tr>
<tr><td>%p</td><td>復帰したノードのポート番号</td></tr>
<tr><td>%D</td><td>復帰したノードのデータベースクラスタパス</td></tr>
<tr><td>%M</td><td>古いマスターのノード番号</td></tr>
<tr><td>%m</td><td>新しいマスターのノード番号</td></tr>
<tr><td>%H</td><td>新しいマスターのホスト名</td></tr>
<tr><td>%P</td><td>古いプライマリノード番号</td></tr>
<tr><td>%r</td><td>新しいマスターのポート番号</td></tr>
<tr><td>%R</td><td>新しいマスターのデータベースクラスタパス</td></tr>
<tr><td>%%</td><td>'%'文字</td></tr>
</table>
</center>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="FOLLOW_MASTER_COMMAND"></a>follow_master_command <span class="version">V3.1 〜</span></dt>
<dd>
<p>
マスターノードのフェイルオーバー後に実行するコマンドを指定します。
これは、マスタースレーブモードでストリーミングレプリケーション構成の場合のみ有効です。
特殊文字を指定すると、pgpool が必要な情報に置き換えてコマンドを実行します。
</p>
<center>
<table border>
<tr class="header"><th>文字</th><th>意味</th></tr>
<tr><td>%d</td><td>切り離されたノード番号</td></tr>
<tr><td>%h</td><td>切り離されたノードのホスト名</td></tr>
<tr><td>%p</td><td>切り離されたノードのポート番号</td></tr>
<tr><td>%D</td><td>切り離されたノードのデータベースクラスタパス</td></tr>
<tr><td>%M</td><td>古いマスターのノード番号</td></tr>
<tr><td>%m</td><td>新しいマスターのノード番号</td></tr>
<tr><td>%H</td><td>新しいマスターのホスト名</td></tr>
<tr><td>%P</td><td>古いプライマリノード番号</td></tr>
<tr><td>%r</td><td>新しいマスターのポート番号</td></tr>
<tr><td>%R</td><td>新しいマスターのデータベースクラスタパス</td></tr>
<tr><td>%%</td><td>'%'文字</td></tr>
</table>
</center>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
<p>
空文字列以外を指定すると、マスターノードのフェイルオーバー後に新しいマスター以外のすべてのノードは切り離され、
クライアントから再び接続を受け付けるために子プロセスの再起動が行われます。
その後、切り離されたそれぞれのノードに対してfollow_master_commandに指定したコマンドが実行されます。
通常は、ここに <a href="#pcp_recovery_node">pcp_recovery_node</a> コマンドを組み込んだシェルスクリプトなどを
指定し、新しいマスターからスレーブをリカバリするために使用します。
</p>
</dd>
<dt><a name="FAIL_OVER_ON_BACKEND_ERROR"></a>fail_over_on_backend_error <span class="version">V2.3 〜</span></dt>
<dd>
<p>
trueならば、バックエンドのソケットへからの読み出し、書き込みに失敗するとフェイルオーバします。
falseにすると、フェイルオーバせず、単にエラーがレポートされてセッションが切断されます。
このパラメータをfalseにする場合には、health checkを有効にすることをお勧めします。
なお、このパラメータがfalseの場合でも、バックエンドがシャットダウンされたことを
pgpool-IIが検知した場合にはフェイルオーバが起きることに注意してください。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
</dl>
<h3>Load balancing mode</h3>
<dl>
<dt><a name="IGNORE_LEADING_WHITE_SPACE"></a>ignore_leading_white_space</dt>
<dd>
<p>
trueならば、load balanceの際にSQL文行頭の空白を無視します(全角スペースは無視されません)。
これは、DBI/DBD:Pgのように、勝手に行頭にホワイトスペースを追加するようなAPIを使い、
ロードバランスしたいときに有効です。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
</dl>
<h3>Backends</h3>
<dl>
<dt><a name="BACKEND_HOSTNAME"></a>backend_hostname</dt>
<dd>
<p>
使用するPostgreSQLサーバのホスト名を指定します。
pgpool-IIは、このホスト名を使ってPostgreSQLと通信します。
</p>
<p>
TCP/IPを使用する場合、ホスト名またはIPアドレスを指定できます。
"/"で始まる文字列を指定すると、TCP/IPではなく、UNIXドメインソケットを使用され、
ディレクトリ名とみなしてそこにソケットファイルが作成されることになります。
空文字(<code>''</code>)を指定すると、<code>/tmp</code>下に作成したUNIXドメインソケットで接続します。
</p>
<p>
実際には、"backend_hostname"の後に0, 1, 2...と数字を付加して使用する複数
のPostgreSQLを区別します(たとえば<code>backend_hostname0</code>)。
この数字のことを「DBノードID」と呼び、0から開始します。
DBノードID == 0のPostgreSQLは、特別に「マスターDB」と呼ばれます。
複数のDBノードを運用している場合、条件によってはマスターDBがダウンしても運用を続けることができます。
この場合は、稼働中かつDBノードIDがもっとも若いものが新しいマスターDBになります。
</p>
<p>
ただし、ストリーミングレプリケーションモードで運用している場合は、
DBノードIDが0のノードには特別な意味はなく、プライマリノードかどうかが問題になります。
詳細は<a href="#stream">Streaming Replicationへの対応</a>をご覧ください。
<p>
1台しかPostgreSQLを使用しない場合は、"backend_hostname0"としてください。
</p>
<p>
backend_hostname は新しく追加した行を設定ファイル再読み込みで追加することができます。
すでにある情報を途中で変更することはできません。
変更する場合には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="BACKEND_PORT"></a>backend_port</dt>
<dd>
<p>
使用するPostgreSQLサーバのポート番号を指定します。
実際には、"backend_port"の後に0, 1, 2...とDBノードIDを付加して使用する複数のPostgreSQLを区別します。
1台しかPostgreSQLを使用しない場合は、"backend_port0"としてください。
</p>
<p>
backend_port は新しく追加した行を設定ファイル再読み込みで追加することができます。
すでにある情報を途中で変更することはできません。変更する場合には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="BACKEND_WEIGHT"></a>backend_weight</dt>
<dd>
<p>
使用するPostgreSQLサーバに対する負荷分散の比率を0以上の整数または浮動小数点で指定します。
"backend_weight"の後には、DBノードIDを付加して使用する複数のPostgreSQLを区別します。
1台しかPostgreSQLを使用しない場合は、"backend_weight0"としてください。
負荷分散を使用しない場合は、「1」を設定してください。
</p>
<p>
backend_weight は新しく追加した行を設定ファイル再読み込みで追加することができます。
pgpool-II 2.2.6/2.3以降では、設定ファイルの再読込でbackend_weight値を変更できます。
新しく接続したクライアントセッションから、この新しいweight値が反映されます。
マスタースレーブモードにおいて、あるスレーブに対して管理業務を実施する都合上、
問い合わせがそのスレーブに送られるのを防ぎたい場合に有用です。
</p>
</dd>
<dt><a name="BACKEND_DATA_DIRECTORY"></a>backend_data_directory</dt>
<dd>
<p>
使用する PostgreSQL サーバのデータベースクラスタのパスを指定します。
実際には、"backend_data_directory"の後にDBノードIDを付加して使用する複数のPostgreSQLを区別します。
このパラメータはオンラインリカバリの際に使用します。
オンラインリカバリを使用しない場合には設定する必要はありません。
</p>
<p>
backend_data_directory は新しく追加した行を設定ファイル再読み込みで追加することができます。
すでにある情報を途中で変更することはできません。変更する場合には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="BACKEND_FLAG"></a>backend_flag <span class="version">V3.1 〜</span></dt>
<dd>
<p>
バックエンド単位での様々な挙動を制御するフラグです。
実際には、"backend_flag"の後に数字を付けて、どのバックエンドのフラグか指定します。
</p>
<p>
例: <code>backend_flag0</code>
</p>
<p>
複数のフラグを"|"で連結して指定することができます。
現在以下のものがあります。
</p>
<table border>
<tr><th class="nodec">ALLOW_TO_FAILOVER</th>
<td>フェイルオーバやデタッチが可能になります。これがデフォルトの動作です。
DISALLOW_TO_FAILOVERと同時には指定できません。
</td></tr>
<tr><th class="nodec">DISALLOW_TO_FAILOVER</th>
<td>フェイルオーバやデタッチが行われeせん。
HeartbeatやPacemakerなどのHA(High Availability)ソフトでバックエンドを二重化しているなどの事情で、
pgpool-II側でフェイルオーバの制御をして欲しくないときなどに指定します。
ALLOW_TO_FAILOVERと同時には指定できません。
</td></tr>
</table>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h3>SSL</h3>
<dl>
<dt><a name="SSL">ssl</a> <span class="version">V2.3 〜</span></dt>
<dd>
<p>
trueならばpgpool-IIとフロントエンド、pgpool-IIとバックエンドの間のSSL接続が可能になります。
なお、pgpool-IIとフロントエンドの接続にSSLが利用できるためには、
<code>ssl_key</code>と<code>ssl_cert</code>が設定されてなければなりません。
</p>
<p>
デフォルトではSSLサポートはオフになっています。
SSLサポートを有効にするためには、configure時にOpenSSLサポートを有効にする必要があります。
詳細は<a href="#install">インストール</a>の項目をご覧下さい。
</p>
<p>
sslを有効に設定したら、pgpoolの再起動をしてください。
</p>
</dd>
<dt><a name="SSL_KEY"></a>ssl_key <span class="version">V2.3 〜</span></dt>
<dd>
<p>
フロントエンドとの接続に使用するプライベートキーファイルのフルパスを指定します。
</p>
<p>
ssl_keyのデフォルト値はありません。
ssl_keyの設定がない場合は、フロントエンドとの接続でSSLが使用されなくなります。
</p>
</dd>
<dt><a name="SSL_CERT"></a>ssl_cert <span class="version">V2.3 〜</span></dt>
<dd>
<p>
フロントエンドとの接続に使用する公開x509証明書のフルパスを指定します。
</p>
<p>
ssl_certのデフォルト値はありません。
ssl_certの設定がない場合は、フロントエンドとの接続でSSLが使用されなくなります。
</p>
</dd>
<dt><a name="SSL_CA_CERT"></a>ssl_ca_cert</dt>
<dd>
<p>
1 つ以上の CA ルート証明書を格納している PEM 形式ファイルのパスを指定します。
このファイルはバックエンドサーバ証明書の検証に用いられます。
このオプションは OpenSSL の <code>verify(1)</code> コマンドにおける <code>-CAfile</code> オプションと同様の機能を提供します。
</p>
<p>
デフォルトでは値が設定されておらず検証は行われません。
このオプションが設定されていない場合においても、<code>ssl_ca_cert_dir</code> オプション
が設定されている場合には検証が行われます。
</p>
</dd>
<dt><a name="SSL_CA_CERT_DIR"></a>ssl_ca_cert_dir</dt>
<dd>
<p>
PEM 形式の CA 証明書ファイルを格納しているディレクトリのパスを指定します。
これらのファイルはバックエンドサーバ認証の検証に用いられます。
このオプションは OpenSSL の <code>verify(1)</code> コマンドにおける <code>-CApath</code> オプションと同様の機能を提供します。
</p>
<p>
デフォルトでは値が設定されておらず検証は行われません。
このオプションが設定されていない場合においても、<code>ssl_ca_cert</code> オプション
が設定されている場合には検証が行われます。
</p>
</dd>
</dl>
<h3>Other</h3>
<dl>
<dt><a name="RELCACHE_EXPIRE"></a>relcache_expire <span class="version">V3.1 〜</span></dt>
<dd>
<p>
リレーションキャッシュの寿命を秒単位で指定します。
0を指定すると、キャッシュの寿命の管理は行わず、プロセスが生きているか、
キャッシュが溢れるまでは有効になります(デフォルトの動作)。
</p>
<p>
リレーションキャッシュは、PostgreSQLのシステムカタログに対する問い合わせを保存しておくものです。
問い合わせる内容は、テーブルの構造、テーブルが一時テーブルかどうかなどがあります。
キャッシュはpgpoolの子プロセスのローカルメモりに保管されています。
<p>
もしALTER TABLEが発行されると、テーブルの構造が変わる場合があり、
リレーションキャッシュの内容と一致しなくなる恐れがあります。
relcache_expireにより、その危険性をコントロールできるようになります。
</p>
</dd>
<dt><a name="RELCACHE_SIZE"></a>relcache_size <span class="version">V3.2 〜</span></dt>
<dd>
<p>
リレーションキャッシュのサイズを指定します。
デフォルトは256です。
</p>
<pre>
"pool_search_relcache: cache replacement happend"
</pre>
<p>
のようなメッセージがログに頻繁に出る場合は、この数字を大きくしてください。
</p>
</dd>
<dt><a name="CHECK_TEMP_TABLE"></a>check_temp_table <span class="version">V3.2 〜</span></dt>
<dd>
<p>
もしonなら、SELECTに含まれるテーブルが一時テーブルかどうかのチェックを行います。
このチェックは、primary/masterのシステムカタログへのアクセスを発生させ、それなりに負荷を上げます。
もし一時テーブルを使っていないということが確かで、primary/masterの負荷を少しでも下げたいのであれば、
offにすることができます。デフォルトはonです。
</p>
</dd>
</dl>
<h2>SSL証明書の生成</h2>
<p>
証明書の扱いについてはこのマニュアルの範囲外です。
PostgreSQLドキュメント<a href="http://www.postgresql.jp/document/pg842doc/html/ssl-tcp.html">
SSLによる安全なTCP/IP接続</a>の章に自分で認証する証明書を作成するコマンドの例があります。
</p>
<h2 id="failover_in_raw_mode">rawモードにおけるフェイルオーバ動作について</h2>
<p>
rawモードにおいて、2台以上のPostgreSQLサーバを指定すると、フェイルオーバが可能です。
フェイルオーバでは、正常時にはbackend_hostname0で指定したPostgreSQLのみを使用し、
ほかのサーバにはアクセスしません。
backend_hostname0のサーバがダウンすると、次にbackend_hostname1で指定したサーバにアクセスをこころみ、
成功すればそれを使用します。以下、backend_hostname2...でも同様になります。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="connection_pool_mode"></a>コネクションプールモード</h1>
<p>
rawモードに加え、コネクションプーリングが利用できるようになります。
コネクションプールモードを有効にするには、 <a href="#CONNECTION_CACHE">connection_cache</a> をonにします。
以下の設定項目がコネクションプールの動作に影響を与えます。
</p>
<dl>
<dt><a name="MOtherAX_POOL"></a>max_pool</dt>
<dd>
<p>
pgpool-IIの各サーバプロセスがキープするPostgreSQLへの最大コネクション数です。
pgpool-IIは、ユーザ名、データベースが同じならばコネクションを再利用しますが、
そうでなければ新たにPostgreSQLへのコネクションを確立しようとします。
したがって、ここでは想定される[ユーザ名:データベース名]のペアの種類の数だけを
max_poolに指定しておく必要があります。
もしmax_poolを使いきってしまった場合は一番古いコネクションを切断し、
そのスロットが再利用されます。
</p>
<p>
max_poolのデフォルト値は4です。
</p>
<p>
なお、pgpool-II全体としては、<a href="#NUM_INIT_CHILDREN">num_init_children</a> *
<a href="#MAX_POOL">max_pool</a> 分だけ
PostgreSQLへのコネクションが張られる点に注意してください。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="CONNECTION_LIFE_TIME"></a>connection_life_time</dt>
<dd>
<p>
コネクションプール中のコネクションの有効期間を秒単位で指定します。
0を指定すると有効期間は無限になります。
connection_life_timeのデフォルト値は0です。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="RESET_QUERY_LIST"></a>reset_query_list</dt>
<dd>
<p>
セッションが終了するときにコネクションを初期化するためのSQLコマンドを「;」で区切って列挙します。
デフォルトは以下のようになっていますが、任意のSQL文を追加しても構いません。
<pre>
reset_query_list = 'ABORT; DISCARD ALL'
</pre>
<p>
PostgreSQLのバージョンによって使用できるSQLコマンドが違います。
各バージョンごとのお勧め設定は以下です(ただし、"ABORT"は必ずコマンドに含めてください)。
</p>
<table border>
<tr class="header"><th>PostgreSQLバージョン</th><th>reset_query_listの推奨設定値</th></tr>
<tr><th>7.1以前</th><td>ABORT</td></tr>
<tr><th>7.2から8.2</th><td>ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT</td></tr>
<tr><th>8.3以降</th><td>ABORT; DISCARD ALL</td></tr>
</table>
<ul>
<li>「ABORT」は、PostgreSQL 7.4以上ではトランザクションブロックの中にいない場合には発行されません。</li>
</ul>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
</dl>
<h2 id="failover_in_cp_mode">コネクションプールモードにおけるフェイルオーバ動作について</h2>
<p>
rawモードと同様の動作をします。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="replication_mode"></a>レプリケーションモード</h1>
<p>
レプリケーションを有効にするモードです(設定ファイルの雛形はpgpool.conf-replication)。
rawモード、コネクションプールモードに加え、以下を設定します。
</p>
<dl>
<dt><a name="REPLICATION_MODE"></a>replication_mode</dt>
<dd>
<p>
レプリケーションモードで動作させる場合はtrueを指定してください。デフォルト値はfalseです。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="LOAD_BALANCE_MODE"></a>load_balance_mode</dt>
<dd>
<p>
trueを指定するとレプリケーションモードまたはマスタースレーブモードの際に、
SELECT文をロードバランスして検索性能を向上させることができます。デフォルト値はfalseです。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="REPLICATION_STOP_ON_MISMATCH"></a>replication_stop_on_mismatch</dt>
<dd>
<p>
各DBノードから送られてくるパケットの種類が不一致になった場合に、DBノードを切り放して縮退運転に入ります。
</p>
<p>
良くあるケースとしては、<a href="#REPLICATE_SELECT">replicate_select</a> が指定されていて
SELECTが各DBノードで実行されているときに、
検索結果行数が一致しないなど、があります(これに限定されるものではありません。
たとえばあるDBノードでUPDATEが成功したのに、他のDBノードでは失敗した場合が一例です)。
ただし、pgpoolはパケットの中身まではチェックしていないので、SELECT結果のデータ内容が異なっていても、
縮退は起きないことに注意してください。
</p>
<p>
縮退対象のDBノードは「多数決」で少数派になったものが対象になります。
もし多数決で同票になった場合は、マスタDBノード(DBノード番号がもっともわかいもの)を含むグループが優先され、
それ以外のグループに所属するDBノードが切り放しの対象になります。
</p>
<p>
このオプションがfalseの場合は、該当のセッションを強制的に終了するだけに留めます。
デフォルト値はfalseです。
</p>
<dt><a name="FAILOVER_IF_AFFECTED_TUPLES_MISMATCH"></a>failover_if_affected_tuples_mismatch <span class="version">V3.0 〜</span></dt>
<dd>
<p>
各DBノードで実行されたINSERT/UPDATE/DELETEの結果行数が不一致になった場合に、
DBノードを切り放して縮退運転に入ります。
</p>
<p>
縮退対象のDBノードは「多数決」で少数派になったものが対象になります。
もし多数決で同票になった場合は、マスタDBノード(DBノード番号がもっともわかいもの)を含むグループが優先され、
それ以外のグループに所属するDBノードが切り放しの対象になります。
</p>
<p>
このオプションがfalseの場合は、該当のセッションを強制的に終了するだけに留めます。
デフォルト値はfalseです。
</p>
</dd>
<dt><a name="WHITE_FUNCTION_LIST"></a>white_function_list <span class="version">V3.0 〜</span></dt>
<dd>
<p>
データベースに対して<strong>更新を行なわない関数名</strong>をコンマ区切りで指定します。
このリストに含まれない関数呼び出しを含むSELECTは、負荷分散の対象とはならず、
レプリケーションモードにおいてはすべてのDBノードで実行されます。
(マスタースレーブモードにおいては、マスター(primary)DBノードにのみ送信されます)。
</p>
<p>
関数名には正規表現を使うことができます。指定した各表現に ^ と $ をつけた形で使われます。
たとえば、読み出しのみの関数が"get_"あるいは"select_"で始まるならば、以下のような指定が可能です。
</p>
<pre>
white_function_list = 'get_.*,select_.*'
</pre>
</dd>
<dt><a name="BLACK_FUNCTION_LIST"></a>black_function_list <span class="version">V3.0 〜</span></dt>
<dd>
<p>
データベースに対して<strong>更新を行なう関数名</strong>をコンマ区切りで指定します。
このリストに含まれる関数呼び出しを含むSELECTは、負荷分散の対象とはならず、
レプリケーションモードにおいてはすべてのDBノードで実行されます。
このリストに含まれない関数呼び出しを含むSELECTは、負荷分散の対象となります。
</p>
<p>
関数名には正規表現を使うことができます。指定した各表現に ^ と $ をつけた形で使われます。
たとえば、読み出しのみの関数が"set_"、"update_"、"delete_"あるいは"insert_"で始まるならば、
以下のような指定が可能です。
</p>
<pre>
black_function_list = 'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'
</pre>
<p>
white_function_listとblack_function_listの両方を空以外にすることはできません。
どちらか一方のみに関数名を指定します。
</p>
<p>
pgpool-II 3.0より前のバージョンでは、固定でnextvalとsetvalが書き込みを行なう関数として認識されていました。
それと同じ動作を行なわせるには、以下のようにwhite_function_listとblack_function_listを指定します。
</p>
<pre>
white_function_list = ''
black_function_list = 'nextval,setval,lastval,currval'
</pre>
<p>
上の例では、nextvalとsetvalに加え、lastvalとcurrvalが追加されていることに注意してください。
lastvalとcurrvalは書き込みを行う関数ではありませんが、これらの関数が負荷分散されることによって、
エラーが発生するのを未然に防ぐことができます。
black_function_listに含まれる関数は負荷分散されないからです。
</p>
</dd>
<dt><a name="REPLICATE_SELECT"></a>replicate_select</dt>
<dd>
<p>
true を設定すると、レプリケーションモードでは SELECT 文をレプリケーションします。
これは pgpool-II 1.0 までの挙動と同じになります。
false を設定すると SELECT 文をマスタのみに送信します。デフォルト値は false です。
</p>
<p>
replicate_select、<a href="#LOAD_BALANCE_MODE">load_balance_mode</a>、
SELECT問合わせが明示的なトランザクションブロックの内側にあるかどうかどうかで、
レプリケーションモードの動作が変化します。詳細を表に示します。
</p>
<table border>
<tr>
<th class="nodec">SELECTが明示的なトランザクションブロックの内側にある</th>
<td>Y</td><td>Y</td><td>Y</td><td>N</td><td>N</td><td>N</td><td>Y</td><td>N</td>
</tr>
<tr>
<th class="nodec">replicate_selectがtrue</th>
<td>Y</td>
<td>Y</td>
<td>N</td>
<td>N</td>
<td>Y</td>
<td>Y</td>
<td>N</td>
<td>N</td>
</tr>
<tr>
<th class="nodec">load_balance_modeがtrue</th>
<td>Y</td><td>N</td><td>N</td><td>N</td><td>Y</td><td>N</td><td>Y</td><td>Y</td>
</tr>
<tr>
<th class="nodec">結果(R:レプリケーション, M: マスタのみに送信, L: ロードバランスされる)</th>
<td>R</td><td>R</td><td>M</td><td>M</td><td>R</td><td>R</td><td>M</td><td>L</td>
</tr>
</table>
</dd>
<dt><a name="INSERT_LOCK"></a>insert_lock</dt>
<dd>
<p>
SERIAL型を使っているテーブルをレプリケーションすると、SERIAL型の列の値がDBノードの間で
一致しなくなることがあります。
この問題は、該当テーブルを明示的にロックすることで回避できます
(もちろんトランザクションの並列実行性は犠牲になりますが)。
しかし、そのためには、
</p>
<pre>
INSERT INTO ...
</pre>
<p>
を
</p>
<pre>
BEGIN;
LOCK TABLE ...
INSERT INTO ...
COMMIT;
</pre>
<p>
に書き換えなければなりません。
insert_lockをtrueにすると自動的にトランザクションの開始、テーブルロック、トランザクションの終了を
行ってくれるので、こうした手間を省くことができます
（すでにトランザクションが開始されている場合はLOCK TABLE...だけが実行されます）。
</p>
<dl>
<dt>pgpool-II 2.2以降</dt>
<dd><p>
テーブルがSERIAL列を持つかどうか自動判別するため、
SERIAL列がなければ決してテーブルをロックしません。
</p></dd>
<dt>pgpool-II 3.0.4までの3.0シリーズ</dt>
<dd><p>
対応するシーケンステーブルに対して行ロックをかけることで排他制御を行ないます。
それ以前のバージョンと比べると、VACUUM(autovacuumを含む)とのロック競合がなくなるメリットがあります。
</p>
<p>
しかし、これは他の問題を引き起こします。
トランザクション周回が起きた後、シーケンステーブルに対する行ロックはPostgreSQLの内部エラー
(詳細には、トランザクション状態を保持するpg_clogへのアクセスエラー)を起こします。
これを防ぐため、PostgreSQLのコア開発者はシーケンステーブルに対する行ロックを許可しないことを決定しました。
これはもちろんpgpool-IIを動作不能にします(修正されたPostgreSQLはバージョン
9.0.5, 8.4.9, 8.3.16そして8.2.22としてリリースされるでしょう)。
</p></dd>
<dt>pgpool-II 3.0.5以降</dt>
<dd><p>
新しいPostgreSQLがシーケンステーブルに対するロックを許可しなくなったため、
pgpool_catalog.insert_lockテーブルに対して行ロックをかけることで排他制御を行ないます。
したがって、pgpool-II経由でアクセスするすべてのデータベースにinsert_lockテーブルを
あらかじめ作成しておく必要があります。
詳細は<a href="#install">insert_lockテーブルの作成</a>の項目をご覧ください。
</p>
<p>
もし、insert_lockテーブルが存在しない場合は、挿入対象のテーブルに対してロックを行います。
これは、pgpool-II 2.2と2.3シリーズのinsert_lockと同じ動作です。
また、過去のバージョンと互換性のあるinsert_lockを使用したい場合は、configureスクリプトで設定できます。
詳細は<a href="#install">configureの実行</a>の項目をご覧下さい。
</dd></p>
</dl>
<p>
なお、あまり必要ないかも知れませんが、コメントを利用して、この挙動を細かく制御することもできます。
</p>
<ol>
<li>insert_lockをtrueにして、INSERT文の先頭に/*NO INSERT LOCK*/コメントを追加する。
このコメントがあると、テーブルロックは行われません(pgpool-II 3.0以降でも同様)。
</li>
<li>insert_lockをfalseにして、INSERT文の先頭に/*INSERT LOCK*/コメントを追加する。
このコメントがあると、このINSERT文に対してのみテーブルロックが行われます(pgpool-II 3.0以降でも同様)。
</li>
</ol>
<p>
insert_lockのデフォルト値はtrueです。
</p>
<p>
なお、insert_lockを有効にしてregression testを実行すると、少くともPostgreSQL 8.0では
transactions, privileges, rules, alter_tableがfailします。
ruleでは、viewに対してLOCKをしようとしてしまうこと、ほかのものは
</p>
<pre>
! ERROR: current transaction is aborted, commands ignored until end of transaction block
</pre>
<p>
というようなメッセージが出てしまうためです。たとえば、transactions では、
存在しないテーブルに対してINSERTを行うテストが含まれており、
pgpoolが最初に存在しないテーブルに対してLOCKを行う結果、エラーになってトランザクションがアボート状態になり、
続くINSERTで上記エラーが出てしまいます。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="RECOVERY_USER"></a>recovery_user</dt>
<dd>
<p>
オンラインリカバリを行うための PostgreSQL ユーザ名です。
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="RECOVERY_PASSWORD"></a>recovery_password</dt>
<dd>
<p>
オンラインリカバリを行うための PostgreSQL ユーザパスワードです。
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="RECOVERY_1ST_STAGE_COMMAND"></a>recovery_1st_stage_command</dt>
<dd>
<p>
オンラインリカバリ中に起動するコマンド名を指定します。
このスクリプトはPostgreSQLのマスタサーバ(プライマリサーバ)が起動します。
コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にある
コマンドやスクリプトのみを呼び出します。
例えば、recovery_1st_stage_command = 'sync-command' と設定してある場合、
$PGDATA/sync-command を起動しようとします。
</p>
<p>
recovery_1st_stage_command は次の3つの引数を受けとります。
</p>
<ol>
<li>マスタ(プライマリ)データベースクラスタへのパス</li>
<li>リカバリ対象のPostgreSQLのホスト名</li>
<li>リカバリ対象のデータベースクラスタへのパス</li>
</ol>
<p>
recovery_1st_stage_command を実行している間は pgpool ではクライアン
トからの接続を<b>制限しません</b>。参照や更新を行うことができます。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="RECOVERY_2ND_STAGE_COMMAND"></a>recovery_2nd_stage_command</dt>
<dd>
<p>
2 回目のオンラインリカバリ中に起動するコマンド名を指定します。
このスクリプトはPostgreSQLのマスタサーバ(プライマリサーバ)が起動します。
コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にある
コマンドやスクリプトのみを呼び出します。
例えば、recovery_2nd_stage_command = 'sync-command' と設定してある場合、
$PGDATA/sync-command を起動しようとします。
</p>
<p>
recovery_2nd_stage_command は次の3つの引数を受けとります。
</p>
<ol>
<li>マスタ(プライマリ)データベースクラスタへのパス</li>
<li>リカバリ対象のPostgreSQLのホスト名</li>
<li>リカバリ対象のデータベースクラスタへのパス</li>
</ol>
</p>
<p>
recovery_2nd_stage_command を実行している間は pgpool ではクライアントから
接続、参照、更新処理を一切<b>受け付けません</b>。
また、バッチ処理などによって接続しているクライアントが長時間存在している場合にはコマンドを起動しません。
新たな接続を制限し、現在の接続数が 0 になった時点
でコマンドを起動します。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="RECOVERY_TIMEOUT"></a>recovery_timeout</dt>
<dd>
<p>
pgpoolは、オンラインリカバリの際にすべてのクライアントが接続を終了するまで待ちます。
recovery_timeoutでその最大待ち時間を指定します。単位は秒です。
待ち時間がrecovery_timeoutを越えると、オンラインリカバリは中止され、通常の状態に戻ります。
</p>
<p>
アイドル状態のクライアントが自分から切断するのを待ちたくない場合は、
<a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a>を利用することもできます。
</p>
</p>
<p>
recovery_timeoutは、この他、オンラインリカバリの最後にリカバリ対象のDBノードで
postmasterを起動する際の待ち時間にも利用されます。
</p>
<p>
recovery_timeoutのデフォルト値は90秒です。
recovery_timeoutを0としてもタイムアウトが無効になるわけではなく、
単に即座にタイムアウトするだけですので注意してください。
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="CLIENT_IDLE_LIMIT_IN_RECOVERY"></a>client_idle_limit_in_recovery <span class="version">V2.2 〜</span></dt>
<dd>
<p>
client_idle_limitと似ていますが、このパラメータはリカバリのセカンドステージでのみ効力があります。
前回クライアントから来たクエリから、client_idle_limit_in_recovery 秒越えても次のクエリが届かない場合は、
クライアントへの接続を強制的に切断し、リカバリのセカンドステージの進行が妨害されるのを防ぎます。
-1を指定すると、直ちにクライアントへの接続を切断してセカンドステージに入ります。
デフォルト値は 0(無効)です。
</p>
<p>
クライアントが忙しく、アイドル状態にならない場合はclient_idle_limit_in_recoveryを設定しても
セカンドステージに移行できません。
この場合、client_idle_limit_in_recoveryに-1を設定すると、クライアントがビジーであっても
ただちにクライアントへの接続を切断し、セカンドステージに移行することができます。
</p>
<p>
このパラメータを変更した時には設定ファイルを再読み込みしてください。
</p>
</dd>
<dt><a name="LOBJ_LOCK_TABLE"></a>lobj_lock_table <span class="version">V2.3 〜</span></dt>
<dd>
<p>
ラージオブジェクトのレプリケーションを行いたいときにロック管理に使うためのテーブル名を指定します。
このテーブルが指定されていて、ラージオブジェクトの作成要求がクライアントから送信され、
かつその要求の中にラージオブジェクトのIDの明示的な指定が含まれていない場合
(つまり、lo_creatでラージオブジェクトを作成する場合)、
pgpool-IIは、排他制御のためにこのテーブルをロックした後、
ラージオブジェクトを格納するシステムカタログpg_largeobjectのラージオブジェクトに格納されている
IDの最大値を取りだし、その値+1のIDを使ってlo_create()を呼び出してラージオブジェクトの作成を行います
(lo_create()を持たないバージョン8.1より前のPostgreSQLではこの処理は行われません)。
この方法により、すべてのDBノードで同じIDを持つラージオブジェクトが作成されることが保証されます。
</p>
<p>
このような処理の対象となるラージオブジェクトの操作は、PostgreSQLのC言語用のAPI(libpq)で言うと、lo_creat()です。
2010年2月時点の我々の調査では、以下の言語のラージオブジェクト作成APIは、すべてlo_creat()を呼び出すか、
またはlo_creat()と同じ通信プロトコルを使っているので、pgpool-IIの上記の操作の対象になり、
ラージオブジェクトのレプリケーションが安全に行われるようになります。
</p>
<ul>
<li>Java(JDBCドライバ)</li>
<li>PHP(pg_lo_create関数、またはPDOなどの該当API)</li>
<li>psqlから\lo_importを呼び出す場合</li>
</ul>
<p>
上記以外であっても、ラージオブジェクトの作成APIで
ラージオブジェクトのIDを引数として渡すようになっていないものは
間違いなくlo_creat()を使っており、pgpool-IIの上記の操作の対象になると考えて良いでしょう。
</p>
<p>
pgpool-IIの上記処理の対象とならないようなラージオブジェクトの作成処理は以下のものです。
</p>
<ul>
<li>libpqのlo_create()を使用している</li>
<li>C言語以外のAPIで、lo_create()を使用しているもの</li>
<li>バックエンド関数のlo_importをSELECTで呼び出す場合</li>
<li>バックエンド関数のlo_creatをSELECTで呼び出す場合</li>
</ul>
<p>
lobj_lock_tableで指定するテーブルはどのような定義のものでも構いませんが、
あらかじめ作成済でかつすべてのユーザが書き込み可能でなければなりません。
そのようなテーブルを作る例を示します。
</p>
<pre>
CREATE TABLE public.my_lock_table ();
GRANT ALL ON public.my_lock_table TO PUBLIC;
</pre>
<p>
この操作はpgpool-II経由で接続するすべてのデータベースに対して、あらかじめ実施しておかなければなりません。
しかし、この操作をtemplate1データベースに対して一度行っておけば、
以後作成されるデータベースにはこのテーブルが含まれるようになるので、管理の手間が省けます。
</p>
<p>
lobj_lock_tableに指定するテーブル名が空文字の場合は、ラージオブジェクトに関する上記の処理は行いません
(したがって、ラージオブジェクトのレプリケーションは保証されません)。
lobj_lock_tableのデフォルト値は空文字です。
</p>
</dd>
</dl>
<h2 id="condition_for_load_balance">ロードバランスの条件について</h2>
<p>
load_balance_mode = true を設定した場合、以下の条件のすべてを満たした時に
SELECTなどの問い合わせがロードバランスされます。
</p>
<ul>
<li>PostgreSQLのバージョンが7.4以降である</li>
<li>レプリケーションモードまたはマスタースレーブモードである</li>
<li>問い合わせが明示的なトランクザションブロックの内側にない(つまり、BEGINを発行していない)</li>
<li>SELECT文(WITH付も含む。<a href="#BLACK_FUNCTION_LIST">black_list</a> または
<a href="#WHITE_FUNCTION_LIST">white_list</a> で指定された書き込みを含むSELECTを除く)
またはCOPY TO STDOUT, EXPLAIN, EXPLAIN ANALYZE SELECT... のいずれかである</li>
<li>SELECT INTO 文ではない</li>
<li>SELECT FOR UPDATE/SELECT FOR SHARE文ではない</li>
<li>クエリ文字列が SELECTまたはWITH で始まる(ignore_leading_white_space = trueの場合は空白は無視します)</li>
<li>マスタースレーブモードの場合、更に以下の条件が満たされなければなりません。<span class="version">V3.0 -</span></li>
<ul>
<li>一時テーブルを使っていない</li>
<li>unloggedテーブルを使っていない</li>
<li>システムカタログを使っていない</li>
<li>トランザクションブロックの内側であっても上記条件と下記条件を満たせばロードバランスされます。</li>
<ul>
<li>トランザクション分離レベルがSERIALIZABLEでない</li>
<li>トランザクション内で更新を伴うクエリが実行されていない(更新を伴うクエリが実行されるまではロードバランスされます)</li>
</ul>
</ul>
</ul>
<p>
(<a href="#replicate_select">replicate_selectの項目</a>も参考にしてください)
また、<a href="where_to_send_queries.pdf">詳細な判定条件をフローチャートにしたもの</a>もご覧下さい。
</p>
<p>
なお、
</p>
<pre>
/*REPLICATION*/ SELECT ...
</pre>
<p>
とすることによって、本来負荷分散されたり、マスタのみに送信されるべき問合わせが
すべてのバックエンドに送信される（レプリケーションされる）ようになります。
副作用がある関数を含む問合わせに対してはこのテクニックが利用できます。
</p>
<p>
<font color="red">
注意: JDBC ドライバなどのように、ドライバ内で autocommit の有効・無効のオプションがある場合、
autocommit を無効にすると、ドライバが内部で BEGIN コマンドを実行する関係上、
正しくロードバランスされない可能性があります。
クエリをロードバランスさせたい場合は autocommit を有効にしてください。
たとえばJDBCであれば setAutoCommit(true) を実行してください。
</font>
</p>
<h2 id="detach_in_replication_mode">レプリケーションモードにおける縮退運転について</h2>
<p>
PostgreSQLサーバのうち、1台がダウンすると、そのサーバを切り離して縮退運転に入ります。
1台でもサーバが生き残っていれば、システムとしての運用を継続できます。
</p>
<h2 id="errors_in_replication_mode">レプリケーションモード固有のエラーについて</h2>
<p>
レプリケーションモードにおいて、pgpoolはレプリケーション時に INSERT、UPDATE、DELETE の更新件数が
すべてのノードが同じでない場合、
<a href="#FAILOVER_IF_AFFECTED_TUPLES_MISMATCH">failover_if_affected_tuples_mismatch</a> が falseならば、
意図的に構文エラーを起すSQLを送信することによって、トランザクションをアボートさせます。
trueならば、フェイルオーバが起きます。その際、以下のようなエラーメッセージが表示されます。
</p>
<pre>
=# UPDATE t SET a = a + 1;
ERROR: pgpool detected difference of the number of update tuples Possible last query was: "update t1 set i = 1;"
HINT: check data consistency between master and other db node
</pre>
<p>
ログには更に以下のように、更新行数が記録されます(この場合はDBノード0が0行、DBノード1が1行)。
</p>
<pre>
2010-07-22 13:23:25 LOG: pid 5490: SimpleForwardToFrontend: Number of affected tuples are: 0 1
2010-07-22 13:23:25 LOG: pid 5490: ReadyForQuery: Degenerate backends: 1
2010-07-22 13:23:25 LOG: pid 5490: ReadyForQuery: Number of affected tuples are: 0 1
</pre>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="master_slave_mode"></a>マスタースレーブモード</h1>
<p>
master/slaveモードは、Slony-IやStreaming Replicationのような、
master/slave式のレプリケーションソフトにレプリケーションをまかせるモードです。
このモードで使うためには、レプリケーションモードと同じように、
DBノードのホスト情報(<a href="#BACKEND_HOSTNAME">backend_hostname</a>,
<a href="#BACKEND_PORT">backend_port</a>, <a href="#BACKEND_WEIGHT">backend_weight</a>,
<a href="#BACKEND_FLAG">backend_flag</a> それにオンラインリカバリが必要ならば
<a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a>)をセットし、
<a href="#MASTER_SLAVE_MODE">master_slave_mode</a>と<a href="LOAD_BALANCE_MODE">load_balance_mode</a>をtrueにします。
</p>
<p>
pgpool-IIは、レプリケーションされる必要のある問い合わせはマスターに送り、
その他の問い合わせを可能ならば負荷分散します。問い合わせによってマスターDBだけに問い合わせが送られる場合と、
DBノードの間でロードバランスされて問い合わせが送られる場合があります。
</p>
<p>
マスタスレーブモードでは、一時テーブルの作成、更新、検索はマスタノードでのみ実行されます。
SELECTをマスタだけで実行するように強制することができます。
このためには、/*NO LOAD BALANCE*/ コメントをSELECTに前に挿入しなければなりません。
</p>
<p>
マスタースレーブモードでは、pgpool.confのreplication_modeをfalseに、
<a href="#MASTER_SLAVE_MODE">master_slave_mode</a> をtrueにします(同時にtrueにはできません)。
また、'<a href="#MASTER_SLAVE_SUB_MODE">master_slave_sub_mode</a>'を指定します。
これは、'slony'(デフォルト)か、'stream'です。
</p>
<p>
'slony'はSlony-Iを利用する時に指定します。
'stream'は、PostgreSQL組み込みのStreaming Replicationを利用するときに指定します。
</p>
<p>
Slony-Iを使う場合の設定ファイルの雛形はpgpool.conf.sample-master-slaveです。
Streaming Replicationを使う場合の雛形はpgpool.conf.sample-streamです。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
<p>
マスタースレーブモードでも、DB書き込みを行なう関数の呼び出しを含むSELECTを負荷分散の対象から外す指定を
<a href="#white_function_list">white_function_list</a>と
<a href="#black_function_list">black_function_list</a>で行なうことができます。
詳細は<a href="#white_function_list">white_function_list</a>の項をご覧下さい。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="stream"></a>Streaming Replicationへの対応 <span class="version">V3.1 〜</span></h1>
<p>
前述のように、マスタスレーブモードで、'<a href="#MASTER_SLAVE_SUB_MODE">master_slave_sub mode</a>'に
'stream'を指定すると、PostgreSQL 9.0から利用可能になったStreaming Replicationに対応します
(pgpool-IIでは、今のところ、Streaming ReplicationとHot Standbyを併用することを前提にしています)。
このモードでは、以下の設定項目も利用できます。
<dl id="params_for_stream_mode">
<dt id="DELAY_THRESHOLD">delay_threshold <span class="version">V3.0 〜</span></dt>
<dd>
<p>
スタンバイサーバへのレプリケーションの遅延許容度をバイト単位で指定します。
pgpool-IIは、スタンバイサーバの遅延がこの値を超えた場合には、
負荷分散が有効であってもそのDBノードにSELECTを送信せず、プライマリサーバに送るようにします。
delay_thresholdが0の場合は、遅延のチェックを行ないません。
また、delay_thresholdが指定されていても、<a href="#SR_CHECK_PERIOD">sr_check_period</a>が無効(=0)ならば、
やはりこの機能は働きません。
デフォルト値は0です。
</p>
<p>
このパラメータは設定ファイルの再読込によって変更できます。
</p>
</li>
<dt id="SR_CHECK_PERIOD">sr_check_period <span class="version">V3.1 〜</span></dt>
<dd>
<p>
ストリーミングレプリケーションの遅延チェックの間隔を秒単位で指定します。
デフォルト値は0で、これはチェックを行わないことを意味します。
</p>
<p>
このパラメータは設定ファイルの再読込によって変更できます。
</p>
</dd>
<dt id="SR_CHECK_USER">sr_check_user <span class="version">V3.1 〜</span></dt>
<dd>
<p>
ストリーミングレプリケーションの遅延チェックを行うユーザ名を指定します。
このユーザは、すべてのバックエンドに存在しなければなりません。
さもなければエラーになります。
sr_check_userとsr_check_passwordは、sr_check_periodが0であっても
指定が必要です。pgpool-IIは、どのサーバがprimaryサーバであるのかを調べるために、
PostgreSQLバックエンドに関数呼び出しのリクエストを送ります。
そのセッションでsr_check_userとsr_check_passwordが使われるからです。
</p>
<p>
このパラメータは設定ファイルの再読込によって変更できます。
</p>
</dd>
<dt id="SR_CHECK_PASSWORD">sr_check_password <span class="version">V3.1 〜</span></dt>
<dd>
<p>
ストリーミングレプリケーションの遅延チェックを行うユーザに対するパスワードをを指定します。
パスワードが必要なければ空文字('')を指定します。
</p>
<p>
このパラメータは設定ファイルの再読込によって変更できます。
</p>
</dd>
<dt id="LOG_STANDBY_DELAY">log_standby_delay <span class="version">V3.0 〜</span></dt>
<dd>
<p>
レプリケーションの遅延状況をログする条件を指定します。
'none'を指定すると、ログを出力しません。
'always'ならヘルスチェックを実行するたびに必ず出力します。
'if_over_threshold'を指定すると、<a href="#DELAY_THRESHOLD">delay_threshold</a>を超えたときだけ
ログが出力されます。
デフォルト値は'none'です。
</p>
<p>
このパラメータは設定ファイルの再読込によって変更できます。
</p>
<p>
なお、レプリケーションの遅延状況は <a href="#pool_status">show pool_status</a> コマンドでも確認できます。
項目名は"standby_delay#"です(#はDBノードIDです)。
</p>
</dd>
</dl>
<h2 id="failover_in_stream_mode">Streaming Replicationでのフェイルオーバ</h2>
<p>
Streaming replicationを利用したマスタスレーブモードでは、PrimaryやStandbyノードが停止した場合に、
レプリケーションモードと同じように自動フェイルオーバを行なわせることができます。
特に何も設定しなくても、停止したノードを自動的に切り放すことができますが、Streaming replicationでは、
「トリガファイル」を作成することにより、Standbyノードを、リカバリモードから更新問い合わせを受け付ける
通常のPostgreSQLの動作モードに自動変更することができます。
これを利用して、フェイルオーバコマンドを併用して、Primaryノードがダウンしたときに、
Standbyノードが自動的にとって代るような設定を行なうことができます。
</p>
<p>
<strong>注意: 複数のStandbyノードを利用している場合、この設定を行なうときは、
<a href="#DELAY_THRESHOLD">delay_threshold</a>を設定して、
他のStandbyに振り分けられたSELECTが古いデータを取得しないようにしておくことをお勧めします。
また、1台目のStandbyノードがPrimaryにとって代ったのちにダウンしてしまったケースで、
2台目のStandbyが更に取って代わるとデータに不整合がおきるので、そのような設定は行なわないようにしてください。</strong>
</p>
<p>
フェイルオーバの設定手順を示します。
</p>
<p>
<ol>
<li>フェイルオーバ用のスクリプトを適当な場所(ここでは/usr/local/pgsql/bin)に配置して、実行権限を与えておきます。
<pre>
$ cd /usr/loca/pgsql/bin
$ cat failover_stream.sh
#! /bin/sh
# Failover command for streming replication.
# This script assumes that DB node 0 is primary, and 1 is standby.
#
# If standby goes down, does nothing. If primary goes down, create a
# trigger file so that standby take over primary node.
#
# Arguments: $1: failed node id. $2: new master hostname. $3: path to
# trigger file.
failed_node=$1
new_master=$2
trigger_file=$3
# Do nothing if standby goes down.
if [ $failed_node = 1 ]; then
exit 0;
fi
# Create trigger file.
/usr/bin/ssh -T $new_master /bin/touch $trigger_file
exit 0;
chmod 755 failover_stream.sh
</pre>
</li>
<li>pgpool.confの、<a href="#FAILBACK_COMMAND">failover_commmand</a>を設定します。
<pre>
failover_command = '/usr/local/src/pgsql/9.0-beta/bin/failover_stream.sh %d %H /tmp/trigger_file0'
</pre>
</li>
<li>standbyノードのrecovery.confを設定します。
<a href="recovery.conf.sample">recovery.confのサンプル</a>は PostgreSQLのインストールディレクトリ下の
"share/recovery.conf.sample"にあります。
これをstanndbyノードのデータベースクラスタ下に"recovery.conf"としてコピーしておきます。
そして、以下の項目を設定します。
<pre>
standby_mode = 'on'
primary_conninfo = 'host=primary_hostのホスト名 user=postgres'
trigger_file = '/tmp/trigger_file0'
</pre>
</li>
<li>primaryノードのpostgresql.confを設定します。
以下は例ですので、必ず実際に合わせて調整してください。
<pre>
wal_level = hot_standby
max_wal_senders = 1
</pre>
</li>
<li>primaryノードのpg_hba.confを設定します。
以下は例ですので、必ず実際に合わせて調整してください。
<pre>
host replication postgres 192.168.0.10/32 trust
</pre>
</li>
</ol>
<p>
primaryとstandbyのPostgreSQLを起動すれば、Streaming replicationが開始されます。
そして、primaryノードがダウンしたときに、自動的にstandbyノードが通常のPostgreSQLとして立ち上がり、
更新問い合わせを受け付けるようになります。
</p>
<h2 id="load_balance_in_stream_mode">Streaming Replicationでのクエリ振り分け</h2>
<p>
Streaming replicationとHot Standbyを利用している環境では、primaryノードに送ってよい問い合わせ、
standbyに送ってもよい問い合わせ、両方に送らなければならない問い合わせを厳密に管理する必要があります。
pgpool-IIのStreaming Replicationモードは、こうした振り分けを自動的に行ないます。
ここでは、そのロジックについて説明します。
</p>
<p>
まず、問い合わせの種類によって以下のように分けられます。
</p>
<ul>
<li>Primaryノードにしか送られない問い合わせ
<ul>
<li>INSERT, UPDATE, DELETE, COPY FROM, TRUNCATE, CREATE, DROP, ALTER, COMMENT</li>
<li>SELECT ... FOR SHARE | UPDATE</li>
<li>トランザクションの分離レベルがシリアライザブルの場合のSELECT</li>
<li>ROW EXCLUSIVE MODEよりも強いLOCK</li>
<li>トランザクションコマンドの一部
<ul>
<li>BEGIN READ WRITE, START TRANSACTION READ WRITE
<li>SET TRANSACTION READ WRITE, SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE
<li>SET transaction_read_only = off
</ul>
</li>
<li>二相コミット関連のコマンド。PREPARE TRANSACTION, COMMIT PREPARED, ROLLBACK PREPARED</li>
<li>LISTEN, UNLISTEN, NOTIFY</li>
<li>VACUUM</li>
<li>シーケンス関連の関数(nextvalやsetvalなど)の呼び出し。</li>
<li>ラージオブジェクトの生成</li>
</ul>
</li>
<li>Primary/Standbyどちらにも送ることのできる問い合わせ。
<p>
負荷分散設定が有効ならば、standbyノードにも送信されます。
ただし、レプリケーションの遅延上限(delay_threshold)が設定されていて、
レプリケーションの遅延が<a href="#DELAY_THRESHOLD">delay_threshold</a>を上回っている場合は
問い合わせはPrimaryに送られます。
</p>
<ul>
<li>上記以外のSELECT</li>
<li>COPY TO</li>
<li>DECLARE, FETCH, CLOSE</li>
<li>SHOW</li>
</ul>
</li>
<li>Primary/Standbyどちらにも送られる問い合わせ
<ul>
<li>SET</li>
<li>DISCARD</li>
<li>DEALLOCATE ALL</li>
</ul>
</li>
</ul>
<p>
明示的なトランザクションでは、以下のようになります。
</p>
<ul>
<li>BEGINなどのトランザクション開始コマンドは、Primaryサーバに送られます。</li>
<li>続くSELECTなど、Primary/Standbyどちらにも送ることのできる問い合わせは、
Primaryのトランザクション内でそのまま実行されるか、Standbyサーバで実行されます。</li>
<li>
INSERTなど、Standbyに送ることのできない問い合わせが現われた場合は、Primaryサーバで実行されます。
以後、SELECTなど、本来Standbyに送信しても構わないコマンドもPrimaryサーバで実行されます。
これは、トランザクションの中で実行されたINSERTなどの問い合わせの結果を
SELECTが直ちに参照できるようにするためです。
この状態は、トランザクションが閉じるか、アボートするまで続きます。
</li>
</ul>
<p>
問い合わせが、拡張問い合わせモードで実行される場合は、問い合わせのparse段階で、
問い合わせが負荷分散可能かどうかで送信先が決まります。
その際の判断ルールは、通常のSQLと同じです。
たとえば問い合わせがINSERTならば、Primaryサーバで実行される、という具合です。
parseに続くbind, describe, executeも同じDBノードで実行されます。
</p>
<p>
[注: SELECTが負荷分散されて Standby ノードで parseが実行されてから更新クエリが来た場合は、
そのSELECTはPrimaryノードで実行されなければなりません。
そのため、同じSELECTが再度Primaryノードでパースされることになります。]
</p>
<p>
最後に、pgpool-IIのパーサが構文エラーと判断した問い合わせはPrimaryノードだけに送られます。
</p>
<h2 id="online_recovery_in_stream_mode">Streaming Replicationでのオンラインリカバリ</h2>
<p>
Streaming replicationを利用したマスタスレーブモードでは、
レプリケーションモードと同じようにオンラインリカバリが利用できます。
primaryサーバをマスタとし、standbyサーバをリカバリします。
primaryサーバが動作しているのがこの方法の前提条件ですので、
primaryサーバが停止している状態ではオンラインリカバリはできません。
primaryサーガ停止している状態からの復旧は、すべてのDBノードとpgpool-IIを停止させて手動で実施しなければなりません。
</p>
<ol>
<li>リカバリ処理を実行するユーザ <a href="#RECOVERY_USER">recovery_user</a> を設定します。
通常、postgresユーザとなります。
<pre>
recovery_user = 'postgres'
</pre>
</li>
<li><a href="#RECOVERY_PASSWORD">recovery_password</a> を設定します。
これは、<a href="#RECOVERY_USER">recovery_user</a> がDBにログインするときに使うパスワードです。
<pre>
recovery_password = 't-ishii'
</pre>
</li>
<li><a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a> を設定します。
<p>
ここで指定するファイルは、primaryサーバからベースバックアップを取得し、
standbyサーバにリストアするものでなければなりません。
recovery_1st_stage_command は、primaryのPostgreSQLから、recovery_userの権限で起動され、
その時に引数を受けとります。
詳細は、<a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a>の設定項目をご覧ください。
</p>
<p>
このスクリプトファイルは、primaryのデータベースクラスタ下に配置し、実行権限を与えておきます。
サンプルとして、primary/standbyそれぞれ一台構成の場合のスクリプト
<a href="basebackup.sh">(basebackup.sh)</a>を示します。
このスクリプトでは、recovery_user がパスワードなしでリカバリ対象の
standbyノードにログインできることを前提にしているので、
あらかじめsshの設定を行なっておく必要があります。
</p>
<pre>
recovery_1st_stage_command = 'basebackup.sh'
</pre>
</li>
<li><a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command</a> は、空のままで構いません。
<pre>
recovery_2nd_stage_command = ''
</pre>
</li>
<li>オンラインリカバリを実施するための PostgreSQL の C 言語関数やSQL関数を各DBノードにインストールします。
<pre>
# cd pgpool-II-x.x.x/sql/pgpool-recovery
# make
# make install
# psql -f pgpool-recovery.sql template1
</pre>
</li>
<li>オンラインリカバリが終了したあと、pgpool-IIは、停止していたDBノードのPostgreSQLを起動します。
そのためのスクリプトを、各DBノードのDBクラスタにインストールします。
<p>
<a href="pgpool_remote_start">スクリプトのサンプル</a>がソースコードの"sample"ディレクトリに含まれているので、
それを利用してください。
このサンプルの中では、PostgreSQLの起動をpg_ctlコマンドで行っており、pg_ctlコマンドへのパスが記述されています。
デフォルトでは/usr/local/pgsql/bin/pg_ctlとなっているので、お使いの環境に合わせて修正してください。
</p>
<p>
なお、このスクリプトはsshを使用しますので、少くとも、primaryのDBノードから、standbyのDBノードに対して、
recovery_userでパスワードなしでsshが利用できることが必要です。
必要ならばあらかじめ設定しておいてください。
</p>
</li>
</ol>
<p>
以上でオンラインリカバリの設定が終了しました。
standbyノードを停止した状態で、<a href="#pcp_recovery_node">pcp_recovery_node</a> を利用するか、
pgpoolAdminの「リカバリ」ボタンでオンラインリカバリが出来るようになったはずです。
うまくいかない場合は、pgpool-IIのログ、primaryサーバ、standbyサーバのログを確認してください。
</p>
<p>
参考までに、ストリーミングレプリケーションでのオンラインリカバリの内部処理の流れを説明します。
</p>
<ol id="setting_for_online_recovery_in_stream_mode">
<li>pgpool-IIは、primaryサーバにユーザ: <a href="#RECOVERY_USER">recovery_user</a>,
パスワード: <a href="#RECOVERY_PASSWORD">recovery_password</a> で
template1データベースに接続します。
</li>
<li>primaryサーバで、pgpool_recovery関数を実行します。
</li>
<li>pgpool_recovery関数は、<a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a> で
指定されたスクリプトを実行します。
<p>
なお、PostgreSQLは、データベースクラスタディレクトリ中で関数を実行します。
よって、pgpool_recovery関数もprimaryサーバのデータベースクラスタディレクトリ中で
関数を実行されることに注意してください。
</p>
</li>
<li>primaryサーバで、pgpool_remote_start関数を実行します。
<p>
この関数は、primaryサーバのデータベースクラスタディレクトリ中にある
pgpool_remote_startという名前のスクリプトを起動し、
ここからssh経由でリカバリ対象のstandbyサーバのPostgreSQLをpg_ctlコマンドを使って起動します。
起動はバックグラウンドで行われ、起動できたかどうかは次のステップで確認されます。
</p>
</li>
<li>pgpool-IIから、standbyサーバのPostgreSQLのpostgresデータベース
(postgresデータベースがない場合はtemplate1データベース)に、
ユーザ: <a href="#RECOVERY_USER">recovery_user</a>,
パスワード: <a href="#RECOVERY_PASSWORD">recovery_password</a> でtemplate1データベースに接続を試みます。
<p>
リトライは、<a href="#RECOVERY_TIMEOUT">recovery_timeout</a>秒間行われます。
PostgreSQLの起動に成功したら、次のステップに移ります。
</p>
</li>
<li><a href="#FAILBACK_COMMAND">failback_command</a>が空でない場合は、
pgpool-IIの親プロセスは指定されたスクリプトを起動します。
</li>
<li><a href="#FAILBACK_COMMAND">failback_command</a>が終了したら、pgpool-IIの子プロセスをすべて再起動します。
</li>
</ol>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="parallel"></a>パラレルモード</h1>
<p>
パラレルクエリ機能が利用できるモードです。
テーブルを分割させ、各ノードにデータを持たせることができます。またレプリケーションや負荷分散機能も同時に使うことができます。
</p>
<p>
パラレルモードでは、pgpool.confの<a href="#REPLICATION_MODE">replication_mode</a>または
<a href="#LOAD_BALANCE_MODE">loadbalance_mode</a>にtrueを設定し、
<a href="#MASTER_SLAVE_MODE">master_slave</a> をfalseにし、
<a href="#PARALLEL_MODE">parallel_mode</a> をtrueにします。
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
<h2 id="system_db">システムDBの設定</h2>
<p>
パラレルモードを利用するためには、システムDBを設定する必要があります。
システムDBはデータを各PostgreSQLサーバで分割するためのルールをPostgreSQLのテーブルの形で保持します。
システムDBはpgpoolが動作するホストと同じホストに置く必要はありません。
システムDBの設定はpgpool.confで行います。
</p>
<dl>
<dt><a name="SYSTEM_DB_HOSTNAME"></a>system_db_hostname</dt>
<dd>
<p>
システムDBが動いているホスト名です。空文字を指定すると、UNIXドメインソケットで接続します。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="SYSTEM_DB_PORT"></a>system_db_port</dt>
<dd>
<p>
システムDBのポート番号です。
</p>
<p>
このパラメータを変更した時には pgpool-IIを再起動してください。
</p>
</dd>
<dt><a name="SYSTEM_DBNAME"></a>system_dbname</dt>
<dd>
<p>
システムDBは専用のデータベースに設置します。そのデータベース名を指定します。
このデータベースはあらかじめ存在しなければなりません。ここでは、
"pgpool"というデータベース名にするものとします。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="SYSTEM_DB_SCHEMA"></a>system_db_schema</dt>
<dd>
<p>
システムDBは専用のスキーマに設置します。そのスキーマ名を指定します。
このスキーマはあらかじめ存在しなければなりません。ここでは、
"pgpool_catalog"というスキーマにするものとします。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="SYSTEM_DB_USER"></a>system_db_user</dt>
<dd>
<p>
システムDBに接続するときのユーザ名です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="SYSTEM_DB_PASSWORD"></a>system_db_password</dt>
<dd>
<p>
システムDBに接続するときのパスワードです。パスワードを設定していない場合は空文字にしておきます。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h2 id="system_db_sql">システムDBの初期設定</h2>
<p>
システムDBにスキーマとテーブルを作成します。初期設定用のスクリプトが
$prefix/share/system_db.sqlにあるのでそれを利用します。
ただし、このスクリプトではスキーマ名が"pgpool_catalog"となっているので、
違うスキーマを使う場合は適当に書き換えてください。
また、データベース名として"pgpool"以外を使う場合は以下を適当に読み替えてください。
<pre>
psql -f $prefix/share/system_db.sql pgpool
</pre>
<h2 id="install_dblink">dblinkのインストール</h2>
<p>
パラレルモードではdblinkを使います。dblinkはPostgreSQLソースファイル($POSTGRES_SRC)
</p>
<pre>
$(POSTGRES_SRC)/contrib/dblink
</pre>
<p>
にあります。$POSTGRES_SRC/contrib/dblink/README.dblinkを参考にシステム
DBにdblinkをインストールしてください。
</p>
<p>
また、pgpoolデータベースに関数の登録が必要です。
</p>
<pre>
psql pgpool < $POSTGRES_SRC/contrib/dblink/dblink.sql
</pre>
<h2 id="connection_setting">コネクション数の設定</h2>
<p>
パラレルモードでは、クエリによりシステムDBからdblink経由でpgpoolに接続するので、
想定される同時接続数以上のコネクションが必要になる場合があります。
そのため、pgpool.confの<a href="#NUM_INIT_CHILDREN">num_init_children</a>には
同時接続数より十分大きい値を設定して下さい。
</p>
<p>
目安として以下の式で<a href="#NUM_INIT_CHILDREN">num_init_children</a>を設定してください。
</p>
<pre>
num_init_children = 想定される同時接続数 * ( 1 + クエリの中で使われているテーブルの最大数)
</pre>
<h3 id="distdef">データ分割ルールの登録</h3>
<p>
データ分割を行うテーブルに対しては、テーブル情報をあらかじめ pgpool_catalog.dist_def
というテーブルに登録しておきます。
</p>
<pre>
CREATE TABLE pgpool_catalog.dist_def(
dbname TEXT, -- DB名
schema_name TEXT, --schema名
table_name TEXT, -- テーブル名
col_name TEXT NOT NULL CHECK (col_name = ANY (col_list)), -- 分散キー列名
col_list TEXT[] NOT NULL, -- tableの属性名
type_list TEXT[] NOT NULL, -- 属性のタイプ名
dist_def_func TEXT NOT NULL, -- 分散先のDBノードを決定する関数名
PRIMARY KEY (dbname,schema_name,table_name)
);
</pre>
<h3 id="replicate_def">レプリケーションテーブルのルール登録</h3>
<p>
一つのSQL文にJOIN等でデータ分割ルールに登録したテーブルと共に
レプリケーションを行うテーブルを指定する場合には、レプリケーションを行うテーブルの情報を
あらかじめ、pgpool_catalog.replicate_defというテーブルに登録しておきます。
</p>
<pre>
CREATE TABLE pgpool_catalog.replicate_def(
dbname TEXT, -- DB名
schema_name TEXT, -- schema名
table_name TEXT, -- テーブル名
col_list TEXT[] NOT NULL, -- tableの属性名
type_list TEXT[] NOT NULL, -- 属性のタイプ名
PRIMARY KEY (dbname,schema_name,table_name)
);
</pre>
<h2 id="example_partitioning">pgbench テーブルでの分割ルール例</h2>
<p>
pgbenchのテーブルを分割するルールの例を示します。
</p>
<p>
この例では、accountsテーブルに対しては分割を行い、branchesテーブル
とtellersテーブルに対してはレプリケーションを行うことにします。
また、accountsテーブルとbanchesテーブルはbidで結合されることを想定し
branchesテーブルはレプリケーションテーブルのルール登録を行います。
</p>
<p>
もし、accountsテーブル、branchesテーブルとtellersテーブルの３つの
テーブルの結合が行われる場合には、あらかじめtellersテーブルに対しても
レプリケーションテーブルのルール登録を行う必要があります。
</p>
<pre>
INSERT INTO pgpool_catalog.dist_def VALUES (
'pgpool',
'public',
'accounts',
'aid',
ARRAY['aid','bid','abalance','filler'],
ARRAY['integer','integer','integer','character(84)'],
'pgpool_catalog.dist_def_accounts'
);
INSERT INTO pgpool_catalog.replicate_def VALUES (
'pgpool',
'public',
'branches',
ARRAY['bid','bbalance','filler'],
ARRAY['integer','integer','character(84)']
);
</pre>
<p>
ここで、pgpool_catalog.dist_def_accountsは、引数として分割キーの値を受け取り、
どのPostgreSQLサーバ(「DBノード」と呼びます)を0からの番号で返す関数です。
ここでは、3台のDBノードにデータを分割する関数の例を示します。
</p>
<pre>
CREATE OR REPLACE FUNCTION pgpool_catalog.dist_def_accounts (val ANYELEMENT) RETURNS INTEGER AS '
SELECT CASE WHEN $1 >= 1 and $1 <= 30000 THEN 0
WHEN $1 > 30000 and $1 <= 60000 THEN 1
ELSE 2
END' LANGUAGE SQL;
</pre>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="hba"></a>クライアント認証(HBA)のための pool_hba.conf 設定方法</h1>
<p>
PostgreSQLのpg_hba.confと同じようにpgpoolでもpool_hba.confファイルを使った
クライアント認証がサポートされています。
</p>
<p>
pgpoolをインストールするとデフォルトインストール先の設定ファイルディレクトリ
"/usr/local/etc"にpool_hba.conf.sampleが一緒にインストールされます。
このpool_hba.conf.sampleファイルをpool_hba.confとしてコピーし、
必要であれば編集してください。
デフォルトではpool_hbaによる認証は無効にになっています。
pgpool.confの<a href="#ENABLE_POOL_HBA">enable_pool_hba</a>をonにしてください。
</p>
<p>
pool_hba.confのフォーマットはpg_hba.confのものとほとんど同じです。
</p>
<pre>
local DATABASE USER METHOD [OPTION]
host DATABASE USER CIDR-ADDRESS METHOD [OPTION]
</pre>
<p>
各フィールドで設定できる値の詳細は"pool_hba.conf.sample"を参照してください。
</p>
<p>
以下はpool_hbaの制限事項です。
</p>
<ul>
<li>"hostssl"接続タイプはサポートされません</li>
<p>
pool_hba.confに"hostssl"は指定することはできませんが、pgpool-IIは2.3以降でSSLをサポートしています。
詳細は<a href="#ssl">SSL</a>を参照してください。
</p>
<li>DATABASEフィールド値として"samegroup"はサポートされません</li>
<p>
pgpoolはバックエンドサーバにあるユーザ情報を事前に知る事ができないため、
データベース名はpool_hba.confにある値のみと比較されます。
なのでグループに関する認証はpool_hbaで行うことができません。
</p>
</li>
<li>USERフィールド値として"+"を使ったグループ指定はサポートされません</li>
<p>
上記の"samegroup"と同じ理由で、ユーザ名はpool_hba.confにある値のみと比較されます。
グループに関する認証はpool_hbaで行うことはできません。
</p>
</li>
<li>IPv6アドレス/マスク表記法はサポートされません</li>
<p>
現在pgpoolはIPv6をサポートしていません。
</p>
</li>
<li>"trust", "reject", "pam", "md5"以外のメソッドはサポートされません</li>
<p>
これも上記の"samegroup"と同じ理由によるものです。
pgpoolはバックエンドのユーザ/パスワード情報を持っていないので、
バックエンドに保存されているパスワードを使った認証を行うことができません。
</p>
<p>
md5に関しては、pool_passwdというパスワードファイルを併用することによって利用できます。
詳細は<a href="#md5">認証・アクセス制御方式</a>を参照してください。
</p>
</li>
</ul>
<p>
ここで説明された機能、制限はクライアントとpgpool間で行われるクライアント認証についてだということに
注意してください。
クラインアントはpgpoolのクライアント認証に成功したとしても、
PostgreSQLによるクライアント認証に成功しないと接続状態となりません。
pool_hbaにとってはクライアントに指定されたユーザ名やデータベース名(例. psql -U testuser testdb)が
実際にバックエンド上に存在するかどうかは問題ではありません。
それがpool_hba.confの値とマッチするかどうかでチェックが行われます。
</p>
<p>
pgpoolが稼働するホスト上のユーザ情報を使ったPAM認証を利用することができます。
pgpoolをPAMサポート付きでビルドするにはconfigureオプションに"--with-pam"を指定してください。
</p>
<pre>
./configure --with-pam
</pre>
<p>
実際にPAM認証を有効にするには、pool_hba.confで"pam"メソッドを設定するのに加え、
pgpoolのサービス設定ファイルをシステムのPAM設定ディレクトリ（通常は /etc/pam.d に作成する必要があります。
サービス設定ファイルの例はインストールディレクトリの"share/pgpool.pam"を参考にしてく
ださい。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="query_cache"></a>クエリキャッシュの設定方法 <span class="version">〜 V3.1 (DEPRECATED)</span></h1>
<strong>注意: このクエリキャッシュ機能は近い将来実装から削除される予定です。
代わりに、<a href="#memqcache">オンメモリクエリキャッシュ機能</a>を使用してください。
</strong>
<p>
pgpool-IIでは、すべてのモードでクエリキャッシュを利用することができます。
クエリキャッシュは、SELECTの結果を再利用することにより、性能を向上させます。
利用する場合には、pgpool.confの設定を以下のように設定します。
</p>
<pre>
enable_query_cache = true
</pre>
<p>
また、システムDBに以下のテーブルを作成してください。
</p>
<pre>
CREATE TABLE pgpool_catalog.query_cache (
hash TEXT,
query TEXT,
value bytea,
dbname TEXT,
create_time TIMESTAMP WITH TIME ZONE,
PRIMARY KEY(hash, dbname)
);
</pre>
<p>
ただし、この例ではスキーマ名が"pgpool_catalog"となっているので、
違うスキーマを使う場合は適当に書き換えてください。
</p>
<p>
<strong>注意: 現在のクエリキャッシュの実装では、キャッシュがデータベース上に作成されます。
そのため、実行にあまり時間のかからないようなSELECTでは、クエリキャッシュを有効にすることによって、
かえって遅くなることがあります。また、クエリキャッシュの内容は、テーブルが更新されてもそのままです。
手動で上記テーブルから削除するか、-c オプション(クエリキャッシュのクリア)を追加して
pgpool-IIを再起動する必要があります。</strong>
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="memqcache"></a>オンメモリクエリキャッシュの設定方法 <span class="version">V3.2 〜</span></h1>
<p>
pgpool-IIでは、すべてのモードでオンメモリクエリキャッシュを利用することができます。
上記のクエリキャッシュと違い、メモリ上にキャッシュが置かれるので高速であるばかりでなく、
データが更新されると自動的にキャッシュが無効になり、pgpool-IIの再起動の必要がありません。
</p>
<p>
オンメモリクエリキャッシュは、問い合わせのSELECT文(拡張問い合わせの場合は更にバインドパラメータ)と
検索結果をペアで記録し、2回目以降に同じSELECT文が発行された場合に、キャッシュから結果を返します。
通常のSELECT文処理と違って、PostgreSQLにアクセスしないだけでなく、
pgpool内部のSQLパース処理などを経由しないため、非常に高速です。
</p>
<p>
反面、キャッシュにヒットしない場合は通常のSELECT文の処理に加えてキャッシュ処理のオーバヘッドが生じるので、
かえって遅くなります。
また、あるテーブルが更新された場合、そのテーブルを参照している
すべてのキャッシュが自動削除されるため(自動削除しない設定も可能)、
更新処理が多いシステムではオンメモリクエリキャッシュを有効にしていることでかえって遅くなります。
キャッシュのヒット率が70%以下の場合は、オンメモリクエリキャッシュの設定を有効にしないほうが良いでしょう。
</p>
<h2 id="MEMORY_CACHE_RESTRICTIONS">オンメモリクエリキャッシュの制限事項</h2>
<ul>
<li>オンメモリクエリキャッシュでは、テーブルに変更があると、関連するキャッシュを自動的に削除して古いデータが返却されないようにする機能があります。
このため、pgpoolは常にUPDATEやINSERTやALTER TABLEなどのコマンドが発行されたかどうかをモニタしています。
しかし、トリガ、外部キーやDROP TABLE CASCADEなどの働きによって暗黙的にテーブルが更新されたことはpgpool-IIからはわからないため、この機能が働きません。
この問題を回避するためには、<a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>を使って一定時間経過したキャッシュを削除するようにするか、<a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a>を使って、該当テーブルがキャッシュされないようにしてください。</li>
<li>複数のpgpool-IIを動かす環境で共有メモリを使ったオンメモリクエリキャッシュを使用すると、あるpgpool-II経由でテーブルが更新された時に、他のpgpool-IIのキャッシュが削除されず、古いデータを読みだしてしまうことがあります。
このような環境では、キャッシュストレージにmemcachedを使ってください。</li>
</ul>
<h2 id="MEMORY_CACHE_ENABLED">オンメモリクエリキャッシュの有効化</h2>
<p>
オンメモリクエリキャッシュを有効にするには、pgpool.confの"memory_cache_enabled"を有効にします。
<pre>
memory_cache_enabled = true
</pre>
</p>
<h2 id="MEMQCACHE_METHOD">キャッシュストレージの選択</h2>
<p>
メモリキャッシュのストレージには、共有メモリと<a href="http://memcached.org">memcached</a>のどちらかを
選択することができます(併用はできません)。
<p>
共有メモリを使用するクエリキャッシュは高速で、memcachedの立ち上げも必要なく、手軽に利用できます。
ただし、共有メモリサイズの上限によって保存できるキャッシュの量に制限があります。
memcachedをキャッシュストレージに使用する場合は、ネットワークアクセスのオーバヘッドがあるものの、
比較的自由にキャッシュメモリの大きさを設定できます。
</p>
<p>
共有メモリを利用する場合は"memqcache_method"に 'shmem'、Memcachedを利用する場合は'memcached'と設定します。
デフォルトは、'shmem'です。
</p>
<h2 id="memqcache_cases">キャッシュが作成される場合と作成されない場合</h2>
<p>
すべてのSELECT(もしくはWITH)がオンメモリクエリキャッシュの対象になるわけではありません。
キャッシュとDBの一貫性を極力保つために、キャッシュされないケースがあります。以下それを列挙します。
</p>
<ul>
<li> <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a>で指定されているテーブルを使っているSELECT</li>
<li>「/*NO QUERY CACHE*/」コメントで始まるSELECT</li>
<li>SELECT FOR SHAREまたはUPDATE</li>
<li>IMMUTABLEでない関数を使っているSELECT</li>
<li>一時テーブルを使っているSELECT</li>
<li>システムカタログを検索しているSELECT</li>
<li>VIEWをまたはunloggedテーブル使っているSELECT。
ただし、それらのテーブルが<a href="#WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list</a>で指定されている場合はキャッシュの対象になります。</li>
<li>明示的なトランザクション内でSELECTが発行され、そのトランザクションがアボートした時</li>
<li>SELECT結果が大きい場合(<a href="#MEMQCACHE_MAXCACHE">memqcache_maxcache</a>の項参照)</li>
</ul>
<h2 id="non_memqcache_case">キャッシュがあっても参照されない場合</h2>
<p>
オンメモリクエリキャッシュが存在しても、そのキャッシュが利用されないケースがあります。
以下それを列挙します。
</p>
<ul>
<li>明示的なトランザクション内で更新クエリが発行されている場合は、そのトランザクション内では
一切クエリキャッシュは参照されません。</li>
<li>そのキャッシュを違うユーザが作成していた場合(セキュリティ上の理由)</li>
<li>キャッシュの寿命を超えていた場合(<a href="#MEMQCACHE_EXPIRE">memqcache_expireの項</a>を参照)</li>
</ul>
<h2 id="memqcache_params">共通設定項目</h2>
<p>
キャッシュストレージを共有メモリにする場合でも、memcachedにする場合でも、共通で設定する項目を説明します。
</p>
<dl>
<dt id="MEMQCACHE_EXPIRE">memqcache_expire <span class="version">V3.2 〜</span></dt>
<dd>
<p>
クエリキャッシュの寿命を秒単位で設定します。デフォルト0です。
0を指定すると寿命が無限大になり、関連テーブルが更新されるまではキャッシュが有効になります。
なお、この設定は、<a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a>とは
独立です。
</p>
</dd>
<dt id="MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation <span class="version">V3.2 〜</span></dt>
<dd>
<p>
trueならば関連するテーブルが更新されるとキャッシュを無効化します。
falseならばテーブルが更新されてもキャッシュを無効化しません。
デフォルト値はonです。
なお、この設定は<a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>の設定とは独立です。
</p>
</dd>
<dt id="WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list <span class="version">V3.2 〜</span></dt>
<dd>
<p>
VIEW やunloggedテーブルを使っているSELECTは通常キャッシュの対象になりませんが、
white_memqcache_table_list に記述しておくことで、キャッシュされるようになります。
テーブル名はカンマ区切りで指定します。正規表現も利用できます
（指定した各表現に ^ と $ をつけた形で使われます）。
<p>
なお、同じテーブル・VIEW が <a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> と両方に
指定されている場合は、white_memqcache_table_list が優先され、キャッシュを利用します。
</p>
<p>スキーマ名を付けないテーブル名とスキーマ名を付けた形の両方をクエリの中で使う場合は、両方共リストに登録してください。たとえば、"table1"と"public.table1"の両方がクエリに現れる場合は、単に"table1"ではなく、"table1,public.table1"を追加する必要があります。
</p>
</dd>
<dt id="BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list <span class="version">V3.2 〜</span></dt>
<dd>
<p>
SELECT結果をキャッシュしたくないテーブル名をカンマ区切りで指定します。正規表現も利用できます
（指定した各表現に ^ と $ をつけた形で使われます）。
</p>
<p>スキーマ名を付けないテーブル名とスキーマ名を付けた形の両方をクエリの中で使う場合は、両方共リストに登録してください。たとえば、"table1"と"public.table1"の両方がクエリに現れる場合は、単に"table1"ではなく、"table1,public.table1"を追加する必要があります。
</p>
</dd>
<dt id="MEMQCACHE_MAXCACHE">memqcache_maxcache <span class="version">V3.2 〜</span></dt>
<dd>
<p>
SELECT文の実行結果がmemqcache_maxcacheバイトを超えると、キャッシュされません。
この場合、以下のようなメッセージが表示されます。
</p>
<pre>
2012-05-02 15:08:17 LOG: pid 13756: pool_add_temp_query_cache: data size exceeds memqcache_maxcache. current:4095 requested:111 memq_maxcache:4096
</pre>
<p>
この問題を回避するためには、memqcache_maxcacheを大きくすれば良いのですが、
キャッシュストレージとして共有メモリを使用する場合は、
<a href="#MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size</a>を超えないようにしてください。
キャッシュストレージとしてmemcachedを使用する場合は、
memcachedのスラブサイズ(デフォルトで1MB)を超えないようにしてください。
</p>
</dd>
<dt id="MEMQCACHE_OIDDIR">memqcache_oiddir <span class="version">V3.2 〜</span></dt>
<dd>
<p>
SELECT文が使用するテーブルにOIDを格納する一時ファイル領域のトップディレクトリをフルパスで指定します。
memqcache_oiddir以下には、データベースOID名のディレクトリが作成され、
更にその下にはテーブルOID名のファイルが作成されます。
テーブルOID名ファイルの中には、クエリキャッシュへのポインタが格納されており、
テーブルの更新があった際にキャッシュを削除するキーとなります。
</p>
<p>
この領域はデフォルトでは、pgpool を再起動しても再利用されます。
再利用せずに削除して起動したい場合は、<a href="#start">pgpool コマンド</a> に -C オプションをつけて起動します。
</p>
</dd>
</dl>
<h2 id="monitoring_memqcache">キャッシュのモニタリング</h2>
<p>
オンメモリクエリキャッシュをモニタする方法を説明します。
キャッシュから検索結果が取得されたかどうかは、<a href="#LOG_PER_NODE_STATEMENT">log_per_node_statement</a> を
有効にすることで確認できます。
</p>
<pre>
2012-05-01 15:42:09 LOG: pid 20181: query result fetched from cache. statement: select * from t1;
</pre>
<p>
クエリキャッシュのヒット率は、<a href="#pool_status">show pool_status コマンド</a> で確認できます。
</p>
<pre>
memqcache_stats_start_time | Tue May 1 15:41:59 2012 | Start time of query cache stats
memqcache_no_cache_hits | 80471 | Number of SELECTs not hitting query cache
memqcache_cache_hits | 36717 | Number of SELECTs hitting query cache
</pre>
<p>
この例では、
</p>
<p>
<pre>
(memqcache_cache_hits) / (memqcache_no_cache_hits+memqcache_cache_hits) = 36717 / (36717 + 80471) = 31.3%
</pre>
<p>
がキャッシュヒット率ということになります。
</p>
<p>
<a href="#pool_cache">show pool_cache</a>コマンドでも同様の内容が確認できます。
</p>
<h2 id="shmem_params">共有メモリ設定項目</h2>
<p>
キャッシュストレージとして共有メモリを使用する場合の設定項目を説明します。
</p>
<dl>
<dt id="MEMQCACHE_TOTAL_SIZE">memqcache_total_size <span class="version">V3.2 〜</span></dt>
<dd>
<p>
キャッシュストレージに使用する共有メモリ領域のサイズを指定します。単位はバイトです。
</p>
</dd>
<dt id="MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache <span class="version">V3.2 〜</span></dt>
<dd>
<p>
キャッシュの数を指定します。
この設定項目は、キャッシュの管理領域の大きさを決めるために使用します
(<a href="MEMQCACHE_TOTAL_SIZE">memqcache_total_size</a>とは別に取られます)。
管理領域の大きさは、memqcache_max_num_cache * 48(バイト)になります。
この数は少なすぎるとキャッシュを登録することができずにエラーになります。
逆に多すぎると無駄になります。
</p>
</dd>
<dt id="MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size <span class="version">V3.2 〜</span></dt>
<dd>
<p>
キャッシュストレージとして共有メモリを使用する場合は、メモリを
memqcache_cache_block_size のブロックに分けて利用します。検索結果
のキャッシュはこのブロックに入るだけ詰め込まれます。
ただし、キャッシュは複数のブロックにまたがって格納されないので、
memqcache_cache_block_sizeを検索結果が超えると、キャッシュに格納できなくなります。
memqcache_cache_block_sizeは、512以上の値でなければなりません。
</p>
</dd>
</dl>
<h2 id="memcached_params">memcached設定項目</h2>
<p>
キャッシュストレージとしてmemcachedを使用する場合の設定項目を説明します。
</p>
<dl>
<dt id="MEMQCACHE_MEMCACHED_HOST">memqcache_memcached_host <span class="version">V3.2 〜</span></dt>
<dd>
<p>
memcachedが動いているホスト名またはIPアドレスを指定します。
pgpool-IIと同じマシンでmemcachedを動かす場合は、'localhost'とします。
</p>
</dd>
<dt id="MEMQCACHE_MEMCACHED_PORT">memqcache_memcached_port <span class="version">V3.2 〜</span></dt>
<dd>
<p>
memcachedのポート番号を指定します。デフォルト値は 11211 です。
</p>
</dd>
</dl>
<h3 id="install_memcached">memcachedのインストール</h3>
<p>
pgpool-IIのクエリキャッシュストレージとしてmemcachedを使用する場合は、動作しているmemcachedと、
libmemcachedというクライアントライブラリのインストールが必要です。
rpmなどからインストールするのがおすすめですが、ここではソースコードからインストールする方法を説明します。
</p>
<p>
memcachedのソースコードは<a href="http://memcached.org/">memcached開発ページ</a>からダウンロードできます。
</p>
<dl>
<dt>configureの実行
<dd>
<p>
ソースコードのtar ballを展開したら、configureを実行します。
</p>
<pre>
./configure
</pre>
</dd>
<dt>makeの実行
<dd>
<pre>
make
make install
</pre>
</dd>
</dl>
<h3 id="install_libmemcached">libmemcachedのインストール</h3>
<p>
memcachedのクライアントライブラリは、libmemcachedを使用しています。<br>
memcachedのインストール後に、libmemcachedをインストールする必要があります。
</p>
<p>
libmemcachedのソースコードは、<a href="http://libmemcached.org/libMemcached.html">libMemcached開発ページ</a>から
ダウンロードできます。
</p>
<dl>
<dt>configureの実行
<dd>
<p>
ソースコードのtar ballを展開したら、configureを実行します。
</p>
<pre>
./configure
</pre>
<p>
configureに指定できるオプションは以下です。
</p>
<ul>
<li><code>--with-memcached=path</code><br/>
Memcachedがインストールされているトップディレクトリを指定します。</li>
</ul>
</dd>
<dt>makeの実行
<dd>
<pre>
make
make install
</pre>
</dd>
</dl>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1>pgpool-IIの起動と停止<a name="start"></a></h1>
<h2 id="start_pgpool">pgpool-II の起動</h2>
<p>
以上で設定が終わったので、各DBノードを起動し、必要ならばシステムDBも起動してからpgpool-IIを起動します。
</p>
<pre>
pgpool [-c][-f config_file][-a hba_file][-F pcp_config_file][-n][-D][-d]
</pre>
<table border>
<tr><td>-c</td><td>--clear-cache</td>
<td>クエリキャッシュを消去します</td></tr>
<tr><td>-f config_file</td><td>--config-file config-file</td>
<td>pgpool-IIの設定ファイルを指定します</td></tr>
<tr><td>-a hba_file</td><td>--hba-file hba_file</td>
<td>HBA認証設定ファイルを指定します</td></tr>
<tr><td>-F pcp_config_file</td><td>--pcp-password-file</td>
<td>pcpの設定ファイルを指定します</td></tr>
<tr><td>-n</td><td>--no-daemon</td>
<td>デーモンモードで起動しません（制御端末を切り離しません）</td></tr>
<tr><td>-D</td><td>--discard-status</td>
<td>pgpool_statusを削除し、以前の状態を復元しません
<span class="version">V3.0 〜</span></td></tr>
<tr><td>-C</td><td>--clear-oidmaps</td>
<td>オンメモリクエリキャッシュの <a href="#MEMQCACHE_OIDDIR">memqcache_oiddir</a> の
ディレクトリの中身を消去します
（<a href="#MEMQCACHE_METHOD">memqcache_method</a> が 'memcached' のときのみ。
'shmem' のときは指定しなくても、必ず消去されます）。
<span class="version">V3.2 〜</span></td></tr>
<tr><td>-d</td><td>--debug</td>
<td>デバッグモードで起動します</td></tr>
</table>
<h2 id="start_pgpool">pgpool-II の停止</h2>
<p>
pgpool-IIの停止は後述のpcpコマンドでもできますが、pgpool-IIコマンドを使うこと
もできます。
</p>
<pre>
pgpool [-f config_file][-F pcp_config_file] [-m {s[mart]|f[ast]|i[mmediate]}] stop
</pre>
<table border>
<tr><td>-m s[mart]</td><td>--mode s[mart]</td>
<td>接続中のクライアントが接続を終わるのを待ってから停止します(デフォルト)</td></tr>
<tr><td>-m f[ast]</td><td>--mode f[ast]</td>
<td>接続中のクライアントが接続を終わるのを待たずに直ちに停止します</td></tr>
<tr><td>-m i[mmediate]</td><td>--mode i[mmediate]</td>
<td>-m fと同じ動作です</td></tr>
</table>
<p id="pool_status_file">
pgpoolが停止すると、[logdir]/pgpool_statusというファイルにバックエンドの状態を書き込みます。
次回pgpoolが起動したときにこのファイルが存在すると、バックエンドの状態をそこから復元します。
これによって、
</p>
<ol>
<li>バックエンドが停止してフェイルオーバ</li>
<li>pgpool経由で正常なDBを更新</li>
<li>pgpoolを停止</li>
<li>停止していたDBを再起動</li>
<li>pgpoolを再起動</li>
</ol>
<p>
というシーケンスで、不整合のあるDBからレプリケーション状態に移行することを防ぐことができます。
</p>
<p>
もしもDBの状態に不整合がなくなっている、あるいはpgpool.confを書き換えて設定を変えてしまった、
というときはpgpool_statusを削除すればバックエンドの状態の復元を行いません。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1>pgpool-IIの設定ファイルの再読み込み<a name="reload"></a></h1>
<p>
pgpool-IIの設定ファイルは、pgpool-IIを再起動することなく読み直すことができます。
</p>
<pre>
pgpool [-f config_file][-a hba_file][-F pcp_config_file] reload
</pre>
<table border>
<tr><td>-f config_file</td><td>pgpool-IIの設定ファイルを指定します</tr>
<tr><td>-a hba_file</td><td>HBA認証設定ファイルを指定します</tr>
<tr><td>-F pcp_config_file</td><td>pcpの設定ファイルを指定します</tr>
</table>
<p>
設定項目によっては、再読み込みを行なっても反映されないものがあるので、ご注意下さい。
また、設定の変更はすでに接続中のセッションには反映されません。
次回、クライアントがpgpool-IIに接続したときから反映されます。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="show-commands"></a>SHOWコマンド</h1>
<h2 id="show_commands">概要</h2>
<p>
pgpool-IIでは、SHOWコマンドを使って情報を参照することができます。
SHOWはSQLコマンドですが、pgpool-IIは一部のSHOWコマンドを独自に解釈して、pgpool-IIが管理する情報を返却します。
以下のようなものがあります。
</p>
<table border>
<tr><th><a href="#pool_status">pool_status</a></th><td>構成情報</td></tr>
<tr><th><a href="#pool_nodes">pool_nodes</a></th>
<td>DBノード情報 <span class="version">V3.0 〜</span></td></tr>
<tr><th><a href="#pool_processes">pool_processes</a></th>
<td>pgpool-IIプロセスの内部情報 <span class="version">V3.0 〜</span></td></tr>
<tr><th><a href="#pool_pools">pool_pools</a></th>
<td>コネクションプール情報 <span class="version">V3.0 〜</span></td></tr>
<tr><th><a href="#pool_version">pool_version</a></th>
<td>pgpool-IIのバージョン <span class="version">V3.0 〜</span></td></tr>
</table>
<p>"pool_status" SQL は以前からありますが、他のSQLはpgpool-II 3.0から追加されました。</p>
<p>
<u>注意</u>: "pool"という用語は、pgpoolプロセスによって所有されるPostgreSQLセッションを指します。
pgpoolによって所有されるセッション全体ではありません。
</p>
<h2 id="pool_status">pool_status</h2>
<p>"SHOW pool_status" は設定パラメータの名前と値、説明を表示します。出力の一部を示します。</p>
<pre>
benchs2=# show pool_status;
item | value | description
--------------------------------------+--------------------------------+------------------------------------------------------------------
listen_addresses | localhost | host name(s) or IP address(es) to listen to
port | 9999 | pgpool accepting port number
socket_dir | /tmp | pgpool socket directory
pcp_port | 9898 | PCP port # to bind
pcp_socket_dir | /tmp | PCP socket directory
</pre>
<h2 id="pool_nodes">pool_nodes <span class="version">V3.0 〜</span></h2>
<p>"SHOW pool_nodes"は、DBノードのリストを表示します。
ホスト名、ポート番号、状態、重み(ロードバランスモードで運用しているときにのみ意味があります)、
ノードの役割が表示されます。
状態(status)の意味については、<a href="#pcp_node_info">pcp_node_infoリファレンス</a>で説明されています。
</p>
<pre>
benchs2=# show pool_nodes;
id | hostname | port | status | lb_weight | role
------+-------------+------+--------+-----------+---------
0 | 127.0.0.1 | 5432 | 2 | 0.5 | primary
1 | 192.168.1.7 | 5432 | 3 | 0.5 | standby
(2 lignes)
</pre>
<h2 id="pool_processes">pool_processes <span class="version">V3.0 〜</span></h2>
<p>"SHOW pool_processes"は、接続待ち、あるいは接続中pgpool-IIの子プロセスの状態を表示します。
</p>
<p>
6つのカラムがあります。
</p>
<ul>
<li>pool_pid はpgpool-IIプロセスのプロセスIDです。</li>
<li>start_timeはこのプロセスが起動された時刻です(1970年1月1日からの経過秒で表示されます)。</li>
<li>databaseはこのプロセスが接続しているデータベース名です。</li>
<li>usernameはこのプロセスの接続で使用しているユーザ名です。</li>
<li>create_time isはこの接続が作成された時刻です。</li>
<li>pool_counter はこの接続が使用された回数です。</li>
</ul>
<p>返却行数は常にnum_init_childrenになります。
また、データベース名などが表示されるのは、そのプロセスにフロントエンドからの接続がある場合に限ります。</p>
<pre>
benchs2=# show pool_processes;
pool_pid | start_time | database | username | create_time | pool_counter
----------+---------------------+----------+-----------+---------------------+--------------
8465 | 2010-08-14 08:35:40 | | | |
8466 | 2010-08-14 08:35:40 | benchs | guillaume | 2010-08-14 08:35:43 | 1
8467 | 2010-08-14 08:35:40 | | | |
8468 | 2010-08-14 08:35:40 | | | |
8469 | 2010-08-14 08:35:40 | | | |
(5 lines)
</pre>
<h2 id="pool_pools">pool_pools <span class="version">V3.0 〜</span></h2>
<p>"SHOW pool_pools"は、pgpool-IIのコネクションプールの状態を表示します。
</p>
<p>
11のカラムがあります。
</p>
<ul>
<li>start_timeはこのプロセスが起動された時刻です(1970年1月1日からの経過秒で表示されます)。</li>
<li>pool_pid はpgpool-IIプロセスのプロセスIDです。</li>
<li>pool_id はコネクションプールIDです。(0からmax_pool-1の値です)</li>
<li>backend_id はPostgreSQLバックエンドの識別子です(0からバックエンド数-1の値です)</li>
<li>databaseはこのプロセスが接続しているデータベース名です。</li>
<li>usernameはこのプロセスの接続で使用しているユーザ名です。</li>
<li>create_time isはこの接続が作成された時刻です。</li>
<li>majorversion と minorversion はこの接続で使用されているプロトコルバージョン番号です。</li>
<li>pool_counter はこの接続が使用された回数です。</li>
<li>pool_backendpid は PostgreSQL のバックエンドプロセスのプロセスIDです。</li>
<li>pool_connected は真偽値で、0ならフロントエンドからの接続無し、1なら接続ありを表します。</li>
</ul>
<p>返却行数は常に<a href="#NUM_INIT_CHILDREN">num_init_children</a> * <a href="#MAX_POOL">max_pool</a>になります。
<pre>
benchs2=# show pool_pools;
pool_pid | start_time | pool_id | backend_id | database | username | create_time | majorversion | minorversion | pool_counter | pool_backendpid | pool_connected
----------+---------------------+---------+------------+----------+-----------+---------------------+--------------+--------------+--------------+-----------------+----------------
8465 | 2010-08-14 08:35:40 | 0 | 0 | | | | | | | |
8465 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
8465 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
8465 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
8466 | 2010-08-14 08:35:40 | 0 | 0 | benchs | guillaume | 2010-08-14 08:35:43 | 3 | 0 | 1 | 8473 | 1
8466 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
8466 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
8466 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
8467 | 2010-08-14 08:35:40 | 0 | 0 | | | | | | | |
8467 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
8467 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
8467 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
8468 | 2010-08-14 08:35:40 | 0 | 0 | | | | | | | |
8468 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
8468 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
8468 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
8469 | 2010-08-14 08:35:40 | 0 | 0 | | | | | | | |
8469 | 2010-08-14 08:35:40 | 1 | 0 | | | | | | | |
8469 | 2010-08-14 08:35:40 | 2 | 0 | | | | | | | |
8469 | 2010-08-14 08:35:40 | 3 | 0 | | | | | | | |
(20 lines)
</pre>
<h2 id="pool_version">pool_version <span class="version">V3.0 〜</span></h2>
<p>"SHOW pool_version" はpgpool-IIのバージョン情報を表示します。
例を示します。
</p>
<pre>
benchs2=# show pool_version;
pool_version
------------------------
3.0-dev (umiyameboshi)
(1 line)
</pre>
<h2 id="pool_cache">pool_cache <span class="version">V3.1 〜</span></h2>
<p>"SHOW pool_cache" は<a href="#memqcache">オンメモリクエリキャッシュ</a>が有効である場合に、クエリキャッシュのヒット率や、キャッシュストレージの状況を表示します。
例を示します。
</p>
<p>
<pre>
test=# \x
\x
Expanded display is on.
test=# show pool_cache;
show pool_cache;
-[ RECORD 1 ]---------------+---------
num_cache_hits | 891703
num_selects | 99995
cache_hit_ratio | 0.90
num_hash_entries | 131072
used_hash_entries | 99992
num_cache_entries | 99992
used_cache_enrties_size | 12482600
free_cache_entries_size | 54626264
fragment_cache_entries_size | 0
</pre>
</p>
<ul>
<li>num_cache_hits は、キャッシュにヒットした検索件数を表示します。</li>
<li>
num_selects は、キャッシュにヒットしなかった検索件数を表示します。
cache_hit_ratio は、キャッシュヒット率で、num_cache_hits/(num_cache_hits+num_selects)
から計算されています。
</li>
<li>num_hash_entries 以下は、キャッシュストレージが共有メモリの時だけ有効です。</li>
<li>
num_hash_entries は、キャッシュの検索インデックスであるハッシュテーブルのエントリ数を表し、
pgpool.confの <a href="MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache</a> と一致します。
この値が登録できるキャッシュ件数の最大値になります。
</li>
<li>used_hash_entries は、num_hash_entries のうち、使用済みのエントリ数です。</li>
<li>num_cache_entries は、キャッシュ本体の登録件数で、used_hash_entries と一致します。</li>
<li>
used_cache_enrties_size は、使用済みのキャッシュ領域の合計サイズです。
単位はバイトです。
</li>
<li>
free_cache_entries_size は、キャッシュ領域のうち、未使用または最利用可能な領域の合計サイズです。
単位はバイトです。
</li>
<li>
fragment_cache_entries_size は、空き領域ではあるが、断片化していて利用できないキャッシュ領域の合計サイズです。
単位はバイトです。
断片化した領域は、利用できるキャッシュ領域を使い果たした時に自動的に再利用できるようになります。
</li>
</ul>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="online-recovery"></a>オンラインリカバリ</h1>
<h2>オンラインリカバリ概要</h2>
<p>
この章では、レプリケーションモードで利用する場合のオンラインリカバリ機能
について説明します。
マスタ／スレーブモード(Streaming Replication)でのオンラインリカバリの利用方法については、
<a href="#stream">Streaming Replicationへの対応</a>をご覧下さい。
レプリケーションモードで pgpool が動作している場合、ダウンしたノードのデータを再同期させた上で、
ノードを復帰させることができます。この機能を「オンラインリカバリ」と呼びます。
</p>
<p>
オンラインリカバリを実施するためには、ノードが切り離されていると
pgpool が検知している必要があります。ノードを動的に追加したい場合には
pgpool.conf の backend_hostnameなどのパラメータを追加しておき、
設定ファイルを再読み込みさせると、ノードが切り離された状態で pgpool にノード情報が登録されます。
</p>
<p>
また、リカバリするノードの PostgreSQL がすでに動作中であれば、あらかじめ
PostgreSQL をシャットダウンさせておいてください。
</p>
<!--
<p>
<font color="red">注意: オンラインリカバリを実行する前に、マスタノード
(稼働中のノードのうち、一番番号が若いノード)上でのautovacuumを停止してください。
オンラインリカバリ中にautovacuumが動くと、データベースの内容が変化する可能性があるため、
ノード間の同期がきちんと取れなくなる可能性があります。
この制限は、rsyncなどの単純なコピー方法を使っている場合にのみ適用されます。
PostgreSQLのPITRを使っている場合は適用されません。
</font>
</p>
-->
<p>
pgpool ではオンラインリカバリを 2 段階に分けて実施します。
pgpool のクライアントからは完全なデータの同期を取るために若干の接続待ちが発生します。
リカバリ手順で以下のとおりです。
</p>
<ol>
<li>CHECKPOINT 実行</li>
<li>ファーストステージの実施</li>
<li>接続がすべて切断されるまで待機</li>
<li>CHECKPOINT 実行</li>
<li>セカンドステージの実施</li>
<li>postmaster の起動(pgpool_remote_start の実行)</li>
<li>ノードの復帰</li>
</ol>
<p>
データ同期の第一段階を「ファーストステージ」と呼びます。ファーストステージ中に1 回目のデータ同期を行います。
ファーストステージ中はデータの更新や参照を並行して行うことができます。
</p>
<p>
ファーストステージで処理する内容はユーザが定義することができます。
スクリプトでは 3 つの引数を受け取ることができます。
</p>
<ol>
<li>マスタのデータベースクラスタパス</li>
<li>リカバリノードのホスト名</li>
<li>リカバリノードのデータベースクラスタパス</li>
</ol>
<p>
次に 2 回目のデータ同期を行います。これを「セカンドステージ」と呼びます。
pgpool ではセカンドステージに入る前に接続中のクライアントがすべて接続が終了されるまで待ちます。
その間に接続リクエストが来た場合には、その接続をすべてブロックします。
</p>
<p>
セカンドステージで処理する内容はユーザが定義することができます。
スクリプトでは 3 つの引数を受け取ることができます。
</p>
<ol>
<li>マスタのデータベースクラスタパス</li>
<li>リカバリノードのホスト名</li>
<li>リカバリノードのデータベースクラスタパス</li>
</ol>
<p>
すべての接続が終了されると、ファーストステージ以降に更新されたデータを同期するための
セカンドステージが開始されます。そこで最終的なデータの同期を行います。
この間はクライアントからは pgpool への接続が待たされる状態になります。
</p>
<p>
<font color="red">
なお、オンラインリカバリの制限事項として、複数のホストに pgpool を配置して
レプリケーションさせている場合には、オンラインリカバリは正しく動作しません。
どれかの pgpool にリカバリリクエストを出した時に、他の pgpool から更新が伝搬すると、
データを同期させることができなく
なります。
</font>
</p>
<h2 id="online_recovery_params">pgpool の設定</h2>
<p>
オンラインリカバリを設定するためには、pgpool.conf の以下の値を設定してください。
</p>
<ul>
<li><a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a></li>
<li><a href="#RECOVERY_USER">recovery_user</a></li>
<li><a href="#RECOVERY_PASSWORD">recovery_password</a></li>
<li><a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a></li>
<li><a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command></a></li>
</ul>
<h2 id="installing-c-functions">C 言語関数のインストール</h2>
<p>
次に、リカバリを実施するための PostgreSQL の C 言語関数を各ノードの
template1 データベースにインストールします。ソースコードは
</p>
<pre>
pgpool-II-x.x.x/sql/pgpool-recovery/
</pre>
<p>
にあります。ディレクトリを移動し、make install してください。
</p>
<pre>
% cd pgpool-II-x.x.x/sql/pgpool-recovery/
% make install
</pre>
<p>
C 言語関数のモジュールをインストールしたら、続いて C 言語関数を呼びだすための SQL をインストールします。
</p>
<pre>
% cd pgpool-II-x.x.x/sql/pgpool-recovery/
% psql -f pgpool-recovery.sql template1
</pre>
<h2 id="recovery_script">リカバリスクリプトの配置</h2>
<p>
データを同期させるためのスクリプトと、リモートから postmaster を再起動させるためのスクリプトを
各ノードの $PGDATA 以下に配置します。
あらかじめpgpool-II-x.x.x/sample 以下にサンプルスクリプトも用意してありますので参考にしてください。
ここではサンプルスクリプトを使って、PITR によるリカバリ方法と、rsync によるリカバリ方法を説明します。
</p>
<h3 id="recovery_pitr">PITR によるリカバリ</h3>
<p>
ここでは PostgreSQL 8.2 以降で PITR 機能を使ってリカバリをする設定例を説明します。
PITR によるリカバリをする場合にはあらかじめ PostgreSQL の設定で
ログをアーカイブさせるようにしておいてください。
</p>
<h4>1st stage</h4>
<p>
まずファーストステージでベースバックアップを取得し、リカバリ先へコピーするスクリプト
(ここではファイル名を copy-base-backup とします)を用意します。
例えば以下のようなスクリプトで取得することができます。
</p>
<pre>
#! /bin/sh
DATA=$1
RECOVERY_TARGET=$2
RECOVERY_DATA=$3
psql -c "select pg_start_backup('pgpool-recovery')" postgres
echo "restore_command = 'scp $HOSTNAME:/data/archive_log/%f %p'" > /data/recovery.conf
tar -C /data -zcf pgsql.tar.gz pgsql
psql -c 'select pg_stop_backup()' postgres
scp pgsql.tar.gz $RECOVERY_TARGET:$RECOVERY_DATA
</pre>
<p>
ベースバックアップ取得時に recovery.conf を生成しておきます。
</p>
<pre>
restore_command = 'scp master:/data/archive_log/%f %p'
</pre>
<h4>2nd stage</h4>
<p>
セカンドステージでは最新の状態まで PITR によるリカバリを実施できるようにするために、
pgpool_recovery_pitr スクリプトを$PGDATA にコピーします。
このスクリプトではトランザクションログを強制的に切り替えるようにします。
</p>
<p>
通常、トランザクションログを切り替えるには、pg_switch_xlog 関数を利用しますが、
この関数は、アーカイブログファイルが生成される前に終了してしまう可能性があります。
</p>
<p><span class="version">V3.1 〜</span>
そこで、より安全にオンラインリカバリを行うために
pgpool_switch_xlog 関数が用意されています。
pgpool_switch_xlog 関数の基本動作は pg_switch_xlog 関数と同じですが、
トランザクションログの切り替えによるアーカイブログファイルの生成を
待ってから終了します。
この関数は、前述の「C言語関数のインストール」を実施するとインストールされ、
引数にはアーカイブログの出力先ディレクトリを指定します。
</p>
<p>
<pre>
#! /bin/sh
# Online recovery 2nd stage script
#
datadir=$1 # master dabatase cluster
DEST=$2 # hostname of the DB node to be recovered
DESTDIR=$3 # database cluster of the DB node to be recovered
port=5432 # PostgreSQL port number
archdir=/data/archive_log # archive log directory
# Force to flush current value of sequences to xlog
psql -p $port -t -c 'SELECT datname FROM pg_database WHERE NOT datistemplate AND datallowconn' template1|
while read i
do
if [ "$i" != "" ];then
psql -p $port -c "SELECT setval(oid, nextval(oid)) FROM pg_class WHERE relkind = 'S'" $i
fi
done
psql -p $port -c "SELECT pgpool_switch_xlog('$archdir')" template1
</pre>
<p>
スクリプト中のwhileループは、全データベース中のシーケンス値をトランザクションログに吐き出します。
これによって、シーケンスも正しくリカバリされるようになります。
</p>
<p>
スクリプトの配置が完了したら pgpool.conf に設定します。
</p>
<pre>
recovery_1st_stage_command = 'copy-base-backup'
recovery_2nd_stage_command = 'pgpool_recovery_pitr'
</pre>
<p>
これで PITR によるオンラインリカバリの準備が完了です。
</p>
<h4 id="pool_remote_start">pgpool_remote_start</h4>
<p>
データ再同期後に postmaster を起動させるスクリプトです。
pgpool からは以下の形式でスクリプトを実行します。
</p>
<pre>
% pgpool_remote_start remote_host remote_datadir
remote_host: リカバリノードのホスト名
remote_datadir: リカバリノードのデータベースクラスタパス
</pre>
<p>
サンプルスクリプトでは ssh 経由で postmaster を起動しています。
こちらもあらかじめパスフレーズ無しで ssh 経由でログインできるように設定しておく必要があります。
</p>
<p>
PITR によるリカバリであれば、pgpool_remote_start 内でベースバックアップを展開し、
recovery.conf の内容にしたがってリカバリした後にpostmaster が接続可能状態になります。
</p>
<pre>
#! /bin/sh
DEST=$1
DESTDIR=$2
PGCTL=/usr/local/pgsql/bin/pg_ctl
# Expand a base backup
ssh -T $DEST 'cd /data/; tar zxf pgsql.tar.gz' 2>/dev/null 1>/dev/null < /dev/null
# Startup PostgreSQL server
ssh -T $DEST $PGCTL -w -D $DESTDIR start 2>/dev/null 1>/dev/null < /dev/null &
</pre>
<h3 id="recovery_rsync">rsync によるリカバリ </h3>
<p>
7.4 以前の場合は PITR 機能がありません。また、8.0 と 8.1 の場合は
トランザクションログを強制的に切り替える関数が用意されていません。
そこで PITR を使わずにrsync を使ったリカバリ方法を説明します。
</p>
<p>
sample ディレクトリに pgpool_recovery というファイルがあります。
マスタから復帰させるノードへのデータの物理コピーを行うスクリプトです。
pgpool からは以下の形式でスクリプトを実行します。
</p>
<pre>
% pgpool_recovery datadir remote_host remote_datadir
datadir: マスタのデータベースクラスタパス
remote_host: リカバリノードのホスト名
remote_datadir: リカバリノードのデータベースクラスタパス
</pre>
<p>
サンプルスクリプトでは rsync を使って物理コピーをしています。もし
rsync を使う場合は、パスフレーズ無しで ssh 経由でログインできるように
あらかじめ設定しておく必要があります。
</p>
<p>
rsyncに関する注記:
</p>
<ul>
<li>-c (or --checksum) オプションを付けないと、ファイルが確実に転送されない場合があります。</li>
<li>-z (or --compress)オプションは低速なネットワークでは効果がありますが、
100M以上の高速なネットワークではかえってCPU負荷を増やし、結果的に遅くなることがあります。
高速ネットワークでは、このオプションを使用しないことをお勧めします。
</li>
<li>rsync の新しいバージョン(3.0.5)では、50%も性能が良くなったという報告が
pgpool-generalメーリングリストでありました。
</li>
</ul>
<p>
pgpool_recovery を使う場合は pgpool.conf に以下の行を追加してください。
</p>
<pre>
recovery_1st_stage_command = 'pgpool_recovery'
recovery_2nd_stage_command = 'pgpool_recovery'
</pre>
<h2 id="perform_online_recovery">リカバリの実行</h2>
<p>
以上でオンラインリカバリの準備が整いました。
オンラインリカバリを実行するには <a href="#pcp_recovery_node">pcp_recovery_node</a> コマンドを使うか、
pgpool 管理ツールから実行してください。
</p>
<p>
注意点として、<a href="#pcp_recovery_node">pcp_recovery_node</a> を実行する際に、タイムアウトを長くして
ください。pgpoolAdmin から実行する場合は pgmgt.conf.php 内の
_PGPOOL2_PCP_TIMEOUT を大きくしてください。
</p>
<h2 id="minorup_w_online_recovery">オンラインリカバリを利用したPostgreSQLのマイナーバージョンアップ</h2>
<h3>レプリケーションモードの場合</h3>
<p>
レプリケーションモードでpgpool-IIが動作している場合は、
オンラインで各ノードのPostgreSQLをバージョンアップできます。
ただし、ノードの切り離し時と追加時に、pgpool-IIに接続しているすべての
すべてのセッションが切断されるので注意してください。
また、オンラインリカバリが利用できるバージョンアップはマイナーバージョンアップのみで、
ダンプ/リストアが不要なリリースに限ります。
</p>
<p>
はじめに、上記の「オンラインリカバリの概要」を参考に各ノードでオンラインリカバリが利用できるように準備します。
</p>
<p>
PostgreSQLのバージョンアップは、マスタ以外のノードから行い、最後にマスタノードをバージョンアップします。
そこで、まずバージョンアップを行うマスタ以外の１つのノードのPostgreSQLを停止します。
pgpool-IIがPostgreSQLの停止を検知すると、以下のようなログを出力して縮退運転に移行します。
その際、pgpool-IIに接続しているすべてのセッションは一旦切断されます。
</p>
<pre>
2010-07-27 16:32:29 LOG: pid 10215: set 1 th backend down status
2010-07-27 16:32:29 LOG: pid 10215: starting degeneration. shutdown host localhost(5433)
2010-07-27 16:32:29 LOG: pid 10215: failover_handler: set new master node: 0
2010-07-27 16:32:29 LOG: pid 10215: failover done. shutdown host localhost(5433)
</pre>
<p>
停止したノードのPostgreSQLをバージョンアップします。
バージョンアップは、新しいバージョンのPostgreSQLを古いバージョンのインストール先に上書きしても構いませんが、
問題が起きた時に元のバージョンに戻せるようにインストール先を変えておくことをお勧めします。
</p>
<p>
新しいバージョンのPostgreSQLを古いバージョンと別の場所にインストールした場合、
リカバリスクリプトを編集することなくそのまま使用するには、シンボリックリンクなどを使用してインストール先のパスを以前と合わせる必要があります。
上書きインストールした場合は以下のC言語関数をインストールするまでの操作は不要です。
すぐにオンラインリカバリが実行できます。
</p>
<p>
古いバージョンのPostgreSQLのインストール先ディレクトリ名を変更します。
以下は、PostgreSQLが/usr/local/pgsqlにインストールされていたと仮定した一例です。
</p>
<pre>
$ mv /usr/local/pgsql /usr/local/pgsql-old
</pre>
<p>
新しいバージョンのPostgreSQLのインストール先にシンボリックリンクを作成します。
これにより、今までどおりのパスで新しいバージョンのPostgreSQLが使用できるようになります。
以下は、新しいバージョンのPostgreSQLが/usr/local/pgsql-newにインストールされていると仮定した一例です。
</p>
<pre>
$ ln -s /usr/local/pgsql-new /usr/local/pgsql
</pre>
<p>
データベースクラスタディレクトリがPostgreSQLのインストール先ディレクトリの下位にある場合は、
同じパスでデータベースクラスタにアクセスできるようにシンボリックリンクを作成するかコピーします。
以下は、シンボリックリンクを作成する例です。
</p>
<pre>
$ ln -s /usr/local/pgsql-old/data /usr/local/pgsql/data
</pre>
<p>
新しいバージョンのPostgreSQLに、オンラインリカバリ用の関数を
「C言語関数のインストール」を参考にインストールします。
オンラインリカバリは、データベースクラスタをコピーしますので、最後のpsqlを使用した関数の作成は不要です。
make installを実行してください。
</p>
<p>
最後にオンラインリカバリを実行して、１つのノードのバージョンアップが完了します。
オンラインリカバリは、pcp_recovery_nodeコマンドを実行するかpgpoolAdminで行います。
</p>
<p>
以上の手順をマスタ以外のノードで繰り返し、最後にマスタノードで行えば、
全体のPostgreSQLのマイナーバージョンアップは完了です。
</p>
<h3>Streaming Replicationを利用している場合</h3>
<p>
マスタースレーブモードでStreaming Replicationを利用している場合は、
オンラインでスタンバイのPostgreSQLをマイナーバージョンアップできます。
</p>
<p>
スタンバイのPostgreSQLをマイナーバージョンアップする手順は、上記のレプリケーションモードの手順と同じです。
ただし、recovery_1st_stage_commandとrecovery_2nd_stage_commandの設定などは、
「Streaming Replicationでのオンラインリカバリ」を参考にしてください。
</p>
<p>
プライマリのPostgreSQLのマイナーバージョンアップは、オンラインではできません。
pgpool-IIの停止が必要になります。
プライマリのPostgreSQLもバージョンアップの方法自体は、スタンバイと同様です。
プライマリのPostgreSQLのバージョンアップは以下の手順で行います。
<ol>
<li>pgpool-IIを停止
<li>プライマリのPostgreSQLを停止
<li>プライマリのPostgreSQLをバージョンアップ
<li>プライマリのPostgreSQLを起動
<li>pgpool-IIを起動
</ol>
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="backup"></a>バックアップ</h1>
<p>
バックエンドとシステムDBのPostgreSQLのバックアップは、単体のPostgreSQLと同様に、
物理バックアップ、論理バックアップ(pg_dump, pg_dumpall)、PITRが使用できます。
ただし、論理バックアップとPITRの操作は、pgpool-IIを経由せずにPostgreSQLに対して直接行ってください。
これは、<a href="#LOAD_BALANCE_MODE">load_balance_mode</a>や<a href="#REPLICATE_SELECT">replicate_select</a>などの
設定によるバックアップの失敗を避けるためです。
</p>
<h2 id="backup_rep_or_ms_mode">レプリケーションモード、マスタースレーブモード</h2>
<p>
レプリケーションモードとマスタースレーブモードでpgpool-IIが動作している場合は、
クラスタを構成しているいずれかのノードでバックアップを行います。
</p>
<p>
マスタースレーブモードで非同期のレプリケーションを行っている場合で、かつ、
最新のバックアップを取得したい場合は、マスタノードでバックアップしてください。
</p>
<p>
バックアップ時の注意点として、PostgreSQLに対してpg_dumpコマンドなどを実行すると、
ACCESS SHAREモードのロックがかかります。
そのため、ACCESS SHAREモードと競合するACCESS EXCLUSIVEロックが必要になるコマンド
（ALTER TABLE、DROP TABLE、TRUNCATE、REINDEX、CLUSTERおよびVACUUM FULLなど）は、ロック待ちが発生します。
これは、非同期のレプリケーションで、スレーブノードに対してバックアップを行っている場合も、
マスタが影響を受けることがありますので注意してください。
</p>
<h2 id="backup_parallel">パラレルモード</h2>
<p>
パラレルモードでpgpool-IIが動作している場合、クラスタ全体のデータが一貫性のある状態でバックアップを取得するには、
アプリケーション、またはpgpool-IIの一時的な停止が必要になります。
</p>
<p>
論理バックアップを利用する場合は、アプリケーション、またはpgpool-IIを停止し、
すべてのノードでpg_dump, pg_dumpallコマンドを実行します。
そして、すべてのノードでダンプが終了したら、アプリケーション、またはpgpool-IIを起動してください。
</p>
<p>
PITRを利用する場合は、まず各ノードのシステムの時刻がほぼ一致していることを確認してください。
そして、事前に各ノードでアーカイブログの設定を行い、ベースバックアップを取得します。
ベースバックアップが終了したら、アプリケーション、またはpgpool-IIを一時的に停止します。
停止後、その時刻と次に起動した時刻を記録します。
この一時的な停止によって、クラスタ全体のデータが一貫性のある状態を保った期間ができます。
ベースバックアップとアーカイブログを使用して各ノードをリストアする場合は、
一時停止期間の真ん中あたりの時刻をrecovery.confのrecovery_target_timeに指定したうえで、リカバリを行ってください。
</p>
<h2 id="backup_system_db">システムDBのバックアップ</h2>
<p>
パラレルクエリモード、またはクエリキャッシュを使用している場合は、システムDBもバックアップする必要があります。
pgpool.confの <a href="#SYSTEM_DBNAME">system_db_dbname</a> に設定したデータベースをバックアップしてください。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="deploy"></a>pgpool-IIの配置について</a></h1>
<p>
pgpool-IIは、独立したサーバに配置することもできますし、アプリケーションサーバと同居させることもできますし、
その他の配置も考えられます。
ここではそれぞれの配置方法を紹介し、それぞれの特徴、メリット、デメリットを検討します。
</p>
<dl>
<dt>専用のサーバに配置
<dd>
<p>
pgpool-IIを物理的に独立した専用のサーバに配置する方法です。
分かりやすい方法ですし、他のサーバソフトウェアの影響を受けないのでpgpool-IIをもっとも安全に運営できますが、
サーバ装置を1台余計に増やす必要があるのが欠点です。
また、そのサーバが単一障害点になります(pgpool-IIが単一障害点になることを回避するには、
後述の<a href="#watchdog">watchdog</a>かpgpool-HAを併用します)。
</p>
</dd>
<dt>Webサーバやアプリケーションサーバと同居
<dd>
<p>
Apache、JBoss、TomcatなどのWebサーバやアプリケーションサーバが稼働しているサーバに
pgpool-IIを同居させる方法です。
この方法では、Webサーバやアプリケーションサーバとpgpool-IIの通信がローカルマシン内になるので、
ソケット通信がマシン間で通信するよりも高速になるメリットがあります。
また、複数のWebサーバ／アプリケーションサーバがあれば、自然と単一障害点を回避できるようになります。
(この場合、複数のpgpool-IIの設定は<a href="#watchdog">watchdog用の設定</a>を除き同じにしてください)。
なお、複数のpgpool-IIが動作しているケースでは以下のような問題が考えられますが、<a href="#watchdog">watchdog</a>を有効にすることによって回避できます。したがって、このような構成では<a href="#watchdog">watchdog</a>を有効にすることを強くおすすめします。
</p>
<ul>
<li>pgpool-IIとDBサーバの間のネットワークが不安定だと、pgpool-IIから見てDBノード#1がダウン、
他のpgpool-IIから見て正常、というような状態になってしまうことがあります。
ネットワークを二重化するなどして、ネットワーク障害が起きないようにしてください。
</li>
<li>レプリケーションモードで、オンラインリカバリ実行中は、一つのpgpool-IIだけ残して
他のpgpool-IIを落してください。
さもないと、リカバリ後の結果に整合性がなくなる可能性があります。
マスター／スレーブモード+Streaming Replicationモードでは、同時に複数のpgpool-IIで
オンラインリカバリを実行しない限り、問題ありません。
</li>
</ul>
</dd>
<dt>DBサーバと同居
<dd>
<p>
PostgreSQLの稼働しているDBサーバと同居させる方法です。
この方法では、pgpool-IIが単一障害点になることがなく、余計なサーバを追加する必要もない点が優れていますが、
アプリケーションがどのDBサーバに接続するのかを自ら判断する必要があるのが欠点です。
この問題を解決するには、<a href="#watchdog">watchdog</a>を有効にするか、pgpool-HAと組み合わせて仮想IPを利用します。
</p>
</dd>
</dl>
<h2 id="pgpool_ha">pgpool-HAについて</h2>
<p>
pgpool-HAは、heartbeatなどを利用してpgpool-IIを二重化し、pgpool-II自体の可用性を上げるソフトウェアです。
pgpool-IIと同様、pgpoolプロジェクトのサブプロジェクトであり、pgpoolの開発サイトでOSSとして公開されています。
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1 id="watchdog">Watchdog <span class="version">V3.2 ～</span></h1>
<h2 id="what_is_watchdog">watchdog とは</h2>
<p>
watchdog プロセスは pgpool-II から起動される、高可用性を目的としたプロセスです。
複数の pgpool-II を連携させることで単一障害点を回避します。
watchdog は以下の機能を提供します。
</p>
<h3>pgpool-II の死活監視</h3>
<p>watchdog は pgpool-II の監視を行います。監視の方法は「ハートビート」モードと「クエリ」モードの２つがあります。</p>
<ul>
<li>
ハートビートモードでは、watchdog はハートビート信号を用いて 他の pgpool-II プロセスの死活監視を行います。
watchdog は、他の pgpool-II の watchdog より定期的に送られるハートビート信号を受け取り、これが一定期間以上途切れた場合には当該 pgpool-II プロセスに障害が発生したと判断します。
冗長性を高めるために、複数のネットワークを用いたハートビート交換が可能です。
デフォルトではこのモードで動作し、これが推奨設定です。
</li>
<li>
クエリモードでは、watchdog は pgpool-II のプロセスではなく「サービス」の応答を監視します。
このモードでは、監視対象の pgpool-II にクエリを発行しその応答をチェックします。
この方法では他の pgpool-II から接続を受ける必要があるため、<a href="NUM_INIT_CHILDREN">num_init_children</a> が十分大きくない場合には監視が失敗する場合があることに注意してください。
これは非推奨の監視方法であり、下位互換のために残されています。
</li>
</ul>
<p>
また watchdog は、pgpool-II から上位のサーバ（アプリケーションサーバなど）への接続も監視し、上位サーバへ pgpool-II のサービスを提供できるかチェックしています。
この監視に失敗した場合には、watchdog は pgpool-II に障害が発生しているとみなしダウンステータスに移行します。
</p>
<h3>pgpool-II 間の協調動作</h3>
<p>
watchdog は互いに情報交換を行うことで複数の pgpool-II を協調動作させます。
</p>
<ul>
<li>
フェイルオーバなどでバックエンドノードの状態が変化した場合には、この情報を他の pgpool-II へ伝達し、同期を行います。
</li>
<li>
オンラインリカバリ時には、複数の pgpool-II で DB に不整合が生じないよう他の pgpool-II へのクライアントの接続を制限します。
</li>
</p>
<li>
フェイルオーバ、ファイルバックの際に実行されるコマンド（<a href="#FAILOVER_COMMAND">failover_command</a>,
<a href="#FAILBACK_COMMAND">failback_command</a>, <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a>）は、インターロック機構により、１つの pgpool-II でのみ実行されます。
</li>
</ul>
<h3>障害発生検知時のアクティブ、スタンバイ切り替え</h3>
<p>
pgpool-II の障害を検知した場合、watchdog は他の watchdog に障害検知を通知します。
故障した pgpool-II がアクティブの場合、他の watchdog は新しいアクティブを投票で決め、
アクティブ・スタンバイの切り替えを行います。
</p>
<h3>サーバ切り替えと連動した仮想 IP アドレスの自動付け替え</h3>
<p>
スタンバイが新しいアクティブに昇格する際、新アクティブ機の watchdog は
アクティブ用の仮想IPインターフェースを起動します。
</p>
<p>
一方、旧アクティブ機の watchdog はアクティブ用仮想 IP インターフェースを停止します。
これにより、サーバが切り替わった後もアクティブは同じ IP アドレスでサービスを継続することができます。
</p>
<h3>サーバ復旧時、スタンバイ機としての自動登録</h3>
<p>
障害機の復旧や新規サーバを追加する場合、watchdog はサーバの情報を他の watchdog に通知し、
他の watchdog からはアクティブや他のサーバの情報を受け取ります。
これにより追加したサーバはスタンバイ機として自動的に追加されます。
</p>
<h2 id="watchdog_server_composition">サーバ構成</h2>
<p>
watchdogプロセスを含むpgpool-IIサーバは以下の図のようなシステム構成をとります。
</p>
<p><img src="wd-ja.jpg" alt="watchdog server composition" hight="70%" width="70%"></p>
<h2 id="start_watchdog">watchdog の起動と停止</h2>
<p>
watchdog プロセスは pgpool-II の子プロセスとして自動的に起動・停止されますので、固有の起動・停止コマンドはありません。
</p>
<p>
watchdog は仮想 IP インターフェースの起動・停止を行うため、 <font color="red">root 権限</font>を要求します。
pgpool-II を起動する際に root 権限で実行するのが１つの方法です。
しかし、セキュリティ上の理由からは、sudo や setuid を利用したコマンドを <a href="#IF_UP_CMD">if_up_cmd</a>、
<a href="#IF_DOWN_CMD">if_up_cmd</a>、<a href="#ARPING_CMD">if_up_cmd</a> に設定するのがより良い方法です。
</p>
<p>
watchdog の 死活監視は他の全ての pgpool-II が起動した後に開始されます。
全ての pgpool-II が起動していない状態では監視は行われず、仮想 IP の切り替えも行われません。
</p>
<h2 id="config_watchdog">pgpool.conf の設定</h2>
<p>
watchdog プロセスの設定項目は pgpool.conf に記述します。
pgpool.conf.sample ファイルの WATCHDOG セクションにサンプルを記述していますので、参照してください。
</p>
<p>
watchdog プロセスは以下の項目すべてを指定する必要があります。
</p>
<h3>有効化</h3>
<dl>
<dt><a name="USE_WATCHDOG"></a>use_watchdog <span class="version">V3.2 ～</span></dt>
<dd>
<p>
watchdog を有効にするには on にします。デフォルトは off です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h3>watchdog 間通信</h3>
<p>watchdog 間の情報交換に関する設定です。</p>
<dl>
<dt><a name="WD_HOSTNAME"></a>wd_hostname <span class="version">V3.2 ～</span></dt>
<dd>
<p>
pgpool-II サーバのホスト名または IP アドレスです。
クエリやパケットの送受信の他、watchdog の識別子としても用います。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_PORT"></a>wd_port <span class="version">V3.2 ～</span></dt>
<dd>
<p>
wachdog 間の情報交換のためのパケットを受信するポート番号を指定します。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_AUTHKEY"></a>wd_authkey <span class="version">V3.3 ～</span></dt>
<dd>
<p>
wachdog 間通信で用いられる認証キーです。
全ての pgpool-II で同じキーを指定する必要があります。
認証キーが異なる watchdog からの通信は拒絶されます。
死活監視をハートビートモードで行う場合には、この認証はハートビート信号にも適用されます。
指定が無い場合には認証は行われず、これがデフォルトです。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h3>上位サーバへの接続</h3>
<p>
pgpool-II あるいは PostgreSQL のサービス提供先（DB クライアント）のサーバを、上位サーバと呼びます。
pgpool-II が生きていて PostgreSQL と繋がっている場合でも、
上位サーバとのリンクが切れていればサービスを継続できません。
そのため、watchdog は上位サーバとのリンクが繋がっているかどうかも監視します。
</p>
<dl>
<dt><a name="TRUSTED_SERVERS"></a>trusted_servers <span class="version">V3.2 ～</span></dt>
<dd>
<p>
上位接続を確認するための信頼できるサーバリストです。
ping の応答が得られる必要があります。
"hostA,hostB,hostC ..." のようにカンマで区切って複数のサーバを指定できます。
全てのサーバへの ping が失敗した場合、watchdog は pgpool-II に障害が発生したと判断します。
そのため、複数のサーバを指定することを推奨します。
</p>
<p>
指定がない場合は上位サーバへの接続監視は行いません。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="PING_PATH"></a>ping_path <span class="version">V3.2 ～</span></dt>
<dd>
<p>
上位サーバへの接続監視に利用する ping コマンドのパスです。
"/bin" のようにパスだけを指定します。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h3>仮想 IP</h3>
<p>
仮想 IP の制御に関する設定です。
</p>
<dl>
<dt><a name="DELEGATE_IP"></a>delegate_IP <span class="version">V3.2 ～</span></dt>
<dd>
<p>
（アプリケーションサーバなど）外部からの接続される pgpool-II の仮想 IP アドレスです。
スタンバイからアクティブに切り替わる際、pgpool-II はこの仮想 IP を引き継ぎます。
このオプションが空の場合には、仮想 IP は起動されません。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="IFCONFIG_PATH"></a>ifconfig_path <span class="version">V3.2 ～</span></dt>
<dd>
<p>
IP アドレス切り替えに利用するコマンドのパスです。
"/sbin" のようにパスだけを指定します。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="IF_UP_CMD"></a>if_up_cmd <span class="version">V3.2 ～</span></dt>
<dd>
<p>
仮想 IP を起動するために実行するコマンドです。
"ifconfig eth0:0 inet $_IP_$ netmask 255.255.255.0"
のようにコマンドとパラメータを指定します。
$_IP_$ は <a href="#DELEGATE_IP">delegate_IP</a> で指定された IP アドレスに置換されます。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="IF_DOWN_CMD"></a>if_down_cmd <span class="version">V3.2 ～</span></dt>
<dd>
<p>
仮想IPを停止するために実行するコマンドです。
"ifconfig eth0:0 down"
のようにコマンドとパラメータを指定します。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="ARPING_PATH"></a>arping_path <span class="version">V3.2 ～</span></dt>
<dd>
<p>
IP アドレス切り替え後に ARP リクエストを送信するコマンドのパスです。
"/usr/sbin" のようにパスだけを指定します。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="ARPING_CMD"></a>arping_cmd <span class="version">V3.2 ～</span></dt>
<dd>
<p>
IPアドレス切り替え後にARPリクエストを送信するコマンドです。
"arping -U $_IP_$ -w 1"
のようにコマンドとパラメータを指定します。
$_IP_$ は <a href="#DELEGATE_IP">delegate_IP</a> で指定された IP アドレスに置換されます。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h3>昇格時の振る舞い</h3>
<p>pgpool-II がアクティブ（仮想 IP を保持しているステータス）に昇格した時の振る舞いの設定です。</p>
<dl>
<dt><a name="CLEAR_MEMQCACHE_ON_ESCALATION"></a>clear_memqcache_on_escalation <span class="version">V3.3 ～</span></dt>
<dd>
<p>
このオプションが on の場合、pgpool-II がアクティブに昇格した時に、共有メモリ上のクエリキャッシュを全て削除します。
これにより、旧アクティブと非整合な古いクエリキャッシュが使われることを防止します。
<a href="#MEMQCACHE_METHOD">memqcache_method</a> が 'shmem' の場合のみ有効です。
デフォルトは on です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_ESCALATION_COMMAND"></a>wd_escalation_command <span class="version">V3.3 ～</span></dt>
<dd>
<p>
pgpool-II がアクティブに昇格した時に、ここで指定したコマンドが実行されます。
コマンドは、仮想 IP が立ち上がる直前のタイミングで実行されます。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h3>pgpool-II の死活監視</h3>
<p>watchdog は一定時間間隔で pgpool-II の状態のチェック、すなわち死活監視を行います。</p>
<h4>共通設定</h4>
<dl>
<dt><a name="WD_LIFECHECK_METHOD"></a>wd_lifecheck_method <span class="version">V3.3 ～</span></dt>
<dd>
<p>
死活監視の方法を指定します。指定できる値は 'heartbeat' (デフォルト)か 'query' です。
</p>
<p>
'heartbeat' を指定した場合には、監視は「ハートビートモード」で行われます。
watchdog は一定間隔でハートビート信号（UDP パケット）を他の pgpool-II へ送信します。
また watchdog は他の pgpool-II から送られてくる信号を受信し、これが一定時間以上途絶えた場合にはその pgpool-II に障害が発生したと判断します。
</p>
<p>
'query' を指定した場合には、監視は「クエリモード」で行われます。
watchdog は監視用のクエリを pgpool-II に発行し、それが成功するかどうかで pgpool-II が生きているかどうかを判断します。
</p>
<p>
<font color="red">注意: クエリモードを使用する場合は、<a href="#NUM_INIT_CHILDREN">num_init_children</a>に十分大きな値を設定して下さい。watchdog 自身も pgpool-II にクライアントとして接続するためです。</font>
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_INTERVAL"></a>wd_interval <span class="version">V3.2 ～</span></dt>
<dd>
<p>
死活監視を行う間隔（秒）です。
（1 以上の数値）
デフォルトの値は 10 です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h4>ハートビートモードの設定</h4>
<dl>
<dt><a name="WD_HEARTBEAT_PORT"></a>wd_heartbeat_port <span class="version">V3.3 ～</span></dt>
<dd>
<p>
ハートビート信号を受信するポート番号を指定します。
ハートビートモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_HEARTBEAT_KEEPALIVE"></a>wd_heartbeat_keepalive <span class="version">V3.3 ～</span></dt>
<dd>
<p>
ハートビート信号を送信する間隔（秒）を指定します。
デフォルトは 2 です。
ハートビートモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_HEARTBEAT_DEADTIME"></a>wd_heartbeat_deadtime <span class="version">V3.3 ～</span></dt>
<dd>
<p>
このオプションで指定された間隔（秒）の間ハートビート信号が途絶えた場合、その pgpool-II に障害が発生したとみなされます。
ハートビートモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="HEARTBEAT_DESTINATION"></a>heartbeat_destination<font color="red">0</font> <span class="version">V3.3 ～</span></dt>
<dd>
<p>
ハートビート信号の送り先を、ホスト名か IP で指定します。
複数の送り先が指定可能です。
数値の部分は送り先の番号です。0 からの連番にします。
ハートビートモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="HEARTBEAT_DESTINATION_PORT"></a>heartbeat_destination_port<font color="red">0</font> <span class="version">V3.3 ～</span></dt>
<dd>
<p>
<a href="#HEARTBEAT_DESTINATION">heartbeat_destinationX</a>に指定したハートビート信号の送り先のポート番号を指定します。
通常は <a href="#WD_HEARTBEAT_PORT">wd_heartbeat_port</a> と同じ値を指定します。
そのポート番号が使用できないホストや、同じホストで複数の pgpool-II を動作させる場合には、異なる値を指定する必要があります。
数値の部分は送り先の番号です。0 からの連番にします。
ハートビートモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="HEARTBEAT_DEVICE"></a>heartbeat_device<font color="red">0</font> <span class="version">V3.3 ～</span></dt>
<dd>
<p>
<a href="#HEARTBEAT_DESTINATION">heartbeat_destinationX</a>に指定した送り先とのハートビートの送受信に用いるネットワークデバイス名を指定します。
数値の部分は送り先の番号です。デバイス毎に 0 からの連番にします。
複数の異なる送り先に同じデバイスを設定することが可能です。
ハートビートモードの場合のみ有効です。空文字列が指定された場合には無視されます。
また、SO_BINDTODEVICE ソケットオプションを使用しているため、pgpool-II が Linux で root 権限で起動している場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h4>クエリモードの設定</h4>
<dl>
<dt><a name="WD_LIFE_POINT"></a>wd_life_point <span class="version">V3.2 ～</span></dt>
<dd>
<p>
監視クエリの応答が得られなかった場合のリトライ回数です。
（1 以上の数値）
デフォルトの値は 3 です。
クエリモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_LIFECHECK_QUERY"></a>wd_lifecheck_query <span class="version">V3.2 ～</span></dt>
<dd>
<p>
pgpool-II の死活監視のために発行されるクエリです。
デフォルトは "SELECT 1" です。
クエリモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_LIFECHECK_DBNAME"></a>wd_lifecheck_dbname <span class="version">V3.3 ～</span></dt>
<dd>
<p>
監視クエリを送る際の接続先のデータベース名です。
デフォルトは 'template1' です。
クエリモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_LIFECHECK_USER"></a>wd_lifecheck_user <span class="version">V3.3 ～</span></dt>
<dd>
<p>
監視クエリを送る際にデータベースに接続するユーザ名です。
デフォルトは 'nobody' です。
クエリモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="WD_LIFECHECK_PASSWORD"></a>wd_lifecheck_password <span class="version">V3.3 ～</span></dt>
<dd>
<p>
監視クエリを送る際にデータベースに接続するパスワードです。
デフォルトでは設定されていません。
クエリモードの場合のみ有効です。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h3>監視対象サーバ</h3>
<dl>
<dt><a name="OTHER_PGPOOL_HOSTNAME"></a>other_pgpool_hostname<font color="red">0</font> <span class="version">V3.2 ～</span></dt>
<dd>
<p>
監視対象の pgpool-II サーバのホスト名を指定します。
クエリやパケットの送受信の他、watchdog の識別子としても用います。
数値の部分は監視対象サーバの通し番号です。
監視対象のサーバ毎に 0 からの連番にします。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="OTHER_PGPOOL_PORT"></a>other_pgpool_port<font color="red">0</font> <span class="version">V3.2 ～</span></dt>
<dd>
<p>
監視対象の pgpool-II サーバの pgpool ポート番号を指定します。
クエリモード使用時に、<a href="#WD_LIFECHECK_QUERY">wd_lifecheck_query</a> に指定したクエリがこのポートへ送られます。
数値の部分は監視対象サーバの通し番号です。
監視対象のサーバ毎に 0 からの連番にします。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
<dt><a name="OTHER_WD_PORT"></a>other_wd_port<font color="red">0</font> <span class="version">V3.2 ～</span></dt>
<dd>
<p>
監視対象の pgpool-II サーバの watchdog パケット受信ポート番号を指定します
数値の部分は監視対象サーバの番号です。
監視対象のサーバ毎に 0 からの連番にします。
</p>
<p>
このパラメータを変更した時には pgpool-II を再起動してください。
</p>
</dd>
</dl>
<h2 id="watchdog_restrictions">watchdog の制限事項</h2>
<ul>
<li>
クエリモード使用時に、PostgreSQL サーバのダウンや pcp_detach_node の実行により pgpool-II から全ての DB ノードが切り離された場合、
watchdog は pgpool-II のサービスがダウンした状態とみなし、watchdog に割り当てられていた仮想 IP は停止されます。
そのため、クライアントは仮想 IP を使って pgpool-II への接続することは出来なくなります。
これは、アクティブの pgpool-II が複数できてしまう「スプリットブレイン」状況を避けるための仕様です。
</li>
<li>
ダウン状態の pgpool-II へ 実 IP を使った接続はしないでください。ダウン状態の pgpool-II は watchdog からの
情報を受け取ることが出来ないため、バックエンドの状態が他のpgpool-II と異なっている場合があります。
</li>
<li>
ダウン状態の pgpool-II はアクティブまたはスタンバイになることはできません。ダウン状態から復帰するためには
pgpool-II を再起動する必要があります。
</li>
<li>
アクティブな pgpool-II の停止後、スタンバイ pgpool-II が新しいアクティブに昇格するまでには数秒の時間がかかることに注意してください。
これは、アクティブ pgpool-II の停止を他の pgpool-II に通知する前に、仮想 IP が停止されたことの確認を行っているためです。
</li>
</ul>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1>PCP コマンド<a name="pcp_command"></a></h1>
<h2>PCP コマンド一覧</h2>
<p>pgpool-II を操作する UNIX コマンドとして、以下のものがあります。</p>
<table border>
<tr><th colspan="2">情報を取得する PCP コマンド</th></tr>
<tr><th><a href="#pcp_node_count">pcp_node_count</a></th>
<td>ノード数を取得する</td></tr>
<tr><th><a href="#pcp_node_info">pcp_node_info</a></th>
<td>ノード情報を取得する</td></tr>
<tr><th><a href="#pcp_watchdog_info">pcp_watchdog_info</a></th>
<td>watchdog 情報を取得する <span class="version">V3.3 ～</span></td></tr>
<tr><th><a href="#pcp_proc_count">pcp_proc_count</a></th>
<td>プロセス一覧を取得する</td></tr>
<tr><th><a href="#pcp_proc_info">pcp_proc_info</a></th>
<td>プロセス情報を取得する</td></tr>
<tr><th><a href="#pcp_pool_status">pcp_pool_status</a></th>
<td>pgpool.conf のパラメータ設定値を取得する <span class="version">V3.1 〜</span></td></tr>
<tr><th><a href="#pcp_systemdb_info">pcp_systemdb_info</a></th>
<td>システム DB 情報を取得する</td></tr>
<tr><th><a href="#pcp_detach_node">pcp_detach_node</a></th>
<tr><th colspan="2">ノード等を操作する PCP コマンド</th></tr>
<tr><th><a href="#pcp_detach_node">pcp_detach_node</a></th>
<td>ノードを切り離す</td></tr>
<tr><th><a href="#pcp_attach_node">pcp_attach_node</a></th>
<td>ノードを復帰させる</td></tr>
<tr><th><a href="#pcp_promote_node">pcp_promote_node</a></th>
<td>ノードをマスターに昇格させる <span class="version">V3.1 〜</span></td></tr>
<tr><th><a href="#pcp_stop_pgpool">pcp_stop_pgpool</a></th>
<td>pgpool-IIを停止させる</td></tr>
<tr><th><a href="#pcp_recovery_node">pcp_recovery_node</a></th>
<td>マスタノードを使ってノードのデータを再同期、ノード起動させる</td></tr>
</table>
<h2 id="pcp_comand_args">共通引数</h2>
<p>全てのコマンドには共通する引数があります。これは接続するpgpool-IIの情報や認証情報などです。</p>
<pre>
ex)
$ pcp_node_count [-d] 10 localhost 9898 postgres hogehoge
</pre>
<table border>
<tr>
<th nowrap>第 1 引数</th><td>タイムアウト値<br>
秒数でタイムアウト値を指定します。
この時間内に pgpool-II から応答がない場合はコネクションを切断して終了します。
なお、このオプションは 2.1 からは無視するようになっています。
</td>
</tr>
<tr><th nowrap>第 2 引数</th><td>pgpool-II が稼動しているホスト名</td></tr>
<tr><th nowrap>第 3 引数</th><td>PCP ポート番号</td></tr>
<tr><th nowrap>第 4 引数</th><td>PCP ユーザ名</td></tr>
<tr><th nowrap>第 5 引数</th><td>PCP パスワード</td></tr>
</table>
<p>
オプション引数として、<code>-d </code>があります。
<code>-d</code> が指定されるとデバッグ情報を出力します。
</p>
<p>
PCPユーザ名とパスワードは <code>./configure</code> 時に <code>--prefix</code> で指定した
'インストールディレクトリ/etc' にある pcp.conf 内に記述されているものを指定します。
pcp.conf ファイルの場所がデフォルト以外の場所にある場合、
<code>pgpool</code> の <code>-F</code> オプションでその位置を指定することができます。
パスワードはコマンドに渡す時点でmd5化されている必要はありません。
</p>
<h2>情報を取得するコマンド群</h2>
<p>
全てのコマンドは、実行した結果が標準出力に表示されます。
</p>
<h3 id="pcp_node_count">pcp_node_count</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_node_count _timeout_ _host_ _port_ _userid_ _passwd_</code></dd>
<dt>説明</dt>
<dd>pgpool-II の pgpool.conf で定義されたノードの総数を表示します。
切り離されているノードの区別はしません。</dd>
</dl>
<h3><a name="pcp_node_info"></a>pcp_node_info</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_node_info _timeout_ _host_ _port_ _userid_ _passwd_ _nodeid_</code></dd>
</pre>
<dt>説明</dt>
<dd>pgpool-II の pgpool.conf で定義されたノードの情報を表示します。出力結果は以下の例のとおりです。
<pre>
$ pcp_node_info 10 localhost 9898 postgres hogehoge 0
host1 5432 1 1073741823.500000
</pre>
<p>結果は以下の順のとおりです。</p>
<ul>
<li>1. ノードのホスト名</li>
<li>2. ノードのポート番号</li>
<li>3. ステータス</li>
<li>4. ロードバランスウェイト</li>
</ul>
<p>ステータスは [0..3] までの数字で表わされます。各数字の意味は：</p>
<ul>
<li>0 - 初期化時のみに表われる。PCP コマンドで表示されることはない。</li>
<li>1 - ノード稼働中。接続無し</li>
<li>2 - ノード稼働中。接続有り</li>
<li>3 - ノードダウン</li>
</ul>
<p>ロードバランスウェイトは Normalize されたフォーマットで出力されます。</p>
<p>定義されていないノード ID を指定すると BackendError と表示され、
<a href="#exit_status">終了コード 12</a> で終了します。</p>
</dd>
</dl>
<h3><a name="pcp_watchdog_info"></a>pcp_watchdog_info</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_watchdog_info _timeout_ _host_ _port_ _userid_ _passwd_ [_watchdogid_]</code></dd>
<dt>説明</dt>
<dd>
<p>pgpool-II の pgpool.conf の watchdog セクションで定義された pgpool-II の watchdog ステータスを表示します。</p>
<p>_watchdogid_ は other_pgpool_hostname パラメータの添字です。
省略された場合には、_host_:_port_ で動作している pgpool-II の watchdog ステータスが表示されます。</p>
<p>出力結果は以下の例のとおりです。</p>
<pre>
$ pcp_watchdog_info 10 localhost 9898 postgres hogehoge 0
host1 9999 9000 2
</pre>
<p>結果は以下の順のとおりです。</p>
<ul>
<li>1. pgpool-II のホスト名</li>
<li>2. pgpool-II ポート番号</li>
<li>3. watchdog ポート番号</li>
<li>4. watchdog ステータス</li>
</ul>
<p>ステータスは [1..4] までの数字で表わされます。各数字の意味は：</p>
<ul>
<li>1 - 初期化時のみに表われる。指定された pgpool-II が未起動の場合に表示される。</li>
<li>2 - スタンバイ: 仮想 IP を保持していない</li>
<li>3 - アクティブ: 仮想 IP を保持している</li>
<li>4 - ダウン</li>
</ul>
<p>定義されていない watchdog ID を指定すると BackendError と表示され、
<a href="#exit_status">終了コード 12</a> で終了します。</p>
</dd>
</dl>
<h3 id="pcp_proc_count">pcp_proc_count</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_proc_count _timeout_ _host_ _port_ _userid_ _passwd_</code></dd>
<dt>説明</dt>
<dd>pgpool-II の子プロセスのプロセス ID を一覧表示します。複数ある場合は空白文字で区切られます。</dd>
</dl>
<h3 id="pcp_proc_info">pcp_proc_info</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_proc_info _timeout_ _host_ _port_ _userid_ _passwd_ _processid_</code></dd>
<dt>説明</dt>
<dd>
<p>pgpool-II の子プロセス情報を表示します。出力結果は以下の例のとおりです。</p>
<pre>
$ pcp_proc_info 10 localhost 9898 postgres hogehoge 3815
postgres_db postgres 1150769932 1150767351 3 0 1 14067 1
postgres_db postgres 1150769932 1150767351 3 0 1 14068 1
</pre>
<p>結果は以下の順のとおりです。</p>
<ul>
<li>1. 接続しているデータベース名</li>
<li>2. 接続しているユーザ名</li>
<li>3. プロセススタート時刻</li>
<li>4. コネクション作成時刻</li>
<li>5. プロトコルメジャーバージョン</li>
<li>6. プロトコルマイナーバージョン</li>
<li>7. コネクション使用回数</li>
<li>8. PostgreSQL バックエンドプロセスID</li>
<li>9. フロントエンドから接続がある場合は 1、そうでなければ 0</li>
</ul>
<p>
コネクションがバックエンドに対して張られていない場合、データは表示されません。
コネクション情報が複数ある場合、複数行に 1 行 1 コネクション情報で表示されます。
時刻は EPOCH タイムからの秒数で表わされます。
</p>
<p>定義されていないプロセスIDを指定するとBackendErrorと表示され、
<a href="#exit_status">終了コード 12</a>で終了します。</p>
</dd>
</dl>
<h3 id="pcp_pool_status">pcp_pool_status <span class="version">V3.1 〜</span></h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_pool_status _timeout_ _host_ _port_ _userid_ _passwd_</code></dd>
<dt>説明</dt>
<dd>
<p>pgpool.conf のパラメータ設定値を取得します。出力結果は以下のとおりです。</p>
<pre>
$ pcp_pool_status 10 localhost 9898 postgres hogehoge
name : listen_addresses
value: localhost
desc : host name(s) or IP address(es) to listen to
name : port
value: 9999
desc : pgpool accepting port number
name : socket_dir
value: /tmp
desc : pgpool socket directory
name : pcp_port
value: 9898
desc : PCP port # to bind
</pre>
</dd>
</dl>
<h3 id="pcp_systemdb_info">pcp_systemdb_info</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_systemdb_info _timeout_ _host_ _port_ _userid_ _passwd_</code></dd>
<dt>説明</dt>
<dd>
<p>pgpool-II のシステム DB 情報を表示します。出力結果は以下のとおりです。</p>
<pre>
$ pcp_systemdb_info 10 localhost 9898 postgres hogehoge
localhost 5432 yamaguti '' pgpool_catalog pgpool 3
yamaguti public accounts aid 4 aid bid abalance filler integer integer integer character(84) dist_def_accounts
yamaguti public branches bid 3 bid bbalance filler integer integer character(84) dist_def_branches
yamaguti public tellers bid 4 tid bid tbalance filler integer integer integer character(84) dist_def_tellers
</pre>
<p>まず 1 行目にシステム DB の情報が表示されます。結果は以下の順のとおりです。</p>
<ul>
<li>1. ホスト名</li>
<li>2. ポート番号</li>
<li>3. ユーザ名</li>
<li>4. パスワード。空の場合は '' で表示されます。</li>
<li>5. スキーマ名</li>
<li>6. データベース名</li>
<li>7. 分散定義関数の数</li>
</ul>
<p>
2 行目以降は分散定義が表示されます。複数の定義がある場合は、1 つの定義につき 1 行表示されます。
結果は以下の順のとおりです。
</p>
<ul>
<li>1. 分散対象のデータベース名</li>
<li>2. 分散対象のスキーマ名</li>
<li>3. 分散対象のテーブル名</li>
<li>4. 分散キーカラム名</li>
<li>5. 分散対象テーブル中のカラム数</li>
<li>6. カラム名リスト（5. のカラム数分表示されます）</li>
<li>7. カラム型リスト（5. のカラム数分表示されます）</li>
<li>8. 分散定義関数名</li>
</ul>
<p>
システム DB が定義されていない（pgpool-II モードでない、かつクエリキャッシュがオフの）場合に実行すると、
BackendErrorと表示され、<a href="#exit_status">終了コード 12</a> で終了します。
</p>
</dd>
</dl>
<h2>ノード等を操作するコマンド群</h2>
<h3 id="pcp_detach_node">pcp_detach_node</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_detach_node [-g] _timeout_ _host_ _port_ _userid_ _passwd_ _nodeid_</code></dd>
<dt>説明</dt>
<dd>
<p>pgpool-II のノードを切り離します。</p>
<p><code>-g</code> を指定すると、すべてのクライアントが接続を終了するまでノードを復帰しません。
（ただし、<a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a> が -1
あるいは、<a href="#RECOVERY_TIMEOUT">recovery_timeout</a> が設定されている場合を除く）
</p>
</dd>
</dl>
<h3 id="pcp_attach_node">pcp_attach_node</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_attach_node _timeout_ _host_ _port_ _userid_ _passwd_ _nodeid_</code></dd>
<dt>説明</dt>
<dd>pgpool-II のノードを復帰させます。</dd>
</dl>
<h3 id="pcp_promote_node">pcp_promote_node <span class="version">V3.1 〜</span></h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_promote_node [-g] _timeout_ _host_ _port_ _userid_ _passwd_ _nodeid_</code></dd>
<dt>説明</dt>
<dd>
<p>pgpool-II のノードをマスターに昇格させます。これは、マスタースレーブモードで
ストリーミングレプリケーション構成の場合のみ使用できます。
</p>
<p><code>-g</code> を指定すると、すべてのクライアントが接続を終了するまでノードを復帰しません。
（ただし、<a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a> が -1
あるいは、<a href="#RECOVERY_TIMEOUT">recovery_timeout</a> が設定されている場合を除く）
</p>
</dd>
</dl>
<h3 id="pcp_stop_pgpool">pcp_stop_pgpool</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_stop_pgpool _timeout_ _host_ _port_ _userid_ _passwd_ _mode_</code></dd>
<dt>説明</dt>
<dd><p>pgpool-IIを指定されたモードでシャットダウンします。指定できるモードは以下のとおりです。</p>
<ul>
<li>s - smart モード</li>
<li>f - fast モード</li>
<li>i - immediate モード</li>
</ul>
<p>pgpool-II が起動していない場合は ConnectionError と表示され、
<a href="#exit_status">終了コード 8</a> で終了します。</p>
<p>
※ 現在は fast モードと immediate シャットダウンの処理に区別はありません。
命令を送った時点でクライアントがいる・いないに関わらずシャットダウン処理を即座に行います。
</p>
</dd>
</dl>
<h3 id="pcp_recovery_node">pcp_recovery_node</h3>
<dl class="flat">
<dt>書式</dt>
<dd><code>pcp_recovery_node _timeout_ _host_ _port_ _userid_ _passwd_ _nodeid_</code></dd>
<dt>説明</dt>
<dd>
pgpool-II のノードをデータを再同期させた上で復帰させます。
</dd>
</dl>
<h2 id="exit_status">終了ステータス</h2>
<p>
PCPコマンドは正常に処理を終了した場合、ステータス'0'で終了します。エラーが起
きた場合は以下のステータスにより終了します。
</p>
<table border>
<tr><th>UNKNOWNERR</th>
<td>1</td><td>不明なエラー</td></tr>
<tr><th>EOFER</th>
<td>2</td><td>EOFエラー</td></tr>
<tr><th>NOMEMERR</th>
<td>3</td><td>メモリ不足</td></tr>
<tr><th>READERR</th>
<td>4</td><td>サーバからのデータ読み込みエラー</td></tr>
<tr><th>WRITEERR</th>
<td>5</td><td>サーバへのデータ書き込みエラー</td></tr>
<tr><th>TIMEOUTERR</th>
<td>6</td><td>タイムアウト</td></tr>
<tr><th>INVALERR</th>
<td>7</td><td>PCPコマンドへの不正なオプション</td></tr>
<tr><th>CONNERR</th>
<td>8</td><td>サーバ接続エラー</td></tr>
<tr><th>NOCONNERR</th>
<td>9</td><td>接続が存在しない</td></tr>
<tr><th>SOCKERR</th>
<td>10</td><td>ソケットエラー</td></tr>
<tr><th>HOSTERR</th>
<td>11</td><td>ホスト名解決エラー</td></tr>
<tr><th>BACKENDERR</th>
<td>12</td><td>サーバでのPCP処理エラー。存在しないプロセスIDの情報を取得しようとした場合など</td></tr>
<tr><th>AUTHERR</th>
<td>13</td><td>認証エラー</td></tr>
</table>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1><a name="troubleshooting"></a>トラブルシューティング</h1>
<p>
この章では、pgpool-IIを運用中に直面しやすい障害と、その対策方法をケース別に説明します。
</p>
<dl>
<dt id="health_check_failed">health check failed</dt>
<dd>
<p>
ヘルスチェックでpgpool-IIがDBノードの障害を検出しました。
</p>
<pre>
2010-07-23 16:42:57 ERROR: pid 20031: health check failed. 1 th host foo at port 5432 is down
2010-07-23 16:42:57 LOG: pid 20031: set 1 th backend down status
2010-07-23 16:42:57 LOG: pid 20031: starting degeneration. shutdown host foot(5432)
2010-07-23 16:42:58 LOG: pid 20031: failover_handler: set new master node: 0
2010-07-23 16:42:58 LOG: pid 20031: failover done. shutdown host foo(5432)
</pre>
<p>
このログは、DBノード1(ホスト名 foo)がダウンして切り離され、
新しくDBノード0がマスタとして扱われ出したことを示しています。
DBノード1をチェックし、異常原因を取り除いた後に、可能であればオンラインリカバリ機能を使っ
てDBノード1を復帰させてください。
</p>
</dd>
<dt id="failed_to_read_kind_from_frontend">failed to read kind from frontend</dt>
<dd>
<pre>
2010-07-26 18:43:24 LOG: pid 24161: ProcessFrontendResponse: failed to read kind from frontend. frontend abnormally exited
</pre>
<p>
pgpool-IIから見てクライアントが突然セッションを切断した際にこのようなログが残ります。
原因としては、アプリケーションのバグ、アプリケーションが強制終了された、
やネットワークの一時的な障害が考えられます。
このログが出ても、DBが壊れるとか一貫性がなくなるような問題は起きませんが、
継続してこのログが出力されるようであれば、アプリケーションやネットワークの障害を調査することをおすすめします。
</p>
</dd>
<dt id="kind_mismatch">kind mismatchエラー</dt>
<dd>
<p>
レプリケーションモードで運用している場合に出ることがあるエラーです。
</p>
<pre>
2010-07-22 14:18:32 ERROR: pid 9966: kind mismatch among backends. Possible last query was: "FETCH ALL FROM c;" kind details are: 0[T] 1[E: cursor "c" does not exist]
</pre>
<p>
pgpool-IIは、SQLコマンドを各DBノードに送信したら、各DBノードから同じレスポンスが返ってくることを期待します。
このエラーは、異なるレスポンスが返ってきたことを示します。
Possible last query was:のあとに、このエラーを返す原因となった問い合わせのSQL文が表示されます。
そのあとで、各DBノードからのレスポンスの種類と、レスポンスがエラーの場合は、
PostgreSQLのエラーメッセージが表示されます。
ここでは、"0[T]"により、0番目のDBノードが"T"(行情報の開始)という応答を返したこと、
一方"1[E"で、DBノード1がエラーを返したとこと、そのエラーメッセージは
「cursor "c" does not exist」であったことがわかります。
<p>
注意: このエラーは、マスタースレーブモードでも出ることがあります。
たとえば、SETコマンドは、各セッションの状態を同じにするために、基本的にすべてのDBノードに送信されるからです。
</p>
<p>
データベースを調べて原因を特定し、もしDBの同期が崩れているようであれば、
オンラインリカバリを使って正しいデータと同期させてください。
</p>
</dd>
<dt id="difference_of_number">pgpool detected difference of the number of inserted, updated or deleted tuples</dt>
<dd>
<p>
レプリケーションモードにおいて、pgpool-IIが、DBノード間でINSERT/UPDATE/DELETEが返す結果行の違いを検出しました。
</p>
<pre>
2010-07-22 11:49:28 ERROR: pid 30710: pgpool detected difference of the number of inserted, updated or deleted tuples. Possible last query was: "update t1 set i = 1;"
2010-07-22 11:49:28 LOG: pid 30710: ReadyForQuery: Degenerate backends: 1
2010-07-22 11:49:28 LOG: pid 30710: ReadyForQuery: Affected tuples are: 0 1
</pre>
<p>
この例では、update t1 set i = 1によって更新された行数が、DBノードで異なっています。
また、次の行では、DBノード1を切り離したこと、更にDBノード0での結果行数が0だったのに対して、DBノード1では、1行だったことを表しています。
</p>
<p>
正しくないデータを持っていると思われるDBノードを停止し、オンラインリカバリを使って
正しいデータと同期させてください。
</p>
</dd>
</dl>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1>制限事項<a name="restriction"></a></h1>
<p>
<h2>PostgreSQLの機能</h2>
<ul>
<li>pg_terminate_backend()でバックエンドを終了させるとフェイルオーバしてしまいます。
これは、PostgreSQLがpostmasterをシャットダウンしたときと同じメッセージをpgpoolに送るためです。
今のところ対応方法はないので、この関数を使わないようにしてください。
</li>
</ul>
<h2><a name="md5"></a>認証・アクセス制御方式</h2>
<p>
<ul>
<li>レプリケーションモードまたマスタ/スレーブモード時にはtrust, reject, clear
text password, pam, 認証方式だけが利用できます。
crypt認証は利用できません。
md5認証に関しては、PostgreSQLに該当ユーザをmd5認証付でPostgreSQLに登録し、
次にpgpoolに付属するpg_md5コマンドを使って、pool_passwdという認証ファイルを作成することにより
利用できるようになります。
pool_passwdは認証ファイルのデフォルトのファイル名です。
ファイル名は<a href="#POOL_PASSWD">pool_passwd</a>で変更することができます。
<ol>
<li>DBユーザのアカウントでログインし、"pg_md5 --md5auth パスワード"
または "pg_md5 --md5auth --username=ユーザ名 パスワード" を実行します。
</li>
<li>md5により暗号化されたユーザ名とパスワードがpool_passwdに登録されます。
pool_passwdがまだ存在しなければ、pgpool.confと同じディレクトリ内に作成されます。
</li>
<li>pool_passwdのフォーマットは、"ユーザ名:パスワード"となっています。
</li>
<li>pool_hba.confにmd5認証のエントリを作成します。
pool_hba.confについては、<a href="#hba">クライアント認証(HBA)のためのpool_hba.conf設定方法</a>
を参照してください。
</li>
<li>注意事項: pool_passwdに登録するパスワードは、PostgreSQLに登録したパスワードと
完全に同じでなければなりません。
</li>
<li>pool_passwdとPostgreSQLのmd5パスワードを変更したら、pgpool reload を実行してください。
pgpool-II 3.1またはそれよりも以前のバージョンでは、pgpool-IIの再起動が必要です。
</li>
</ol>
<li>それ以外のモードでは、trust, reject, clear text password, pam, crypt, md5認証方式だけが利用できます。
</li>
</ul>
<h2 id="temp_table_in_master_slave_mode">一時テーブルの扱い</h2>
<p>
制限対象:マスタースレーブモード
</p>
<p>
一時テーブルの作成、更新は常にマスタ(primary)で行なわれます。
一時テーブルの検索も、pgpool-II 3.0以降では、マスタで行なわれるので、
一時テーブルを使っているかどうかを意識する必要はありません。
ただし、文字列として一時テーブル名をSELECTの中で使っている場合は一時テーブルかどうかの確認のしようがないので、
負荷分散されてしまい、その一時テーブルが見つからないか、
もしくは同じ名前の別のテーブルを検索してしまうことになります。
そのような問い合わせは避けるか、/*NO LOAD BALNCE*/のコメントを挿入してください。
</p>
<pre>
SELECT 't1'::regclass::oid;
</pre>
<p>
ちなみに、psqlの\dコマンドのように、システムカタログを問い合わせる中で
文字列としてのテーブル名を使っている場合は、pgpool-II 3.0以降ではマスタで検索が行なわれるので、問題になりません。
なぜなら、システムカタログへの検索は常にマスタで行なわれるからです。
</p>
<h2 id="caution_in_replication_mode">レプリケーションモードで注意が必要な関数など</h2>
<p>
pgpool-IIでは同じ問い合わせを送っても異なる結果を返すようなデータ、
たとえば乱数やトランザクションID、OIDのようなものに関してはレプリケーションはしますが、
2台のホストでまったく同じ値がコピーされる保証はありません。
</p>
<p>
シリアル型に関しては、insert_lockを有効にしておけばテーブルロックを利用して同期が取られます。
シーケンスを扱う関数をSELECT setval()、SELECT nextval()で呼び出している場合は
自動的にレプリケーションされるので同期が取れます。
</p>
<p>
pgpool-II 2.3以降では、テーブルのデフォルト値での利用も含め、
CURRENT_TIMESTAMP, CURRENT_DATE, now()は、自動的にマスタ側から取得した時刻値に置き換えることによって
レプリケーションできるようになっています。
ただし、以下の点に注意してください。
</p>
<ul>
<li>
pgpool-II 3.1より前のバージョンではDEFAULTにタイムスタンプを返す式が
含まれているかどうかの判定は正確ではありません。例えば
<pre>
CREATE TABLE rel1(
d1 date DEFAULT CURRENT_DATE + 1
)
</pre>
のようなものも現在のタイムスタンプとして書き換えを行います。
pgpool-II 3.1以降では、拡張プロトコルとPREPARE以外の場合にこの点が改善されており、
上記の例にあるような例も正しく処理されます(つまり、デフォルト値として明日の日付がセットされます)。
</p>
<p>
なお、列の定義が、
</p>
<pre>
foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)
</pre>
<p>
のように、データ型が日付、時刻以外になっている場合は書き換えは行ないません。
</p>
</li>
<li>INSERT ... SELECTでは、列のDEFAULTに対する書き換えを行いません。例えば、
<pre>
CREATE TABLE rel1(
c1 int,
c2 timestamp default now()
)
</pre>
の時、
<pre>
INSERT INTO rel1(c1) VALUES(1)
</pre>
は
<pre>
INSERT INTO rel1(c1, c2) VALUES(1, '2009-01-01 23:59:59.123456+09')
</pre>
のように書き換えられますが
<pre>
INSERT INTO rel1(c1) SELECT 1
</pre>
は書き換えられません。
</li>
</ul>
<p>
PostgreSQL 8.2かそれより前のPostgreSQLをお使いの場合、
CREATE TEMP TABLEで作成されたテーブルはフロントエンドがセッションを終了しても削除されません。
これは、コネクションプールの効果でバックエンドから見るとセッションが継続しているように見えるからです。
セッションの終了時に明示的にDROP TABLEするか、トランザクションブロックの中で
CREATE TEMP TABLE ... ON COMMIT DROPをお使い下さい。
</p>
<p>
PostgreSQL 8.3以降では、reset_query_listにDISCARD ALLを指定すれば自動的に削除されるので問題ありません。
</p>
<h2 id="ng_queries">クエリについて</h2>
<p>
pgpool-II では扱うことができないクエリについて説明します。
</p>
<h3 id="ng_multibyte_chars">マルチバイト文字について</h3>
<p>
制限対象:全モード
</p>
<p>
現在の実装では、マルチバイト文字の変換処理を行いません。
クライアントエンコーディング、バックエンドノードのサーバエンコーディング、システムDB
のサーバエンコーディングを一致させるようにしてください。
</p>
<h3 id="ng_multi_statement">マルチステートメント</h3>
<p>
制限対象:全モード
</p>
<p>
マルチステートメント(';' で区切って複数の文をまとめた SQL)を pgpool が
正しく処理することができません。必ず文を分けて送信してください。
</p>
<p>
なお、psql を使って pgpool に接続した場合は、psql 内部でマルチステートメントを分解し、
1 つずつ送信するので、実際には問題になりません。
</p>
<h3 id="ng_extended_protocol">拡張問い合わせプロトコル</h3>
<p>
制限対象:パラレルモード
</p>
<p>
JDBC ドライバなどのような拡張問い合わせプロトコルには対応していません。
必ず簡易問い合わせプロトコルを使用してください。
</p>
<h3 id="ng_select">SELECT</h3>
<p>
制限対象:パラレルモード
</p>
<p>
postgresql.conf の add_missing_from 設定値を off (デフォルト値)に設定してください。
add_missing_from 設定値が on の時に使えるクエリは正しくpgpoolで処理されない可能性
があります。
</p>
<h3 id="ng_insert">INSERT</h3>
<p>
制限対象:パラレルモード
</p>
<p>
データ分割をしているテーブルに対して <code>INSERT</code> を行う際には、分割ルールとなる値を
<code>DEFAULT</code> にはできません。
例えばテーブル t のカラム x が分割ルールの対象カラムだった場合には、
</p>
<pre>
INSERT INTO t(x) VALUES (DEFAULT);
</pre>
<p>
とはできません。また、以下の様に分割ルールとなる値が関数呼び出しの場合も
対応していません。
</p>
<pre>
INSERT INTO t(x) VALUES (func());
</pre>
<p>
このカラムには必ず明示的に値を与える必要があります。
</p>
<p>
また、<code>SELECT INTO</code>、 <code>INSERT INTO ... SELECT</code>、および以下のような
<code>VALUES</code> を用いた複数行の挿入には対応していません。
</p>
<pre>
INSERT INTO t(x) VALUES (1),(2),(3);
</pre>
<h3 id="ng_update">UPDATE</h3>
<p>
制限対象:パラレルモード
</p>
<p>
分割ルールとなるカラムを更新すると分割ルールに従ったデータの整合性が崩
れる可能性があります。pgpool-II では特にデータの再配置ということは行い
ません。
</p>
<p>
もし制約違反などにより一部のノードでエラーになった場合にロールバックす
ることはできません。
</p>
<p>
WHERE 句にデータ分割を行ったテーブルを参照するサブクエリや関数呼び出しがある場合には正しく動かない可能性が
あります。
</p>
<pre>
例：UPDATE branches set bid = 100 where bid = (select max(bid) from beances);
</pre>
<h3 id="ng_select_for_update">SELECT ... FOR UPDATE</h3>
<p>
制限対象:パラレルモード
</p>
<p>
WHERE 句にデータ分割を行ったテーブルを参照するサブクエリや関数呼び出しがある場合には正しく動かない可能性が
あります。
<pre>
例：SELECT * FROM branches where bid = (select max(bid) from beances) FOR UPDATE;
</pre>
</p>
<h3 id="ng_copy">COPY</h3>
<p>
制限対象:パラレルモード
</p>
<p>
COPY BINARY には対応していません。また、ファイルからのコピーにも対応していません。
COPY FROM STDIN と COPY TO STDOUT のみ対応しています。
</p>
<h3 id="ng_create_table">ALTER/CREATE TABLE について</h3>
<p>
制限対象:パラレルモード
</p>
<p>
pgpool に情報を更新させるためには、pgpool を再起動する必要があります。
</p>
<h3 id="ng_transaction">トランザクション</h3>
<p>
制限対象:パラレルモード
</p>
<p>
トランザクション中に発行される SELECT は dblink を経由する場合には別ト
ランザクションになります。以下に例を示します。
</p>
<pre>
BEGIN;
INSERT INTO t(a) VALUES (1);
SELECT * FROM t ORDER BY a; <-- 上の INSERT した値は見えない
END;
</pre>
<p>
また制約違反などにより一部のノードでエラーになった場合にロールバックすることはできません。
</p>
<h3 id="ng_view">View/Rule</h3>
<p>
制限対象:パラレルモード
</p>
<p>
View や Rule は各ノードに同じ内容が定義されます。
</p>
<pre>
CREATE VIEW sample AS SELECT * FROM a, b where a.i = b.i
</pre>
<p>
上記のような テーブル結合を含んだVIEWは、a と b は同じノード内でのみ結合処理を行い、
各ノードからの実行結果を統合します。ノードをまたがった JOIN を行う View を作成することはできません。
Rule についても同様になります。
</p>
<p>
ただし、データ分割したテーブルを同じノード内でのみ結合したい場合に、VIEWを作成することは可能です。
この場合にはVIEWをpgpool_catalog.dist_defテーブルにVIEWを登録しておきます。
</p>
<p>
また、pgpool_catalog.dist_defテーブルのcol_nameとdist_def_funcには、
VIEWで定義したカラムとVIEWに対してINSERTが発行された場合に
何処のノードにクエリを問い合わせるのかを決定する関数を登録してください。
</p>
<h3 id="ng_fuction">関数/トリガについて</h3>
<p>
制限対象:パラレルモード
</p>
<p>
関数は各ノードに同じ内容が定義されます。関数内で JOIN や他のノードのデータ操作を行うことはできません。
</p>
<h3 id="ng_natural_join">Natural Join について</h3>
<p>
制限対象:パラレルモード
</p>
<p>
Natural Join は利用できません。ON 結合条件または、USING(結合カラム) を明示的に
指定する必要があります。
</p>
<h3 id="ng_using">USING 句について</h3>
<p>
制限対象:パラレルモード
</p>
<p>
JOIN 構文の中で利用される USING 句はクエリの書き換え処理によって ON 句に変換されます。
そのため、ターゲットリストに "*" を利用する問い合わせを行う場合には、同じ列名が出力されます。
</p>
<h3 id="ng_dead_lock">デッドロックについて</h3>
<p>
制限対象:パラレルモード
</p>
<p>
ノード間をまたがるデッドロックを検出することができません。
</p>
<pre>
例：accountsテーブルは以下のルールで分割されている。
aid <= 100000 ノード 0
aid >= 100000 ノード 1
A) BEGIN;
B) BEGIN;
A) SELECT * FROM accounts WHERE aid = 100001 FOR UPDATE;
B) SELECT * FROM accounts WHERE aid = 100000 FOR UPDATE;
A) SELECT * FROM accounts WHERE aid = 100000 FOR UPDATE;
B) SELECT * FROM accounts WHERE aid = 100001 FOR UPDATE;
</pre>
<p>
この場合、単一のノードではデッドロックを検知できないため、pgpool は待
たされた状態になります。この現象は SELECT FOR UPDATE 以外にも行ロック
を獲得するクエリで発生する可能性があります。
</p>
<p>
また、あるノードでデッドロックが発生した場合は、各ノードのトランザクショ
ンの状態が異なる状況になります。そのため、デッドロックを検知した時点で
以下のログを出力して pgpool は該当のプロセスを終了させます。
<pre>
pool_read_kind: kind does not match between master(84) slot[1] (69)
</pre>
<h3 id="ng_schema">スキーマについて</h3>
<p>
制限対象:パラレルモード
</p>
<p>
public 以外のスキーマに属すようなオブジェクトの参照は必ず
</p>
<pre>
スキーマ.オブジェクト
</pre>
<p>
と指定するようにしてください。
</p>
<pre>
set search_path = xxx
</pre>
<p>
を指定し、スキーマ名を省略すると、pgpool がどの分散ルールを適用するか
判断できません。
</p>
<h3 id="ng_relname">テーブル名、カラム名について</h3>
<p>
制限対象:パラレルモード
</p>
<p>
pool_で始まるテーブル、カラム名は使えません。クエリ書き換えの際に内部処理で使用します。
</p>
<h2 id="caution_system_db">システム DB</h2>
<h3>分割ルール</h3>
<p>
pgpool-II では分割ルールの対象のカラムは 1 つのみとします。x と y の
OR 条件などといったものには対応していません。
</p>
<h2>ビルドに必要な環境</h2>
<h3>libpq</h3>
<p>
pgpool-II では libpq をリンクします。libpq のバージョンは 2.0 の場合、
configure に失敗します。必ず libpq 3.0 以降(PostgreSQL 7.4以降) をリンクするよ
うにしてください。また、SystemDB のバージョンも PostgreSQL 7.4 以降が
必須になります。
</p>
<h2 id="caution_query_cache">クエリキャッシュ</h2>
<p>
<a href="#query_cache">ディスク上のクエリキャッシュ機能</a>では、キャッシュの無効化を手動で行う必要があります。
<a href="#memqcache">オンメモリクエリキャッシュ機能</a>にはこの制限は当てはまりません。
</p>
</p>
<p class="top_link"><a href="#Top">△ back to top</a></p>
<!-- ================================================================================ -->
<h1>内部情報<a name="internal"></a></h1>
<p>
pgpool-IIバージョン 2.0 以降では、1.x バージョンと比べ大幅な改良が加えられています。
1.x バージョンの情報とは互換性がないので注意してください。
</p>
<h2 id="parallel_execute_engine">パラレル実行エンジン</h2>
<p>
pgpool-IIにはパラレル実行エンジンが組み込まれています。
</p>
<p>
このエンジンは、パラレルモードのときに、各ノードに同じクエリを問い合
わせ、ノードの応答順に結果をフロントエンドに送信するエンジンのことを
指します。
</p>
<h2 id="rewrite_query">クエリ書き換え</h2>
<p>
パラレルモードでpgpool-IIが行うクエリ書き換えについて説明します。
</p>
<p>
パラレルモードでは、クライアントが送信した検索系(SELECT処理)の問い合わせは、
大きく分けて以下の 2 つの処理を行います。
</p>
<ol>
<li>クエリの解析</li>
<li>クエリの書き換え</li>
</ol>
<p>
これら２つの処理について順に説明致します。
</p>
<h3 id="analyze_query">クエリの解析</h3>
<h4>はじめに</h4>
<p>
クライアントが送信した検索系の問い合わせは、SQLパーサを通してからシステムDBに登録されている情報を
もとにクエリ解析を行います。クエリの解析には実行ステータスの遷移で評価しています。
</p>
<p>
ここで実行ステータスというのは、あるデータの集合が何処で取得または処理できるのか判断するものです。
例えば、pgpool_catalog.dist_defテーブルに登録されているテーブルのデータ集合全体は、
データが分割されているのですべてのノードから取得する必要があります。
逆に、pgpool_catalog.replicate_defテーブルに登録されているテーブルのデータ集合全体は、
すべてのノードから取得するのではなく、いずれかのノード
から取得すれば十分です。
</p>
<p>
ここで実行ステータスというのは、あるデータの集合が何処で取得または処理できるのか判断するものです。
ここですべてのノードで処理する必要がある状態を P 状態、一つのノードで処理する必要がある状態を
L 状態として定義します。
</p>
<p>
ここで実行ステータスというのは、あるデータの集合が何処で取得または処理できるのか判断するものです。
もう一つ、特別な状態として S 状態があります。
これは、すべてのノードから取得した全データに対して処理を行ったときの状態のことを示します。
</p>
<p>
ここで実行ステータスというのは、あるデータの集合が何処で取得または処理できるのか判断するものです。
例えば、ソート処理です。pgpool_catalog.dist_defテーブルに登録されている
テーブルのデータに対するソート処理は、すべてのノードからデータを取得した後に実行する必要があります。
</p>
<p>
検索系クエリは、以下の処理順に解析され、実行ステータスが遷移していきます。
実行ステータスが遷移していく過程で S 状態となると、以降の処理は必ず S 状態となります。
そして最後のSELECTの最終実行ステータスの状態により、何処のDBで処理されるかが決定します。
<ol>
<li> UNION、EXTRACT、INTERCECTが利用されているかどうか</li>
<li> FROM 句の実行ステータス</li>
<li> TARGETLIST による実行ステータスの変化</li>
<li> WHERE 句 にる実行ステータスの変化</li>
<li> GROUP BY 句による実行ステータスの変化</li>
<li> HAVING 句による実行ステータスの変化</li>
<li> ORDER BY 句による実行ステータスの変化</li>
<li> LIMIT OFFSET 述語に実行ステータスの変化</li>
<li> SELECTの最終実行ステータスの取得</li>
</ol>
<p>
SELECTの最終実行ステータスと処理される場所との関係は、以下のとおりです。
</p>
<table border>
<tr class="header"><th>実行ステータス</th><th>処理される場所</th></tr>
<tr><th>L</th><td>いずれかのノードに問い合わせを行う</td></tr>
<tr><th>P</th><td>すべてのノード同じ問い合わせを行い、パラレル実行エンジンを通してクライアントに返却</td></tr>
<tr><th>S</th><td>システムDBで処理を行った後にクライアントに返却</td></tr>
</td></tr>
</table>
<p>
またサブクエリに対しても上記のルールが適応されます。
以下の単純なクエリでは、p1-tableがシステムDBのpgpool_catalog.dist_defテーブルに登録されている場合、
つまりデータの分割が
行われている場合には、サブクエリの最終実行ステータスが P となり、
その結果サブクエリの呼び出し元である SELECT の実行ステータスも P となります。
</p>
<pre>
SELECT * FROM (SELECT * FROM P1-table) as P2-table;
</pre>
<p>
次に具体的に実行ステータスがどのように遷移するのか説明します。
まず2. From句の実行ステータス から説明します。
</p>
<h4>FROM 句の実行ステータス</h4>
<p>
検索系クエリ(SELECT)は FROM 句によりデータの集合を定義します。
FROM句から構成せれるデータ集合は P 状態, L 状態、または S 状態を取ります。
FROM句に指定しているテーブルが一つの場合には、単純にテーブルの実行ステータスが
FROM句から構成されるデータ集合全体の実行ステータスとなります。
FROM句に複数のテーブル、又はサブクエリがある場合
には、結合方法によって以下のように実行ステータスが決定します。
</p>
<table border>
<tr class="header">
<th>結合方式</th>
<th colspan="3">LEFT OUTER JOIN</th>
<th colspan="3">RIGHT OUTER JOIN</th>
<th colspan="3">FULL OUTER JOIN</th>
<th colspan="3">その他</th>
</tr>
<tr class="center"><th>左＼右</th>
<td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td>
</tr>
<tr class="center"><th> P </th>
<td> S </td><td> P </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> P </td><td> S </td>
</tr>
<tr class="center"><th> L </th>
<td> S </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td><td> S </td><td> L </td><td> S </td><td> P </td><td> L </td><td> S </td>
</tr>
<tr class="center"><th> S </th>
<td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td><td> S </td>
</tr>
</table>
<p>
以下の例では、P1-tableが P 状態のテーブルでL1-table,L2-tableが L 状態のテーブルだとします。
すると上記の表により、P1-table (左)とL1-table (右) が結合し P 状態となり、
さらに P 状態と L 状態のL2-tableが結合してFROM句の実行ステータスは P 状態となります。
<pre>
SELECT * FROM P1-table,L1-table,L2-table;
</pre>
</p>
<h4>TARGETLIST と WHERE句の実行ステータス</h4>
<p>
基本的なクエリでは、FROM 句と同じ実行ステータスを継承します。
しかし、TARGETLIST と WHERE句の実行ステータスは、以下の場合に変化します。
</p>
<ol>
<li>サブクエリがある場合</li>
<li>FROM句が P 状態の場合、かつ、TARGETLISTに集約関数、DISTINCTがある場合 </li>
<li>FROM句で定義したテーブル(データ集合)に存在しないカラムが使われている場合</li>
</ol>
<p>
サブクエリの最終実行ステータスが P 状態、または、S 状態の場合には、
TARGETLIST、WHERE句の実行ステータスは、S 状態となります。
下記の例では、サブクエリで使われているテーブルが、P 状態の場合には、
サブクエリの最終実行ステータスはP 状態となります。
そのため L1-tableの実行ステータスに依存せずに、WHERE句の実行ステータスは S状態となり、
このクエリの実行場所はシステムDBとなります。
</p>
<pre>
SELECT * FROM L1-table WHERE L1-table.column IN (SELECT * FROM P1-table);
</pre>
<p>
FROM 句が P 状態の場合、かつ、TARGETLISTに集約関数がある場合は、
データを取得後に集計する必要があるため、S状態に遷移します。
また、特定の条件の下では、集約関数による最適化が行われます。
</p>
<p>
FROM句で定義したテーブル、サブクエリには存在しないカラムがWHERE句に使われている場合があります。
これは以下のような相関サブクエリ内で発生します。
</p>
<pre>
SELECT * FROM L1-table WHERE L1-table.col1 IN (SELECT * FROM P1-table WHERE P1-table.col = L1-table.col1);
</pre>
<p>上記のサブクエリに使われている L1-table.col1は、L1-tableを外部参照しています。
この場合にサブクエリのWHERE句の実行ステータスは S 状態となります。
<h4>GROUP BY 句、HAVING 句、ORDER BY 句、LIMIT OFFSET 述語の実行ステータス</h4>
<p>
WHERE句の実行ステータスが P 状態の場合に、GROUP BY , HAVING 句、ORDER BY 句、
LIMIT OFFSET 述語があるとS状態に遷移します。
GROUP BY句が存在しないクエリはWHERE句の実行ステータスを継承します。
また、HAVING句が無い場合にはGROUP BY 句の実行ステータスを継承します。
ORDER BY 句、LIMIT OFFSET 述語も同様です。
</p>
<p>
UNION、EXTRACT、INTERSECTが使われている場合
</p>
<p>
UNION、EXTRAT、INTERSECTが使っているクエリは左側のSELECT文と右側のSELECT文の最終実行ステータスに依存します。
左側と右側のSELECT文の最終実行ステータスが共に L 状態の時には、L 状態となります。
</p>
<p>
また、左側と右側のSELECT文の最終実行ステータスが共に P 状態、かつUNION ALLの場合には P 状態となります。
その他の組み合わせの場合には、S状態となります。
</p>
<h4>SELECTの最終実行ステータスの取得</h4>
<p>
実行ステータスがすべて L 状態の場合にはL状態、すべて P 状態の場合には、P 状態となります。
それ以外は、S 状態となります。
</p>
<p>
L 状態の場合には、pgpool.confのloadbalance_modeがtrueの場合には負荷分散され、
それ以外の場合にはMASTERに問い合わせを行います。
</p>
<p>
また、P 状態の場合には、パラレル実行エンジンを使って並列処理が行われます。
S 状態の場合には、次のフェーズであるクエリ書き換えを行います。
</p>
<h3 id="step_rewrite_query">クエリ書き換え</h3>
<p>
クエリの解析フェーズで取得した実行ステータスを使ってクエリの書き換えを行います。
例として P 状態の P1-table と L 状態の L1-table を使ったクエリで説明します・
</p>
<pre>
SELECT P1-table.col, L1-table.col FROM P1-table,L1-table where P1-table.col = L1-table.col order by P1-table.col;
</pre>
<p>
このクエリでは ORDER BY 句があるため S 状態となり、FROM句、WHERE句、TARGETLISTは P 状態となります。
このようなクエリでは以下のように書き換えられます。
</p>
<pre>
SELECT P1-table.col, L1-table.col FROM
dblink(select pool_parallel(SELECT P1-table.col, L1-table.col FROM P1-table,L1-table where P1-table.col = L1-table.col))
order by P1-table.col;
</pre>
<p>
ここでdblinkはpgpool-IIに問い合わせを送信します。
また、pool_parallelは引数のクエリをパラレル実行エンジンをにわたす関数です。
なお、上記はあくまでイメージであり実際に実行可能なクエリではありません。
</p>
<p>
上記の例のように、FROM句、WHERE句、TARGETLISTがすべて P 状態の場合には、
FROM句、WHERE句、TARGETLISTをまとめて並列処理を行います。
<p>
次の例を見てみます。
</p>
<pre>
SELECT L1-table.col FROM L1-table WHERE L1-table.col % 2 = 0 AND L1-table.col IN (SELECT P1-table FROM P1-table) ;
</pre>
<p>
この例では、FROM 句は L 状態、TARGETLISTも L 状態、WHERE句は P 状態のサブクエリを持っているため S 状態となります。
これは以下のように書き換えが行われます。
</p>
<pre>
SELECT L1-table.col FROM dblink(SELECT loadbalance(SELECT L1-table.col FROM L1-table WHERE L1-table.col % 2 = 0 AND TRUE))
WHERE
L1-table.col %2 = 0 AND
L1-table.col IN
(
SELECT P1-Table FROM
dblink(select pool_parallel(SELECT P1-table FROM P1-table))
) ;
</pre>
<p>
ここで、pool_loadbalanceはクエリをいずれかのノードに送信する関数です。
</p>
<h4>集約によるクエリ書き換え</h4>
<p>
集計を行うクエリ(集約関数、GROUP BY )は各ノードに計算させ、システムDBで再集計を行うことにより、
システムDBの負荷を減らしパフォーマンスも向上します。
</p>
<p>
まず、最初にpgpool-IIが実際に行うクエリの書き換えを見てみます。
</p>
<p>
FROM 句が P 状態で count(*) を使ったクエリは、以下のように書き換えが行われます。
</p>
<pre>
select count(*) from P1-table;
-> クエリ書き換え
SELECT
sum(pool_c$1) as count
FROM
dblink(select pool_parallel('select count(*) from P1-table'))
AS pool_$1g (pool_c$1 bigint);
</pre>
<p>
各ノードでcount(*) を計算した後に、システムDBで集計(sum)をすることによ
り、目的が達成できます。
</p>
<p>
上記のようなクエリ書き換えが行われる条件は以下の場合です。
</p>
<ol>
<li>FROM 句がP 状態</li>
<li>ターゲットリストに集約関数(count, sum, min, max,avgのみ対応),GROUP BYに指定したカラムが使われている</li>
<li>WHERE 句がP 状態</li>
<li>HAVING 句 に使われている集約関数(count, sum, min, max,avgのみ対応),
FROM句で定義されているカラム,GROUP BYに指定したカラムのみ使われている。</li>
</ol>
<pre>
例)
select P1-table.col,L1-table.col,count(*),avg(P1-table.col) from P1-table,L1-table wehre P1-table.col %2 = 0 group by P1-table.col,L1-table.coli having count(*) < 100
</pre>
<h3 id="caution_in_parallel_mode">パラレルモードの注意事項</h3>
<p>
パラレルモードでは、クエリの解析の際にカラム名とタイプが必要になります。
そのため、サブクエリのTARGETLISTに式、関数を使っている場合には別名と型名をキャストでつける必要があります。
式、関数に型のキャストがない場合には、text型として処理されますので注意してください。
</p>
<p>
なお、集約関数の場合でかつ集約によるクエリ書き換えが行われる場合には、countはbigint型、sumはnumeric型となります。
min,maxの場合には、引数が日付型の場合には日付型として計算され、それ以外はnumericとして計算されます。
avgはsum/countとして処理されます。
</p>
<h3 id="performance_parallel_mode">パラレルモードのパフォーマンスについて</h3>
<p>
<p>
SELECTの最終実行ステータスとパフォーマンスのおおよその目安は以下のとおりです。
</p>
<table border>
<tr class="header"><th>実行ステータス</th><th>パフォーマンス</th></tr>
<tr><th>L</th><td>パラレルクエリを利用しないのでpgpool-IIのオーバーヘッドを除き、単体ノードとの性能劣化はない</td></tr>
<tr><th>P</th><td>並列処理を行うので高速、特にシーケンシャルスキャンの場合には効果がでる。また、データを分割することでテーブルサイズ(/1台)が小さくなることによりキャッシュに乗りやすくなる </td></tr>
<tr><th>S</th><td>集約によるクエリ書き換えが行われると高速</td></tr>
</table>
<!-- ================================================================================ -->
<h1 id="release">リリースノート</h1>
<ul class="flat_ul">
<li><a href="#release3.3.x">V3.3.x</a></li>
<li><a href="#release3.2.x">V3.2.x</a></li>
<li><a href="#release3.1.x">V3.1.x</a></li>
<li><a href="#release3.0.x">V3.0.x</a></li>
<li><a href="#release2.3.x">V2.3.x</a></li>
<li><a href="#release2.2.x">V2.2.x</a></li>
<li><a href="#release2.1.x">V2.1.x</a></li>
<li><a href="#release2.0.x">V2.0.x</a></li>
<li><a href="#release1.3.x">V1.3.x</a></li>
<li><a href="#release1.2.x">V1.2.x</a></li>
<li><a href="#release1.1.x">V1.1.x</a></li>
<li><a href="#release1.0.x">V1.0.x</a></li>
</ul>
<!-- ================================================================================ -->
<!-- 3.3 -->
<!-- ================================================================================ -->
<hr><a name="release3.3.x"></a>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.3.2"></a>3.3.2 (tokakiboshi) 2013/11/29</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.3.1 に対するバグ修正リリースです。
<h3>バグ修正</h3>
<ul>
<li>レプリケーションモード稼働時、一部のタイムゾーンでタイムスタンプの書き換えが誤っていました。(Tatsuo Ishii)
<p>タイムスタンプの書き換え処理では、現在日時を取得するあめに "SELECT now()" を実行します。
しかし一部のタイムゾーンにおいては、"02:30" のような場合に現在日時のためのバッファの大きさが
十分ではありませんでした。"0900" のように 30 分刻みでのタイムゾーンでないときは、この問題は発生しません。
そのため、これまでこの不具合が報告されたことはありませんでした。</p>
<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-September/002142.html" target="_blank">[pgpool-general: 2113]</a> で報告され、Sean Hogan さんによって修正が提供されました。</p>
</li>
<li>installer: redhat/rpm_installer/getsources.sh での pgpoolAdmin の
バージョン指定方法を修正しました。 (Yugo Nagata)
</li>
<li>Makefile: Makefiles 内の pg_config を $(PG_CONFIG) に置き換えました。
したがって、PostgreSQL のメジャーバージョンが異なる場合には、コンパイル中で上書きされるようになります。(Tatsuo Ishii)
<p>パッチは Christoph Berg さんから提供されました。（<a href="ttp://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html" target="_blank">[pgpool-general: 2127]</a>）</p>
</li>
<li>watchdog: <code>-Werror=format-security</code> をつけてコンパイルしたときの、warning/error を修正しました。(Tatsuo Ishii)
<p>パッチは Christoph Berg さんから提供されました。（<a href="ttp://www.sraoss.jp/pipermail/pgpool-general/2013-September/002156.html" target="_blank">[pgpool-general: 2127]</a>）</p>
</li>
<li>configure: FreeBSD で問題があったため、-lcompat を削除しました。(Tatsuo Ishii)
<p><a href="http://www.pgpool.net/mantisbt/view.php?id=15">bug#15</a> で報告されました。</p>
</li>
<li>pgpool.conf で <a href="#LOG_STANDBY_DELAY">log_standby_delay</a> を設定してないときに
segfault していたのを修正しました。(Tatsuo Ishii)
<p>これは、pool_config.l での log_standby_delay の初期化が誤っていたためです。
<a href="http://www.pgpool.net/mantisbt/view.php?id=74" target="_blank">bug#74</a> として報告されました。</p>
</li>
<li>doc: パラレルモードの制限事項を追記しました。VALUES 句を使った複数行の INSERT はパラレルモードではサポートされていません。(Yugo Nagata)</li>
<li>スタンバイノードがダウンしようとしているときに find_primary_node_repeatedly() が
呼ばれないようにしました。(Tatsuo Ishii)
<p>これによってフェイルオーバの所要時間が短くなります。
<a href="http://www.pgpool.net/mantisbt/view.php?id=75" target="_blank">bug#75</a> として報告され、
パッチを Tatsuo Ishii が編集しました。</p>
</li>
<li>レプリケーションモードと拡張プロトコルを組み合わせた場合に、
データ不整合があったのでこれを修正しました。(Tatsuo Ishii)
<p>JDBC ドライバを使った同時 INSERT で、ノード間でのデータ不整合があるという報告がありました。
この事象は以下の条件で必ず発生します。
</p>
<ol>
<li>レプリケーションモードを使用している</li>
<li>拡張プロトコルを使用している</li>
<li>parse で作成された portal が bind で再利用される</li>
<li>autocommit が on である</li>
<li>SERIAL（シーケンス）を使用している</li>
</ol>
<p>pgpool-II の parse 関数は、クライアントが INSERT (+ 5 の状態）を発行すると、対象テーブルをロックされていることを
認識しています。しかし、bind 関数はそれを認識していませんでした。
一度 parse / bind / execute が完了すると、pgpool は 4 の理由により parse で獲得したロックを解放します。
そして JDBC は portal を再利用しようとし、ロックを獲得しないまま bind からのサイクルを開始してしまいます。
その結果、ロックのない INSERT がノード間でのデータ不整合を引き起こします。
この解決方法としては、bind でテーブルをロックするようにしました。
</p>
<p>この問題は、たいていのユーザは JDBC を autocommit = off で使っているために、
今まで報告されることがありませんでした。off であれば、ユーザが commit / rollback を発行するまで、
parse によるロックが残存するためです。</p>
<p>この不具合は Steve Kuekes さんにより、<a href="http://www.sraoss.jp/pipermail/pgpool-gener" target="_blank">[pgpool-general: 2142]</a> で報告されました。</p>
</li>
<li>クエリキャッシュにおけるメモリ確保サイズの不具合を修正しました。(Tatsuo Ishii)
<p>execute() において、メモリ確保サイズが一部の場合において小さすぎました。</p>
</li>
<li>クエリキャッシュ + 拡張プロトコルの組み合わせで使っている場合に、segfault する可能性があったのを
修正しました。(Tatsuo Ishii)
<p>クエリが "cache safe" でないときに、bind_msg->param_offset が Bind() でセットされていませんでした。
しかし Execute() では無条件に bind_msg->param_offset を使おうとしていました。
</p>
<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=76" target="_blank">bug#76</a> で報告されました。</p>
</li>
<li>クエリキャッシュの hash index エントリがいっぱいにならないようにしました。(Tatsuo Ishii)
<p>hash index エントリがいっぱいになると、pgpool-II は hash index の残りが少なくとも 1 つはある前提だったため、
古いキャッシュエントリを再利用できませんでした。
これを改善するために、hash index エントリがいっぱいになったら、再利用できるキャッシュブロックを
探すようにしました。</p>
<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=70" target="_blank">bug#70</a> で報告されました。</p>
</li>
<li>installer: checkEnv() が何もせず必ず 0（成功）を返していました。(Nozomi Anzai)</li>
<li>clock hand の不適切なサイズの共有メモリ確保を修正しました。(Tatsuo Ishii)
<p>clock hand のメモリは、sizeof(pool_fsmm_clock_hand) 分確保されており、
この変数が「<code>static int *pool_fsmm_clock_hand</code>」と定義されていることから、8 バイトでした。</p>
<p>しかしこれは誤りで、実際に必要なのは「<code>sizeof(*pool_fsmm_clock_hand)</code>」での 4 バイトでした。</p>
<p>これは Coverity "1111476 Wrong sizeof argument" で発見されました。</p>
</li>
<li>"<a href="#pool_status">show pool_status</a>" で
<a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a> が常に
0 と表示されていました。 (Tatsuo Ishii)
<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=80" target="_blank">bug#80</a> で報告されました。</p>
</li>
<li>read_password_packet() のエラーメッセージを修正しました。(Tatsuo Ishii)</li>
<li>watchdog: 一部関数で、引数を指定するのに大きな値そのものを渡さず、そのポインタを渡すようにしました。
(Yugo Nagata)</li>
<li>SSL 要求でのメモリリークを修正しました。(Tatsuo Ishii)
<p>SSL での要求があったとき、pgpool 子プロセスは start up packet の読み込みをリトライしていました。
しかし子プロセスは、以前の start up packet のメモリを解放していませんでした。</p>
<p>これは Coverity "1111443 Resource" で発見されました。</p>
</li>
<li>do_query() がタイムスタンプの書き換えに失敗したとき、メモリリークしていました。(Tatsuo Ishii)
<p>この修正のために、free_select_result() で NULL 引数を受け取れるようにしました。</p>
<p>これは Coverity "1111454, 1111455 Resource leak" で発見されました。</p>
</li>
<li>レプリケーションモードでのロードバランスにおける不具合を修正しました。(Tatsuo Ishii)
<p>load_balance_mode = off のとき、書き込みを関数を使った SELECT はすべての DB ノードに送られるべきでした。</p>
<p>これは <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-October/002250.html" target="_blank">
[pgpool-general: 2221]</a> で報告されました。
また、この不具合は <a href="http://git.postgresql.org/gitweb/?p=pgpool2.git;a=commitdiff;h=1ac45a28258074ea4d9d902aca016f970d31f311" target="_blank">3.3.1</a> で混入しました。
</p>
</li>
<li>watchdog: ping 結果を格納する文字列で、終端に NULL 文字を追加しました。（Yugo Nagata)</li>
<li>"<code>DEALLOCATE portal|statement</code>" 実行時の対象ノードの選定ロジックを修正しました。(Tatsuo Ishii)
<p>"<code>DEALLOCATE portal|statement</code>" 実行時、最後の prepared statement や portal が見つからない場合に、
対象ノード選定マップがセットされていませんでした。
おそらく、そうした場合はエラーなので、実際には問題ありません。</p>
<p>これは Coverity "1111491 Structurally dead code" で発見されました。</p>
</li>
<li>MAX_NUM_BACKENDS の範囲チェックにおける不具合を修正しました。 (Tatsuo Ishii)
<p>MAX_NUM_BACKENDS は DB ノードの最大数が限界値でした（現時点では 128）。
実際には 128 の DB ノードで試す人がいなかったために、発見されなかった不具合のようです。</p>
<p>これは Coverity "1111429, 1111430 and 1111431 Out-of-bounds write" で発見されました。</p>
</li>
<li>フロントエンド接続情報を、すでに無効なバックエンドについて set/unset しないようにしました。(Tatsuo Ishii)
<p>この不具合は <a href="http://www.pgpool.net/mantisbt/view.php?id=82" target="_blank">bug#82</a> で報告されました。</p>
</li>
<li>pgpool_catalog への public access を許可していませんでした。
<p>これは、pgpool_catalog がレプリケーションモードで作成されている場合に、
ユーザテーブルにデータを INSERT すると発生します。</p>
<p>この不具合は <a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2013-November/001228.htm" target="_blank">[pgpool-general-jp: 1229]</a> で報告されました。</p>
</li>
<li>doc: <a href="#TRUSTED_SERVERS">trusted_servers</a> に複数のサーバを指定すべきであることを記述しました。
(Yugo Nagata)</li>
<li>pool_do_auth() のエラーケースで変数を初期化していませんでした。 (Tatsuo Ishii)
<p>有効なバックエンドがいないとき、pgpool は認証フェーズのフロントエンドにごみの pid を返していました。
実際に、有効なバックエンドがいないために、フロントエンドは認証後に接続することができません。
もちろんこれは問題あるものではありません。</p>
<p>これは Coverity "1127331 Uninitialized scalar variable" で発見されました。</p>
</li>
<li>ノード ID を使ったエラーメッセージの発行時に、ノード ID の範囲チェックをするようにしました。
(Tatsuo Ishii)
<p>これは Coverity "1111433 "Out-of-bounds read" で発見されました。</p>
</li>
<li>parse_copy_data() でのバッファオーバーランとリソースリークを修正しました。 (Tatsuo Ishii)
<p>これは Coverity "1111427 Out-of-bounds write"、"1111453 Resource leak" で発見されました。</p>
</li>
<li>CopyDataRaws() で segfault する可能性があったのを修正しました。(Tatsuo Ishii)
<p>pool_get_id() がエラーを返した場合に VALID_BACKEND が配列外にアクセスしようとしていました。</p>
<p>これは Coverity "1111433 Out-of-bounds read" で発見されました。</p>
</li>
<li>クエリキャッシュ有効 + プロトコルバージョン = 2 の組み合わせでの処理を修正しました。(Tatsuo Ishii)
<p>プロトコルバージョンが 2 のとき、セッション状態が "idle" である前提でしたが、
実際にはそうではありませんでした。
プロトコルバージョンが 2 の場合はクエリキャッシュを使用しないことをおすすめします。</p>
<p>これは Coverity "1111488 Uninitialized scalar variable" で発見されました。</p>
</li>
<li>pool_pools() での strftime() の用法を修正しました。(Tatsuo Ishii)
<p>バッファが第 2 引数で期待する値にたいして十分な大きさではありませんでした。
実際にはそのような長い値がわたることはなく、問題ないものです。</p>
<p>これは Coverity "1111426 Out-of-bounds access" で発見されました。</p>
</li>
<li>RPM: spec ファイルで、pgpool-II と PostgreSQL のバージョンを指定できるようにしました。(Nozomi Anzai)</li>
<li>make_persistent_db_connection のリソースリークを修正しました。(Tatsuo Ishii)
<p>この修正ののために、新しく free_persisten_db_connection_memory 関数を追加しました。</p>
<p>これは Coverity #1111468 で発見されました。</p>
</li>
<li>watchdog: RTT が非常に短いときに <a href=#TRUSTED_SERVERS">trusted servers</a> への
コネクションチェックに失敗する不具合をを、修正しました。(Yugo Nagata)
</li>
<li>Coverity で見つかったさまざまな不具合を修正しました。(Tatsuo Ishii)</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.3.1"></a>3.3.1 (tokakiboshi) 2013/09/06</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.3.0 に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>
tar ball 作成時にレグレッションテストを含めるよう修正しました。(Tatsuo Ishii)
<p>
3.3.0 リリースの tar ball にはレグレッションテストが含まれていませんでした。
</p>
</li>
<li>
レグレッションテストの watchdog テストスクリプトを修正しました。(Tatsuo Ishii)
</li>
<li>
メモリオーバーランを修正しました。(Tatsuo Ishii)
<p>
このバグは [pgpool-general: 1956] で Sean Hogan さんにより指摘されました。
</p>
<blockquote>
[pgpool-general: 1956] memory overrun bug?<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001984.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001984.html
</a>
</blockquote>
</li>
<li>
コンパイル時のエラーを修正しました。(Yugo Nagata)
</li>
<li>
オンメモリクエリキャッシュ使用時に子プロセスが sig abort で異常終了するバグを修正しました。
(Tatsuo Ishii)
<p>
parse メッセージの後に複数の bind/execute メッセージが来た場合に発生していた、メモリの二重開放がこのバグの原因です。
parse メッセージが来ると、クエリコンテキストと共に一時的なキャッシュが作成され、
クエリの実行時にこの一時キャッシュを指すポインタが配列に追加されます。そして、続く複数の bind
メッセージがこの同じポインタを使用することが、キャッシュ削除の際に二重開放を引き起こす原因となっていました。
</p>
<p>
このバグはバグトラック #68 にて harukat さんにより報告されました。
</p>
<blockquote>
#68: child process termination with sigabort when memory_cache_enabled = on<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=68">
http://www.pgpool.net/mantisbt/view.php?id=68
</a>
</blockquote>
</li>
<li>
いくつかのテストケースをレグレッションテストに追加しました。(Tatsuo Ishii)
</li>
<li>
ドキュメントの pgpool-recovery のインストールの節の typo を修正しました。(Tatsuo Ishii)
</li>
<li>
ログメッセージの typo を修正しました。 (Yugo Nagata)
</li>
<li>
日本語ドキュメントの typo を修正しました。 (Yugo Nagata)
</li>
<li>
レプリケーションモードにてロードバランスモードが off の場合には、SELECT
クエリをマスターノードにのみ送信するよう修正しました。(Tatsuo Ishii)
<p>
レプリケーションモードでロードバランスモードが off の場合には、明示的なトランザクションの中で
SELECT クエリは、全てのノードにではなく、マスターノードにのみ送られなくてはなりません。
</p>
<p>
このバグは [pgpool-general: 2038] にて Rypl Lukas さんにより報告されました。
</p>
<blockquote>
[pgpool-general: 2038] SELECT sent to both nodes in replication mode<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-August/002066.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-August/002066.html
</a>
</blockquote>
</li>
<li>
pgpool_setup が単独で動作しなくなっていたのを修正しました。(Tatsuo Ishii)
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.3.0"></a>3.3.0 (tokakiboshi) 2013/07/30</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.3 系列の最初の版で、3.2 系からの「メジャーバージョンアップ」にあたります。
</p>
<h3>互換性のない変更</h3>
<p>以下は全て watchdog に関する変更です。詳細は以下の<a href="3.3_new_features">新機能</a>の項目を
参照してください。</p>
<ul>
<li>デフォルトの監視方法がクエリモードからハートビートモードに変更されました。</li>
<li>failover/failback コマンドが１つの pgpool-II でのみ実行されるようになりました。</li>
<li>デフォルトで、アクティブ pgpool-II への昇格時には共有メモリ内のクエリキャッシュを
全て削除するようになりました。</li>
<li>クエリモードで他の pgpool-II を監視する際に用いられるデータベース名、ユーザ名、パスワードは
専用のパラメータで指定されるようになりました。
以前は template1, <a href="#RECOVERY_USER">recovery_user</a>,
<a href="#RECOVERY_PASSWORD">recovery_password </a> が使われていました。</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h3 id="3.3_new_features">新機能</h3>
<h4>watchdog</h4>
<ul>
<li>UDP のパケットのハートビート信号を用いた新しい監視方法が追加されました。(Yugo Nagata)
<p>「ハートビート」モードと「クエリ」モードのから監視方法を選ぶことができます。</p>
<dl>
<dt>ハートビートモード</dt>
<dd>
<p>ハートビートモードは今回新しく追加された方法です。</p>
<p>
このモードでは、watchdog はハートビート信号を用いて 他の pgpool-II プロセスの死活監視を行います。
watchdog は、他の pgpool-II の watchdog より定期的に送られるハートビート信号を受け取り、
これが一定期間以上途切れた場合にはその pgpool-II プロセスに障害が発生したと判断します。
</p>
<p>冗長性を高めるため、複数のネットワーク用いたハートビート交換が可能です。</p>
<p>デフォルトではこのモードで動作し、これが推奨設定です。</p>
</dd>
<dt>クエリモード</dt>
<dd>
<p>
クエリモードでは従来と同じ動作になります。
このモードではwatchdog は pgpool-II のプロセスではなく「サービス」の応答を監視します。
このモードでは、監視対象の pgpool-II にクエリを発行しその応答をチェックします。
</p>
<p>
この方法では他の pgpool-II から接続を受ける必要があるため、
<a href="#NUM_INIT_CHILDREN">num_init_children</a> が十分大きくない場合には
監視が失敗する場合があることに注意してください。
</p>
<p>これは非推奨の監視方法であり、下位互換のために残されています。</p>
</dd>
</dl>
<p>以下のパラメータが追加されました。</p>
<ul>
<li><a href="#WD_LIFECHECK_METHOD">wd_lifecheck_method</a></li>
<li><a href="#WD_HEARTBEAT_PORT">wd_heartbeat_port</a></li>
<li><a href="#WD_HEARTBEAT_KEEPALIVE">wd_heartbeat_keepalive</a></li>
<li><a href="#WD_HEARTBEAT_DEADTIME">wd_heartbeat_deadtime</a></li>
<li><a href="#HEARTBEAT_DESTINATION">heartbeat_destinationX</a></li>
<li><a href="#HEARTBEAT_DESTINATION_PORT">heartbeat_destination_portX</a></li>
<li><a href="#HEARTBEAT_DEVICE">heartbeat_deviceX</a></li>
</ul>
</li>
<li>filover/failback コマンドを排他的に実行するインターロック機能が追加されました。(Yugo Nagata)
<p>
watchdog で複数の pgpool-II を連携した場合、failover/failback コマンド
（<a href="#FAILOVER_COMMAND">failover_command</a>, <a href="#FAILBACK_COMMAND">failback_command</a>,
<a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a>）は１つの pgpool-II でのみ実行されます。
</p>
<p>以前は、これらのコマンドは全ての pgpool-II で実行されていました。</p>
</li>
<li>watchdog パケット通信に認証機構が追加されました。(Yugo Nagata)
<p>
間違った認証キーを持つ pgpool-II から送られた watchdog パケットは拒絶されます。（ハートビート信号を含む）
全ての pgpool-II は同じキーを pgpool.conf の wdauthkey パラメータに持っている必要があります。
間違った認証キーを持っていると、スタートアップパケットも他の pgpool-II から拒絶されるため、
起動することもできません。
</p>
</li>
<li><a href="#CLEAR_MEMQCACHE_ON_ESCALATION">clear_memqcache_on_escalation</a> パラメータを
追加しました。(Yugo Nagata)</dt>
<p>これが on の場合は、pgpool-II がアクティブに昇格した時に、
共有メモリ上のメモリキャッシュが全てクリアされます。</p>
<p>これは、新しいアクティブの pgpool-II が以前のアクティブと矛盾する
古いキャッシュを使わないようにするためです。</p>
</li>
<li><a href="#WD_ESCALATION_COMMAND">wd_escalation_command</a> パラメータを追加しました. (Yugo Nagata)
<p>
このパラメータに指定されたコマンドは、pgpool-II がアクティブに昇格した時に実行されます。
実行のタイミングは、仮想 IP が立ち上がった直後です。
</p>
</li>
<li><a href="#WD_LIFECHECK_DBNAME">wd_lifeccheck_dbname</a>, <a href="#WD_LIFECHECK_USER">wd_lifecheck_user</a>,
<a href="#WD_LIFECHECK_PASSWORD">wd_lifecheck_password</a> パラメータを追加しました。(Yugo Nagata)
<p>
これらのパラメータは、クエリモードで監視の際に使用するデータベース名、ユーザ名、パスワードを提要します。
以前はそれぞれ templat1, <a href="#RECOVERY_USER">recovery_user</a>,
<a href=="#RECOVERY_PASSWORD">recovery_password</a> が使われていました。
</p>
</li>
<li><a href="#DELEGATE_IP">delegate_ip</a> オプションが空の場合には、
仮想 IP の立ち上げ/切り替えを行わないようになりました。(Yugo Nagata)
<p>これにより、各 pgpool-II に固定 IP を用いてアクセスするマルチマスタ的運用で、
仮想 IP を用意する必要がなくなりました。</p>
</li>
<li><a href="#pcp_watchdog_info">pcp_watchdog_info</a> コマンドを追加しました。(Yugo Nagata)</dt>
<p>これは watchdog ステータスを取得する pcp コマンドです。</p>
</li>
</ul>
<h4>その他</h4>
<ul>
<li>PostgreSQL 9.2 の raw パーサを取り入れました。 (Nozomi Anzai, Tatsuo Ishii)</li>
<li>pgpool_setup を追加しました。(Tatsuo Ishii)</dt>
<p>これはカレントディレクトリ下 pgpool-II と PostgreSQL のテスト環境を構築するツールです。</p>
<pre>
ex.) $ ./pgpool_setup -m s
usage: pgpool_setup [-m r|s][-n num_clusters][--no-stop]
-m s: ストリームレプリケーションモードで構築（デフォルト）
-m r: ネイティブレプリケーションモードで構築
-n num_clusters: num_clusters 台で PostgreSQL データベースクラスタノードを作成
-p base_port: ベースとなるポート番号を指定。最初の PostgreSQL ノードのポートは
base_port, 次の PostgreSQL ノードのポートは base_port + 1, n 番目
の PostgreSQL ノードのポートは base_port + n-1, pgpool のポートは
base_port + n, pcp のポートは base_port + n + 1 となる。
--no-stop: セットアップ終了後に pgpool-II, PostgreSQL を終了しない
</pre>
</li>
<li>pgpool-recovery, pgpool-regclass を CREATE EXTENSION を使って
インストールできるようになりました。(Tatsuo Ishii)
<p>古いインストール方法も継続して利用可能です。</p>
<p>
エクステンションの名前が "pgpool-recovery", "pgpool-regclass" ではなく
"pgpool_recovery", "pgpool_regclass" であることに注意してください。
前者では二重引用符が必要であり CREATE EXTENSION コマンドでは不便なためです。
</p>
</li>
<li><a href="#pgpool_pgctl">pgpool_pgctl() 関数</a> を追加しました。(Nozomi Anzai)
<p>これを用いると、SQL から pg_ctl stop/restart/reload の実行が可能です。（ただし、start は除きます。）</p>
<pre>
$ psql sales -c "select pgpool_pgctl('reload', 'fast')";
pgpool_pgctl
--------------
t
(1 row)
</pre>
<p>
この関数は実行結果を無視して常に 't' を返すため、ユーザは pg_ctl が成功したか失敗したか知ることができません。
この関数を使用するには、セキュリティ上の理由から PostgreSQL で「pgpool.pg_ctl」というカスタム変数を設定し、
データディレクトリへの権限を持ち pg_ctl を実行するユーザを限定する必要があります。
</p>
</li>
<li>pgpool-II と pgpoolAdmin の RPM をインストールするシェルスクリプトを追加しました。
(Nozomi Anzai, Yugo Nagata)
<p>
getsources.sh を実行することで作成された work/installer に RPM ファイルをコピーし、
このディレクトリを tar ボールで固めたものがインストーラパッケージとなります。
このインストーラは、RPM をインストールするだけではなく、postgresql.conf, pgpool.conf, pg_hba.conf
recovery.conf, ファイルオーバやオンラインリカバリ用のスクリプトの設定も行ないます。
</p>
<p>２ノード構成を前提としており、インストールスクリプトは両方のノードで実行する必要があります。</p>
</li>
<li>新しいパラメータ <a href="#SEARCH_PRIMARY_NODE_TIMEOUT">search_primary_node_timeout</a> を追加しました。
(Muhammad Usama, Tatsuo Ishii)
<p>
このパラメータはファイルオーバ時にプライマリノードを探す最大の秒数を指定します。
パッチは Muhammad Usama さんが作成し、日本語マニュアルの作成と、英語マニュアルの若干の修正を
Tatsuo Ishii が行いました。</p>
</li>
<li>オンメモリクエリキャッシュと watchdog の 中国語のチュートリアルを追加しました。(Bambo Huang)</li>
<li>レグレッションテストを作成しました。(Tatsuo Ishii)</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h3>バグ修正</h3>
<ul>
<li>オンラインリカバリ時のフェイルバックの完了待機でタイムアウト処理をするようにしました。(Tatsuo Ishii)
<p>
これによりリカバリが永遠に終わらず pgpool-II が終了できなくなる状況を回避します。
この現象は特に <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a> の実行中に起こり得ました。
</p>
</li>
<li>ストリームレプリケーションモードでの <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a> 実行時に、
%H に新しいプライマリノードが正しく割り当てられないバグを修正しました。(Tatsuo Ishii)
</li>
<li>他の pgpool-II からダウン通知を受け取った pgpool-II が既にアクティブである場合には、
昇格処理を実行しないよう修正しました。(Yugo Nagata)
</li>
<li>watchdog ソケット作成時に、connect() の前に select() を実行していたのを修正しました。(Yugo Nagata)
<p>
未接続のソケットで select() を実行したときの処理は未定義で、プラットフォームで異なります。
Linux では 2 を返し、結果としては無害です。
しかし、Solaris では 0 を返し、これはタイムアウトと区別がつかないため、
watchdog が正しく動いていませんでした。
</p>
</li>
<li>pgpool_regclass がインストールされていない場合に生じるエラーを修正しました。(Tatsuo Ishii)
<p>
pgpool_rgcalss が存在しない場合に、pool_has_pgpool_regcalss() で使われているクエリが失敗していました。
詳しくは、<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001749.html">
[pgpool-general:1722]</a> を参照してください。
</p>
</li>
<li>PostgreSQL がエラーを返したときに do_query() がハングしないよう修正しました。(Tatsuo Ishii)
<p>
典型的な症状が「pg_stat_activety によると SELECT が実行されたままのように見える」というものです。
これを解決するため、pgpool-II は当該プロセスを終了させ、既存のコネクションを捨てるように修正しました。
あまり行儀のよい方法ではありませんが、これが最善の方法と信じています。
</p>
</li>
<li>watchdog を有効にしたときに、フェイルオーバの最中に起こりうるデッドロックを修正しました。(Yugo Nagata)
<p>このバグは、バグトラッカ #54 にて arshu arora さんによって報告されました。</p>
<blockquote>
#54: pgpool-II semaphore lock problem<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=54">
http://www.pgpool.net/mantisbt/view.php?id=54
</a>
</blockquote>
</li>
<li>COMMIT 時エラーに不要なバックエンド切り離しを行わないようにしました。(Tatsuo Ishii)
<p>
マスタースレーブモードで、COMMIT 時にマスターノードでエラーが発生していたとしても、
他のスレーブノードが正常な場合にはバックエンドを切り離す必要はありません。
これは、遅延トリガーのために "kind mismatch error" が発生しうるからです。
</p>
</li>
<li>拡張プロトコルの際に do_query で発生しうるハングアップを修正しました。(Tatsuo Ishii)
<p>
これは insert_lock が有効で、pgpool_catalog.insert_lock が存在することに起こり得ます。
詳しくは <a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html">
[pgpool-general: 1684]</a> を参照してください。
</p>
</li>
<li>トランザクション内の DML で、クエリキャッシュの無効化が失敗する場合があるのを修正しました。(Tatsuo Ishii)
<pre>
CREATE TABLE t1(i INTEGER);
CREATE TABLE t2(i INTEGER);
SELECT * FROM t1;
BEGIN;
DELETE FROM t2 WHERE i = 0;
INSERT INTO t1(i) VALUES(1);
COMMIT;
SELECT * FROM t1;
</pre>
<p>
上の SQL で、COMMIT 発行時に pgpool は t2 のキャッシュを削除しようとしますが、実際には t2 の
OID テーブルエントリがないのでこれは失敗します。そのときに、t1 の OID テーブルの確認までも失敗とみなされ、
直前の t1 の SELECT 結果のキャッシュが不正に残っていました。
</p>
<p>この問題はバグトラッカ #58 で wms さんにより報告されました。</p>
<blockquote>
#58: query cache invalidation does not fire for multiple DML in transaction<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=58">http://www.pgpool.net/mantisbt/view.php?id=58</a>
</blockquote>
</li>
<li>pgpool_regclass を pg_catalog スキーマに登録するよう修正しました。(Tatsuo Ishii)
<p>これは postgres_fdw のような、スキーマ検索パスが pg_catalog に限定されているクライアントに
対応するために必要です。
</p>
</li>
<li>"pgpool -m f stop" で起こるハングアップを修正しました。(Tatsuo Ishii)
<p>
これは管理を外れた子プロセスが終了されずに残ってしまうのが原因で、複数のバックエンドがダウンしたときや、
バックエンドの起動前に pgpool-II が起動した場合に発生することがありました。
</p>
</li>
<li>pg_md5 コマンドで起こりうるクラッシュを修正しました。(Muhammad Usama)</li>
<li>オンメモリクエリキャッシュ有効時に発生するセグメンテーション違反が修正されました。(Tatsuo Ishii))
<p>
これは、拡張クエリモードで実行されたクエリが長い結果を返すときに発生します。
このバグはバグトラック #63 にて、harukat さんにより報告、解析され、テストケースが提供されました。
</p>
<blockquote>
#63 Child process was terminated by segmentation fault with memcached<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=63">
http://www.pgpool.net/mantisbt/view.php?id=63
</a>
</blockquote>
</li>
<li>スタートアップパケットに PostgreSQL ユーザ情報が含まれていなかった場合に発生する子プロセスの
セグメンテーション違反を修正しました。(Yugo Nagata)
<p>このバグは以下を実行することにより再現できます。</p>
<pre>
$ psql -p 9999 -U ''
</pre>
<p>
<a href="#ENABLE_POOL_HBA">enable_pool_hba</a> が有効の場合は子プロセスがセグメンテーション違反で異常終了し、
無効の場合には以下のメッセージがログに出力されていました。
</p>
<pre>
ERROR: pool_discard_cp: cannot get connection pool for user (null) database (null)
</pre>
<p>
また、両方の場合で psql はフロントエンドに何のメッセージ出力せずに終了していました。
修正後は、スタートアップパケットに PostgreSQL ユーザが指定されていない場合には
以下のメッセージがログとフロントエンドの両方に出力されます。
これは PostgreSQLと同じ振る舞いです。
</p>
<pre>
FATAL: no PostgreSQL user name specified in startup packet
</pre>
</li>
<li>オンメモリクエリキャッシュを有効にした時の拡張クエリの処理におけるメモリ割り当てロジックを修正しました。(Tatsuo Ishii)
<p>
バインドパラメータ付きの拡張クエリで、1024 バイト以上の長いクエリ文字列が渡されたときに、
十分なメモリ割り当てができていませんでした。
</p>
</li>
<li><a href="#pcp_recovery_node">pcp_recovery_node</a> コマンドで、
バックエンドノード番号をチェックするように修正しました。(Yugo Nagata)
<p>
不正な値が使用された場合、リカバリで実行されるスクリプトの引数に空の値が渡されており、
誤動作の原因となっていました。
特にベースバックアップを行うスクリプトで、rsync が関係のないファイルを削除してしまうことがありました。
</p>
</li>
<li>バックエンドエラー検出時に発生することがあるメインプロセスの
セグメンテーション違反を修正しました。(Tatsuo Ishii)
<p>この問題はバグトラック #62 で tuomas さんにより報告されました。</p>
<blockquote>
#62 Slave network outage causes a segmentation fault on main process <br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=62">
http://www.pgpool.net/mantisbt/view.php?id=62
</a>
</blockquote>
</li>
<li><a href="#CHILD_LIFE_TIME">child_life_time</a> 使用時に発生しうる
ヘルスチェックのバグを修正しました。(Tatsuo Ishii)
<p>
バックエンドが正しく動作しているにも関わらずフェイルオーバが発生することがありました。
この問題は [pgpool-general: 1892] で larisa sabban さんにより報告されました。
</p>
<blockquote>
[pgpool-general: 1892] Pgpool is unable to connect backend PostgreSQL<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001920.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001920.html
</a>
</blockquote>
</li>
<li>レプリケーションモードにおけるプリペアド文のパース処理を修正しました。
(Tatsuo Ishii)
<p>
レプリケーションモードで SELECT 以外のクエリをパースする際には、ノード間の
一貫性保持のため自動的にトランザクションが開始されますが、トランザクション
を閉じる処理が行われていませんでした。そのため、実際に誤っているクエリだけ
ではなく、その次にパース処理されたクエリもアボートされていました。
このバグは [pgpool-general: 1877] で Sean Hogan さんにより報告されました。
</p>
<blockquote>
[pgpool-general: 1877] current transaction is aborted, commands ignored<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html
</a>
</blockquote>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h3>改良</h3>
<ul>
<li>man ページに -D オプションの記述を追加しました。（Tatsuo Ishii)</li>
<li>watchdog のプロセスが異常終了した場合に、これが自動で再起動されるよう修正しました。(Yugo Nagata)</li>
<li>watchdog 有効時に ping コマンドを実行する関数にエラーチェックを追加しました。(Tatsuo Ishii)</li>
<li>sprintf strncpy などの安全でない関数を、より安全な snprintf, strlcpy に置き換えました。(Yugo Nagata)</li>
<li>ログ出力、コメント、関数名で使われていた "sticky bit" という用語を
"setuid bit" に置き換えました。(Yugo Nagata)
<p>この用語は本来とは違う意味で使われており、混乱の元となっていました。</p>
</li>
<li>pool_hba.conf.sample の SSL に関する記述を修正しました。(Tatsuo Ishii)</li>
<li>レプリケーションモードで、明示的なトランザクション内のロードバランスができるようになりました。(Tatsuo Ishii)
<p>ロードバランスが行われる条件は以下のとおりです。</p>
<ol>
<li><a href="#REPLICATE_SELECT">replicate_select</a> が off</li>
<li>書き込みを行う関数が使われていない</li>
<li>トランザクション分離モードが SERIALIZABLE ではない</li>
<li>DML/DDL がトランザクションの中で実行されていない</li>
</ol>
</li>
<li>中国語マニュアルを最新の情報に更新しました。(Bambo Huang)</li>
<li>ドキュメントの <a href="#SSL_CA_CERT">ssl_ca_cert</a> と
<a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a> の記述を SSL セクションに移動しました。(Yugo Nagata)</li>
<li>日本語ドキュメントに <a href="#SSL_CA_CERT">ssl_ca_cert</a> と
<a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a> の記述を加えました。(Yugo Nagata)</li>
</ul>
<!-- ================================================================================ -->
<!-- 3.2 -->
<!-- ================================================================================ -->
<hr><a name="release3.2.x"></a>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.2.6"></a>3.2.6 (namameboshi) 2013/09/06</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.2.5 に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>
バックエンドエラー検出時に発生することがあるメインプロセスのセグメンテーション違反を修正しました。
(Tatsuo Ishii)
<p>
この問題はバグトラック #62 で tuomas さんにより報告されました。
</p>
<blockquote>
#62 Slave network outage causes a segmentation fault on main process<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=62">
http://www.pgpool.net/mantisbt/view.php?id=62
</a>
</blockquote>
</li>
<li>
child_life_time 使用時に発生しうるヘルスチェックのバグを修正しました。(Tatsuo Ishii)
<p>
バックエンドが正しく動作しているにも関わらずフェイルオーバが発生することがありました。この問題は
[pgpool-general: 1892] で larisa sabbanさんにより報告されました。
</p>
<blockquote>
[pgpool-general: 1892] Pgpool is unable to connect backend PostgreSQL<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001920.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001920.html
</a>
</blockquote>
</li>
<li>
マニュアルの「pgpool-IIの配置について」の項目を改訂しました。(Tatsuo Ishii)
<p>
watchdog の使用に関する記述を追加しました。
</p>
</li>
<li>
doc/basebackup.sh スクリプトの ssh コマンドの間違いを修正しました。(Tatsuo Ishii)
</li>
<li>
レプリケーションモードにおけるプリペアド文のパース処理を修正しました。(Tatsuo Ishii)
<p>
レプリケーションモードで SELECT 以外のクエリをパースする際には、
ノード間の一貫性保持のため自動的にトランザクションが開始されますが、
トランザクションを閉じる処理が行われていませんでした。
そのため、実際に誤っているクエリだけではなく、その次にパース処理されたクエリもアボートされていました。
</p>
<p>
このバグは [pgpool-general: 1877] で Sean Hogan さんにより報告されました。
</p>
<blockquote>
[pgpool-general: 1877] current transaction is aborted, commands ignored<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html
</a>
</blockquote>
</li>
<li>
オンメモリクエリキャッシュ使用時に子プロセスが sig abort で異常終了するバグを修正しました。
(Tatsuo Ishii)
<p>
parse メッセージの後に複数の bind/execute メッセージが来た場合に発生していた、メモリの二重開放がこのバグの原因です。
parse メッセージが来ると、クエリコンテキストと共に一時的なキャッシュが作成され、
クエリの実行時にこの一時キャッシュを指すポインタが配列に追加されます。そして、続く複数の bind
メッセージがこの同じポインタを使用することが、キャッシュ削除の際に二重開放を引き起こす原因となっていました。
</p>
<p>
このバグはバグトラック #68 にて harukat さんにより報告されました。
</p>
<blockquote>
#68: child process termination with sigabort when memory_cache_enabled = on<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=68">
http://www.pgpool.net/mantisbt/view.php?id=68
</a>
</blockquote>
</li>
<li>
日本語ドキュメントの typo を修正しました。 (Yugo Nagata)
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.2.5"></a>3.2.5 (namameboshi) 2013/07/10</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>このバージョンは 3.2.4 に対するバグ修正リリースです。</p>
<h3>バグ修正</h3>
<ul>
<li>man ページに -D オプションの記述を追加しました。（Tatsuo Ishii)</li>
<li>オンラインリカバリ時のフェイルバックの完了待機でタイムアウト処理をするようにしました。(Tatsuo Ishii)
<p>
これによりリカバリが永遠に終わらず pgpool-II が終了できなくなる状況を回避します。
この現象は特に <a href="#FOLLOW_MASTER_COMMAND">Wfollow_master_command</a> の実行中に起こり得ました。
</p>
</li>
<li>ストリームレプリケーションモードでの <a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a> 実行時に、
%H に新しいプライマリノードが正しく割り当てられないバグを修正しました。(Tatsuo Ishii)
</li>
<li>watchdog ソケット作成時に、connect() の前に select() を実行していたのを修正しました。(Yugo Nagata)
<p>
未接続のソケットで select() を実行したときの処理は未定義で、プラットフォームで異なります。
Linux では 2 を返し、結果としては無害です。
しかし、Solarisでは 0 を返し、これはタイムアウトと区別がつかないため、watchdog が正しく動いていませんでした。
</p>
</li>
<li>pgpool_regclass がインストールされていない場合に生じるエラーを修正しました。(Tatsuo Ishii)
<p>
pgpool_rgcalss が存在しない場合に、pool_has_pgpool_regcalss() で使われているクエリが失敗していました。
詳しくは、[pgpool-general:1722] を参照してください。
</p>
<blockquote>
[pgpool-general: 1722] [PgPool-II 3.2.4] pgpool_regclass now mandatory? <br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001749.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001749.html
</a>
</blockquote>
</li>
<li>PostgreSQL がエラーを返したときに do_query() がハングしないよう修正しました。(Tatsuo Ishii)
<p>
典型的な症状が「pg_stat_activety によると SELECT が実行されたままのように見える」というものです。
これを解決するため、pgpool-II は当該プロセスを終了させ、既存のコネクションを捨てるように修正しました。
</p>
</li>
<li>watchdog を有効にしたときに、フェイルオーバの最中に起こりうるデッドロックを修正しました。(Yugo Nagata)
<p>
このバグは、バグトラッカ #54 にて arshu arora さんによって報告されました。
</p>
<blockquote>
#54 pgpool-II semaphore lock problem<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=54">
http://www.pgpool.net/mantisbt/view.php?id=54
</a>
</blockquote>
</li>
<li>拡張プロトコルの際に do_query で発生しうるハングアップを修正しました。(Tatsuo Ishii)
<p>
これは insert_lock が有効で、pgpool_catalog.insert_lock が存在することに起こり得ます。
詳しくは [pgpool-general: 1684] を参照してください。
</p>
<blockquote>
[pgpool-general: 1684] insert_lock hangs <br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html
</a>
</blockquote>
</li>
<li>COMMIT 時エラーに不要なバックエンド切り離しを行わないようにしました。(Tatsuo Ishii)
<p>
マスタースレーブモードで、COMMIT 時にマスターノードでエラーが発生していたとしても、
他のスレーブノードが正常な場合にはバックエンドを切り離す必要はありません。
これは、遅延トリガーのために "kind mismatch error" が発生しうるからです。
</p>
</li>
<li>トランザクション内の DML で、クエリキャッシュの無効化が失敗する場合があるのを修正しました。(Tatsuo Ishii)
<pre>
CREATE TABLE t1(i INTEGER);
CREATE TABLE t2(i INTEGER);
SELECT * FROM t1;
BEGIN;
DELETE FROM t2 WHERE i = 0;
INSERT INTO t1(i) VALUES(1);
COMMIT;
SELECT * FROM t1;
</pre>
<p>
上の SQL で、COMMIT 発行時に pgpool は t2 のキャッシュを削除しようとします
が、実際には t2 のOID テーブルエントリがないのでこれは失敗します。そのとき
に、t1 の OID テーブルの確認までも失敗とみなされ、直前の t1 の SELECT 結果
のキャッシュが不正に残っていました。
</p>
<p>この問題はバグトラッカ #58 で wms さんにより報告されました。</p>
<blockquote>
#58 query cache invalidation does not fire for multiple DML in transaction<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=58">
http://www.pgpool.net/mantisbt/view.php?id=58
</a>
</blockquote>
</li>
<li>pgpool_regclass を pg_catalog スキーマに登録するよう修正しました。(Tatsuo Ishii)
<p>これは postgres_fdw のような、スキーマ検索パスが pg_catalog に限定されているクライアントに
対応するために必要です。
</p>
</li>
<li>pg_md5 コマンドで起こりうるクラッシュを修正しました。(Muhammad Usama)</li>
<li>オンメモリクエリキャッシュ有効時に発生するセグメンテーション違反が修正されました。(Tatsuo Ishii))
<p>
これは、拡張クエリモードで実行されたクエリが長い結果を返すときに発生します。
このバグはバグトラック #63 にて、harukat さんにより報告、解析され、テストケースが提供されました。
</p>
<blockquote>
#63 Child process was terminated by segmentation fault with memcached<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=63">
http://www.pgpool.net/mantisbt/view.php?id=63
</a>
</blockquote>
</li>
<li>スタートアップパケットに PostgreSQL ユーザ情報が含まれていなかった場合に発生する
子プロセスのセグメンテーション違反を修正しました。(Yugo Nagata)
<p>このバグは以下を実行することにより再現できます。</p>
<pre>
$ psql -p 9999 -U ''
</pre>
<p><a href="#ENABLE_POOL_HBA">enable_pool_hba</a> が有効の場合は
子プロセスがセグメンテーション違反で異常終了し、
無効の場合には以下のメッセージがログに出力されていました。</p>
<pre>
ERROR: pool_discard_cp: cannot get connection pool for user (null) database (null)
</pre>
<p>また、両方の場合で psql はフロントエンドに何のメッセージ出力せずに終了していました。
修正後は、スタートアップパケットに PostgreSQL ユーザが指定されていない場合には
以下のメッセージがログとフロントエンドの両方に出力されます。
これは PostgreSQLと同じ振る舞いです。
</p>
<pre>
FATAL: no PostgreSQL user name specified in startup packet
</pre>
</li>
<li>オンメモリクエリキャッシュを有効にした時の拡張クエリの処理におけるメモリ割り当てロジックを修正しました。(Tatsuo Ishii)
<p>バインドパラメータ付きの拡張クエリで、1024 バイト以上の長いクエリ文字列が渡されたときに、
十分なメモリ割り当てができていませんでした。
</p>
</li>
<li>マニュアルの <a href="#SSL_CA_CERT">ssl_sa_cert</a>, <a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a>
オプションの説明を SSL セクションに移動しました。(Yugo Nagata)</li>
<li><a href="#SSL_CA_CERT">ssl_sa_cert</a>, <a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a> オプションの説明を
日本語マニュアルに追加しました。(Yugo Nagata)</li>
<li><a href="#pcp_recovery_node">pcp_recovery_node</a> コマンドで、
バックエンドノード番号をチェックするように修正しました。(Yugo Nagata)
<p>不正な値が使用された場合、リカバリで実行されるスクリプトの引数に空の値が渡されており、
誤動作の原因となっていました。
特にベースバックアップを行うスクリプトで、rsync が関係のないファイルを削除してしまうことがありました。
</p>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.2.4"></a>3.2.4 (namameboshi) 2013/04/26</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>このバージョンは 3.2.3 に対するバグ修正リリースです。</p>
<h3>バグ修正</h3>
<ul>
<li>connect_inet_domain_socket_by_port() 関数内で select(2) に渡されるタイムアウトパラメータを
より適切に修正しました。(Tatuo Ishii)
<p>
Solaris などいくつかのプラットフォームでは、タイムアウトのマイクロ秒に
1000000 以上の大きな値を指定することが許されていません。そのため、タイム
アウト値を秒とマイクロ秒に分けて設定するようにしました。
</p>
</li>
<li>connect_inet_domain_socket_by_port() で alarm 割り込み時を受けた時に、
エラー処理を行うよう修正しました。(Tatsuo Ishii)
<p>
この関数が無効なファイルディスクリプタを返すためにヘルスチェックが混乱し、
エラー検出に長時間かかる原因となっていました。
</p>
<blockquote>
[pgpool-general: 1458]<br />
health check timeout in pgpool-II-3.2.3<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general/2013-March/001482.html">
http://www.pgpool.net/pipermail/pgpool-general/2013-March/001482.html
</a>
</blockquote>
</li>
<li>拡張プロトコルの処理における timestamp の書き換えに関する
長い間見過ごされていてたバグを修正しました。(Tatsuo Ishii)
<p>
Parse() 関数は、parse メッセージの書き換えの際に palloc() を使ってメモリを確保していました。
書き換えられたメッセージは pool_create_sent_message()
関数などが管理するデータ領域に格納されますが、これが問題となっていました。
この関数ではデータが session context memory 中に存在することを想定しているのに対し、
palloc() では query context においてメモリの割り当てを行っており、この領域は
query context 終了時に解放されます。しかし、他の関数もこのメモリ領域を解放しようとするため、
セグメンテーション違反や二重解放を含む様々な問題の原因となっていました。
この問題は、書き換えたメッセージを格納するメモリを session context を用いて確保するこで修正されました。
これは pgpool-II 3.0 以来ずっと存在していたバグです。
</p>
<p>この問題は、Naoya Anzai さんによって解析され、パッチが提供されました。</p>
<blockquote>
[pgpoolgenera-jp: 1146]<br />
拡張問い合わせプロトコルでセグメンテーションフォルト<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html">
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html
</a>
</blockquote>
</li>
<li>md5 認証で長いユーザ名を処理する際のバグを修正しました。(Tatsuo Ishii)
<p>
ユーザ名が 32 バイトより長い場合、md5 認証が動作していませんでした。
この問題は [pgpool-general: 1526] で Thomas Martin さんにより報告されました。
</p>
<blockquote>
[pgpool-general: 1526]<br />
[pgPool-II 3.2.3] MD5 authentication and username longer than 32 characters.<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html">
http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html
</a>
</blockquote>
</li>
<li>レプリケーション遅延の計算はスタンバイサーバがプライマリサーバより遅れている場合にのみ
行うよう修正しました。(Yugo Nagata)
<p>
タイミングによってスタンバイよりプライマリの方がレプリケーションが遅延しているように見える場合があり、
その場合には負値の遅延が計算されていました。
この値が符号無し変数に代入されると、実際には遅延が生じていないにも関わらず、
ログに遅延が負値で出力され、されに悪いことには、ロードバランス機能により
SELECT クエリがプライマリに振り分けられ、その結果プライマリの負荷が高まることがありました。
</p>
<p>この問題は Saitoh Hidenori さんによって報告、解析されました。</p>
<blockquote>
[pgpool-genera-jp: 1145]<br />
レプリケーション遅延確認の不具合について<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html">
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html
</a>
</blockquote>
</li>
<li>pgpool-recovery が PostgreSQL 9.3 に対応しました。 (Tatsuo Ishii)
<p>パッチは Asif Rehman さんにより提供され、これに Tatsuo Ishii が若干の修正を加えました。</p>
<blockquote>
[pgpool-hackers: 180] <br />
compile error in ppool-recovery<br />
<a href="http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html">
http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html
</a>
</blockquote>
</li>
<li>pool_has_pgpool_regclass が pgpool_regclass() の実行権限をチェックするよう修正しました。 (Tatsuo Ishii)
<p>
pgpool_regclass が存在する場合でも、pgpool がこの関数を実行できない場合に、
バックエンドへの接続がハングしていました。この問題は、pgpool_regclass
から実行権限を剥奪し、ネイティブレプリケーションモードで INSERT を実行
することで再現可能です。
</p>
<p>この問題は bugtrack #53 で報告されました。</p>
<blockquote>
#53 pgpool_regclas hangs all connections<br />
Date: 2013-04-04 13:35 <br />
Reporter: tmandke<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=53">
http://www.pgpool.net/mantisbt/view.php?id=53
</a>
</blockquote>
</li>
<li>detect_postmaster_down_error() のエラーメッセージを修正しました。(Tatsuo Ishii)
<p>
例えば、"LOG: detect_stop_postmaster_error: detect_error error" を
"LOG: detect_postmaster_down_error: detect_error error" に修正するなどです。
</p>
</li>
<li>watchdog 使用時の root ユーザであるかのチェックを取り除きました。(Tatsuo Ishii)
<p>詳しい議論は以下を参照してください。</p>
<blockquote>
[pgpool-general: 1627]<br />
Re: watchdog root requirement.<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general/2013-April/001654.html">
http://www.pgpool.net/pipermail/pgpool-general/2013-April/001654.html
</a>
</blockquote>
</li>
<li>別名を持つ UPDATE/DELETE の処理におけるオンメモリクエリキャッシュのバグを修正しました。(Tatsuo Ishii)
<p>
別名を持つ UPDATE/DELETE 文（例えば、UPDATE t1 AS foo ...）において、
"t1 AS foo" がテーブル名と認識されていたため、クエリキャッシュの無効化が
うまく働いていませんでした。
これは、パースツリーのノードからクエリ文を生成する nodeToString() 関数から呼び出されている
_outRangeVar() 関数に原因があります。
出力されたクエリ文から "AS foo" の部分を取り除くことで解決しました。
</p>
<p>この問題はバグトラック #56 で報告されました。</p>
<blockquote>
#56 UPDATE with alias does not discard cache<br />
Date: 2013-04-18 17:33 <br />
Reporter: harukat <br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=56">
http://www.pgpool.net/mantisbt/view.php?id=56
</a>
</blockquote>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.2.3"></a>3.2.3 (namameboshi) 2013/02/18</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>pgpool-II 3.2.2 に対するバグ修正リリースです。
おもに、3.2.2 のヘルスチェックに関する致命的な問題を修正するものです。</p>
<p>以下の条件がすべて満たされたとき、フェイルオーバ発生時に pgpool のメインプロセスが消滅し、
pgpool-II へのクライアントの接続がすべてハングします。
また、その状態から復帰するには、pgpool の子プロセスを手動で kill し、pgpool-II を
再起動するしかありませんでした。</p>
<ul>
<li>ヘルスチェックが有効である。 </li>
<li>PostgreSQL への接続を、UNIX ドメインソケットではなく TCP/IP で行なっている
（※ pgpool.conf のバックエンドノード設定において "backend_hostnameN" が空欄でない）。</li>
</ul>
</p>
<h3>バグ修正</h3>
<ul>
<li><a href="#322_bugfix_connect">3.2.2</a> で入り込んだ connect_inet_domain_socket_by_port() の
バグを修正しました。 (Tatsuo Ishii)
<p>
接続において non blocking の connect() が EINPROGRESS や EALREADY という結果を返したときには、
select(2) を呼んで read / write ファイルディスクリプタの準備されるまで待つようにしました。
</p>
<p>
本来は select() が 0 以上を返したときにそうするべきところを、0 を返したときだけになっていました。
その結果、connect_inet_domain_socket_by_port() が実際には失敗しているのに
成功していたと誤って返していました。
</p>
<p>
またさらに、これによって health_check() がバックエンドが生きているものと誤認し、
バックエンドソケットに書き込みを行なおうとし、失敗していました。
これをトリガに notice_backend_error() が呼ばれ、SIGUSR1 シグナルが pgpool のメインプロセスの
親プロセスに送られます。
その結果、pgpool をシェルから起動していれば、シェルを kill する、ということになります。
</p>
<p>
pgpool をバックグラウンドで起動していれば #1 プロセスを kill します。
これは、pgpool を root として起動していなければ問題ありません。
もっとも root として起動していても、SIGUSR1 を受け取って /dev/initctl を再度 open するだけなので、
実際に問題はありません。
</p>
<p>
これらの困った問題は pgpool が誕生した時点から存在していましたが、
connect_inet_domain_socket_by_port() のバグによって表面化しました。
修正には、notice_backend_error() と child_exit() を変更し、
pgpool のメインプロセス自体から呼ばれたときには、自分自身を kill しないように、何も行なわないようにしました。
</p>
</li>
<li>設定パラメータの一覧を表示する "<a href="#pool_status">SHOW pool_status</a>" で
<a href="#POOL_PASSWD">pool_passwd</a> が表示されていないのを修正しました。(Yugo Nagata)</li>
<li>configure.in にある configure のヘルプの typo を修正しました。 (Yugo Nagata)</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.2.2"></a>3.2.2 (namameboshi) 2013/02/08</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>このバージョンは 3.2.1 に対するバグ修正リリースです。</p>
<h3>バグ修正</h3>
<ul>
<li>FreeBSD で発生するコンパイルエラーを修正しました。 (Tatsuo Ishii)</li>
<li>デフォルトのスキーマ（通常は public）以外で作られたビューが
認識されていなかったバグを修正しました。(Tatsuo Ishii)
<p>このバグのため、本来キャッシュされるべきでない、該当するビューのクエリ結果がキャッシュされていました。</p>
<p>この問題はバグトラック #30 で jgentsch さんによって報告され、パッチを提供頂きました。</p>
<blockquote>
#30 pgpool 3.2.1 - views in schema other than public are caching<br />
Reporter: jgentsch<br />
Date: 2012-10-19 23:13<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=30">
http://www.pgpool.net/mantisbt/view.php?id=30</a>
</blockquote>
</li>
<li>md5 認証で競合が発生する不具合が修正されました。(Tatsuo Ishii)
<p>
pool_passwd のファイル識別子は pgpool の親プロセスで開かれたものが子プロセスに引き継がれてます。
複数の接続で同時に md5 認証を行う際には、pool_get_passwd が呼ばれ、ファイル識別子が走査されますが、
ファイル識別子が共有されるために md5 認証が失敗することがありました。
この問題は、個々の子プロセスで pool_passwd ファイルを開き直すことで解決されました。
</p>
<p>この問題は [pgpool-general:1141] にて、Jason Slagle さんによって報告・解析されました。</p>
<blockquote>
[pgpool-general: 1141] Possible race condition in pool_get_passwd<br />
From: Jason Slagle<br />
Date: Sun, 28 Oct 2012 01:12:52 -0400<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html</a>
</blockquote>
</li>
<li>ロードバランスの条件について、より詳しい情報をマニュアルに追記しました。 (Tatso Ishii)</li>
<li>オンメモリクエリキャッシュ使用時に発生するセグメンテーションフォルトを修正しました。
これはキャッシュアレイの処理のバグが原因です。 (Tatsuo Isii)
<p>
トランザクション中の一時キャッシュの結果を保持するためにキャッシュアレイ使用されます。
１つのトランザクションに 128 以上の SELECT がある場合には、キャッシュアレイの領域が
realloc を用いて拡張されます。
しかし、その時に返却される新しいポインタではなく、古いポインタが使われ続けていました。
</p>
<p>この問題はバグトラック #31 にて jgentsch さんによって報告されました。</p>
<blockquote>
#31 pgpool V3_2_STABLE - segfault in pool_memqcache.c:2529<br />
Reporter:jgentsch<br />
Date: 2012-10-23 06:25<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=31">
http://www.pgpool.net/mantisbt/view.php?id=31</a>
</blockquote>
</li>
<li><a href="#pcp_attach_node">pcp_attach_node</a>, <a href="#pcp_detach_node">pcp_detach_node</a> を
繰り返し実行したときに起こるハングアップを修正しました。 (Tatsuo Ishii)
<p>
<a href="#pcp_attach_node">pcp_attach_node</a>, <a href="#pcp_detach_node">pcp_detach_node</a> により
ノードステータスが変更された時、failover() は子プロセスに SIGUSR1 シグナルを送り、
プロセスの終了とノードステータスの更新を行います。
その時に発せられた SIGCHLD シグナルは全て reaper() ハンドラで受信しますが、システムの
負荷とタイミングによりこれが失敗することがありました。pcp プロセスによる SIGCHLD シグナルの
受信に失敗した場合に、これがゾンビプロセスとなり、pcp プロセスが永遠に再起動されなくなって
いました。
</p>
<p>この問題はバグトラック #32（oleg_myrk さんによる）他で報告されました。</p>
<blockquote>
#32 PGPool hangs on pcp_attach/detach<br />
Reporter: oleg_myrk<br />
Date: 2012-10-24 00:01<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=32">
http://www.pgpool.net/mantisbt/view.php?id=32</a>
</blockquote>
</li>
<li>pool_send_severity_message() で未初期化のメモリを使用しないよう修正しました。(Tatsuo Ishii)
<p>
このバグによりセグメンテーション違反が発生することがありました。
バグトラック #33 に投稿された valgrind 実行結果（dudee さんによる）にて報告されました。
</p>
<blockquote>
#33 pgpool-II 3.2.1 segfault<br />
Reporter: dudee<br />
Date: 2012-10-30 19:16<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=33">
http://www.pgpool.net/mantisbt/view.php?id=33</a>
</blockquote>
</li>
<li>通常のテーブルと同名の一時テーブルがあるときに、クエリキャッシュの結果が不正になるバグを
修正しました。 (Tatsuo Ishii)
<p>以下はバグを引き起こす処理の例です。</p>
<pre>
1) CREATE TABLE t1(i int); -- 通常のテーブルを作成
2) INSERT INTO t1 VALUES(1);
3) SELECT * FROM t1; -- クエリキャッシュが作成される
4) CREATE TEMP TABLE t1(i int); -- 一時テーブルの作成
5) SELECT * FROM t1; -- 誤ったクエリキャッシュが作成される！
</pre>
<p>#3 で t1 のキャッシュが生成されますが、#5 でこれが不正に使われており、
一時テーブル t1 が一時テーブルと見なされていないのが問題でした。
</p>
</li>
<li>ヘルプメッセージに -f オプションの説明を追加しました。 (Tatsuo Ishii)</li>
<li>pcp または worker 子プロセスの終了イベントを受信したときに、reaper() で wait3()
ループを終了しないように修正しました。 (Tatsuo Ishii)
<p>修正前は、reaper() は子プロセスの終了イベントを誤って無視してしまい、ゾンビプロセスを作り、
新しいプロセスを生成できないことがありました。</p>
<p>この問題は [pgpool-general-jp: 1123] にて、後藤さんより報告され、修正の示唆を頂きました。</p>
<blockquote>
[pgpool-general-jp: 1123] Re: オンラインリカバリ後にゾンビプロセスになる<br />
From: GOTO, Daisuke<br />
Date: Wed, 21 Nov 2012 19:56:17 +0900<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html">
http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html</a>
</blockquote>
</li>
<li>configure のヘルプメッセージの typo を修正しました。 (Yugo Nagata)</li>
<li><a href="#WD_HOSTNAME">wd_hostname</a> を pool_process_reporting.c に追加しました。 (Yugo Nagata)
<p>
以前は <a href="#pool_status">SHOW pool_status</a>, <a href="#pcp_pool_status">pcp_pool_status</a>
の結果に <a href="#WD_HOSTNAME">wd_hostname</a> が出力されていませんでした。
</p>
</li>
<li>connect(2) が EISCONN（ソケットが接続済み）エラーを返したときには、
connect_inet_domain_socket_by_port() はエラーを出力しないよう修正しました。(Tatsuo Ishii)
<p>
これはノンブロッキングソケットでは起こり得る、正常のこととして扱われるべきです。
バグトラック #29 （by spork）と pgpool-general 1218（by Mikola Rose）で報告されました。
</p>
<blockquote>
#29 pgpool 3.2.1 cannot connect to db hosts<br />
Reporter: spork<br />
Date: 2012-10-18 15:03<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=29">
http://www.pgpool.net/mantisbt/view.php?id=29</a>
</blockquote>
<blockquote>
[pgpool-general: 1218] pgpool 3.2.1 - Health check failing to connect<br />
From: Mikola Rose<br />
Date: Tue, 4 Dec 2012 20:21:55 +0000<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-December/001237.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-December/001237.html</a>
</blockquote>
</li>
<li>health_check() が template1 データベースに再接続を試みる前に、ヘルスチェックタイマーを
チェックするよう修正しました。 (Tastuo Ishii)
<p>
修正前は、ヘルスチェックタイマーが既に期限を向かえているために、0 番ノードへのヘルスチェックの
再接続が常に失敗していました。
</p>
</li>
<li>pool_search_relcache() が REAL_MASTER_NODE_ID ではなく MASTER, MASTER_NODE_ID
を使用するように修正しました。 (Tatsuo Ishii)
<p>
ストリーミングレプリケーションモードで 0 番ノードがフェイルバックした場合、pgpool は
子プロセスを再起動しません。そのとき、REAL_MASTER_NODE_ID は 0 番ノードの接続情報を探しにいきますが、
これはバックエンドへの新しい接続が確立するまで存在しません。
そのため、接続情報の参照によって、セグメンテーションフォルトが発生していました。
この状況でも、MASTER または MASTER_NODE_ID は以前にキャッシュされたマスターノード ID を見にいくため、
安全に使うことが出来ます。
</p>
</li>
<li>ストリーミングレプリケーションモードでレプリケーション遅延が大きくなったときに、
"portal not found" エラーが発生するバグを修正しました。 (Tatsuo Ishii)
<p>これは <a href="#DELAY_THRESHOLD">delay_threshold</a> が導入されて以来、ずっと存在していたバグです。</p>
<p>
bind, describe, execute の実行時に遅延が域値を越えた場合、送り先の DB ノードは
変更されていました。しかし、parse がそれとは異なるノードに送られていた場合、送り先ノードには
parse された ステートメントやポータルが存在しないために bind, describe, execute は
失敗していました。
修正後は、大きな遅延が発生した場合でも、これらは parse が実行されたノード以外には
送られないようになりました。
</p>
</li>
<li>pg_md5 で、ユーザからのパスワード入力の後には改行するように修正しました。 (Yugo Nagata)</li>
<li>watchdog のポート番号が既に使用されていた場合にエラーメッセージを出力するよう修正しました。
(Yugo Nagata)
<p>この問題は [pgpool-general: 1167] で Will Ferguson さんによって報告されました。</p>
<blockquote>
[pgpool-general: 1167] Re: Watchdog error - wd_init: delegate_IP already exists<br />
From: Will Ferguson<br />
Date: Tue, 6 Nov 2012 13:03:36 +0000<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html</a>
</blockquote>
</li>
<li>コネクションプールが存在しない場合には、child_exit() が send_frontend_exits()
を呼ばないよう修正しました。 (Tatsuo Ishii)
<p>
send_frontend_exits() は pool_connection_pool で指されてるオブジェクトを参照しているため、
修正前にはセグメンテーションフォルトが発生していました。バグトラック #44 の tuomas さんの報告によります。
</p>
<blockquote>
#44 pgpool went haywire after slave shutdown triggering master failover<br />
Reporter: tuomas<br />
Date: 2012-12-11 00:33<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=44">
http://www.pgpool.net/mantisbt/view.php?id=44</a>
</blockquote>
</li>
<li>オンメモリクエリキャッシュで、<a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> に
テーブルが指定されている場合に <a href="#WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list</a> に
指定されたテーブルのみがキャッシュされていたバグを修正しました。
(Yugo Nagata)</li>
<li>pool_read() が不正なパケットを読み込んだ場合に、read_startup_packet() がアラームクロック
をリセットして StartupPacket を解放するよう修正しました。 (Nozomi Anzai)
<p>
修正前は、pgpool ポートの監視を行うプログラムの接続により、認証のタイムアウトが発生していました。
この問題は、バグトラック #35 で報告されました。
</p>
<blockquote>
#35 Authentication is timeout<br />
Reporter: tuomas <br />
Date: 2012-11-20 11:54<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=35">
http://www.pgpool.net/mantisbt/view.php?id=35</a>
</blockquote>
</li>
<li>pool_open() が誤ったバッファポインタを初期化していたバグを修正しました。 (Tatsuo Ishii)
<p>
このポインタは事前に memset() によって初期化されているため、実際にはこのバグによる害は
ありませんでした。
</p>
</li>
<li><a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a> が無効のため
フェイルオーバが行われなかった場合には、ログメッセージを出力するようにしました。 (Tatsuo Ishii)</li>
<li>LISTEN/NOTIFY の処理に関するバグを修正しました。 (Tatsuo Ishii)
<p>1) ストリームレプリケーションモードにおいて以下の状況でハングアップが起きていました。</p>
<pre>
Session 1: LISTEN aaa;
Session 2: NOTIFY aaa;
Session 1: LISTEN aaa; --- ハング
</pre>
<p>（LISTEN と NOTIFY が同じセッションで発行された場合には問題ありませんでした。）</p>
<p>
pgpool では、パケットは全てのバックエンドから送られてくることを前提にしていました。
しかし、ストリーミングレプリケーションモードでは notifiction メッセージはプライマリノードからしか
送られて来ません。このハングは、スタンバイノードからのパケット読込を回避することで修正しました。
</p>
<p>
2) この修正後も、ストリーミングレプリケーションモードでプライマリノードが 0 番ノードの場合には、
#1 と同様のハングが発生していました。これは、MASTER_NODE_ID マクロが
常に REAL_MASTER_NODE_ID を返していたためです。 master/slave モードでは、これが
PRIMARY_NODE_ID を返すように修正しました。
</p>
<p>
3) レプリケーションモードでは LISTEN/NOTIFY は全く動作していませんでした。このモード
では NOTIFY は全てのバックエンドに送られます。しかし、その応答の順番はマスターが最初で、
次がスレーブとは限りません。最初にスレーブから応答した場合には、単にそれを破棄するのではなく、
マスターから読込を行うように pool_process_query() を修正しました。
</p>
<p>
4) レプリケーションモードで、LISTEN と NOTIFY が同じセッションから発行された場合、
db_command() が 'N', 'E', 'S', 'C' 以外のパケットを受信するために、そのセッションは切断されていました。
これは、'A'パケットをスタックに入れておき、都合の良いときに取り出すことで解決しました。
そのための関数、pool_push(), pool_pop(), pool_stacklen() が追加されています。
</p>
<p>このバグはバグトラック #45 で rpashin さんにより報告されました。</p>
<blockquote>
#45 LISTEN/NOTIFY doesn't work if cluster contains more then 1 node in<br />
streaming replication mode<br />
Reporter: rpashin <br />
Date: 2012-12-12 00:09<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=45">
http://www.pgpool.net/mantisbt/view.php?id=45</a>
</blockquote>
<p>
修正のサイズが大きいため、この修正は 3.1 以前にはバックパッチされません。
（これまでのところ、3.1 以前でこの障害の報告はありません。）
</p>
</li>
<li id="322_bugfix_connect">connect(2) が EINPREGESS または EALREADY エラーを返したときには、
connect_inet_domain_socket_by_port() は エラーを出力せずに、select(2) を実行するよう
修正しました。 (Tatsuo Ishii)
<p>
ノンブロッキングソケットでは、"Connection timed out" エラーにもかかわらず、実際には
接続は確立されています。これを解決するためには、connect(2) が EINPROGRESS または
EALREADY を返した場合には、再試行ループではなく select(2) を使って接続を待つ必要があります。
</p>
<p>この問題は、バグトラック #46 で mcousin さんにより報告されました。</p>
<blockquote>
#46 Watchdog failing to connect sometimes<br />
Reporter: mcousin <br />
Date: 2012-12-15 01:01<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=46">
http://www.pgpool.net/mantisbt/view.php?id=46</a>
</blockquote>
</li>
<li>watchdog 使用時は <a href="#NUM_INIT_CHILDREN">num_init_children</a> を大きめに設定するよう、
マニュアルに注意書きを追記しました。 (Tatsuo Ishii)
<p>詳しくは [pgpool-general: 1330] をご覧ください。</p>
<blockquote>
[pgpool-general: 1330] WatchDog and pgool sudden stop working<br />
From: Tomas Halgas<br />
Date: Fri, 18 Jan 2013 14:47:23 +0100<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-January/001350.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-January/001350.html</a>
</blockquote>
</li>
<li>watchdog を有効にしたときに、 pgpool-II の起動時、フェイルオーバ時に発生する
セグメンテーションフォルトを修正しました。 (Yugo Nagata)
<p>
このバグの原因は pthread_detach と pthread_join を併用するという pthread の誤使用でした。
スレッドのステータス取得のため、pthread_join のみを用いることで修正しました。
なお、この問題は Fedora 17 などの比較的最近の OS で発生しましたが、
幸運にも他の OS では観察されていませんでした。
</p>
<p>この問題は [pgpool-general: 1179] にて、Lonni J Friedman さんによって報告されました。</p>
<blockquote>
[pgpool-general: 1179] 3.2.1 segfaults at startup on Fedora17.<br />
From: Lonni J Friedman<br />
Date: Mon, 12 Nov 2012 15:58:29 -0800<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001198.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001198.html</a>
</blockquote>>
<p>修正パッチはバグトラック #48 にて、chads さんによって提供頂きました。</p>
<blockquote>
pthread_detach is being used wrong; causes pgpool to segfault.<br />
Reporter: chads <br />
Date: 2013-01-16 05:44<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=48">
http://www.pgpool.net/mantisbt/view.php?id=48</a>
</blockquote>
</li>
<li>[pgpool-general: 1046] で報告されたスプリットブレインが発生しないよう修正しました。(Yugo Nagata)
<p>
全てのバックエンドから切り離された pgpool-II にバックエンドを復帰させた時に、複数の
アクティブ pgpool が存在してしまう状況（スプリットブレイン）が発生していました。
修正後は、一度全てのバックエンドから切り離された pgpool-II は、再起動されない限り、
ダウン状態に留まります。ダウン状態の pgpool-II はアクティブになれないため、
上述のスプリットブレインは回避されます。
</p>
<blockquote>
[pgpool-general: 1046]<br />
watchdog enabled delegate_IP on multiple nodes simultaneously<br />
From: Lonni J Friedman<br />
Date: Wed, 26 Sep 2012 09:05:09 -0700<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001064.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001064.html</a>
</blockquote>
</li>
<li>アクティブ pgpool の終了時にハングすることがあったのを修正しました。(Yugo Nagata)
<p>
アクティブ pgpool は終了時に仮想 IP を停止してパケットを他の pgpool に送ります。
しかし、仮想 IP が完全に停止する前にパケットが送信されることがありました。その場合、
パケットの送信元には仮想 IP がセットされるため、仮想IPの停止後はアクティブ pgpool パケットの
応答を受け取れなくなり、ハングしていました。
</p>
<p>修正後は、アクティブ pgpool は仮想 IP の停止を確認した後に、パケットを送信します。</p>
</li>
<li>マニュアルの「watchdogの制限事項」の項目を加筆・修正しました。 (Yugo Nagata)</li>
<li>pgpool.conf.sample* およびドキュメント中の、「パラメータ変更に再起動が必要かどうか」の情報を
追記・修正しました。 (Yugo Nagata)</li>
<li>pool_passwd に関する記述を pgpool_conf.sample*、 ドキュメント、 および
pool_process_reporting.c に追加しました。 (Yugo Nagata)
<p>
修正前は、<a href="#pool_status">SHOW pool_status</a>, <a href="#pcp_pool_status">pcp_pool_status</a> の出力に
<a href="#POOL_PASSWD">pool_passwd</a> が含まれていませんでした。
</p>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.2.1"></a>3.2.1 (namameboshi) 2012/10/12</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.2.0 に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>send_cached_messages() を修正しました。 (Tatsuo Ishii)
<p>
これまでは、行データが 8192 byte 以上のときはバッファ長を 8192 byte に修正して
キャッシュしているだけでした。
</p>
<p>
これを、引数としてわたってきたバッファ用の raw データのコピーを削除して、
send_message へのポインタを無視するようにしました。
</p>
</li>
<li>クエリキャッシュ機能により、拡張問い合わせが失敗していたのを修正しました。 (Nozomi Anzai)</li>
<li>read_startup_packet() を修正しました。(Tatsuo Ishii)
<p>
パケット長が 0 以下のときは直ちに return するべきでしたが、そうなっていなく、
メモリ確保時にエラーになっていました。
</p>
<p>これは pgpool-general:886 を参照してください。また、キャンセルアラームを追加しました。</p>
<blockquote>
[pgpool-general: 886] read_startup_packet: out of memory<br>
From: Lonni J Friedman<br>
Date: Wed, 8 Aug 2012 10:18:15 -0700<br>
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html</a>
</blockquote>
</li>
<li>pgpool をシャットダウンするときに、watchdog のプロセス終了方法を修正しました。 (Tatsuo Ishii)
<p>
watchdog プロセスは kill(0,SIG) を呼んで watchdog 関連のプロセスを終了していました。
これによってかえって、親プロセスや pgpool や httpd プロセスまでもを終了させることがありました。
これは、pgpoolAdmin によって invoke されている場合に、すべてが同じプロセスグループになるためです。
</p>
<p>将来は、どんな場合でもsetsid()によって新しいプロセスグループを作るべきだと思います。</p>
</li>
<li>"-- コメント" で始まったりコメントが複数あるクエリで、
クエリキャッシュが使えなかったのを修正しました。(Nozomi Anzai)
</li>
<li>マルチステートメントのクエリはキャッシュしないようにしました。(Nozomi Anzai)
<p>これまでは "SELECT 1;UPDATE..." のようなクエリもキャッシュしていましたが、誤りでした。</p>
</li>
<li>ドキュメントに watchdog の制限を追記しました。(Yugo Nagata)</li>
<li>s_do_auth() に NOTICE メッセージを追加しました。(Tatsuo Ishii)
<p>これがなかったために、ヘルスチェックが false アラームを受け取りフェイルオーバしていました。</p>
<p>これはバグトラックで報告されました。</p>
<blockquote>
#25 s_do_auth doesn't handle NoticeResponse (N) message<br>
Date: 2012-08-28 03:57<br>
Reporter: singh.gurjeet<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=25">http://www.pgpool.net/mantisbt/view.php?id=25</a>
</blockquote>
</li>
<li>s_do_auth() から、不要かつ混乱をまねくデバッグメッセージを削除しました。(Tatsuo Ishii)</li>
<li>メモリキャッシュ有効時に Execute() でバッファオーバーランするのを修正しました。(Tatsuo Ishii)
<p>
bind パラメータのひとつが 0 より小さいとき、符号拡張のために "%02X" で
2 バイト以上の文字を生成する可能性がありました。
</p>
<p>
また、そのあとにバッファオーバランを招く可能性を排除するため、sprintf()
ではなく snprintf() を使うようにしました。
</p>
</li>
<li>2009 年 12 月にリリースした pgpool-II 2.3 以来ずっと存在した
free_select_result() のメモリーリークを修正しました。(Tatsuo Ishii)
<p>
実際にはこのバグは、レプリケーションモードでしか発生しません
（タイムスタンプ書き換え時に偶然発生することがありました）。
</p>
<p>これはバグトラック #24 で報告されました。</p>
<blockquote>
#24 Severe memory leak in an OLTP environment<br>
Date: 2012-08-28 03:43<br>
Reporter: singh.gurjeet<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=24">http://www.pgpool.net/mantisbt/view.php?id=24</a>
</blockquote>
</li>
<li>cache_reporting() の typo を修正しました。(Tatsuo Ishii)</li>
<li>SSL モードでの無限ループを修正しました。 (Tatsuo Ishii)
<p>
フロントエンドの SSL レイヤで溜っているデータがあるとき、
pool_process_query() がバックエンドに溜っているデータをチェックします。
もしそれが無かったときは再度ループして、フロントエンド/バックエンドがバッファを受け取っていないか
is_cache_empty() を以ってチェックします。
しかし、フロントエンドの SSL レイヤでデータが溜っているのを一度検知すると、
バックエンドに行ってまたチェックしようとします（無限ループ）。
</p>
<p>
これを解決するには、フロントエンドの SSL レイヤに溜っているデータがあり
かつ クエリが実行中でなければ、ProcessFrontendResponse() を呼んで
フロントエンドへの新しいリクエストをするようにしました。
</p>
</li>
<li>is_system_catalog() で、可能ならば pgpool_regclass を使うようにしました。(Tatsuo Ishii)</li>
<li>pool_get_insert_table_name() のメモリリークを修正しました。(Tatsuo Ishii)
<p>
nodeToString() でセッションコンテクストのメモリコンテクストを使ったあと、
セッション終了までは、メモリを開放していませんでした。
</p>
<p>詳しくはバグトラックをご覧ください。</p>
<blockquote>
#24 Severe memory leak in an OLTP environment<br>
Date: 2012-08-28 03:43<br>
Reporter: singh.gurjeet<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=24">http://www.pgpool.net/mantisbt/view.php?id=24</a>
</blockquote>
</li>
<li>OID マップファイルをロックするのに flock(2) ではなく fcntl(2) を使うようにしました。(Tatsuo Ishii)
<p>
flock(2) は環境に依存し、Solaris で使えませんでした。
パッチは Ibrar Ahmed さんからいただきました。
</p>
</li>
<li>Raw モードで稼働しているとき、get_next_master_node() で見落としがあったのを修正しました。(Tatsuo Ishii)
<p>マスタノードがダウンしたとき、必ずマスタノード ID 0 を返していました。</p>
<p>詳細は [pgpool-general: 1039] をご覧ください。</p>
<blockquote>
[pgpool-general: 1039] Raw failover not working as expected on pgpool-II v3.2.0
From: Quentin White<br>
Date: Tue, 25 Sep 2012 07:45:34 +0000<br>
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001057.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-September/001057.html</a>
</blockquote>
</li>
<li>do_query() のセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
<p>
クエリキャッシュが有効で拡張問い合わせが使われているとき、do_query() はシステムカタログに接続し、
pool_read2() を使います。
しかし、parse メッセージパケットを Parse() で取得し、パケットの内容が pool_read2() のバッファにあります。
このため、do_query() はパケットの内容を分割できず、セグメンテーションフォルトを引き起こしていました。
</p>
<p>
これを解決するために、メモリを確保し、パケット内容をコピーし、Parse() を飛ばすようにしました。
ただし、パケットの中にはクエリコンテクストが参照しているクエリ文字列も含まれています。
そのため、このクエリ文字列をコピーしてポインタをクエリコンテクストに保持する必要があります。
</p>
<p>
これは、Parse() だけの話でなく、他のプロトコルモジュールにもある問題と考えています。
本修正はそれらにも適用しますが、そのためには、ProcessFrontendResponse() を変更します。
</p>
<p>この問題はバグトラック #21 で報告されました。</p>
<blockquote>
#21 pgpool-II 3.2.0 cannot execute sql through jdbc<br>
Date: 2012-08-17 16:31<br>
Reporter: elisechiang<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=21">http://www.pgpool.net/mantisbt/view.php?id=21</a>
</blockquote>
</li>
<li>PCP 通信で UNIX ドメインソケットパスをセットするのを、
シグナルハンドラのセットアップ前に行なうように修正しました。(Yugo Nagata)
<p>これまでは、このパス情報がなかったために、プロセス終了時のソケットの削除が失敗していました。</p>
<p>パッチは Gilles Darold さんが提供しました。</p>
<blockquote>
[pgpool-hackers: 131] Found bug with watchdog resulting in pgpool segmentation fault
From: Gilles Darold<br>
Date: Thu, 13 Sep 2012 18:54:42 +0200<br>
<a href="http://www.sraoss.jp/pipermail/pgpool-hackers/2012-September/000130.html">
http://www.sraoss.jp/pipermail/pgpool-hackers/2012-September/000130.html</a>
</blockquote>
</li>
<li>watchdog の ifup/ifdown や arping コマンドが存在しないときに
メッセージを出すようにしました。 (Yugo Nagata)</li>
<li>ずっとあった do_query() で "portal "" does not exist" エラーが出るのを修正しました。(Tatsuo Ishii)
<p>
1) 拡張問い合わせを使っていて、
2) unnamed portal が使われていて、
3) 明示的なトランザクションを使っていないとき、
ユーザの unnamed portal が Sync メッセージで削除されていました。
</p>
<p>
これは、Sync メッセージがトランザクションを終了して unnamed portal を削除するためです。
このために "portal "" does not exist" というエラーが出ていました。
</p>
<p>
これを修正するために、Sync ではなく Flush メッセージを使うようにしました。
二者の主な違いとしては、Flush は Ready For Query メッセージを返さないことです。
したがって do_query() は、来るべきであろうメッセージをすべて待ってから return するようになります。
</p>
<p>
バックエンドからメッセージが来る順序はランダムに見えますが、do_query() は
それを状態のビットを以って管理しています。
</p>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.2.0"></a>3.2.0 (namameboshi) 2012/08/03</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.2 系列の最初の版で、3.1 系からの「メジャーバージョンアップ」にあたります。
</p>
<h3>互換性のない変更</h3>
<ul>
<li>メモリベースのメモリキャッシュ機能を追加したため、旧来のメモリキャッシュ機能は削除しました。
<ul>
<li>これにともない、enable_query_cache パラメータを削除しました。</li>
</ul>
</li>
</ul>
<h3 id="3.2_new_features">新機能</h3>
<ul>
<li><a href="#memqcache">メモリベースのクエリキャッシュ</a>を追加しました。
(Tatsuo Ishii, Nozomi Anzai, Yugo Nagata)
<p>オリジナルは Masanori Yamazaki さんが作成し、開発グループで改良しました。</p>
<dl>
<dt>概要</dt>
<p>
メモリ上にキャッシュが置かれるので高速であるばかりでなく、データが更新されると自動的にキャッシュが無効になり、
pgpool-II の再起動の必要がありません。
</p>
<p>
オンメモリクエリキャッシュは、問い合わせの SELECT 文(拡張問い合わせの場合は更にバインドパラメータ)と
検索結果をペアで記録し、2 回目以降に同じ SELECT 文が発行された場合に、キャッシュから結果を返します。
通常の SELECT 文処理と違って、PostgreSQL にアクセスしないだけでなく、
pgpool 内部の SQL パース処理などを経由しないため、非常に高速です。
</p>
<p>
反面、キャッシュにヒットしない場合は通常の SELECT 文の処理に加えてキャッシュ処理のオーバヘッドが生じるので、
かえって遅くなります。また、あるテーブルが更新された場合、そのテーブルを参照している
すべてのキャッシュが自動削除されるため（自動削除しない設定も可能）、
更新処理が多いシステムではオンメモリクエリキャッシュを有効にしていることでかえって遅くなります。
キャッシュのヒット率が 70% 以下の場合は、オンメモリクエリキャッシュの設定を有効にしないほうが良いでしょう。
</p>
<dt>キャッシュストレージの選択</dt>
<dd>
<p>
メモリキャッシュのストレージには、共有メモリと memcached のどちらかを選択することができます
（併用はできません）。
</p>
<ul>
<li>共有メモリを使用するクエリキャッシュは高速で、memcached の立ち上げも必要なく、手軽に利用できます。
ただし、共有メモリサイズの上限によって保存できるキャッシュの量に制限があります。
</li>
<li>memcached をキャッシュストレージに使用する場合は、ネットワークアクセスのオーバヘッドがあるものの、
比較的自由にキャッシュメモリの大きさを設定できます。
</li>
</ul>
</dd>
<dt>制限事項</dt>
<dd>
<ul>
<li>
オンメモリクエリキャッシュでは、テーブルに変更があると、関連するキャッシュを自動的に削除して
古いデータが返却されないようにする機能があります。
このため、pgpool は常に UPDATE や INSERT や ALTER TABLE などのコマンドが発行されたかどうかを
モニタしています。<br>
しかし、トリガ、外部キーや DROP TABLE CASCADE などの働きによって暗黙的にテーブルが更新されたことは
pgpool-II からはわからないため、この機能が働きません。<br>
この問題を回避するためには、 memqcache_expire を使って一定時間経過したキャッシュを削除するようにするか、
<a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> を使って、該当テーブルが
キャッシュされないようにしてください。
</li>
<li>
複数の pgpool-II を動かす環境で共有メモリを使ったオンメモリクエリキャッシュを使用すると、
ある pgpool-II 経由でテーブルが更新された時に、他の pgpool-II のキャッシュが削除されず、
古いデータを読みだしてしまうことがあります。<br>
このような環境では、キャッシュストレージに memcached を使ってください。
</li>
</ul>
</dd>
<dt>新しいパラメータ</dt>
<dd>
<ul>
<li>メモリキャッシュ全般に関するパラメータ
<a href="#MEMORY_CACHE_ENABLED">memory_cache_enabled</a>、
<a href="#MEMQCACHE_METHOD">memqcache_method</a>、
<a href="#MEMQCACHE_EXPIRE">memqcache_expire</a>、
<a href="#MEMQCACHE_MAXCACHE">memqcache_maxcache</a>、
<a href="#MEMQCACHE_OIDDIR">memqcache_oiddir</a> を追加しました。(Tatsuo Ishii)</li>
<li>共有メモリを使ったメモリキャッシュに関するパラメータ
<a href="#MEMQCACHE_TOTAL_SIZE">memqcache_total_size</a>、
<a href="#MEMQCACHE_MAX_NUM_CACHE">memqcache_max_num_cache</a>、
<a href="#MEMQCACHE_CACHE_BLOCK_SIZE">memqcache_cache_block_size</a> を追加しました。
(Tatsuo Ishii)</li>
<li>memcached を使ったメモリキャッシュに関するパラメータ
<a href="#MEMQCACHE_MEMCACHED_HOST">memqcache_memcached_host</a>、
<a href="#MEMQCACHE_MEMCACHED_PORT">memqcache_memcached_port</a> を追加しました。
(Tatsuo Ishii)
</li>
<li>リレーションキャッシュに関するパラメータ
<a href="#RELCACHE_EXPIRE">relcache_expire</a>、
<a href="#RELCACHE_SIZE">relcache_size</a> を追加しました。(Tatsuo Ishii)</li>
<li>一時テーブルかどうかをチェックするフラグ <a href="#CHECK_TEMP_TABLE">check_temp_table</a> パラメータを
追加しました。(Tatsuo Ishii)
</li>
<li>テーブル、一時テーブル、ビューのキャッシュ可否を指定するパラメータ、
<a href="#WHITE_MEMQCACHE_TABLE_LIST">white_memqcache_table_list</a>、
<a href="#BLACK_MEMQCACHE_TABLE_LIST">black_memqcache_table_list</a> を追加しました。
(Nozomi Anzai)</li>
<li><a href="#MEMQCACHE_AUTO_CACHE_INVALIDATION">memqcache_auto_cache_invalidation</a>
パラメータを追加しました。(Yugo Nagata)
<p>
true であれば、DDL/DML/DCL が発行されたら <a href="#MEMQCACHE_EXPIRE">memqcache_expire</a> を待たずに
クエリキャッシュを削除します。
</p>
</li>
<li><a href="#pool_cache">SHOW pool_cache</a> を追加しました。クエリキャッシュのヒット率や、
キャッシュストレージの状況を表示します。(Tatsuo Ishii)</li>
<li><a href="#install">configure</a> に --with-memcached オプションを追加しました。(Tatsuo Ishii)</li>
<li><a href="#start">pgpool コマンド</a> に "-C, --clear-oidmaps" オプションを追加しました。
(Nozomi Anzai)
<p>
memcached を使ったメモリキャッシュを行なっている pgpool が -C つきで起動・再起動したときは、
oid マップを削除せず再利用します。
</p>
</li>
</ul>
</dd>
</dl>
</li>
<li><a href="#watchdog">Watchdog 機能</a> を追加しました。(Atsushi Mitani, Yugo Nagata)
<p>Atsushi Mitani が作成し、Yugo Nagata がテストしました。</p>
<dl>
<dt>概要</dt>
<dd>
<p>
watchdog プロセスは pgpool-II 本体から起動される、高可用性を目的としたプロセスです。以下の機能を提供します。
</p>
<dl>
<dt>pgpool サービスの死活監視</dt>
<dd>
<p>
watchdog は、pgpool のプロセスではなくサービスの応答を監視します。
監視対象の pgpool から PostgreSQL に問い合わせを行ない、その応答をチェックします。
</p>
<p>
また watchdog は、pgpool から上位のサーバ（アプリケーションサーバなど）への接続も監視します。
上位サーバから PostgreSQL への接続・応答を pgpool のサービスとして死活監視します。
</p>
</dd>
<dt>watchdog プロセスの相互監視</dt>
<dd>
<p>
各 watchdog はお互いの監視対象のサーバの情報を交換します。
これにより、pgpool サーバの情報を最新に保てるだけでなく、
各 watchdog プロセスの相互 監視を行なっています。
</p>
</dd>
<dt>障害発生検知時のアクティブ、スタンバイ切り替え</dt>
<dd>
<p>
pgpool のサービスに障害を検知した場合、watchdog は他の watchdog に障害検知を通知します。
故障した pgpool がアクティブの場合、他の watchdog は新しいアクティブを投票で決め、
アクティブ・スタンバイの切り替えを行ないます。
</p>
</dd>
<dt>サーバ切り替えと連動した仮想 IP アドレスの自動付け替え</dt>
<dd>
<p>
スタンバイが新しいアクティブに昇格する際、新アクティブ機の watchdog は
アクティブ用の仮想 IP インターフェースを起動します。
一方、旧アクティブ機の watchdog はアクティブ用仮想 IP インターフェースを停止します。
</p>
<p>
これにより、サーバが切り替わった後もアクティブは同じ IP アドレスでサービスを継続することができます。
</p>
</dd>
<dt> サーバ復旧時、スタンバイ機としての自動登録</dt>
<dd>
<p>
障害機の復旧や新規サーバを追加する場合、watchdog はサーバの情報を他のwatchdog に通知し、
他の watchdog からはアクティブや他のサーバの情報を受け取ります。
</p>
<p>
これにより追加したサーバはスタンバイ機として自動的に追加されます。
</p>
</dd>
</dl>
</dd>
<dt>新しいパラメータ</dt>
<dd>
<ul>
<li>watchdog を使用するかどうかを指定するパラメータ
<a href="#USE_WATCHDOG">use_watchdog</a> 追加しました。(Atsushi Mitani)</li>
<li>
pgpool-II の死活監視に関するパラメータ
<a href="#WD_INTERVAL">wd_interval</a>、
<a href="#WD_LIFE_POINT">wd_life_point</a>、
<a href="#WD_LIFECHECK_QUERY">wd_lifecheck_query</a>
を追加しました。(Atsushi Mitani)
</li>
<li>
アプリケーションサーバなど上部サーバへの接続に関するパラメータ
<a href="#TRUSTED_SERVERS">trusted_servers</a>、
<a href="$PING_PATH">ping_path</a> を追加しました。(Atsushi Mitani)
</li>
<li>
watchdog の相互死活監視に関するパラメータ
<a href="#WD_HOSTNAME">wd_hostname</a>、
<a href="#WD_PORT">wd_port</a>、
<a href="#OTHER_WD_PORT">other_wd_port</a>、
<a href="#OTHER_PGPOOL_HOSTNAME">other_pgpool_hostname</a>、
<a href="#OTHER_PGPOOL_PORT">other_pgpool_port</a>
を追加しました。 (Atsushi Mitani)
</li>
<li>
仮想 IP に関するパラメータ
<a href="#DELEGATE_IP">delegate_IP</a>、
<a href="#IFCONFIG_PATH">ifconfig_path</a>、
<a href="#IF_UP_CMD">if_up_cmd</a>、
<a href="#IF_DOWN_CMD">if_down_cmd</a>、
<a href="#ARPING_PATH">arping_path</a>、
<a href="ARPING_CMD">arping_cmd</a> を追加しました。(Atsushi Mitani)
</li>
</ul>
</dd>
</dl>
</li>
<li>チュートリアル</li>
<p><a href="#memqcache">オンメモリクエリキャッシュ</a> と <a href="#watchdog">Watchdog 機能</a>
のチュートリアルを作成しました。(Nozomi Anzai)</p>
</ul>
<h3 id="3.2_enhansements">改良</h3>
<ul>
<li>HP-UX や AIX のような vsyslog を持たないプラットフォームもサポートするようにしました。(Tatsuo Ishii)</li>
<li>ヘルスチェックで、リトライ回数とリトライ間隔秒数を指定できるようにしました。
このために、<a href="#HEALTH_CHECK_MAX_RETRIES">health_check_max_retries</a> と
<a href="#HEALTH_CHECK_RETRY_DELAY">health_check_retry_delay</a> というパラメータを新設しています。(Tatsuo Ishii)
<p>パッチは Matt Solnit さんが作成しました。</p>
<blockquote>
Subject: [Pgpool-hackers] Health check retries (patch)<br>
From: Matt Solnit<br>
Date: Fri, 18 Nov 2011 16:28:44 -0500
</blockquote>
</li>
<li>クエリの解析に失敗したとき、クライアントの IP とポート番号をログに書き出すようにしました。(Tatsuo Ishii)
<p>
これは、<a href="#LOG_CONNECTIONS">log_connections</a> を有効にしていなくても、
問題のあるクエリを発行したのがどのクライアントかを知るのに有用です。
特にログ出力の多く忙しい Webシステムで役立ちます。
</p>
</li>
<li>pool_process_query() が無限ループする場合があったのを修正しました。(Tatsuo Ishii)
<p>
これは、以下がそろったときに起こる可能性がありました。
</p>
<ul>
<li>クエリが実行中でない</li>
<li>マスタ以外のノードがデータを保持している</li>
</ul>
<p>以下で報告されました。</p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2011-December/000042.html">[pgpool-general: 43]</a>
Re: [Pgpool-general] seemingly hung pgpool process consuming 100% CPU<br>
From: Lonni J Friedman<br>
Date: Tue, 6 Dec 2011 16:23:41 -0800
</blockquote>
</li>
<li><a href="#pool_nodes">SHOW pool_nodes</a> に role の列を足しました。
この列には Primary か Standbyかが出力されます。(Tatsuo Ishii)</li>
<li>PostgreSQL 9.2 に対応しました。(Tatsuo Ishii)</li>
<li><a href="#pool_status">SHOW pool_status</a> の出力結果に、
<a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a>,
<a href="#SSL_CA_CERT">ssl_ca_cert</a>,
<a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a> がなかったので追加しました。
また、pgpool.conf の順にソートしました。(Nozomi Anzai)
</li>
<li>pgpool.conf のサンプルファイルで、system db に関するパラメータをコメントアウトしました。(Nozomi Anzai)</li>
<li><a href="#failover">failover/failback/followmaster コマンド</a> に新しいパラメータを追加しました。(Tatsuo Ishii)
<pre>%r: new master port number
%R: new master database cluster path
</pre>
</li>
<li>md5 認証のパスワードを変更が reload でできるようにしました。(Tatsuo Ishii)
<p>
これまでは pgpool-II を再起動する必要がありました。
このパッチは Gurjeet Singh さんが作成しました。
</p>
</li>
<li>マニュアルの見た目を改善しました。また、パラメータ名などページ内リンクを増やしました。(Nozomi Anzai)</li>
<li>is_set_transaction_serializable() 関数から使用されていない引数 query を削除しました。(Tastuo Ishii)</li>
<li>pgpool.conf の on memory query cache セクションのコメントを他のセクションと同じ様式に修正しました。(Tatsuo Ishii)</li>
<li>pgpool.conf.sample-master-slave, pgpool.conf.sample-replication, pgpool.conf.sample-stream に
抜けていたオプション health_check_max_retries, health_check_retry_delay を追加しました。(Tastuo Ishii)</li>
</ul>
<h3 id="3.2_bugfix">バグ修正</h3>
<ul>
<li>Raw モードでのメモリリークを修正しました。(Tatsuo Ishii)</li>
<li>Raw モードでのフェイルオーバ・フェイルバックを修正しました。(Tatsuo Ishii)
<ul>
<li>対象ノードがマスタでないときに、フェイルオーバしませんでした。</li>
<li>ノードが接続受付状態でないとき、どのノードをマスタにするか選定できませんでした。</li>
</ul>
</li>
<li>connect() 中にヘルスチェックのリトライができるようにしました。(Tatsuo Ishii)
<p>
これは、システムがセキュリティ上の理由で接続先に接続できなかったという
メッセージを返さないように設定されているときに、sigalarm がブロックされているという報告によります。
変更の一部は Stevo Slavic さんが提供しました。
</p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-January/000131.html">[pgpool-general: 131]</a>
Healthcheck timeout not always respected<br>
From: From: Stevo Slavic<br>
Date: Tue, 10 Jan 2012 21:16:01 +0100
</blockquote>
</li>
<li>各ノードにおいて、トランザクション状態によって COMMIT / ABORT するかどうかを判定できるように、
pool_send_and_wait() を修正しました。(Tatsuo Ishii)
<p>
マルチステートメントが送信されたとき、明示的なトランザクション内にあるプ
ライマリか、明示的なトランザクション内でないスタンバイで発生する可能性が
ありました。
</p>
<p>これは、[pgpool-general-jp: 1049] で報告されました。</p>
<blockquote>
Subject:
<a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2012-April/001048.html">[pgpool-general-jp: 1049]</a>
COMMITでエラー<br>
From: 稲村暢亮<br>
Date: Mon, 30 Apr 2012 13:48:48 +0900
</blockquote>
</li>
<li>Solaris でのロードバランスを修正しました。(Tatsuo Ishii)
<p>Solaris での random() 関数の仕様のために問題があったため、rand() に変更しました。</p>
<p>この事象は [pgpool-general: 396] で報告されました。</p>
<blockquote>
<a href="http://www.pgpool.net/pipermail/pgpool-general/2012-April/000397.html">[pgpool-general: 396]</a>
strange load balancing issue in Solaris<br>
From: Aravinth<br>
Date: Sat, 28 Apr 2012 07:26:58 +0530
</blockquote>
</li>
<li>パラレルモードでないとき、<a href="#pcp_systemdb_info">pcp_systemdb_info</a> コマンドが
segfault してたのを修正しました。(Nozomi Anzai)</li>
<li>"unnamed prepared statment does not exist" というエラーが出るのを修正しました。(Tatsuo Ishii)
<p>
このエラーは pgpool が内部的に発行しているクエリで発生し、
クライアントが発行する unnamed ステートメントを破壊していました。
</p>
<p>
拡張問い合わせクエリが実行されたときには、内部的に発行するクエリのステートメントとポータルに
名前をつけるようにしました。
</p>
</li>
<li>ホットスタンバイモードでクエリ衝突が起きたときにハングアップするのを修正しました。(Yugo Nagata)
<p>これは、以下の手順で再現します。</p>
<pre>(S1) BEGIN;
(S1) SELECT * FROM t;
(S2) DELETE FROM t;
(S2) VACUUM t;
</pre>
</li>
<li><a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
で報告された、process_query() のバグを修正しました。(Tatsuo Ishii)
<p>
プライマリでは処理するデータがなく スタンバイにはある状態のときに、
プライマリの処理を待ってしまうことがありました。
</p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
Transaction never finishes<br>
From: Luiz Pasqual<br>
Date: Thu, 28 Jun 2012 09:55:23 -0300
</blockquote>
</li>
<li>wait_for_query_response() が、frontend がないときには何もしないように修正しました。(Tatsuo Ishii)
<p>バックエンドをリセットする <a href="#RESET_QUERY_LIST">reset_query_list</a> のクエリを実行に
時間がかかったときに発生する可能性があり、またクラッシュすることがありました。</p>
</li>
<li>マスタ・スレーブモードでの BEGIN TRANSACTION の扱いを修正しました。(Tatsuo Ishii)
<p>
これは <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html">[pgpool-general: 714]</a>
で報告されました。
</p>
<p>
3.1 以降、BEGIN TRANSACTION をすべてのノードに送るようにしました。
PostgreSQL の仕様では、スタンバイノードには BEGIN TRANSACTION READ WRITE を送ることはできませんが、
BEGIN WORK ISOLATION LEVEL SERIALIZABLE についてチェックしておらず、スタンバイノードに送信していました。
もちろんこれは誤りで、スタンバイノードが SERIALIZABLE モードになることは許されていません。
</p>
<p>
そのため、BEGIN WORK ISOLATION LEVEL SERIALIZABLE をチェックするようにしました。
</p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html">[pgpool-general: 714]</a>
Load Balancing / Streaming Replication / Isolation Level serializable<br>
From: Philip Hofstetter<br>
Date: Wed, 11 Jul 2012 17:04:26 +0200
</blockquote>
</li>
<li>SET TRANSACTION ISOLATION LEVELSERIALIZABLE などのクエリはプライマリのみに送るよう
send_to_where() を修正しました。(Tatsuo Ishii)
<p>
マスタ・スレーブモードで、以前はこのクエリはプライマリだけではなくスタンバイにも送られていましたが、
もちろんこれはエラーとなります。同じようなクエリとして以下のものがあります。
</p>
<ul>
<li>SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE</li>
<li>SET transaction_isolation TO 'serializable'</li>
<li>SET default_transaction_isolation TO 'serializable'</li>
</ul>
<p>
これは <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000720.html">[pgpool-general: 715]</a>
で報告されました。
<p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000720.html">[pgpool-general: 715]</a>
Re: Load Balancing / Streaming Replication / Isolation Level serializable<br />
From: Tastuo Ishii<br />
Date: Thu, 12 Jul 2012 00:16:58 +0900
</blockquote>
</li>
<li>オンメモリクエリキャッシュで memcached を利用している場合、
memcached サーバが停止していてもエラーを起こさないようにしました。(Tatsuo Ishii)
<p>
これは主に、memcached_get() が MEMCACHED_NOTFOUND 以外のエラーを返した場合には、
pool_fetch_cache() が "cache not found" を装うように修正することで対処しました。
また、その場合には後のエラーを防ぐために pool_config->memory_cache_enabled を 0
にセットするようにしました。
</p>
</li>
<li>rerun libtoolize with --copy and --force option を実行しました。(Tatsuo Ishii)
<p>
これにより環境によって発生するビルドの問題が回避できます。以下のコマンドが実行されました。
</p>
<pre>
libtoolize --copy --force
aclocal
autoheader
automake -a
autoconf
</pre>
</li>
<li>SSL_read() が不明のエラーを返した場合には EOF の検出とみなし、呼出元の pool_read() には
0 を返すよう pool_ssl_read() を修正しました。(Tatsuo Ishii)
<p>
これは libpq と同じ振る舞いです。また、これにより pool_read() での望ましくないフェイルオーバを回避することが出来ます。
これは、pool_read() は下層の I/O 関数（read(2), pool_ssl_read）が -1 を返したときにフェイルオーバを引き起こすからです。
</p>
</li>
<li>SSL エラー時に、リトライすべきときにしていなかったのを修正しました。 (Tatsuo Ishii)</li>
<li> ハングアップを起こさないよう pool_process_query() を修正しました。 (Tatsuo Ishii)
<p>
プライマリ以外のノードがパケットを送信した際に、pgpool はセッションを終了しようとしてハングアップすることがありました。
これは ssl_read が エラーではなく EOF を返すようになり、フェイルオーバが実行されなくなっためです。
例えば [pgpool-gerenal: 766] では以下のような報告があります。
</p>
<pre>
2012-07-17 00:11:03 NZST [15692]: [257-1] ERROR: canceling statement due to conflict with recovery
2012-07-17 00:11:03 NZST [15692]: [258-1] DETAIL: User query might have needed to see row versions that must be removed.
2012-07-17 00:11:03 NZST [15692]: [259-1] STATEMENT: <SNIP>
2012-07-17 00:11:03 NZST [15696]: [366-1] FATAL: terminating connection due to conflict with recovery
2012-07-17 00:11:03 NZST [15696]: [367-1] DETAIL: User query might have needed to see row versions that must be removed.
</pre>
<p>
このケースでは、pool_process_query() は POOL_END ではなく POOL_ERROR を返すべきです。
</p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000774.html">[pgpool-general: 766]</a>
Re: pgpool dropping backends too much<br />
From: Karl von Randow <br />
Date: Thu, 19 Jul 2012 16:07:41 +1200
</blockquote>
</li>
<li>バックエンドから来たたくさんのクエリ結果を読み込んでいる間に
フロントエンドが終了したときに、pgpool はバックエンドからの読み込みを続行し、
すべてのクエリが送られるまでフロントエンドへの書き込みを行ないます。(Tatsuo Ishii)
<p>
クエリ結果が巨大だとこれは非常に長い時間を要します。
pgpool のセッションを極力早く終了するには、レプリケーションモード以外では、
フロントエンドへの書き込みに失敗したらエラーを返すように、pool_flush_it を変更しました。
レプリケーションモードでは、以前どおりの挙動、すなわちバックエンド間での同期書き込みを行ないます。
</p>
<p>
そのほか、SimpleForwardToFrontend が、pool_write_and_flush がエラーを返してきたときに
それを無視せず、認識するようにしました。
</p>
</li>
</ul>
<!-- ================================================================================ -->
<!-- 3.1 -->
<!-- ================================================================================ -->
<hr><a name="release3.1.x"></a>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.9"></a>3.1.9 (hatsuiboshi) 2013/09/06</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.1.8 に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>
doc/basebackup.sh スクリプトの ssh コマンドの間違いを修正しました。(Tatsuo Ishii)
</li>
<li>
レプリケーションモードにおけるプリペアド文のパース処理を修正しました。(Tatsuo Ishii)
<p>
レプリケーションモードで SELECT 以外のクエリをパースする際には、
ノード間の一貫性保持のため自動的にトランザクションが開始されますが、
トランザクションを閉じる処理が行われていませんでした。
そのため、実際に誤っているクエリだけではなく、その次にパース処理されたクエリもアボートされていました。
</p>
<p>
このバグは [pgpool-general: 1877] で Sean Hogan さんにより報告されました。
</p>
<blockquote>
[pgpool-general: 1877] current transaction is aborted, commands ignored<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html
</a>
</blockquote>
</li>
<li>
日本語ドキュメントの typo を修正しました。 (Yugo Nagata)
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.8"></a>3.1.8 (hatsuiboshi) 2013/07/10</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.1.7 に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>
man ページに -D オプションの記述を追加しました。（Tatsuo Ishii)
</li>
<li>
オンラインリカバリ時のフェイルバックの完了待機でタイムアウト処理をするようにしました。(Tatsuo Ishii)
<p>
これによりリカバリが永遠に終わらず pgpool-II が終了できなくなる状況を回避します。
この現象は特に follow_master_command の実行中に起こり得ました。
</p>
</li>
<li>
ストリームレプリケーションモードでの follow_master_command 実行時に、%H に新しいプライマリノードが正しく割り当てられないバグを修正しました。
(Tatsuo Ishii)
</li>
<li>
PostgreSQL がエラーを返したときに do_query() がハングしないよう修正しました。
(Tatsuo Ishii)
<p>
典型的な症状が「pg_stat_activety によると SELECT が実行されたままのように見える」というものです。
これを解決するため、pgpool-II は当該プロセスを終了させ、既存のコネクションを捨てるように修正しました。
</p>
</li>
<li>
拡張プロトコルの際に do_query で発生しうるハングアップを修正しました。
(Tatsuo Ishii)
<p>
これは insert_lock が有効で、pgpool_catalog.insert_lock が存在することに起こり得ます。
詳しくは [pgpool-general: 1684] を参照してください。
</p>
<blockquote>
[pgpool-general: 1684] insert_lock hangs <br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html
</a>
</blockquote>
</li>
<li>
COMMIT 時エラーに不要なバックエンド切り離しを行わないようにしました。
(Tatsuo Ishii)
<p>
マスタースレーブモードで、COMMIT 時にマスターノードでエラーが発生していたとしても、他のスレーブノードが正常な場合にはバックエンドを切り離す必要はありません。
これは、遅延トリガーのために "kind mismatch error" が発生しうるからです。
</p>
</li>
<li>
pgpool_regclass を pg_catalog スキーマに登録するよう修正しました。
(Tatsuo Ishii)
<p>
これは postgres_fdw のような、スキーマ検索パスが pg_catalog に限定されているクライアントに対応するために必要です。
</p>
</li>
<li>
pg_md5 コマンドで起こりうるクラッシュを修正しました。(Muhammad Usama)
</li>
<li>
スタートアップパケットに PostgreSQL ユーザ情報が含まれていなかった場合に発生する子プロセスのセグメンテーション違反を修正しました。(Yugo Nagata)
<p>
このバグは以下を実行することにより再現できます。
</p>
<pre>
$ psql -p 9999 -U ''
</pre>
<p>
enable_pool_hba が有効の場合は子プロセスがセグメンテーション違反で異常終了し、無効の場合には以下のメッセージがログに出力されていました。
</p>
<pre>
ERROR: pool_discard_cp: cannot get connection pool for user (null) database (null)
</pre>
<p>
また、両方の場合で psql はフロントエンドに何のメッセージ出力せずに終了していました。
修正後は、スタートアップパケットに PostgreSQL ユーザが指定されていない場合には以下のメッセージがログとフロントエンドの両方に出力されます。
これは PostgreSQLと同じ振る舞いです。
</p>
<pre>
FATAL: no PostgreSQL user name specified in startup packet
</pre>
</li>
<li>
マニュアルの ssl_sa_cert, ssl_ca_cert_dir オプションの説明を SSL セクションに移動しました。(Yugo Nagata)
</li>
<li>
ssl_sa_cert, ssl_ca_cert_dir オプションの説明を日本語マニュアルに追加しました。(Yugo Nagata)
</li>
<li>
pcp_recovery_node コマンドで、バックエンドノード番号をチェックするように修正しました。(Yugo Nagata)
<p>
不正な値が使用された場合、リカバリで実行されるスクリプトの引数に空の値が渡されており、誤動作の原因となっていました。
特にベースバックアップを行うスクリプトで、rsync が関係のないファイルを削除してしまうことがありました。
</p>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.7"></a>3.1.7 (hatsuiboshi) 2013/04/26</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.1.6 に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>
設定パラメータの一覧を表示する "SHOW pool_status" で pool_passwdが表示されていないのを修正しました。(Yugo Nagata)
</li>
<li>
拡張プロトコルの処理における timestamp の書き換えに関する長い間見過ごされていてたバグを修正しました。(Tatsuo Ishii)
<p>
Parse() 関数は、parse メッセージの書き換えの際に palloc() を使ってメモリを確保していました。
書き換えられたメッセージは pool_create_sent_message()
関数などが管理するデータ領域に格納されますが、これが問題となっていました。
この関数ではデータが session context memory 中に存在することを想定しているのに対し、
palloc() では query context においてメモリの割り当てを行っており、この領域は
query context 終了時に解放されます。しかし、他の関数もこのメモリ領域を解放しようとするため、
セグメンテーション違反や二重解放を含む様々な問題の原因となっていました。
この問題は、書き換えたメッセージを格納するメモリを session context を用いて確保するこで修正されました。
これは pgpool-II 3.0 以来ずっと存在していたバグです。
</p>
<p>
この問題は、Naoya Anzai さんによって解析され、パッチが提供されました。
</p>
<blockquote>
[pgpoolgenera-jp: 1146]<br />
拡張問い合わせプロトコルでセグメンテーションフォルト<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html">
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html
</a>
</blockquote>
</li>
<li>
md5認証で長いユーザ名を処理する際のバグを修正しました。(Tatsuo Ishii)
<p>
ユーザ名が 32 バイトより長い場合、md5 認証が動作していませんでした。
この問題は [pgpool-general: 1526] で Thomas Martin さんにより報告されました。
</p>
<blockquote>
[pgpool-general: 1526]<br />
[pgPool-II 3.2.3] MD5 authentication and username longer than 32 characters.<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html">
http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html
</a>
</blockquote>
</li>
<li>レプリケーション遅延の計算はスタンバイサーバがプライマリサーバより遅れている場合にのみ行うよう修正しました。(Yugo Nagata)
<p>
タイミングによってスタンバイよりプライマリの方がレプリケーションが遅延
しているように見える場合があり、その場合には負値の遅延が計算されていました。
この値が符号無し変数に代入されると、実際には遅延が生じていないにも関わらず、
ログに遅延が負値で出力され、されに悪いことには、ロードバランス機能により
SELECT クエリがプライマリに振り分けられ、その結果プライマリの負荷が高まる
ことがありました。
</p>
<p>
この問題は Saitoh Hidenori さんによって報告、解析されました。
</p>
<blockquote>
[pgpool-genera-jp: 1145]<br />
レプリケーション遅延確認の不具合について<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html">
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html
</a>
</blockquote>
</li>
<li>pgpool-recovery が PostgreSQL 9.3 に対応しました。 (Tatsuo Ishii)
<p>
パッチは Asif Rehman さんにより提供され、これに Tatsuo Ishii が若干の修正を
加えました。
</p>
<blockquote>
[pgpool-hackers: 180] <br />
compile error in ppool-recovery<br />
<a href="http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html">
http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html
</a>
</blockquote>
</li>
<li>pool_has_pgpool_regclass が pgpool_regclass() の実行権限をチェックするよう修正しました。 (Tatsuo Ishii)
<p>
pgpool_regclass が存在する場合でも、pgpool がこの関数を実行できない場合に、
バックエンドへの接続がハングしていました。この問題は、pgpool_regclass
から実行権限を剥奪し、ネイティブレプリケーションモードで INSERT を実行
することで再現可能です。
</p>
<p>
この問題は bugtrack #53 で報告されました。
</p>
<blockquote>
#53 pgpool_regclas hangs all connections<br />
Date: 2013-04-04 13:35 <br />
Reporter: tmandke<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=53">
http://www.pgpool.net/mantisbt/view.php?id=53
</a>
</blockquote>
</li>
<li>detect_postmaster_down_error() のエラーメッセージを修正しました。(Tatsuo Ishii)
<p>
例えば、"LOG: detect_stop_postmaster_error: detect_error error" を
"LOG: detect_postmaster_down_error: detect_error error" に修正するなどです。
</p>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.6"></a>3.1.5 (hatsuiboshi) 2013/02/08</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>このバージョンは3.1.5に対するバグ修正リリースです。</p>
<ul>
<li>md5 認証で競合が発生する不具合が修正されました。(Tatsuo Ishii)
<p>
pool_passwd のファイル識別子は pgpool の親プロセスで開かれたものが子プロセスに引き継がれてます。
複数の接続で同時に md5 認証を行う際には、pool_get_passwd が呼ばれ、ファイル識別子が走査されますが、
ファイル識別子が共有されるために md5 認証が失敗することがありました。
この問題は、個々の子プロセスで pool_passwd ファイルを開き直すことで解決されました。
</p>
<p>
この問題は [pgpool-general:1141] にて、Jason Slagle さんによって報告・解析されました。
</p>
<blockquote>
[pgpool-general: 1141] Possible race condition in pool_get_passwd<br />
From: Jason Slagle<br />
Date: Sun, 28 Oct 2012 01:12:52 -0400<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html</a>
</blockquote>
</li>
<li>pcp_attach_node, pcp_detach_node を繰り返し実行したときに起こるハングアップを
修正しました。 (Tatsuo Ishii)
<p>
pcp_attach_node, pap_detach_node によりノードステータスが変更された時、failover()
は子プロセスに SIGUSR1 シグナルを送り、プロセスの終了とノードステータスの更新を行います。
その時に発せられた SIGCHLD シグナルは全て reaper() ハンドラで受信しますが、
システムの負荷とタイミングによりこれが失敗することがありました。
pcp プロセスによる SIGCHLD シグナルの受信に失敗した場合に、これがゾンビプロセスとなり、
pcp プロセスが永遠に再起動されなくなっていました。
</p>
<p>
この問題はバグトラック #32（oleg_myrk さんによる）他で報告されました。
</p>
<blockquote>
#32 PGPool hangs on pcp_attach/detach<br />
Reporter: oleg_myrk<br />
Date: 2012-10-24 00:01<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=32">
http://www.pgpool.net/mantisbt/view.php?id=32</a>
</blockquote>
</li>
<li>pool_send_severity_message() で未初期化のメモリを使用しないよう修正しました。
(Tatsuo Ishii)
<p>
このバグによりセグメンテーション違反が発生することがありました。
バグトラック #33 に投稿された valgrind 実行結果（dudee さんによる）にて報告されました。
</p>
<blockquote>
#33 pgpool-II 3.2.1 segfault<br />
Reporter: dudee<br />
Date: 2012-10-30 19:16<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=33">
http://www.pgpool.net/mantisbt/view.php?id=33</a>
</blockquote>
</li>
<li>通常のテーブルと同名の一時テーブルがあるときに、クエリキャッシュの結果が不正になる
バグを修正しました。 (Tatsuo Ishii)
<p>
以下はバグを引き起こす処理の例です。
</p>
<pre>
1) CREATE TABLE t1(i int); -- 通常のテーブルを作成
2) INSERT INTO t1 VALUES(1);
3) SELECT * FROM t1; -- クエリキャッシュが作成される
4) CREATE TEMP TABLE t1(i int); -- 一時テーブルの作成
5) SELECT * FROM t1; -- 誤ったクエリキャッシュが作成される!
</pre>
<p>
#3 で t1 のキャッシュが生成されますが、#5 でこれが不正に使われており、一時テーブル t1 が
一時テーブルと見なされていないのが問題でした。
</p>
</li>
<li>ヘルプメッセージに -f オプションの説明を追加しました。 (Tatsuo Ishii)</li>
<li>pcp または worker 子プロセスの終了イベントを受信したときに、reaper() で wait3()
ループを終了しないように修正しました。 (Tatsuo Ishii)
<p>
修正前は、reaper() は子プロセスの終了イベントを誤って無視してしまい、ゾンビプロセスを作り、
新しいプロセスを生成できないことがありました。
</p>
<p>
この問題は[pgpool-general-jp: 1123]にて、後藤さんより報告され、修正の示唆を頂きました。
</p>
<blockquote>
[pgpool-general-jp: 1123] Re: オンラインリカバリ後にゾンビプロセスになる<br />
From: GOTO, Daisuke<br />
Date: Wed, 21 Nov 2012 19:56:17 +0900<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html">
http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html</a>
</blockquote>
</li>
<li>pool_search_relcache() が REAL_MASTER_NODE_ID ではなく MASTER, MASTER_NODE_ID
を使用するように修正しました。 (Tatsuo Ishii)
<p>
ストリーミングレプリケーションモードで 0 番ノードがフェイルバックした場合、pgpool は
子プロセスを再起動しません。そのとき、REAL_MASTER_NODE_ID は 0 番ノードの接続情報を
探しにいきますが、これはバックエンドへの新しい接続が確立するまで存在しません。
そのため、接続情報の参照によって、セグメンテーションフォルトが発生していました。
この状況でも、MASTER または MASTER_NODE_ID は以前にキャッシュされた
マスターノード ID を見にいくため、安全に使うことが出来ます。
</p>
</li>
<li>ストリーミングレプリケーションモードでレプリケーション遅延が大きくなったときに、
"portal not found" エラーが発生するバグを修正しました。 (Tatsuo Ishii)
<p>
これは delay_threshold が導入以来、ずっと存在していたバグです。
</p>
<p>
bind, describe, execute の実行時に遅延が域値を越えた場合、送り先の DB ノードは
変更されていました。しかし、parse がそれとは異なるノードに送られていた場合、送り先ノードには
parse された ステートメントやポータルが存在しないために bind, describe, execute は
失敗していました。 修正後は、大きな遅延が発生した場合でも、これらは parse が実行された
ノード以外には送られないようになりました。
</p>
</li>
<li>pg_md5 で、ユーザからのパスワード入力の後には改行するように修正しました。 (Yugo Nagata)</li>
<li>watchdog のポート番号が既に使用されていた場合にエラーメッセージを出力するよう修正しました。
(Yugo Nagata)
<p>
この問題は [pgpool-general: 1167] で Will Ferguson さんによって報告されました。
</p>
<blockquote>
[pgpool-general: 1167] Re: Watchdog error - wd_init: delegate_IP already exists<br />
From: Will Ferguson<br />
Date: Tue, 6 Nov 2012 13:03:36 +0000<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html</a>
</blockquote>
</li>
<li>コネクションプールが存在しない場合には、child_exit() が send_frontend_exits()
を呼ばないよう修正しました。 (Tatsuo Ishii)
<p>
send_frontend_exits() は pool_connection_pool で指されてるオブジェクトを参照しているため、
修正前にはセグメンテーションフォルトが発生していました。バグトラック #44 の tuomas さんの報告によります。
</p>
<blockquote>
#44 pgpool went haywire after slave shutdown triggering master failover<br />
Reporter: tuomas<br />
Date: 2012-12-11 00:33<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=44">
http://www.pgpool.net/mantisbt/view.php?id=44</a>
</blockquote>
</li>
<li>pool_read() が不正なパケットを読み込んだ場合に、read_startup_packet() がアラームクロック
をリセットして StartupPacket を解放するよう修正しました。 (Nozomi Anzai)
<p>
修正前は、pgpool ポートの監視を行うプログラムの接続により、認証のタイムアウトが発生していました。
この問題は、バグトラック #35 で報告されました。
</p>
<blockquote>
#35 Authentication is timeout<br />
Reporter: tuomas <br />
Date: 2012-11-20 11:54<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=35">
http://www.pgpool.net/mantisbt/view.php?id=35</a>
</blockquote>
</li>
<li>pool_open() が誤ったバッファポインタを初期化していたバグを修正しました。 (Tatsuo Ishii)
<p>
このポインタは事前に memset() によって初期化されているため、実際にはこのバグによる害は
ありませんでした。
</p>
</li>
<li>ドキュメント中の、「パラメータ変更に再起動が必要かどうか」の情報を追記・修正しました。(Yugo Nagata)</li>
<li>pool_passwd に関する記述を pgpool_conf.sample*、および,ドキュメントに追加しました。 (Yugo Nagata)
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.5"></a>3.1.5 (hatsuiboshi) 2012/10/12</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>このバージョンは3.1.4に対するバグ修正リリースです。</p>
<h3>バグ修正</h3>
<ul>
<li>read_startup_packet() を修正しました。(Tatsuo Ishii)
<p>
パケット長が 0 以下のときは直ちに return するべきでしたが、そうなっていなく、
メモリ確保時にエラーになっていました。
</p>
<p>これは pgpool-general:886 を参照してください。また、キャンセルアラームを追加しました。</p>
<blockquote>
[pgpool-general: 886] read_startup_packet: out of memory<br>
From: Lonni J Friedman<br>
Date: Wed, 8 Aug 2012 10:18:15 -0700<br>
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html</a>
</blockquote>
</li>
<li>s_do_auth() に NOTICE メッセージを追加しました。(Tatsuo Ishii)
<p>これがなかったために、ヘルスチェックが false アラームを受け取りフェイルオーバしていました。</p>
<p>これはバグトラックで報告されました。</p>
<blockquote>
#25 s_do_auth doesn't handle NoticeResponse (N) message<br>
Date: 2012-08-28 03:57<br>
Reporter: singh.gurjeet<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=25">http://www.pgpool.net/mantisbt/view.php?id=25</a>
</blockquote>
</li>
<li>s_do_auth() から、不要かつ混乱をまねくデバッグメッセージを削除しました。(Tatsuo Ishii)</li>
<li>SSL モードでの無限ループを修正しました。 (Tatsuo Ishii)
<p>
フロントエンドの SSL レイヤで溜っているデータがあるとき、
pool_process_query() がバックエンドに溜っているデータをチェックします。
もしそれが無かったときは再度ループして、フロントエンド/バックエンドがバッファを受け取っていないか
is_cache_empty() を以ってチェックします。
しかし、フロントエンドの SSL レイヤでデータが溜っているのを一度検知すると、
バックエンドに行ってまたチェックしようとします（無限ループ）。
</p>
<p>
これを解決するには、フロントエンドの SSL レイヤに溜っているデータがあり
かつ クエリが実行中でなければ、ProcessFrontendResponse() を呼んで
フロントエンドへの新しいリクエストをするようにしました。
</p>
</li>
<li>is_system_catalog() で、可能ならば pgpool_regclass を使うようにしました。(Tatsuo Ishii)</li>
<li>pool_get_insert_table_name() のメモリリークを修正しました。(Tatsuo Ishii)
<p>
nodeToString() でセッションコンテクストのメモリコンテクストを使ったあと、
セッション終了までは、メモリを開放していませんでした。
</p>
<p>詳しくはバグトラックをご覧ください。</p>
<blockquote>
#24 Severe memory leak in an OLTP environment<br>
Date: 2012-08-28 03:43<br>
Reporter: singh.gurjeet<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=24">http://www.pgpool.net/mantisbt/view.php?id=24</a>
</blockquote>
</li>
<li>do_query() のセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
<p>
クエリキャッシュが有効で拡張問い合わせが使われているとき、do_query() はシステムカタログに接続し、
pool_read2() を使います。
しかし、parse メッセージパケットを Parse() で取得し、パケットの内容が pool_read2() のバッファにあります。
このため、do_query() はパケットの内容を分割できず、セグメンテーションフォルトを引き起こしていました。
</p>
<p>
これを解決するために、メモリを確保し、パケット内容をコピーし、Parse() を飛ばすようにしました。
ただし、パケットの中にはクエリコンテクストが参照しているクエリ文字列も含まれています。
そのため、このクエリ文字列をコピーしてポインタをクエリコンテクストに保持する必要があります。
</p>
<p>
これは、Parse() だけの話でなく、他のプロトコルモジュールにもある問題と考えています。
本修正はそれらにも適用しますが、そのためには、ProcessFrontendResponse() を変更します。
</p>
<p>この問題はバグトラック #21 で報告されました。</p>
<blockquote>
#21 pgpool-II 3.2.0 cannot execute sql through jdbc<br>
Date: 2012-08-17 16:31<br>
Reporter: elisechiang<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=21">http://www.pgpool.net/mantisbt/view.php?id=21</a>
</blockquote>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.4"></a>3.1.4 (hatsuiboshi) 2012/08/06</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>このバージョンは3.1.3に対するバグ修正リリースです。</p>
<p>また、PostgreSQL 9.2 に対応しました。</p>
<h3>バグ修正</h3>
<ul>
<li>各ノードにおいて、トランザクション状態によって COMMIT / ABORT するかどうかを判定できるように、
pool_send_and_wait() を修正しました。(Tatsuo Ishii)
<p>
マルチステートメントが送信されたとき、明示的なトランザクション内にあるプ
ライマリか、明示的なトランザクション内でないスタンバイで発生する可能性が
ありました。
</p>
<p>これは、[pgpool-general-jp: 1049] で報告されました。</p>
<blockquote>
Subject:
<a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2012-April/001048.html">[pgpool-general-jp: 1049]</a>
COMMITでエラー<br>
From: 稲村暢亮<br>
Date: Mon, 30 Apr 2012 13:48:48 +0900
</blockquote>
</li>
<li>Solaris でのロードバランスを修正しました。(Tatsuo Ishii)
<p>Solaris での random() 関数の仕様のために問題があったため、rand() に変更しました。</p>
<p>この事象は [pgpool-general: 396] で報告されました。</p>
<blockquote>
<a href="http://www.pgpool.net/pipermail/pgpool-general/2012-April/000397.html">[pgpool-general: 396]</a>
strange load balancing issue in Solaris<br>
From: Aravinth<br>
Date: Sat, 28 Apr 2012 07:26:58 +0530
</blockquote>
</li>
<li><a href="#pool_status">SHOW pool_status</a> の出力結果に、
<a href="#BACKEND_DATA_DIRECTORY">backend_data_directory</a>,
<a href="#SSL_CA_CERT">ssl_ca_cert</a>,
<a href="#SSL_CA_CERT_DIR">ssl_ca_cert_dir</a> がなかったので追加しました。(Nozomi Anzai)
</li>
<li>パラレルモードでないとき、<a href="#pcp_systemdb_info">pcp_systemdb_info</a> コマンドが
segfault してたのを修正しました。(Nozomi Anzai)</li>
<li>"unnamed prepared statment does not exist" というエラーが出るのを修正しました。(Tatsuo Ishii)
<p>
このエラーは pgpool が内部的に発行しているクエリで発生し、
クライアントが発行する unnamed ステートメントを破壊していました。
</p>
<p>
拡張問い合わせクエリが実行されたときには、内部的に発行するクエリのステートメントとポータルに
名前をつけるようにしました。
</p>
</li>
<li>ホットスタンバイモードでクエリ衝突が起きたときにハングアップするのを修正しました。(Yugo Nagata)
<p>これは、以下の手順で再現します。</p>
<pre>(S1) BEGIN;
(S1) SELECT * FROM t;
(S2) DELETE FROM t;
(S2) VACUUM t;
</pre>
</li>
<li>pid ファイルの読み書きを改善しました。(Tatsuo Ishii)</li>
<li><a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
で報告された、process_query() のバグを修正しました。(Tatsuo Ishii)
<p>
プライマリでは処理するデータがなく スタンバイにはある状態のときに、
プライマリの処理を待ってしまうことがありました。
</p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
Transaction never finishes<br>
From: Luiz Pasqual<br>
Date: Thu, 28 Jun 2012 09:55:23 -0300
</blockquote>
</li>
<li>マスタ・スレーブモードでの BEGIN TRANSACTION の扱いを修正しました。(Tatsuo Ishii)
<p>
これは <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html">[pgpool-general: 714]</a>
で報告されました。
</p>
<p>
3.1 以降、BEGIN TRANSACTION をすべてのノードに送るようにしました。
PostgreSQL の仕様では、スタンバイノードには BEGIN TRANSACTION READ WRITE を送ることはできませんが、
BEGIN WORK ISOLATION LEVEL SERIALIZABLE についてチェックしておらず、スタンバイノードに送信していました。
もちろんこれは誤りで、スタンバイノードが SERIALIZABLE モードになることは許されていません。
</p>
<p>
そのため、BEGIN WORK ISOLATION LEVEL SERIALIZABLE をチェックするようにしました。
</p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000719.html">[pgpool-general: 714]</a>
Load Balancing / Streaming Replication / Isolation Level serializable<br>
From: Philip Hofstetter<br>
Date: Wed, 11 Jul 2012 17:04:26 +0200
</blockquote>
</li>
<li>SET TRANSACTION ISOLATION LEVELSERIALIZABLE などのクエリはプライマリのみに送るよう
send_to_where() を修正しました。(Tatsuo Ishii)
<p>
マスタ・スレーブモードで、以前はこのクエリはプライマリだけではなくスタンバイにも送られていましたが、
もちろんこれはエラーとなります。同じようなクエリとして以下のものがあります。
</p>
<ul>
<li>SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL SERIALIZABLE</li>
<li>SET transaction_isolation TO 'serializable'</li>
<li>SET default_transaction_isolation TO 'serializable'</li>
</ul>
<p>
これは <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000720.html">[pgpool-general: 715]</a>
で報告されました。
<p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-July/000720.html">[pgpool-general: 715]</a>
Re: Load Balancing / Streaming Replication / Isolation Level serializable<br />
From: Tastuo Ishii<br />
Date: Thu, 12 Jul 2012 00:16:58 +0900
</blockquote>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.3"></a>3.1.3 (hatsuiboshi) 2012/01/31</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは3.1.2に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>m4 ファイルを追加しました。これにより古い OS で起こるコンパイルの問題を回避できます。(Tatsuo Ishii)</li>
<li>フェイルオーバを適切に処理するよう detect_postmaster_down_error() 関数を修正しました。(Tatsuo Ishii)<br>
<p>
以前はバックエンドソケットの読み込みに失敗することがありました。
</p>
</li>
<li>シグナル割り込みによって、セマフォが解放されないままプロセスが終了することがあるバグを
修正しました。(Tatsuo Ishii)
</li>
<li>reset_query 時のメモリリークを修正しました。 (Tatsuo Ishii)</li>
<li>pool_ssl_read() 関数が大きいサイズのデータを読み込めるよう修正しました。(Tatsuo Ishii)
<p>
以下の報告によるものです。<br>
<a href="http://www.pgpool.net/pipermail/pgpool-general/2012-March/000299.html%22">
http://www.pgpool.net/pipermail/pgpool-general/2012-March/000299.html</a>
</p>
</li>
<li>syslog を有効にしたときに起こるデッドロックを修正しました。(Tatsuo Ishii)
<p>
このバグは以下で報告され、パッチは Gilles Darold さんにより提供頂きました。<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=9">
http://www.pgpool.net/mantisbt/view.php?id=9</a>
</p>
</li>
<li>マスター・スレーブモードで複数の文を扱えるように修正しました。(Tatsuo Ishii)
<p>
以前は BEGIN, END 等を用いた複数文からなるクエリはエラーとなっていました。
</p>
</li>
<li>マスタサーバがダウンした際に、子プロセスが NULL ポインタを参照しようとするバグを修正しました。(Tatsuo Ishii)
<p>
このバグは以下で報告されました。<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=51">
http://www.pgpool.net/mantisbt/view.php?id=51</a>
</p>
</li>
<li>マスターノードIDの初期値が正しく設定されるように pool_start_query() 関数を修正しました。(Tatsuo Ishii)
<p>
このバグのためにセグメントフォルトが発生することがありました。
</p>
</li>
<li>pool_setall_node_to_be_sent() 関数において BACKEND_INFO マクロの代わりに
private_backend_status 変数を利用するよう修正しました。(Tatsuo Ishii)
<p>
これは状況により BACKEND_INFO が利用できなくなる場合があったためです。(Tatsuo Ishii)
</p>
</li>
<li>子プロセスがレプリケーション遅延チェック要求を送り続けることがあるバグを修正しました。(Tatsuo Ishii)
<p>
以前はフェイルオーバ時にレプリケーション遅延をチェックする worker プロセスを限定した条件でしか
起動していませんでしたが、これは間違いで、常に再起動する必要があります。
</p>
</li>
<li>デバッグメッセージにヌル文字が含まれないように修正しました。
ヌル文字が含まれるログは、バイナリファイルであると認識されることがあります。(Toshihiro Kitagawa)</li>
<li>以下の場合に parser memory をリストアするよう SimpleQuery() 関数を修正しました。
<ol>
<li>組み込み show コマンド使用時</li>
<li>パラレルクエリモード</li>
<li>クエリキャッシュ使用時</li>
</ol>
さもないと、後で不正な palloc を発生する障害が起きるからです。(Tatsuo Ishii)
</li>
<li>PREPARE 文でエラーが起きた際に発生するハングアップを修正しました。(Toshihiro Kitagagwa)
<p>
Tominari Katsumata さんの報告に基づきます。
</p>
</li>
<li>doc/pgpool-fr.html を Makefile.am に追加しました。
これはフランス語のドキュメントを追加した際に、追加し忘れたものです。(Tatsuo Ishii)</li>
<li>デーモンモードで syslog を有効にしている際に md5 認証で発生するハングアップを修正しました。(Yugo Nagata)</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.2"></a>3.1.2 (hatsuiboshi) 2012/01/31</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは3.1.1に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>トランザクション隔離レベルの処理で、READ UNCOMMITTED と REPEATABLE READ が解釈できていませんでしたが、
これを修正しました。(Tatsuo Ishii)</li>
<li>以下のスレッドで報告されている無限ループを修正しました。(Tatsuo Ishii)
<p>
<a href="http://www.pgpool.net/pipermail/pgpool-general/2011-December/000099.html">
http://www.pgpool.net/pipermail/pgpool-genral/2011-December/000099.html</a><br>
プライマリからから受け取ったバッファが空である一方で、スタンバイのどれかが
受け取ったバッファが空でないとき、pgpool へのパケットが送られてしまう、
という可能性が考慮されていませんでした。
</p>
<p>
この事象は例えば、postgresql.conf を再読み込みしたときに発生することがありました。
</p>
<p>
この修正では、スタンバイからしか受け取れなかったバッファは無視するようにしました。
</p>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.1"></a>3.1.1 (hatsuiboshi) 2011/12/06</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは3.1に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li><a href="#BLACK_FUNCTION_LIST">black_functon_list</a> と
<a href="#WHITE_FUNCTION_LIST">white_function_list</a> の読み込み処理で
メモリ破壊を起こすバグを修正しました(Tatsuo Ishii)。
</li>
<li>check_replication_time_lag の誤ったエラーメッセージを修正しました(Tatsuo Ishii)。
<p>
ストリーミングレプリケーションの遅れのチェックのために PostgreSQL に接続できなかった時に
誤ったメッセージを出していました。
3.1以降では <a href="#HEALTH_CHECK_USER">health_check_user</a> はこの目的のために使われていないので、
これは誤りです。
</p>
</li>
<li>メモリーリークを修正しました(Toshihiro Kitagawa)。
<p>これは、基本的に3.0.5(commit 19a4ea9215da0b61728741fc0da2271958b09238)で行われた修正と同じものです。</p>
</li>
<li>strncpy()を使った修正を多数行いました(Tatsuo Ishii)。
<p>strncpy()が使われている箇所が複数あり、そこではコピー長とバッファサイズが同じであるケースが
考慮されていません。
このため、コピー後の文字列がNULL終端されていない可能性があり、多くの問題を後で引き起こすことになります。
この問題を修正するために、ほとんどの箇所をstrlcpy()で置き換えました。</p>
</li>
<li>可能な場合にはキャッシュされたバックエンドの状態情報を更新するようにしました(Tatsuo Ishii)。
<p>
これにより、Jeff Frostから以下のメールで報告された問題が解決されました。
すなわち、 follow_master_command が正しくバックエンドの状態を読み取れない問題です。
</p>
<pre>Subject: [Pgpool-general] diagnosing BackendError from pcp_recovery_node
To: pgpool-general@pgfoundry.org
Date: Wed, 05 Oct 2011 15:15:07 -0700
</pre>
</li>
<li>Windows環境でのみ必要なPGDLLIMPORTIを削除しました。
<p>
これはgccを使わない環境で問題を引き起こします。
パッチはIbrar Ahmedさんが提供しました。
</p>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.1.0"></a>3.1.0 (hatsuiboshi) 2011/09/08</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは3.1系列の最初の版で、3.0系からの「メジャーバージョンアップ」にあたります。
</p>
<h3>互換性のない変更</h3>
<p>
</p><ul>
<li><a href="#INSERT_LOCK">insert_lock</a> のロック方法を変更しました。(Toshihiro Kitagawa)
<p>
以前のinsert_lockは、シーケンステーブルに対して行ロックを行いましたが、
現在は、pgpool_catalog.insert_lockテーブルに対して行ロックを行います。
その理由は、シーケンステーブルに対するロックが内部エラーを引き起こすため、
PostgreSQLのコア開発者がそれを許可しないことを決定したためです。
</p>
<p>
したがって、pgpool-II経由でアクセスするすべてのデータベースにinsert_lockテーブルを
あらかじめ作成しておく必要があります。
もし、insert_lockテーブルが存在しない場合は、挿入対象のテーブルに対してロックを行います。
これは、pgpool-II 2.2と2.3シリーズのinsert_lockと同じ動作です。
</p>
<p>
また、過去のバージョンと互換性のあるinsert_lockを使用したい場合は、
<a href="#install">configureオプション</a>(--enable-sequence-lock,--enable-table-lock)で
設定できます。
</p>
</li><li><a href="#BACKEND_SOCKET_DIR">backend_socket_dir</a> パラメータを廃止しました。
<p>
その代わりに、<a href="#BACKEND_HOSTNAME">backend_hostname</a> が'/'で始まるならば、
それをUNIXドメインへのパスとみなします。
backend_hostnameが空ならば、デフォルトのUNIXドメインパス(/tmp)が使われます。
これは、libpqインタフェースの規約に従います。
</p>
<p>
パッチはJehan-Guillaume (ioguix) de Rorthaisさんから頂きました。
</p>
</li><li>フェイルオーバー時にpgpool_walrecrunning()を使用せず、
プライマリノードへの昇格が完了するまで待つようになりました。(Toshihiro Kitagawa)
<p>
関数を使用しない理由はプライマリノードを確実に見つけることができないためです。
しかし、この修正にはプライマリノードが現れないときに <a href="#RECOVERY_TIMEOUT">recovery_timeout</a> の間
pgpool-IIが待ってしまう問題がまだ残っています。
</p>
</li><li>PostgreSQL DBノード情報を出力する <a href="#pool_nodes">pool_nodes</a> に
「ノードID」を追加しました。(Jean-Paul Argudo)
</li><li>シーケンス関数(nextval, setval)の扱いを
<a href="BLACK_FUNCTION_LIST">black/white_function_list</a>の設定に完全に従うように変更しました。
以前、それらは常に書き込み関数として扱われていました。(Toshihiro Kitagawa)
</li></ul>
<p></p>
<h3>新機能</h3>
<p>
</p><ul>
<li><a href="#LOG_DESTINATION">syslog</a> に対応しました。
パッチはGilles Daroldさんから頂き、Guillaume Lelargeさんがレビューと編集をしました。
</li><li>PostgreSQL 9.0で導入されたapplication_nameに対応しました。(Tatsuo Ishii)
<p>
コネクションが再利用されたときに、スタートアップパケットのapplication_nameをバックエンドへ送信し、
ラメータステータスをフロントエンドに返します。
</p>
</li><li>pgpool-II内部で使用するシステムカタログキャッシュの有効時間を、
秒単位で指定できる設定項目relcache_expireが追加されました。(Tatsuo Ishii)
<p>
これにより、ALTER TABLEによってテーブル定義が変更された際に、
もはや有効でない結果を利用してしまうリスクが軽減されます。
</p>
</li><li><a href="#FOLLOW_MASTER_COMMAND">follow_master_command</a> パラメータを追加しました。
<p>
このパラメータには、マスタースレーブモードのストリーミングレプリケーション構成において
マスタノードがフェイルオーバーした後に実行されるコマンドを指定します。
</p>
<p>
パッチはGilles Daroldさんから頂きました。
</p>
</li><li><a href="#pcp_promote_node">pcp_promote_node</a> コマンドを追加しました。
<p>
このコマンドはpgpool-IIに対して新しいマスタノードへの昇格を行います。
これは、マスタースレーブモードのストリーミングレプリケーション構成のみで使用できます。
</p>
<p>
パッチはGilles Daroldさんから頂きました。
</p>
</li><li><a href="#pcp_pool_status">pcp_pool_status</a> コマンドを追加しました。
また、対応するC APIも追加されています。
<p>
パッチはJehan-Guillaume (ioguix) de Rorthaisさんから頂きました。
</p>
</li><li>バックエンドごとのパラメータ"<a href="#BACKEND_FLAG">backend_flag</a>"を追加しました。(Tatsuo Ishii)
<p>
これは、バックエンドごとの動作を制御します。
今は"ALLOW_TO_FAILOVER"または"DISALLOW_TO_FAILOVER"が指定できます。
</p>
</li><li><a href="#HEALTH_CHECK_PASSWORD">health_check_password</a> パラメータを追加しました(Nicolas Thauvin)
</li><li><a href="#SR_CHECK_PERIOD">sr_check_period</a>、<a href="#SR_CHECK_USER">sr_check_user</a>、
<a href="#SR_CHECK_PASSWORD">sr_check_password</a> パラメータを追加しました。(Tatsuo Ishii)
<p>これらは、ストリーミングレプリケーションの遅延チェックとプライマリノードの決定に使用されます。</p>
</li><li>pg_md5コマンドに--username(または-u)オプションを追加しました。(Nicolas Thauvin)
<p>
これは、UNIXアカウントを持たないユーザの管理を可能にします。
日本語ドキュメントはTatsuo Ishiiさんが修正しました。
</p>
</li><li>pgpool_adm関数をpgpool_adm/に追加しました。(Jehan-Guillaume (ioguix) de Rorthais)
<p>これらは、pcpコマンドのように動作するC言語で書かれたユーザ定義関数です。</p>
</li><li>簡体字中国語版のドキュメントを追加しました(Huang Jian, Sun Peng)
</li><li>関数をアンインストールするためのSQLファイルをsql/に追加しました(Nicolas Thauvin)
</li><li>マスタースレーブモードにおいて、unloggedテーブルに対するSELECTは、
常にマスター(primary)で実行されるようになりました(Toshihiro Kitagawa)
</li></ul>
<p></p>
<h3>バグ修正</h3>
<p>
</p><ul>
<li>スタンバイノードでJDBCドライバのカーソルが使用できないバグを修正しました。(Toshihiro Kitagawa)
<p>
この修正によって、マスタースレーブモードではトランザクションコマンドが
すべてのノードに送られるようになります。
</p>
</li><li>空のクエリの処理に関するバグを修正しました。(Toshihiro Kitagawa)
<p>
空のクエリはSELECTクエリと同じ扱いになります。
この修正は、空のクエリのあとのロードバランスを可能にします
</p>
</li><li>カラム定義が"DEFAULT nextval(('"x_seq"'::text)::regclass)"のようになっていても
<a href="#INSERT_LOCK">insert_lock</a> が正しく動作するように修正しました(Toshihiro Kitagawa)
</li><li>フェイルオーバー中はエラーメッセージを出力するように<a href="#pcp_attach_node">pcp_attach_node</a>
コマンドを修正しました(Toshihiro Kitagawa)
</li><li>拡張問い合わせプロトコルでpgpool-IIがクエリを解析できないときに出力されるログメッセージが
クエリを表示するよう修正しました(Toshihiro Kitagawa)
</li><li>pgpool-IIマニュアルの <a href="#BACKEND_WEIGHT">backend_weight</a> に関する説明を修正しました。
それは、pgpool.confの再読み込みで変更できます(Tatsuo Ishii)
</li><li>英語のチュートリアルドキュメント内の表現の改善と修正を行いました。
修正の提案はHuang Jianさんによるものです(Tatsuo Ishii)
</li><li>rawモードでノードを復帰させたときにノードの状態が更新されないバグを修正しました(Guillaume Lelarge)
</li><li>ストリーミングレプリケーションモードにおけるレプリケーション遅延の計算が間違っていたのを修正しました(Tatsuo Ishii)
</li><li>フェイルオーバーのログメッセージにおける誤った関数名
"notice_backend_error"を、正しいもの"degenerate_backend_set"に置き換えました(Tatsuo Ishii)
</li><li>pgpool.conf解析後の不要なログ出力を削除しました(Tatsuo Ishii)
</li><li>バックエンドを新規追加した後に起こり得るpgpool/worker子プロセスのクラッシュを修正しました。
修正はGurjeet Singhさんの提案によるものです(Tatsuo Ishii)
</li><li>FOR SHARE/UPDATE句のあるサブクエリを含むSELECTがスレーブ(standby)に送られるバグを修正しました(Tatsuo Ishii)
</li><li>PREPARE文でデフォルト値のタイムスタンプ書き換えに失敗するバグを修正しました。
これは以前は動作していましたが、3.0で動作しなくなっていました(Toshihiro Kitagawa)
</li><li>getopt_long()がない環境でpcpコマンドのコンパイルが失敗するのを修正しました(Tatsuo Ishii)
</li><li>rawモード、<a href="#ENABLE_POOL_HBA">enable_pool_hba</a>が無効、バックエンドが2台以上の場合に
pgpool子プロセスがクラッシュするのを修正しました(Toshihiro Kitagawa)
</li><li>メモリリークをいくつか修正しました(Toshihiro Kitagawa)
</li></ul>
<p></p>
<h3>改良</h3>
<p>
</p><ul>
<li>ストリーミングレプリケーション構成でのオンラインリカバリにおいて、
リカバリ終了時に子プロセスを再起動しないようにしました。
そのため、既存のセッションはオンラインリカバリ中も継続することができます(Tatsuo Ishii)
</li><li>ストリーミングレプリケーションモードにおいて、<a href="#pcp_attache_node">pcp_attache_node</a> が
既存のセッションを切断しなくなりました。
ほかのモードでは依然としてセッションが切断されます(Tatsuo Ishii)。
</li><li>PostgreSQL 9.0のパーサを移植しました。
これによりPostgreSQL 9.0で新しく導入された暗黙のインデックス名を使用した
CREATE INDEXが実行できるようになりました。パッチは石田さんから頂きました。
</li><li><a href="#BLACK_FUNCTION_LIST">black_function_list</a> と
<a href="#WHITE_FUNCTION_LIST">white_function_list</a>パラメータに正規表現が使えるようになりました。
パッチはGilles Daroldさんから頂き、Guillaume Lelargeさんがレビューしました。
</li><li>読みやすいようにpgpool.confのサンプルファイルを再構成しました(Gleu)
</li><li>pgpool-IIマニュアルのすべてのパラメータに‹a name="..."›タグを
追加しました(Haruka Takatsuka)
</li><li>pgpool-IIマニュアルのストリーミングレプリケーションにおけるオンラインリカバリの説明を改善しました(Tatsuo Ishii)
</li><li>ストリーミングレプリケーションモードにおけるレプリケーション遅延をチェックするための
関数を変更しました。(Tatsuo Ishii)
<p>
現在、pgpoolはpg_last_xlog_receive_location()の代わりにpg_last_xlog_replay_location()を使用します。
修正はAnton Yuzhaninovさんの提案によるものです
</p>
</li><li>カラムのデフォルト値に任意の式を指定してもタイムスタンプ書き換えが動作するようにしました。(Tatsuo Ishii)
<p>
以前は、now()が含まれているものを検知すると、単純にそれをnow()で置き換えてました。
これは、デフォルト値の誤った書き換えを引き起こします。
例えば、timezone('utc'::text, now())です。
</p>
<p>
しかし、これは簡易プロトコルのみへの適用であることに注意してください。
拡張プロトコル(例えばJava, PHP PDO)または、SQLの"PREPARE"にはまだ適用されていません
</p>
</li><li>レプリケーション遅延のチェックに失敗したときに出力されるエラーメッセージを改良しました(Nicolas Thauvin)
</li><li>エラーメッセージ"do_md5: read_password_packet failed"をデバッグレベルにしました(Toshihiro Kitagawa)
</li><li>pgpool-regclass()をPostgreSQL 9.1でコンパイルできるようにしました(Tatsuo Ishii)
</li><li>英語版と日本語版のpgpool-IIマニュアルを更新、同期しました(Tatsuo Ishii)
</li></ul>
<!-- ================================================================================ -->
<!-- 3.0 -->
<!-- ================================================================================ -->
<hr><a name="release3.0.x"></a>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.0.13"></a>3.0.13 (umiyameboshi) 2013/09/06</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.0.12 に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>
doc/basebackup.sh スクリプトの ssh コマンドの間違いを修正しました。(Tatsuo Ishii)
</li>
<li>
レプリケーションモードにおけるプリペアド文のパース処理を修正しました。(Tatsuo Ishii)
<p>
レプリケーションモードで SELECT 以外のクエリをパースする際には、
ノード間の一貫性保持のため自動的にトランザクションが開始されますが、
トランザクションを閉じる処理が行われていませんでした。
そのため、実際に誤っているクエリだけではなく、その次にパース処理されたクエリもアボートされていました。
</p>
<p>
このバグは [pgpool-general: 1877] で Sean Hogan さんにより報告されました。
</p>
<blockquote>
[pgpool-general: 1877] current transaction is aborted, commands ignored<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-July/001905.html
</a>
</blockquote>
</li>
<li>
日本語ドキュメントの typo を修正しました。 (Yugo Nagata)
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.0.12"></a>3.0.12 (umiyameboshi) 2013/07/10</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは 3.0.11 に対するバグ修正リリースです。
</p>
<h3>バグ修正</h3>
<ul>
<li>
man ページに -D オプションの記述を追加しました。（Tatsuo Ishii)
</li>
<li>
オンラインリカバリ時のフェイルバックの完了待機でタイムアウト処理をするようにしました。(Tatsuo Ishii)
<p>
これによりリカバリが永遠に終わらず pgpool-II が終了できなくなる状況を回避します。
この現象は特に follow_master_command の実行中に起こり得ました。
</p>
</li>
<li>
PostgreSQL がエラーを返したときに do_query() がハングしないよう修正しました。
(Tatsuo Ishii)
<p>
典型的な症状が「pg_stat_activety によると SELECT が実行されたままのように見える」というものです。
これを解決するため、pgpool-II は当該プロセスを終了させ、既存のコネクションを捨てるように修正しました。
</p>
</li>
<li>
拡張プロトコルの際に do_query で発生しうるハングアップを修正しました。
(Tatsuo Ishii)
<p>
これは insert_lock が有効で、pgpool_catalog.insert_lock が存在することに起こり得ます。
詳しくは [pgpool-general: 1684] を参照してください。
</p>
<blockquote>
[pgpool-general: 1684] insert_lock hangs <br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html">
http://www.sraoss.jp/pipermail/pgpool-general/2013-May/001711.html
</a>
</blockquote>
</li>
<li>
COMMIT 時エラーに不要なバックエンド切り離しを行わないようにしました。
(Tatsuo Ishii)
<p>
マスタースレーブモードで、COMMIT 時にマスターノードでエラーが発生していたとしても、他のスレーブノードが正常な場合にはバックエンドを切り離す必要はありません。
これは、遅延トリガーのために "kind mismatch error" が発生しうるからです。
</p>
</li>
<li>
pgpool_regclass を pg_catalog スキーマに登録するよう修正しました。
(Tatsuo Ishii)
<p>
これは postgres_fdw のような、スキーマ検索パスが pg_catalog に限定されているクライアントに対応するために必要です。
</p>
</li>
<li>
pg_md5 コマンドで起こりうるクラッシュを修正しました。(Muhammad Usama)
</li>
<li>
スタートアップパケットに PostgreSQL ユーザ情報が含まれていなかった場合に発生する子プロセスのセグメンテーション違反を修正しました。(Yugo Nagata)
<p>
このバグは以下を実行することにより再現できます。
</p>
<pre>
$ psql -p 9999 -U ''
</pre>
<p>
enable_pool_hba が有効の場合は子プロセスがセグメンテーション違反で異常終了し、無効の場合には以下のメッセージがログに出力されていました。
</p>
<pre>
ERROR: pool_discard_cp: cannot get connection pool for user (null) database (null)
</pre>
<p>
また、両方の場合で psql はフロントエンドに何のメッセージ出力せずに終了していました。
修正後は、スタートアップパケットに PostgreSQL ユーザが指定されていない場合には以下のメッセージがログとフロントエンドの両方に出力されます。
これは PostgreSQLと同じ振る舞いです。
</p>
<pre>
FATAL: no PostgreSQL user name specified in startup packet
</pre>
</li>
<li>
マニュアルの ssl_sa_cert, ssl_ca_cert_dir オプションの説明を SSL セクションに移動しました。(Yugo Nagata)
</li>
<li>
ssl_sa_cert, ssl_ca_cert_dir オプションの説明を日本語マニュアルに追加しました。(Yugo Nagata)
</li>
<li>
pcp_recovery_node コマンドで、バックエンドノード番号をチェックするように修正しました。(Yugo Nagata)
<p>
不正な値が使用された場合、リカバリで実行されるスクリプトの引数に空の値が渡されており、誤動作の原因となっていました。
特にベースバックアップを行うスクリプトで、rsync が関係のないファイルを削除してしまうことがありました。
</p>
</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.0.11"></a>3.0.11 (umiyameboshi) 2013/04/26</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンでは、3.0.10における様々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>
設定パラメータの一覧を表示する "SHOW pool_status" で pool_passwdが表示されていないのを修正しました。(Yugo Nagata)
</li>
<li>
拡張プロトコルの処理における timestamp の書き換えに関する長い間見過ごされていてたバグを修正しました。(Tatsuo Ishii)
<p>
Parse() 関数は、parse メッセージの書き換えの際に palloc() を使ってメモリを確保していました。
書き換えられたメッセージは pool_create_sent_message()
関数などが管理するデータ領域に格納されますが、これが問題となっていました。
この関数ではデータが session context memory 中に存在することを想定しているのに対し、
palloc() では query context においてメモリの割り当てを行っており、この領域は
query context 終了時に解放されます。しかし、他の関数もこのメモリ領域を解放しようとするため、
セグメンテーション違反や二重解放を含む様々な問題の原因となっていました。
この問題は、書き換えたメッセージを格納するメモリを session context を用いて確保するこで修正されました。
これは pgpool-II 3.0 以来ずっと存在していたバグです。
</p>
<p>
この問題は、Naoya Anzai さんによって解析され、パッチが提供されました。
</p>
<blockquote>
[pgpoolgenera-jp: 1146]<br />
拡張問い合わせプロトコルでセグメンテーションフォルト<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html">
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001145.html
</a>
</blockquote>
</li>
<li>
md5認証で長いユーザ名を処理する際のバグを修正しました。(Tatsuo Ishii)
<p>
ユーザ名が 32 バイトより長い場合、md5 認証が動作していませんでした。
この問題は [pgpool-general: 1526] で Thomas Martin さんにより報告されました。
</p>
<blockquote>
[pgpool-general: 1526]<br />
[pgPool-II 3.2.3] MD5 authentication and username longer than 32 characters.<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html">
http://www.pgpool.net/pipermail/pgpool-general/2013-March/001551.html
</a>
</blockquote>
</li>
<li>レプリケーション遅延の計算はスタンバイサーバがプライマリサーバより遅れている場合にのみ行うよう修正しました。(Yugo Nagata)
<p>
タイミングによってスタンバイよりプライマリの方がレプリケーションが遅延
しているように見える場合があり、その場合には負値の遅延が計算されていました。
この値が符号無し変数に代入されると、実際には遅延が生じていないにも関わらず、
ログに遅延が負値で出力され、されに悪いことには、ロードバランス機能により
SELECT クエリがプライマリに振り分けられ、その結果プライマリの負荷が高まる
ことがありました。
</p>
<p>
この問題は Saitoh Hidenori さんによって報告、解析されました。
</p>
<blockquote>
[pgpool-genera-jp: 1145]<br />
レプリケーション遅延確認の不具合について<br />
<a href="http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html">
http://www.pgpool.net/pipermail/pgpool-general-jp/2013-March/001144.html
</a>
</blockquote>
</li>
<li>pgpool-recovery が PostgreSQL 9.3 に対応しました。 (Tatsuo Ishii)
<p>
パッチは Asif Rehman さんにより提供され、これに Tatsuo Ishii が若干の修正を
加えました。
</p>
<blockquote>
[pgpool-hackers: 180] <br />
compile error in ppool-recovery<br />
<a href="http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html">
http://www.pgpool.net/pipermail/pgpool-hackers/2013-April/000179.html
</a>
</blockquote>
</li>
<li>pool_has_pgpool_regclass が pgpool_regclass() の実行権限をチェックするよう修正しました。 (Tatsuo Ishii)
<p>
pgpool_regclass が存在する場合でも、pgpool がこの関数を実行できない場合に、
バックエンドへの接続がハングしていました。この問題は、pgpool_regclass
から実行権限を剥奪し、ネイティブレプリケーションモードで INSERT を実行
することで再現可能です。
</p>
<p>
この問題は bugtrack #53 で報告されました。
</p>
<blockquote>
#53 pgpool_regclas hangs all connections<br />
Date: 2013-04-04 13:35 <br />
Reporter: tmandke<br />
<a href="http://www.pgpool.net/mantisbt/view.php?id=53">
http://www.pgpool.net/mantisbt/view.php?id=53
</a>
</blockquote>
</li>
<li>detect_postmaster_down_error() のエラーメッセージを修正しました。(Tatsuo Ishii)
<p>
例えば、"LOG: detect_stop_postmaster_error: detect_error error" を
"LOG: detect_postmaster_down_error: detect_error error" に修正するなどです。
</p>
</li>
</ul>
<h2>3.0.10 (umiyameboshi) 2013/02/08</h2>
<h3>概要</h3>
<p>
このバージョンでは、3.0.9における様々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>md5 認証で競合が発生する不具合が修正されました。(Tatsuo Ishii)
<p>
pool_passwd のファイル識別子は pgpool の親プロセスで開かれたものが子プロセス
に引き継がれてます。複数の接続で同時に md5 認証を行う際には、pool_get_passwd が
呼ばれ、ファイル識別子が走査されますが、ファイル識別子が共有されるために md5 認証
が失敗することがありました。この問題は、個々の子プロセスで pool_passwd ファイルを
開き直すことで解決されました。
</p>
<p>
この問題は [pgpool-general:1141] にて、Jason Slagle さんによって報告・解析されました。
</p>
<blockquote>
[pgpool-general: 1141] Possible race condition in pool_get_passwd<br />
From: Jason Slagle<br />
Date: Sun, 28 Oct 2012 01:12:52 -0400<br />
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-October/001160.html</a>
</blockquote>
</li>
<li>pool_send_severity_message() で未初期化のメモリを使用しないよう修正しました。
(Tatsuo Ishii)
<p>
このバグによりセグメンテーション違反が発生することがありました。
バグトラック #33 に投稿された valgrind 実行結果（dudee さんによる）にて報告されました。
</p>
<blockquote>
#33 pgpool-II 3.2.1 segfault<br />
Reporter: dudee
Date: 2012-10-30 19:16
<a href="http://www.pgpool.net/mantisbt/view.php?id=33">
http://www.pgpool.net/mantisbt/view.php?id=33</a>
</blockquote>
</li>
<li>通常のテーブルと同名の一時テーブルがあるときに、クエリキャッシュの結果が不正になる
バグを修正しました。 (Tatsuo Ishii)
<p>
以下はバグを引き起こす処理の例です。
</p>
<pre>
1) CREATE TABLE t1(i int); -- 通常のテーブルを作成
2) INSERT INTO t1 VALUES(1);
3) SELECT * FROM t1; -- クエリキャッシュが作成される
4) CREATE TEMP TABLE t1(i int); -- 一時テーブルの作成
5) SELECT * FROM t1; -- 誤ったクエリキャッシュが作成される!
</pre>
<p>
#3 で t1 のキャッシュが生成されますが、#5 でこれが不正に使われており、一時テーブル t1 が
一時テーブルと見なされていないのが問題でした。
</p>
</li>
<li>pcp または worker 子プロセスの終了イベントを受信したときに、reaper() で wait3()
ループを終了しないように修正しました。 (Tatsuo Ishii)
<p>
修正前は、reaper() は子プロセスの終了イベントを誤って無視してしまい、ゾンビプロセスを作り、
新しいプロセスを生成できないことがありました。
</p>
<p>
この問題は[pgpool-general-jp: 1123]にて、後藤さんより報告され、修正の示唆を頂きました。
</p>
<blockquote>
[pgpool-general-jp: 1123] Re: オンラインリカバリ後にゾンビプロセスになる<br />
From: GOTO, Daisuke
Date: Wed, 21 Nov 2012 19:56:17 +0900
<a href="http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html">
http://www.sraoss.jp/pipermail/pgpool-general-jp/2012-November/001122.html</a>
</blockquote>
</li>
<li>pool_search_relcache() が REAL_MASTER_NODE_ID ではなく MASTER, MASTER_NODE_ID
を使用するように修正しました。 (Tatsuo Ishii)
<p>
ストリーミングレプリケーションモードで 0 番ノードがフェイルバックした場合、pgpool は
子プロセスを再起動しません。そのとき、REAL_MASTER_NODE_ID は 0 番ノードの接続
情報を探しにいきますが、これはバックエンドへの新しい接続が確立するまで存在しません。
そのため、接続情報の参照によって、セグメンテーションフォルトが発生していました。
この状況でも、MASTER または MASTER_NODE_ID は以前にキャッシュされたマスター
ノード ID を見にいくため、安全に使うことが出来ます。
</p>
</li>
<li>ストリーミングレプリケーションモードでレプリケーション遅延が大きくなったときに、
"portal not found" エラーが発生するバグを修正しました。 (Tatsuo Ishii)
<p>
これは delay_threshold が導入以来、ずっと存在していたバグです。
</p>
<p>
bind, describe, execute の実行時に遅延が域値を越えた場合、送り先の DB ノードは
変更されていました。しかし、parse がそれとは異なるノードに送られていた場合、送り先ノードには
parse された ステートメントやポータルが存在しないために bind, describe, execute は
失敗していました。 修正後は、大きな遅延が発生した場合でも、これらは parse が実行された
ノード以外には送られないようになりました。
</p>
</li>
<li>pg_md5 で、ユーザからのパスワード入力の後には改行するように修正しました。 (Yugo Nagata)</li>
<li>watchdog のポート番号が既に使用されていた場合にエラーメッセージを出力するよう修正しました。
(Yugo Nagata)
<p>
この問題は [pgpool-general: 1167] で Will Ferguson さんによって報告されました。
</p>
<blockquote>
[pgpool-general: 1167] Re: Watchdog error - wd_init: delegate_IP already exists<br />
From: Will Ferguson
Date: Tue, 6 Nov 2012 13:03:36 +0000
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-November/001186.html</a>
</blockquote>
</li>
<li>コネクションプールが存在しない場合には、child_exit() が send_frontend_exits()
を呼ばないよう修正しました。 (Tatsuo Ishii)
<p>
send_frontend_exits() は pool_connection_pool で指されてるオブジェクトを参照しているため、
修正前にはセグメンテーションフォルトが発生していました。バグトラック #44 の tuomas さんの報告によります。
</p>
<blockquote>
#44 pgpool went haywire after slave shutdown triggering master failover<br />
Reporter: tuomas
Date: 2012-12-11 00:33
<a href="http://www.pgpool.net/mantisbt/view.php?id=44">
http://www.pgpool.net/mantisbt/view.php?id=44</a>
</blockquote>
</li>
<li>pool_read() が不正なパケットを読み込んだ場合に、read_startup_packet() がアラームクロック
をリセットして StartupPacket を解放するよう修正しました。 (Nozomi Anzai)
<p>
修正前は、pgpool ポートの監視を行うプログラムの接続により、認証のタイムアウトが発生していました。
この問題は、バグトラック #35 で報告されました。
</p>
<blockquote>
#35 Authentication is timeout<br />
Reporter: tuomas
Date: 2012-11-20 11:54
<a href="http://www.pgpool.net/mantisbt/view.php?id=35">
http://www.pgpool.net/mantisbt/view.php?id=35</a>
</blockquote>
</li>
<li>pool_open() が誤ったバッファポインタを初期化していたバグを修正しました。 (Tatsuo Ishii)
<p>
このポインタは事前に memset() によって初期化されているため、実際にはこのバグによる害は
ありませんでした。
</p>
</li>
<li>ヘルプメッセージに -f オプションの説明を追加しました。 (Tatsuo Ishii)</li>
<li>ドキュメント中の、「パラメータ変更に再起動が必要かどうか」の情報を追記・修正しました。(Yugo Nagata)</li>
<li>pool_passwd に関する記述を pgpool_conf.sample*、および,ドキュメントに追加しました。 (Yugo Nagata)</li>
</ul>
<h2>3.0.9 (umiyameboshi) 2012/10/12</h2>
<h3>概要</h3>
<p>
このバージョンでは、3.0.8における様々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>read_startup_packet() を修正しました。(Tatsuo Ishii)
<p>
パケット長が 0 以下のときは直ちに return するべきでしたが、そうなっていなく、
メモリ確保時にエラーになっていました。
</p>
<p>これは pgpool-general:886 を参照してください。また、キャンセルアラームを追加しました。</p>
<blockquote>
[pgpool-general: 886] read_startup_packet: out of memory<br>
From: Lonni J Friedman<br>
Date: Wed, 8 Aug 2012 10:18:15 -0700<br>
<a href="http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html">
http://www.sraoss.jp/pipermail/pgpool-general/2012-August/000896.html</a>
</blockquote>
</li>
<li>s_do_auth() に NOTICE メッセージを追加しました。(Tatsuo Ishii)
<p>これがなかったために、ヘルスチェックが false アラームを受け取りフェイルオーバしていました。</p>
<p>これはバグトラックで報告されました。</p>
<blockquote>
#25 s_do_auth doesn't handle NoticeResponse (N) message<br>
Date: 2012-08-28 03:57<br>
Reporter: singh.gurjeet<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=25">http://www.pgpool.net/mantisbt/view.php?id=25</a>
</blockquote>
</li>
<li>s_do_auth() から、不要かつ混乱をまねくデバッグメッセージを削除しました。(Tatsuo Ishii)</li>
<li>SSL モードでの無限ループを修正しました。 (Tatsuo Ishii)
<p>
フロントエンドの SSL レイヤで溜っているデータがあるとき、
pool_process_query() がバックエンドに溜っているデータをチェックします。
もしそれが無かったときは再度ループして、フロントエンド/バックエンドがバッファを受け取っていないか
is_cache_empty() を以ってチェックします。
しかし、フロントエンドの SSL レイヤでデータが溜っているのを一度検知すると、
バックエンドに行ってまたチェックしようとします（無限ループ）。
</p>
<p>
これを解決するには、フロントエンドの SSL レイヤに溜っているデータがあり
かつ クエリが実行中でなければ、ProcessFrontendResponse() を呼んで
フロントエンドへの新しいリクエストをするようにしました。
</p>
</li>
<li>is_system_catalog() で、可能ならば pgpool_regclass を使うようにしました。(Tatsuo Ishii)</li>
<li>pool_get_insert_table_name() のメモリリークを修正しました。(Tatsuo Ishii)
<p>
nodeToString() でセッションコンテクストのメモリコンテクストを使ったあと、
セッション終了までは、メモリを開放していませんでした。
</p>
<p>詳しくはバグトラックをご覧ください。</p>
<blockquote>
#24 Severe memory leak in an OLTP environment<br>
Date: 2012-08-28 03:43<br>
Reporter: singh.gurjeet<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=24">http://www.pgpool.net/mantisbt/view.php?id=24</a>
</blockquote>
</li>
<li>do_query() のセグメンテーションフォルトを修正しました。(Tatsuo Ishii)
<p>
クエリキャッシュが有効で拡張問い合わせが使われているとき、do_query() はシステムカタログに接続し、
pool_read2() を使います。
しかし、parse メッセージパケットを Parse() で取得し、パケットの内容が pool_read2() のバッファにあります。
このため、do_query() はパケットの内容を分割できず、セグメンテーションフォルトを引き起こしていました。
</p>
<p>
これを解決するために、メモリを確保し、パケット内容をコピーし、Parse() を飛ばすようにしました。
ただし、パケットの中にはクエリコンテクストが参照しているクエリ文字列も含まれています。
そのため、このクエリ文字列をコピーしてポインタをクエリコンテクストに保持する必要があります。
</p>
<p>
これは、Parse() だけの話でなく、他のプロトコルモジュールにもある問題と考えています。
本修正はそれらにも適用しますが、そのためには、ProcessFrontendResponse() を変更します。
</p>
<p>この問題はバグトラック #21 で報告されました。</p>
<blockquote>
#21 pgpool-II 3.2.0 cannot execute sql through jdbc<br>
Date: 2012-08-17 16:31<br>
Reporter: elisechiang<br>
<a href="http://www.pgpool.net/mantisbt/view.php?id=21">http://www.pgpool.net/mantisbt/view.php?id=21</a>
</blockquote>
</ul>
<h2>3.0.8 (umiyameboshi) 2012/08/06</h2>
<ul>
<li>Solaris でのロードバランスを修正しました。(Tatsuo Ishii)
<p>Solaris での random() 関数の仕様のために問題があったため、rand() に変更しました。</p>
<p>この事象は [pgpool-general: 396] で報告されました。</p>
<blockquote>
<a href="http://www.pgpool.net/pipermail/pgpool-general/2012-April/000397.html">[pgpool-general: 396]</a>
strange load balancing issue in Solaris<br>
From: Aravinth<br>
Date: Sat, 28 Apr 2012 07:26:58 +0530
</blockquote>
</li>
<li>パラレルモードでないとき、<a href="#pcp_systemdb_info">pcp_systemdb_info</a> コマンドが
segfault してたのを修正しました。(Nozomi Anzai)</li>
<li>"unnamed prepared statment does not exist" というエラーが出るのを修正しました。(Tatsuo Ishii)
<p>
このエラーは pgpool が内部的に発行しているクエリで発生し、
クライアントが発行する unnamed ステートメントを破壊していました。
</p>
<p>
拡張問い合わせクエリが実行されたときには、内部的に発行するクエリのステートメントとポータルに
名前をつけるようにしました。
</p>
</li>
<li>pid ファイルの読み書きを改善しました。(Tatsuo Ishii)</li>
<li><a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
で報告された、process_query() のバグを修正しました。(Tatsuo Ishii)
<p>
プライマリでは処理するデータがなく スタンバイにはある状態のときに、
プライマリの処理を待ってしまうことがありました。
</p>
<blockquote>
Subject: <a href="http://www.pgpool.net/pipermail/pgpool-general/2012-June/000676.html">[pgpool-general: 672]</a>
Transaction never finishes<br>
From: Luiz Pasqual<br>
Date: Thu, 28 Jun 2012 09:55:23 -0300
</blockquote>
</li>
<li>wait_for_query_response() が、frontend がないときには何もしないように修正しました。(Tatsuo Ishii)
<p>バックエンドをリセットする reset_query_list のクエリを実行に時間がかかったときに
発生する可能性があり、またクラッシュすることがありました。</p>
</li>
</ul>
<h2>3.0.7 (umiyameboshi) 2012/04/23</h2>
<h3>概要</h3>
<p>
このバージョンでは、3.0.6におけるバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>m4 ファイルを追加しました。これにより古い OS で起こるコンパイルの問題を回避できます。(Tatsuo Ishii)</li>
<li>シグナル割り込みによって、セマフォが解放されないままプロセスが終了することがあるバグを修正しました。(Tatsuo Ishii)</li>
<li>reset_query 時のメモリリークを修正しました。 (Tatsuo Ishii)</li>
<li>以下の場合に parser memory をリストアするよう SimpleQuery() 関数を修正しました。
<ol>
<li>組み込み show コマンド使用時</li>
<li>パラレルクエリモード</li>
<li>クエリキャッシュ使用時</li>
</ol>
さもないと、後で不正な palloc を発生する障害が起きるからです。(Tatsuo Ishii)
</li>
<li>pool_ssl_read() 関数が大きいサイズのデータを読み込めるよう修正しました。以下の報告によるものです。(Tatsuo Ishii)<br />
<a href=http://www.pgpool.net/pipermail/pgpool-general/2012-March/000299.html">
http://www.pgpool.net/pipermail/pgpool-general/2012-March/000299.html</a></li>
<li>PREPARE 文でエラーが起きた際に発生するハングアップを修正しました。Tominari Katsumata さんの報告に基づきます。(Toshihiro Kitagagwa)</li>
</ul>
<h2>3.0.6 (umiyameboshi) 2012/01/31</h2>
<h3>概要</h3>
<p>
このバージョンでは、3.0.5におけるバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>以下のスレッドで報告されている無限ループを修正しました。(Tatsuo Ishii)<br/>
<a href="http://www.pgpool.net/pipermail/pgpool-general/2011-December/000099.html">
http://www.pgpool.net/pipermail/pgpool-genral/2011-December/000099.html</a><br/>
プライマリからから受け取ったバッファが空である一方で、スタンバイのどれかが
受け取ったバッファが空でないとき、pgpool へのパケットが送られてしまう、
という可能性が考慮されていませんでした。<br/>
この事象は例えば、postgresql.conf を再読み込みしたときに発生することがありました。<br/>
この修正では、スタンバイからしか受け取れなかったバッファは無視するようにしました。
</li>
</ul>
<h2>3.0.5 (umiyameboshi) 2011/10/31</h2>
<h3>概要</h3>
<p>
このバージョンでは、3.0.4における様々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>空のクエリの処理に関するバグを修正しました。空のクエリはSELECTクエリと同じ扱いになります。
この修正は、空のクエリのあとのロードバランスを可能にします(Kitagawa)</li>
<li>カラム定義が"DEFAULT nextval(('"x_seq"'::text)::regclass)"のようになっていても
insert_lockが正しく動作するように修正しました(Kitagawa)</li>
<li>pgpool-IIマニュアルのbackend_weightに関する説明を修正しました。
それは、pgpool.confの再読み込みで変更できます(Tatsuo)</li>
<li>rawモードでノードを復帰させたときにノードの状態が更新されないバグを修正しました(Guillaume Lelarge)</li>
<li>FOR SHARE/UPDATE句のあるサブクエリを含むSELECTがスレーブ(standby)に送られるバグを修正しました(Tatsuo)</li>
<li>PREPARE文でデフォルト値のタイムスタンプ書き換えに失敗するバグを修正しました。
これは以前は動作していましたが、3.0で動作しなくなっていました(Kitagawa)</li>
<li>rawモード、enable_hbaが無効、バックエンドが2台以上の場合に
pgpool子プロセスがクラッシュするのを修正しました(Kitagawa)</li>
<li>メモリリークをいくつか修正しました(Kitagawa)</li>
</ul>
<h3>改良</h3>
<ul>
<li>カラムのデフォルト値に任意の式を指定してもタイムスタンプ書き換えが動作するようにしました。
以前は、now()が含まれているものを検知すると、単純にそれをnow()で置き換えてました。
これは、デフォルト値の誤った書き換えを引き起こします。例えば、timezone('utc'::text, now())です。
しかし、これは簡易プロトコルのみへの適用であることに注意してください。
拡張プロトコル(例えばJava, PHP PDO)または、SQLの"PREPARE"にはまだ適用されていません(Tatsuo)</li>
<li>エラーメッセージ"do_md5: read_password_packet failed"をデバッグレベルにしました(Kitagawa)</li>
</ul>
<h2>3.0.4 (umiyameboshi) 2011/06/01</h2>
<h3>概要</h3>
<p>
このバージョンでは、3.0.3における様々なバグが修正されています。
</p>
<h3>互換性のない変更</h3>
<p>
</p><ul>
<li>ストリーミングレプリケーションにおいて、<a href="#DELAY_THRESHOLD">delay_threshold</a> が
0またはヘルスチェックが無効ならば、遅延チェックは実施されません。
これはpgpool-IIマニュアルとおりの動作ですが、これまではヘルスチェックが無効の場合も
遅延チェックが実施されていました(Guillaume Lelarge)
</li></ul>
<p></p>
<h3>バグ修正</h3>
<p>
</p><ul>
<li>pgpool-regclass()をPostgreSQL 8.0以降でコンパイルできるように修正しました。7.4はまだエラーが出ます(Tatsuo Ishii)
</li><li>ストリーミングレプリケーション構成で/*NO LOAD BALANCE*/コメントを使用したときに
ハングアップする可能性を修正しました(Toshihiro Kitagawa)
</li><li>Flush(H)メッセージやCloseComplete(C)メッセージを受信したときのハングアップを修正しました(Toshihiro Kitagawa)
</li><li>pgpool-IIがバックエンドに接続後、RedyForQuery(Z)メッセージを受信するタイミングによって起こり得る
ハングアップを修正しました(Toshihiro Kitagawa)
</li><li><a href="#RECOVERY_1ST_STAGE_COMMAND">recovery_1st_stage_command</a> と
<a href="#RECOVERY_2ND_STAGE_COMMAND">recovery_2nd_stage_command</a> パラメータの説明を追加しました(Tatsuo Ishii)
</li><li>pgpool-II内部で使用するシステムカタログキャッシュのサイズを32から128に増やしました。
これは"unnamed prepared statement does not exist"エラーを軽減する効果があります。(Tatsuo Ishii, Toshihiro Kitagawa)
</li><li>pcp_connect()関数で二重free()を行うバグを修正しました。
パッチはJehan-Guillaume (ioguix) de Rorthaisさんから頂きました(Tatsuo Ishii)
</li><li>PQfinish()関数を誤って使用しているstart_recoery()のバグを修正しました(Tatsuo Ishii)
</li><li>クライアントのアイドル時間が <a href="#CLIENT_IDLE_LIMIT">client_idle_limit</a> に達したときに、
フロントエンドに送信される正しくないエラーメッセージを修正しました(Tatsuo Ishii)
</li><li>pool_statusの「backend status」変数の名前を正しく修正しました。
スペースを'_'に置き換えました(Guillaume Lelarge)
</li><li>md5認証方式を採用してデーモンとして実行したときのハングアップを修正しました。
パッチは、Nicolas Thauvinさんから頂きました(Tatsuo Ishii)
</li><li>拡張問い合わせプロトコルでSQL文が出力されるように、
<a href="#LOG_PER_NODE_STATEMENT">log_per_node_statement</a>を修正しました。
これは以前は動作していましたが、3.0で動作しなくなっていました(Toshihiro Kitagawa)
</li></ul>
<p></p>
<h3>改良</h3>
<p>
</p><ul>
<li>サンプルの設定ファイルの <a href="#BLACK_FUNCTION_LIST">black_function_list</a> に
currval()とlastval()を追加しました。
もしそれらがロードバランスされると、nextval()やsetval()の結果がスレーブに反映される前に
currval()またはlastval()が呼ばれることがあります(Tatsuo Ishii)
</li></ul>
<p></p>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.0.3"></a>3.0.3 (umiyameboshi) 2011/02/23</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンでは、3.0.1における様々なバグが修正されています
(pgpool-II 3.0.2のリリースはパッケージングの問題でキャンセルされました)。
</p>
<h3>互換性のない変更</h3>
<p>
</p><ul>
<li>ストリーミングレプリケーションモードを使用する場合に、PostgreSQLサーバに
C関数「pgpool_walrecrunning()」をインストールすることが推奨されます(後述)。
この場合、新しい変数「%P」がオンラインリカバリのスクリプトで利用できるようになります。
この関数をインストールしない場合は、従来と同じ動作になります(Tatsuo Ishii)
</li><li>rawモードでDBノードがひとつだけの場合、DBノードに問題が発生するとダウン状態になりますが、
DBノードが復旧したらpgpoolの再起動なしにDBノードを使用できるようにしました。
この変更は3.0に含まれていましたが、動作していませんでした(Tatsuo Ishii, Toshihiro Kitagawa)
</li></ul>
<p></p>
<h3>バグ修正</h3>
<p>
</p><ul>
<li>パスワード認証における移植性を損なうコードを修正しました。
これはFreeBSDユーザからのバグ報告に基づきます(Tatsuo Ishii)
</li><li><a href="#INSERT_LOCK">insert_lock</a> がユーザテーブルの全行をロックするバグを
修正しました(Tatsuo Ishii, Toshihiro Kitagawa)
</li><li>ユーザ名の長さが32バイトのときにpgpool子プロセスがクラッシュする
パスワード認証のバグを修正しました(Tatsuo Ishii)
</li><li>rawモードまたはバックエンドノード数が1のときに、pgpool子プロセスがクラッシュする
md5認証のバグを修正しました。パッチはRob Shepherdさんから頂きました(Tatsuo Ishii)
</li><li>以前からあった配列と複合型に対するタイムスタンプ書き換えのバグを修正しました。
パッチはAkio Ishidaさんから頂きました(Tatsuo Ishii)
</li><li><a href="#DEBUG_LEVEL">debug_level</a> パラメータが動作しないバグを修正しました。
パッチはGilles Daroldさんから頂きました(Tatsuo Ishii)
</li><li>フェイルオーバー中に起こりうるpgpool子プロセスのクラッシュを修正しました(Toshihiro Kitagawa)
</li><li>ユーザがスキーマ名の付いた関数を呼んだときに <a href="#WHITE_FUNCTION_LIST">white/black_function_list</a> が
正しく動作するように修正しました(Tatsuo Ishii)
</li><li>コネクションキャッシュによってDROP DATABASEが失敗するバグを修正しました(Toshihiro Kitagawa)
</li><li>rawモードでフェイルオーバが失敗するバグを修正しました(Toshihiro Kitagawa)
</li><li>1セッションで簡易問い合わせプロトコルと拡張問い合わせプロトコルの両方が使われたときに起こりうる
pgpool子プロセスの終了を修正しました(Toshihiro Kitagawa)
</li><li>拡張問い合わせプロトコルを使用中にエラーが発生すると起こりうるハングアップを修正しました(Toshihiro Kitagawa)
</li><li>PG_TRY/CATCHを使用しないようにpgpool-regclass()を修正しました。(Tatsuo Ishii)
<p>
PG_TRY/CATCHは、時々バックエンドが「PANIC: ERRORDATA_STACK_SIZE exceeded.」というメッセージとともに
終了するので安全でないように見えます。
</p>
</li><li>JDBCドライバがマスタノードに何度もBEGINを発行するロードバランスのバグを修正しました(Toshihiro Kitagawa)
</li><li><a href="#FAILBACK_COMMAND">failback_command</a> と
<a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a> が
正しい値を表示するように <a href="#pool_status">pool_status</a> を修正しました(Toshihiro Kitagawa)
</li><li><a href="#pool_status">pool_status</a> から <a href="#RECOVERY_PASSWORD">recovery_password</a> と
<a href="#SYSTEM_DB_PASSWORD">system_db_password</a> を削除しました(Toshihiro Kitagawa)
</li><li>ストリーミングレプリケーションモードでフェイルオーバを実行中に、
バックエンドのログに「unexpected EOF on client connection」が出ないように修正しました(Tatsuo Ishii)
</li><li>バックエンドがすべてダウンした場合に発生するpgpoolのクラッシュを修正しました(Tatsuo Ishii)
</li><li>レプリケーション遅延チェックがバックエンドとの永続的な接続を行わないように修正しました。(Tatsuo Ishii)
<p>
これは、レプリケーション遅延チェックの間でDBノードのダウンとアップが起きた場合に永続的な接続が
不正になる可能性があるためです。
</p>
</li><li>英語ドキュメントを書き直してレビューしました(Marc Cousin, Gleu)
</li><li>以下の条件を満たすとき SELECT クエリがマスタノードに送信されないバグを修正しました(Toshihiro Kitagawa)
<ul>
<li>マスタースレーブモードである
</li><li>拡張問い合わせプロトコルを使用している
</li><li>明示的にトランザクションを開始している
</li><li>更新クエリを実行した後である
</li></ul>
</li><li>ストリーミングレプリケーションモード利用時のオンラインリカバリにおいて、
以下のシナリオがうまく動作しない問題を修正しました。
以下のシナリオでは、ノード0を最初のプライマリサーバ、ノード1を最初のスタンバイサーバとします。
<ol>
<li>ノード0プライマリサーバがダウンし、ノード1スタンバイサーバが新しいプライマリサーバになる
</li><li>ノード0の旧プライマリサーバは、オンラインリカバリで新スタンバイサーバになる
</li><li>このときpgpool-IIは、ノード0の新スタンバイサーバを、プライマリサーバとみなしてしまう
</li></ol>
これは、生きているノード番号の一番若いサーバをプライマリサーバと見なしていたためです。
pgpool-II 3.0.3では、pgpool_walrecrunning()を使って、実際にそのノードがプライマリサーバかどうか
判定するため、このような問題は起きません。
この機能をうまく使うために、オンラインリカバリのスクリプトで
%P(古いプライマリノード番号)が利用できるようになっています。
なお、pgpool_walrecrunning()がインストールされていない場合は、上の問題は解消されず、
3.0.1と同様の動作になります。
</li></ul>
<p></p>
<h3>改良</h3>
<p>
</p><ul>
<li>ステータスファイルを読んでいるときに、特定のバックエンドがダウン状態ならば
ログを出力するようにしました(Tatsuo Ishii)
</li><li>pgpoolが実行したクエリでエラーが発生した場合に、エラーメッセージを出力するようにしました(Tatsuo Ishii)
</li><li>sqlディレクトリに主要なMakefileを追加しました(Tatsuo Ishii)
</li></ul>
<p></p>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.0.2"></a>3.0.2(umiyameboshi) 2011/02/17</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは問題があったために、リリースが取り消されました。
</p>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.0.1"></a>3.0.1 (umiyameboshi) 2010/10/19</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンでは、3.0における様々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<p>
</p><ul>
<li>認証されるサーバが複数ある場合にクラッシュするmd5認証のバグを修正しました(Tatsuo Ishii)
</li><li>拡張問い合わせプロトコルにおいて、構文エラーのクエリを実行したときに
子プロセスがクラッシュするバグを修正しました(Toshihiro Kitagawa)
</li><li>ポータル情報のハンドリングにおける子プロセスが終了するバグを修正しました(Toshihiro Kitagawa)
</li><li>拡張問い合わせプロトコルにおいて、ひとつのノードに送信されたクエリがエラーを起こしたときに
ハングアップするバグを修正しました(Toshihiro Kitagawa)
</li><li>英語ドキュメントの誤植を修正しました。Asaf Ohaionさんのパッチを取り込みました(Tatsuo Ishii)
</li></ul>
<p></p>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release3.0"></a>3.0 (umiyameboshi) 2010/09/10</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンは3.0系列の最初の版で、2.2系や2.3系からの「メジャーバージョンアップ」にあたります。
PostgreSQL 9.0の新機能であるStreaming Replication/Hot Standby構成に対応するなど、
多くの機能が追加されると共に、内部構造が整理されて見通しが良くなって保守性が向上しています。
</p>
<p>
マスタースレーブモード全般で多くの改善がなされています。
</p><ul>
<li>明示的なトランザクション内のSELECTが負荷分散できるようになりました
</li><li>不必要なDBノードにparse/bindメッセージが送られなくなりロック競合が減りました
</li><li>不必要な内部トランザクションの起動がなくなり、オーバヘッドが軽減しています
</li><li>一時テーブルを意識せずに安全に使えるようになりました
</li><li>書き込みを伴う関数呼び出しを行なうSELECTをマスター(primay)でのみ実行するように制御できるようになりました
</li></ul>
<p></p>
<p>
レプリケーションモードにおいても、書き込みを伴う関数呼び出しを行なうSELECTを負荷分散するかどうかの制御できるようになるなどの改良が加えられています。
</p>
<h3>新機能</h3>
<p>
</p><ul>
<li>PostgreSQL 9.0の新機能であるStreaming Replication/Hot Standby(SR+HS)構成に対応しました(Tatsuo Ishii, Toshihiro Kitagawa)。
<p>
pgpool-IIは基本的にはmaster/slave modeとして動作しますが、その際に
"<a href="#MASTER_SLAVE_SUB_MODE">master_slave_sub_mode</a>" という
新しい設定項目に"stream"を設定することにより、SR+HS構成に最適な動作をします。
たとえば、更新クエリはPrimaryサーバにのみ送信し、SELECTはPrimaryとStandbyサーバに負荷分散することが可能です。
</p>
<p>
そのほか、Standbyサーバをオンラインリカバリで復旧したり、PrimaryとStandbyのレプリケーション同期を監視し、
遅れが大きいようならPrimaryにのみSELECTを送信させるようにすることも可能です。
</p>
<p>
詳細は<a href="#stream">Streaming Replicationへの対応"</a>をご覧下さい。
</p>
<ul>
<li>オンラインリカバリがStreaming Replication対応で動作しているmaster/slaveモードに対応しました(Tatsuo Ishii)
</li><li>Streaming Replicationモード用の新しい設定項目 "<a href="#DELAY_THRESHOLD">delay_threshold</a>" が追加され、
レプリケーションの遅れが監視できるようになりました。
遅延が多い場合には、負荷分散しないようにすることができます(Tatsuo Ishii)
</li><li><a href="#pool_status">show pool_status</a> で、Streaming Replicationにおける
レプリケーションの遅延が確認できるようになりました(Tatsuo Ishii)
</li><li>Streaming Replicationにおけるレプリケーションの遅延のログを制御する新しい設定項目
"<a href="#LOG_STANDBY_DELAY">log_standby_delay</a>" が追加されました(Tatsuo Ishii)
</li></ul>
</li><li><a href="#INSERT_LOCK">insert_lock</a> が有効で、テーブルにシリアル型が含まれている場合、
テーブルロックではなく、該当シーケンスを行ロックするようにしました。(Tatsuo Ishii)
<p>
以前はテーブルロックをしていましたが、auto vacuumとロックが衝突したりして
性能が低下する問題がありました。
</p>
</li><li>新しい"SHOW"コマンドが追加されました。すなわち、<a href="#pool_nodes">pool_nodes</a>,
<a href="#pool_processes">pool_processes</a>, <a href="#pool_pools">pool_pools</a>,
<a href="#pool_version">pool_version</a> です(Guillaume Lelarge)
</li><li><a href="#pcp_proc_info">pcp_proc_info</a> コマンドの出力結果に、
PostgreSQLバックエンドプロセスのプロセスIDとフロントエンドからの接続があるかどうかが追加されました(Tatsuo Ishii)
</li><li>関数呼び出しを伴うSELECTを制御する設定項目 <a href="#WHITE_FUNCTION_LIST">white_function_list</a> と
<a href="#BLACK_FUNCTION_LIST">back_function_list</a> が追加されました(Tatsuo Ishii)
</li><li>マスタースレーブモードにおいて、システムカタログを検索するSELECTは、整合性を保つために
常にマスター(primary)で実行されるようになりました(Tatsuo Ishii)
</li><li>マスタースレーブモードにおいて、一時テーブルを検索するSELECTは、整合性を保つために
常にマスター(primary)で実行されるようになりました(Tatsuo Ishii)
</li><li>マスタスレーブモードで、明示的なトランザクション内で実行されない更新クエリにおいて、
自動的にトランザクションを開始することを止めました。(Tatsuo Ishii)
<p>
これは不必要でした。これによって、パフォーマンスが向上しています。
</p>
</li><li>マスタスレーブモードで、明示的なトランザクション内で実行されるSELECTコマンドが
負荷分散できるようになりました(Tatsuo Ishii, Toshihiro Kitagawa)
</li><li>マスタスレーブモードで、必要なDBノードにのみコマンドが送られるようになりました。
(Tatsuo Ishii, Toshihiro Kitagawa)
<p>
これにより、たとえばパースコマンドが不必要なDBノードにおいても
ロックを取ってしまうようなことがなくなりました。
</p>
</li><li>pgpoolの起動時に、ステータスファイルを無視するオプションが追加されました(Tatsuo Ishii)
</li><li>PostgreSQL 9.0のVACUUMの新しい書式をpgpool-IIのパーサがサポートしました(Tatsuo Ishii)
</li><li>フェイルオーバ/フェイルバックコマンドで、"%H"という特殊変数が利用できるようになりました。
これは、新しいマスターノードのホスト名を表します(Tatsuo Ishii)
</li><li><a href="#FAILOVER_IF_AFFECTED_TUPLES_MISMATCH">failover_if_affected_tuples_mismatch</a> という設
定項目が追加されました(Tatsuo Ishii)
<p>
従来、レプリケーションモードでINSERT/UPDATE/DELETEの結果行数が異なると、
トランザクションをアボートしてセッションを強制切断していました。
failover_if_affected_tuples_mismatch を trueに設定すると、この現象が起きたときに、
不一致のあったDBノードを切り放して縮退運転に入るようになります。
</p>
</li><li>レプリケーションモードでDBノード間でINSERT/UPDATE/DELETEの結果行数の不一致が検出された際に、
DBノードにおける結果行数がログに記録されるようになりました(Tatsuo Ishii)
</li><li>レプリケーションモードとマスタスレーブモードで、md5認証がサポートされました(Tatsuo Ishii)
</li><li>オンラインリカバリで、強制的にフロントエンドへの接続を切断して
直ちにセカンドステージに入ることができるようになりました。(Tatsuo Ishii)
<p>
そのためには、<a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a> に
-1 を設定します。
</p>
</li><li>RAWモードにおいて、DBノードが1個だけしか存在しない状態でDBがエラーを起したために
DBノードを切り放したあとでDBノードが回復した場合に、pgpool-IIを再起動することになしに
DBノードを利用できるようになりました(Tatsuo Ishii)
</li><li>pcpコマンドにおいて、ロングオプションがサポートされました(Guillaume Lelarge)
</li><li><a href="#DEBUG_LEVEL">debug_level</a> という設定項目が追加され、
pgpool.confの再読み込みによってデバッグメッセージの出力をオン／オフできるようになりました(Tatsuo Ishii)
</li><li>pgpool.confで、postgresql.confと同じ真偽値表現が利用できるようになりました。
従来は、true/false, 1/0しか使えませんでした(Toshihiro Kitagawa)
</li><li>オンラインリカバリのセカンドステージをより安全に実行するために、
C言語関数 <a href="#recovery_pitr">pgpool_switch_xlog</a> を追加しました(Toshihiro Kitagawa)
</li><li>異なるスキーマに同じ名前のテーブルが存在する場合に起きる不具合を回避するために、
C言語関数pgpool_regclassを追加しました(Tatsuo Ishii)
</li></ul>
<p></p>
<h3>互換性のない変更</h3>
<p>
</p><ul>
<li><a href="#REPLICATE_SELECT">replicate_select</a> と <a href="#LOAD_BALANCE_MODE">load_balance_mode</a> を
共にtrueに設定した場合、トランザクションブロックの外側で実行されるSELECT文は、
replicate_selectに従うようになりました。
以前は、load_balance_modeに従うようになっていました。
<p>
もしクライアントがこの動作を利用している場合は、replicate_selectをfalseにして
<a href="#BLACK_FUNCTION_LIST">back_function_list</a> を設定することで同じ動作を実現できます。
</p>
</li>
</ul>
<p></p>
<p>
</p><h3>バグ修正</h3>
<p></p>
<p>
</p><ul>
<li>型が時刻データ以外の列の場合、デフォルト値にnow()が含まれていても書き換えを行なわないようにしました。(Tatsuo Ishii)
<p>
今までは無条件に書き換えを行なっていたため、書き換えの結果、INSERT文などがエラーになっていました。
</p>
</li><li>タイムスタンプの書き換え処理対象となるテーブルのスキーマが無視されないようにしました。(Tatsuo Ishii)
<p>
ただし、この機能を有効にするためには、付属のユーザ定義関数"pgpool_regclass"のインストールが必要です。
この関数がインストールされていない場合は、依然としてスキーマが無視されてしまいます。
</p>
</li><li>pcpコマンドのタイムアウトの扱いにおけるバグが修正されました(Tatsuo Ishii)
</li><li>SSLが有効な状態で、大量のデータ通信が起るとハングする問題が修正されました(Tatsuo Ishii)
</li><li>DBノードが1個だけしか存在しない状態でDBがエラーを起したた際に、
間違ったDBノードがフェイルオーバするバグを修正しました(Tatsuo Ishii)
</li><li>オンラインリカバリ時のpostmasterの起動チェックにおけるバグを修正しました。(Tatsuo Ishii)
<p>
今まではpostmasterへの最初の接続が失敗すると、接続を無限に繰り返すようになっていました
</p>
</li></ul>
<p></p>
<!-- ================================================================================ -->
<!-- 2.3 -->
<!-- ================================================================================ -->
<hr><a name="release2.3.x"></a>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release2.3.3"></a>2.3.3 (tomiteboshi) 2010/04/23</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>このバージョンでは、2.3.2.2 以前の色々なバグが修正されています。</p>
<h3>互換性のない変更</h3>
<ul>
<li>このバージョンから、pgpool が以前より多くの共有メモリを使うようになったので注意してください。
<p>
これによる問題が pgpool の起動時に発生した場合は、pgpool のログを見てください。
"could not create shared memory segment: Cannot allocate memory" といったメッセージがあれば、
システムの共有メモリを増やしてください。
</p>
</li>
<li>パラレルモードが、レプリケーションモードかロードバランスモードが有効でないと
使えないようになりました。(Toshihiro Kitagawa)
<p>
pgpool-II ではずっと、レプリケーションモードかロードバランスモードが有効でないとき
パラレルモードは正しく動作していませんでした。
</p>
</li>
<li><a href="#INSERT_LOCK">insert_lock</a> のデフォルト値を false に変更しました。(Tatsuo Ishii)
<p>
これは、マスタ・スレーブモードでは true にしても無意味なためです。
Fujii Masao さんの指摘により修正しました。
</p>
</li>
</ul>
<h3>新しく追加したドキュメント</h3>
<ul>
<li>README.online-recovery を追加しました。このドキュメントには、オンラインリカバリの内部的なことが書いてあります。</li>
</ul>
<h3>バグ修正</h3>
<ul>
<li>子プロセスが segfault を起こす pgpool-II 1.0 から長い間存在したバグを修正しました。
これは、親プロセスが shmem サイズの計算を間違えていたことに起因します。
バグ解析(Toshihiro Kitagawa)、パッチ作成(Tatsuo Ishii)</li>
<li>ドキュメントにパラレルモード用の以下の制約を追記しました。(Toshihiro Kitagawa)
<ul>
<li>- NATURAL JOIN は使えません。</li>
<li>- USING 句が、クエリ書き換え処理によって ON 句に変換されます。</li>
</ul>
</li>
<li>パラレルモードのとき、USING 句を含む JOIN 構文の書き換えで発生する可能性があった
クラッシュを修正しました。(Toshihiro Kitagawa)<br>
<p>
この修正により、以下のような JOIN 構文が使えるようになります。<br>
例：
</p><pre>SELECT * FROM a JOIN b USING (aid) JOIN c USING (cid);
SELECT * FROM a JOIN b USING (aid) JOIN c USING (cid) JOIN d USING</pre>
</li>
<li>パラレルクエリで、分散キー列の前に current_time を含む INSERT 文のパースができるように修正しました。</li>
<li>SimpleForwardToBackend() を修正しました。(Toshihiro Kitagawa)
<p>
これにより、拡張プロトコルを使ったクライアントが bind エラーのようなエラーを発生させたときに、
pgpool がバックエンドの応答を待ち続けなくなります。
このバグは、マスタ・スレーブモード、raw モード、コネクションプールモードで発生していました。
</p>
<p>
これを修正したことによって、コマンドがエラーになったあと、エラーを回復させるために
SYNC メッセージを送るようになります。
</p>
</li>
<li>select() を実行中の pgpool 子プロセスが、SIGINT/SIGQUIT シグナルを無視するように修正しました。
シグナルが送られても pgpool は select() を再実行しようとするので、結果的にシグナルが無視されます。(Tatsuo Ishii)</li>
<li>connect_inet_domain_socket_by_port/connect_unix_domain_socket_by_port が
SIGTERM/SIGINT/SIGQUIT シグナルを受け取っていないかチェックするように修正しました。
Daniel Codina さんからのバグ報告に基づきます。(Tatsuo Ishii)</li>
<li>"kind mismatch" というエラーメッセージを生成する際にクラッシュする可能性があったので、これを修正しました。
以前は問題なかったのですが、2.3.2でエンバグしました。(Tatsuo Ishii)</li>
<li>ヘルスチェックにおけるバグを修正しました。(Tatsuo Ishii)
<p>
コードが抜けたなどでネットワーク障害が発生したときに、connect() を呼んでいる間は
ヘルスチェックが行なわれていませんでした。
これは、connect() が ALARM シグナルによって割り込まれた際に、
connect_unix_domain_socket() / connect_inet_domain_socket() が再試行していたためです。
この修正では、上記の関数に対して再試行をコントロールするような引数を追加しています。
</p>
<p>
これは、Daniel Codina さんのバグ報告と分析に基づく修正です。
</p>
</li>
<li>2.3.2.2 で、SimpleForwardToBackend でのタイムスタンプの書き換えにおいてエンバグしていたので、
これを修正しました。(Tatsuo Ishii)
<p>
これは、バグトラック #1010771 にある Peter Pramberge さんらの報告に基づきます。
</p>
</li>
<li>パラレルクエリにおける "*" の書き換えを修正しました。
sho さんから提供いただいたパッチを取り込みました。(Toshihiro Kitagawa)</li>
<li>connect_inet_domain_socket_by_port() でエラーメッセージを出力する際に、
strerror() ではなく hstrerror() を使うように修正しました。 (Tatsuo Ishii)</li>
</ul>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release2.3.2.2"></a>2.3.2.2 (tomiteboshi) 2010/02/22</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンでは、2.3.xにおける様々なバグを修正しています。
とくにタイムスタンプの書き換え時のクラッシュを含む致命的なバグが修正されているので、
すべての2.3ユーザは早急にアップグレードすることをお勧めします。
</p>
<h3>バグ修正</h3>
<p>
</p><ul>
<li>タイムスタンプデータを含む拡張プロトコル問い合わせで、
"message: invalid string in message"のエラーを出してトランザクションが終了してしまう
バグを修正しました(Tatsuo Ishii)
</li><li>タイムスタンプデータを含む拡張プロトコル問い合わせで、bind時にNULLを含むパラメータが存在すると
pgpoolがクラッシュするバグを修正しました(Tatsuo Ishii)
</li><li>pgpool_status上ですべてのノードがダウンのときにはこれを無効とし、
「all node down症候群」が起きないようにしました(Tatsuo Ishii)
</li></ul>
<p></p>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release2.3.2.1"></a>2.3.2.1 (tomiteboshi) 2010/02/11</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンでは、2.3.xにおいて、エラーとなるようなSQLを実行すると
pgpoolへのセッションが切断されるバグを修正しています(Akio Ishida)。
</p>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release2.3.2"></a>2.3.2 (tomiteboshi) 2010/02/07</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンでは、2.3.1の色々なバグが修正されています。
特に、タイムスタンプの書き換え機能のバグが修正されているので、2.3, 2.3.1ユーザはなるべく早く
2.3.2にアップグレードすることをお勧めします。
</p>
<p>
また、2.3.2ではSSLサポート、ラージオブジェクトのレプリケーション機能が追加されています。
</p>
<h3>改良点</h3>
<p>
</p><ul>
<li>フロントエンドとpgpool-II、pgpool-IIとPostgreSQLの間のSSL通信がサポートされました(Sean Finney)
</li><li>ラージオブジェクトのレプリケーションがサポートされました(Tatsuo Ishii)
</li><li>ヘルスチェックとオンラインリカバリの際に可能であればpostgresデータベースを使うようにしました。(Tatsuo Ishii)
<p>
postgresデータベースが存在しない場合はtemplate1が使われます(以前の動作と同じ)。
これにより、DROP DATABASEなどのコマンドがオンラインリカバリ中でも使えるようになりました。
</p>
</li><li>問い合わせのパース処理でエラーが起きたときに、SQL文をログに出力するようにしました。(Tatsuo Ishii)
<p>
エンコーディングエラーなどが発生した際にはPostgreSQLのログにもSQL文が記録されないため、これは有効です。
</p>
</li><li>kind mismatchエラーが発生し、その原因がDEALLOCATEコマンドだった場合にDEALLOCATEが削除しようとした
PREPARED文の元になったSQL文をログに出力するようにしました(Tatsuo Ishii)
</li></ul>
<p></p>
<h3>バグ修正</h3>
<p>
</p><ul>
<li>たまにタイムスタンプを書き換えた問い合わせがマスタ以外のDBノードに
不正なパケットを送ってしまう問題を修正しました(Tatsuo Ishii)
</li><li>V2プロトコルでタイムスタンプの書き換え処理がエラーになるのを修正しました(Toshihiro Kitagawa)
</li><li>master/slaveモード、かつトランザクション内で発行されるBind、Describe、Closeメッセージは
マスタだけに送るようにしました(Tatsuo Ishii)
</li><li>2.3でsmart shutdownによりすぐに停止しなくなったバグを修正しました(Toshihiro Kitagawa)
</li><li>フロントエンドからの不正なコマンドを受け付けないようにしました(Xavier Noguer)
</li><li>移植性を高めるために、fprintfの引数に%dzを使用するようにしました(Tatsuo Ishii)
</li><li>コンパイラワーニングを修正しました(Tatsuo Ishii)
</li><li>master/slaveモードの際に、DEALLOCATEをすべてのノードに送らないようにして、
kind mismatchエラーを防ぐようにしました(Tatsuo Ishii)
</li></ul>
<p></p>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release2.3.1"></a>2.3.1 (tomiteboshi) 2009/12/18</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>
このバージョンでは、2.3の色々なバグが修正されています。
特に、ある条件でDBに不正な数値が書き込まれるバグが修正されており、
以下の示す条件に合致する使い方をしている2.3ユーザは至急バージョンアップすることをお勧めします。
</p>
<h3>バグ修正と改良点</h3>
<p>
</p><ul>
<li>以下のすべての条件に合致する場合、DBに不正な値が書き込まれるバグを修正しました(Tatsuo Ishii)
<p>
</p><ol>
<li>レプリケーションモードで動作
</li><li>64bit OS
</li><li>INSERTまたはUPDATEにおいて、now(), CURRENT_TIMESTAMP, CURRENT_DATE, CURRENT_TIMEを直接含むか、
テーブルのデフォルト値に含んでいる
</li><li>更にそのSQL内に32bit(10進で-2147483648から2147483647)の範囲を超える整数定数が含まれている
</li></ol>
以上を満たすSQLの例:
<pre>INSERT INTO t1(id, regdate) VALUES(98887776655, NOW());
</pre>
この例では、98887776655が32bit値にカットされて書き込まれます。
<p></p>
</li><li>18以上のDBノードを使用している場合に、show pool_statusでクラッシュするバグを修正しました。
このバグはshow pool_statusが実装されてからずっと存在していたものです。
</li><li>"kind mismatch"メッセージが出た際に、kindがERRORまたはNOTICEならば、
そのメッセージを表示するようにしました。(Tatsuo Ishii)
<p>
これにより、PostgreSQLのログを見なくてもkind mismatchエラーの原因を容易に調べることが
できるようになりました。
</p>
</li></ul>
<p></p>
<!-- -------------------------------------------------------------------------------- -->
<h2><a name="release2.3"></a>2.3 (tomiteboshi) 2009/12/07</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>概要</h3>
<p>このバージョンでは、レプリケーション機能に改良が加えられ、
時刻データ(CURRENT_TIMESTAMP, CURRENT_DATE, now()など)を正しく扱うことができるようになりました。</p>
<p>
</p><p>また、同時接続数が1(num_init_childrenが1)のときのレプリケーション性能向上しています。</p>
<p>また、pgpool-II再起動時に前回のDBノードのダウン状態を記録し、不用意に復旧ノードにデータを書き込んで
データの不整合が起きることを防ぐことができるようになりました。</p>
<p>そのほか、クエリログが改良されてDBノード単位の状況が把握しやすくなり、
またフェイルオーバの挙動が細かく制御できるようになりました。</p>
<p>なお、pgpool-II 2.3には、pgpool-II 2.2.1から2.2.6までのすべてのバグ修正、改良が含まれています。</p>
<p></p>
<h3>pgpool-II 2.2.からの非互換性</h3>
<ul>
<li>[logdir]の下にpgpool_statusというファイルが作られるので、pgpoolの実行ユーザが読み書きできる権限を
与えておいてください。
</li></ul>
<h3>改良点</h3>
<ul>
<li>レプリケーションにおいて、時刻データ(CURRENT_TIMESTAMP, CURRENT_DATE, now()など)を
正しく扱うことができるようになりました。(Akio Ishida)
<p>
特にアプリケーションに変更を加えることなく、INSERT/UPDATE文、テーブルのデフォルト値に
これらの時刻関数を含むケースでも正しくレプリケーションできます(いくつか制限事項があります。
詳細は<a href="#restriction">制限事項</a>を参照してください)。
</p>
</li><li>SQLパーサをPostgreSQL 8.4のものにバージョンアップしました(Akio Ishida)
</li><li>同時接続数が1（<a href="#NUM_INIT_CHILDREN">num_init_children</a> が1）のときの
レプリケーション性能が20%から100%向上しました(Tatsuo Ishii)
</li><li>新しいディレクティブ <a href="#LOG_PER_NODE_STATEMENT">log_per_node_statement</a> が追加されました(Tatsuo Ishii)
<p>
<a href="#LOG_STATEMENT">log_statement</a> と似ていますが、DBノード単位でログが出力されるので、
レプリケーションや負荷分散の確認が容易です。
また、バックエンドのプロセスIDも表示されるので、バックエンドのログと併せての解析が容易になっています。
</p>
</li><li>新しいディレクティブ <a href="#FAIL_OVER_ON_BACKEND_ERROR">fail_over_on_backend_error</a> が追加され、
フェイルオーバの挙動がより細かく制御できるようになりました(Tatsuo Ishii)
</li><li>pgpool-II停止時にダウンしたDBノードの情報をステータスファイルに記録し、
pgpool-IIを起動したときにその情報をリストアできるようにしました(Tatsuo Ishii)
ステータスファイルは [logdir]/pgpoo_status というファイルに書かれます。
</li><li>EXPLAINと、問い合わせがSELECTのときのEXPLAIN ANALYZEが負荷分散されるようになりました。(Tatsuo Ishii)
<p>これによって、DBノードの間で大幅に問い合わせプランが異るために、
kind mismatchエラーが起きるのを防ぐことができます。</p>
</li><li>日本語ドキュメントの体裁を改良しました(Tatsuo Ishii)
</li><li>レプリケーションモード、マスタースレーブモード用のデフォルトpgpoo.conf.sampleが別途追加されました(Tatsuo Ishii)
</li><li>時刻データのテストが追加されました(Akio Ishida)
</li></ul>
<p></p>
<!-- ================================================================================ -->
<!-- 2.2 -->
<!-- ================================================================================ -->
<hr><a name="release2.2.x"></a>
<h2>2.2.6 (urukiboshi) 2009/12/01</h2>
<h3>概要</h3>
<p>
このバージョンでは、ロードバランスの重みパラメータweightの扱いが改善され、
また一時テーブルがマスター／スレーブモードで利用できるようになりました。
もちろんいつものように2.2.5以前の色々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>DECLARE, CLOSE, FETCH, MOVEがロードバランスの対象にならなくなりました。(Tatsuo Ishii)
<p>
もしデータが更新され、トランザクションがコミットされた後にCLOSEが発行されるとデータの一貫性がなくなるからです
(つまり、holdできるカーソルの場合のことを言っています)
</p>
</li><li>マスター／スレーブモードにおいて、拡張プロトコルのParseをマスター上でのみ実行するようにしました。(Tatsuo Ishii)
<p>以前はすべてのノードでParseが実行されていたのですが、これだと
不必要なロックがスレーブでも取られてしまいます</p>
</li><li>uninstallの前にすべてのランレベルからinitスクリプトを削除するようにしました(Devrim)
</li><li>認証に失敗したときに適切なエラーメッセージを出すようにしました(Glyn Astill)
</li><li>ソケットへの書き込みに失敗したときにフロントエンド用なのかバックエンド用なのかわかるようにしました(Tatsuo Ishii)
</li><li>フロントエンド用のソケットに書き込み失敗したときにいちいちエラーを出さないようにしました(Tatsuo Ishii)
</li><li>マスター／スレーブモードで一時テーブルが使えるようになりました。(Tatsuo Ishii)
<p>
INSERT/UPDATE/DELETEは自動的にマスタのみに送られます。SELECTに関しては明示的にクエリの前に
/*NO LOAD BALANCE*/というコメントを付けなければなりません。
</p>
</li></ul>
<p></p>
<h2>2.2.5 (urukiboshi) 2009/10/4</h2>
<h3>概要</h3>
<p>
このバージョンでは、2.2.4以前の色々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>コネクション数のカウントのミスにより、オンラインリカバリが終わらなくなるバグを修正しました(Tatsuo Ishii)
</li><li>内部的にロックを発行する際にもフロントエンドが異常終了したことを検出して
SQLコマンドをキャンセルするようにしました(Tatsuo Ishii)
</li><li>接続の終了処理で無限ループに陥ることがあるバグを修正しました(Xavier Noguer, Tatsuo Ishii)
</li><li>拡張プロトコルのパース処理でkind mismatch errorが起きた際に正しいSQL文を表示するようにしました(Tatsuo Ishii)
</li><li>ドキュメントを改善しました(Tatsuo Ishii)
</li></ul>
<p></p>
<h2>2.2.4 (urukiboshi) 2009/8/24</h2>
<h3>概要</h3>
<p>
このバージョンでは、2.2.3以前の色々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>pgpool-II 2.2.2で入ってしまったバグを修正しました。(Tatsuo Ishii)
<p>フロントエンドがアボートするタイミングによっては、以後内部状態がリセットされず、
次のセッションでDMLやDDLがマスターノードのみ送られ、
ノード間でデータの不一致が生じることがありました。</p>
</li><li>pgpool-II 2.2.3でバージョン2プロトコルのクライアントが動かなくなってしまっていたのを修正しました。(Tatsuo Ishii)
<p>
また、時間のかかるクエリを待っている間にフロントエンドが異常終了したことを検知する間隔を
1秒から30秒に変更しました。このチェックは、2.2.4ではプロトコルバージョンが3のときのみ有効です。
</p>
</li><li>子プロセスを起動する前にシグナルのブロックやハンドラの設定を行なうようにしました。(Tatsuo Ishii)
<p>これは、pgpool-IIを起動した直後にフェイルオーバなどの事象が発生して
子プロセスから親プロセスにシグナルが送られると、pgpool-IIの親プロセスが死んでしまうことがあるからです。</p>
</li></ul>
<p></p>
<h2>2.2.3 (urukiboshi) 2009/8/11</h2>
<h3>概要</h3>
<p>
このバージョンでは、2.2.2以前の色々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>バックエンドに新しいコネクションを張る際に、バックエンドの一つが障害を起しているケースで、
後処理の中でpgpool-IIの子プロセスが落ちることがあるバグを修正しました(Tatsuo Ishii)
</li><li>パラレルクエリのバグを修正しました(Yoshiharu Mori)
</li><li>拡張プロトコルの場合にもエラーメッセージの中で最後に使用したクエリが
表示できるようになりました(Akio Ishida)
</li><li>kind mismatch errorメッセージの作成で、メッセージ内容が壊れることがあるバグを修正しました(Tatsuo Ishii, Akio Ishida)
</li><li>バックエンドへの接続記述子の参照タイミングによってはpgpool-IIの子プロセスが
落ちることがあるバグを修正しました(Tatsuo Ishii)。
</li><li>pool_errorやpool_logの引数が間違っていた個所を修正しました(Akio Ishida)。
</li><li>statement_timeoutのタイムアウトによるエラー処理を改良しました。(Tatsuo Ishii)
<p>
実際にはタイムアウトまでにstatement_timeoutで設定した時間の倍かかっていたのを直しました。
また、masterだけがstatement_timeoutを返した場合にも対応できるようにしました。
以前はkind mismatchエラーになっていました
(master以外がstatement_timeoutを返さないケースではkind mismatchエラーになります)。
</p>
</li><li>health checkをより強化し、postmasterがSIGSTOPで止ってしまっている場合も障害検知できるようにしました。
</li><li>バックエンドにSQLを投げ、その応答を待っている間にクライアントがpgpoolに対するコネクションを
切断したことが検出できるようになりました。(Tatsuo Ishii)
<p>たとえば、WebアプリケーションではDBに対してリクエストを投げて、
応答がないとキャンセルするようなことが頻繁に起ります。
この場合、今まではpgpoolやPostgreSQLのプロセスが残ってしまい、同時接続数が枯渇したり、
ロックを取ったままのトランザクションが残るなどしてシステム全体に影響を与えることがありました。</p>
<p>今回の修正により、こうした状況が検出できるようになっただけでなく、
SQLの応答待ちの間にクライアントがコネクションを切断した際には、
SQLコマンドのキャンセルをpgpoolが行なって、ロック待ちなどのバックエンドプロセスが残るのを
防ぐことができるようになりました。</p>
</li><li>引数なしのCLUSTERコマンドはトランザクションの中では実行できないので、
自動トランザクションをスタートしないようにしました(Tatsuo Ishii)。
</li><li>複数のプリペアドステートメントを使っている際に、セッションの終りで
その一部だけが解放されるバグを修正しました(Akio Ishida)。
</li><li>sql/pgpool-recovery/pgpool-recovery.cがPostgreSQL 8.4でコンパイルできるようにしました(Tatsuo Ishii)。
</li><li>拡張プロトコルを使っている場合に、クライアントとpgpoolの間でお互いに
待ち状態になってしまうことがあるバグを修正しました(Gavin Sherry)。
</li><li>COPY FROMを実行中にクライアントが処理を中断した場合に、バックエンドプロセスが
残ってしまうバグを修正しました(Tatsuo Ishii)。
</li></ul>
<h2>2.2.2 (urukiboshi) 2009/5/5</h2>
<h3>概要</h3>
<p>
このバージョンでは、2.2.1以前の色々なバグが修正されています。
とりわけ、pgpoolがクライアントとの間でデータのやり取りをしている最中に、
pgpoolのクライアントが終了(X)パケットをpgpoolに送信せずに終了した場合に起る可能性があります。
このバグは過去のすべてのpgpoolに存在しています。
</p>
<h3>バグ修正</h3>
<ul>
<li>フロントエンドにpgpoolがデータを送信する際のエラーを無視するようにしました。(Tatsuo Ishii)
<p>これによって、バックエンドとの間で必要な処理が中断されないようになり、
バックエンドの間でデータの一貫性がなくなる問題が回避されるようになりました。</p>
</li><li>マスタースレーブモードに関する2.2.1の修正の際に生じたバグを修正しました。
プリペアドステートメントを使い回すとハングアップする可能性がありました(Toshihiro Kitagawa)。
</li><li>SQLコマンドのPREPAREとプロトコルレベルのEXECUTEが混在するとバックエンドがクラッシュする
バグを修正しました。このバグが、2.2で持ち込まれたものです(Tatsuo Ishii)。
</li><li>コネクションのリセット用の問合わせを実行中にエラーが起きた場合に、
PostgreSQLのログに"unexpected EOF on client connection"が記録される問題を修正しました(Tatsuo Ishii)。
</li></ul>
<h2>2.2.1 (urukiboshi) 2009/4/25</h2>
<h3>概要</h3>
<p>
このバージョンでは、2.2の色々なバグが修正されています。
</p>
<h3>バグ修正</h3>
<ul>
<li>master/slaveモードで、DEALLOCATEが失敗することがある問題を修正しました。
これは、最初のPREPAREがslaveで実行されないことによるものです(Toshihiro Kitagawa)
</li><li>pgpool.specなどを2.2対応にしました(Devrim)
</li><li>Version 2プロトコルではinsert_lockが無視されるようにしました(Tatsuo Ishii)
</li><li>パラメータ変更メッセージがバックエンドから届く度にログが出力されるのを止めました(Tatsuo Ishii)
</li><li>ドキュメントで追加し忘れたファイルを登録しました(Tatsuo Ishii)
</li></ul>
<h2>2.2 (urukiboshi) 2009/2/28</h2>
<h3>概要</h3>
<p>
このバージョンでは、SERIALデータの扱いとオンラインリカバリに改良が行なわれています。
また、トランザクション分離レベルがシリアライザブルの場合に、DBノード間でデータの一貫性がなくなる可能性がある問題、
クエリのキャンセルができない問題が修正されました。
</p>
<h3>新機能</h3>
<p>
</p><ul>
<li><a href="#INSERT_LOCK">insert_lock</a> が有効な場合、SERIAL型を持つテーブルだけが
ロックされるようになりました(Tatsuo Ishii)。
</li><li>設定項目 <a href="#CLIENT_IDLE_LIMIT_IN_RECOVERY">client_idle_limit_in_recovery</a> が追加されました。(Tatsuo Ishii)
<p>
オンラインリカバリの第2ステージでクライアントがアイドルのまま居座ることによって、
オンラインリカバリが進行しなくなることを防ぐことができます。
</p>
</li><li>設定項目 <a href="#PID_FILE_NAME">pid_file_name</a> が追加されました。(Tatsuo Ishii)
<p>
これは、pgpool-IIのpidファイルを指定します。
これにより、<a href="#LOGDIR">logdir</a> は使用されなくなりました。
</p>
</li><li>DECLARE, FETCH, CLOSEで負荷分散されるようになりました(Tatsuo Ishii)。
</li><li>pcpコマンドにデバッグオプション(-d)が追加されました(Jun Kuriyama)。
</li><li>"kind mismatch"エラーの際に、原因となったクエリを表示するようにしました(Tatsuo Ishii)。
</li></ul>
<p></p>
<h3>互換性</h3>
<ul>
<li>フェイルオーバ時に必ずpgpoolの子プロセスを再起動するようにしました。(Tatsuo Ishii)
<p>
この結果、フェイルオーバ時には必ずpgpoolへのセッションが一端切れることになります。
こうしないと、ネットワークケーブル抜けなどの際に、
TCP/IPのレイヤで再送が行なわれ、長い時間そのままになってしまうことが
あるからです。
</p>
</li><li>設定項目 <a href="#LOGDIR">logdir</a> は使われなくなりました。
代りに、<a href="#PID_FILE_NAME">pid_file_name</a> を使ってください(Tatsuo Ishii)。
</li><li><a href="#INSERT_LOCK">insert_lock</a> のデフォルト値がtrueになりました(Tatsuo Ishii)。
</li></ul>
<h3>バグ修正</h3>
<ul>
<li> pgpoolがデーモンモードで起動される際に、すべてのファイルディスクリプタを
閉じるようにしました。こうしないと、pgpoolAdminから起動された際に
apacheのソケットファイルを引き継いでしまい、80番ポートが
専有されてしまいます(Akio Ishida)。
</li><li> トランザクションをシリアライズできないエラーが発生したときに、
すべてのDBノードのトランザクションをアボートするようにしました。
こうしないと、DBノードの間でデータの不整合が起きることがあります(Tatsuo Ishii)。
例を示します(Mはマスタ、Sはスレーブを示します)。
<pre>M:S1:BEGIN;
M:S2:BEGIN;
S:S1:BEGIN;
S:S2:BEGIN;
M:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
M:S2:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
S:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
S:S2:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
M:S1:UPDATE t1 SET i = i + 1;
S:S1:UPDATE t1 SET i = i + 1;
M:S2:UPDATE t1 SET i = i + 1; <-- blocked
S:S1:COMMIT;
M:S1:COMMIT;
M:S2:ERROR: could not serialize access due to concurrent update
S:S2:UPDATE t1 SET i = i + 1; <-- success in UPDATE and data becomes inconsistent!
</pre>
</li><li> rawモードでMD5認証が使えるようにしました。ドキュメント上では使えるはずでした(Tatsuo Ishii)。
</li><li> "SET TRANSACTION ISOLATION LEVEL must be called before any query"の
エラーが発生した場合に"kind mimatch"エラーになることを防ぐようにしました(Tatsuo Ishii)。
以下のシナリオで問題が発生します。
<pre>M:S1:BEGIN;
S:S1:BEGIN;
M:S1:SELECT 1; <-- only sent to MASTER
M:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
S:S1:SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
M: <-- error
S: <-- ok since no previous SELECT is sent. kind mismatch error occurs!
</pre>
</li><li>FreeBSDにおいて、psでのprocess statusの表示で余計なスペースが含まれてしまうのを修正しました(Jun Kuriyama)
</li><li>BEGIN;を2度続けるとkind mismatch errorが発生するのを修正しました(Tatsuo Ishii)
</li><li>PostgreSQLがたくさんのDEBUGメッセージを出力する場合に、誤ってエラーと見なすバグを修正しました(Tatsuo Ishii)
</li><li>クエリのキャンセルが動くようになりました(Tatsuo Ishii)
</li><li>オンラインリカバリの後クライアントからの接続を受け付けるタイミングが早すぎるバグを修正しました。
このバグにより、ノードデータの貫性が保たれない可能性がありました(Tatsuo Ishii)
</li><li>SELECT, INSERT, UPDATE, DELETE以外のコマンドでも
必要ならばトランザクションブロックの内側で実行するようにしました。
これにより、エラー発生の際にロールバックしてノードの整合性を保つことができます(Tatsuo Ishii)
</li><li>オンラインリカバリ後、pgpool-IIの子プロセスがクラッシュすることがあるバグを修正しました。(Tatsuo Ishii)
<p>これは、オンラインリカバリの後、新しくアタッチされたノードに接続がないのに、
そのノードに子プロセスが終了時に終了メッセージをバックエンドに送信しようとして起っていました。</p>
</li><li>PostgreSQLがpostgresql.confを再読み込みした際にpgpoolがエラーを検出してしまうバグを修正しました。(Tatsuo Ishii)
<p>これは、PostgreSQLが（たぶん）ドキュメントに書かれていないタイミングで
「パラメータ変更」パケットを送信してくるために起り、修正はそのことに対応したものです。</p>
</li></ul>
<!-- ================================================================================ -->
<!-- 2.1 -->
<!-- ================================================================================ -->
<hr><a name="release2.1.x"></a>
<h2>2.1 (inamiboshi) 2008/7/25</h2>
<h3>新機能</h3>
<ul>
<li><a href="#FAILOVER_COMMAND">failover_command</a> と
<a href="#FAILBACK_COMMAND">failback_command</a> に、新しいマスタノード ID
を表す '%m' をサポートしました。(Yoshiyuki Asaba)
</li><li><a href="#FAILOVER_COMMAND">failover_command</a> と
<a href="#FAILBACK_COMMAND">failback_command</a> に、古いマスタノード ID を
表す '%M' をサポートしました。(Yoshiyuki Asaba)
</li><li>リカバリのタイムアウト時間を指定する <a href="#RECOVERY_TIMEOUT">recovery_timeout</a>
パラメータを追加しました。(Taiki Yamaguchi)
</li><li> pg_md5 コマンドに -p オプションを追加しました。(Volkan Yazici,
Taiki Yanaguchi)
</li><li> pgpool -v を実行するとバージョン番号を表示し、終了するようにし
ました。(Yoshiyuki Asaba)
</li></ul>
<h3>互換性</h3>
<ul>
<li><a href="#pgpool_recovery">pgpool_recovery</a> と
<a href="#pgpool_remote_start">pgpool_remote_start</a> 関数はスーパーユーザのみ
実行できるように権限チェックを強化しました。(Yoshiyuki Asaba)
</li><li> raw モードでスタンバイノードにはコネクションプールを作成しないようにしました。(Yoshiyuki Asaba)
</li><li> replication_timeout パラメータを削除しました。(Yoshiyuki Asaba)
</li><li> PCP クライアントコマンドのタイムアウトを無効にしました。(Taiki Yamaguchi)
</li><li> replicate_select = false の場合に、COPY TO STDOUT をレプリケー
ションさせないようにしました。(Yoshiyuki Asaba)
</li></ul>
<h3>修正</h3>
<h4> 全般 </h4>
<ul>
<li> CloseComplete メッセージを受けとるとクラッシュする不具合を修正
しました。(Yoshiyuki Asaba)
</li><li> メッセージ転送処理を効率よくしました。(Yoshiyuki Asaba)
</li><li> Solaris 10 でコンパイルできるようにしました。(Yoshiyuki Asaba)
</li><li> ヘルスチェックとリカバリのログ出力を改良しました。(Tatsuo Ishii)
</li><li> 様々なメモリリークを修正しました。(Yoshiyuki Asaba)
</li><li> "failed to read kind from frontend" というエラーメッセージを
ERRORレベルから LOG レベルに下げました。(Yoshiyuki Asaba)
</li><li> raw モードでフェイルオーバに失敗する不具合を修正しました。
(Taiki Yamaguchi)
</li><li> 不正なノードを追加・切り離しを行うとゾンビプロセスが発生する不
具合を修正しました。(Yoshiyuki Asaba)
</li><li> <a href="#HEALTH_CHECK_TIMEOUT">health_check_timeout</a> が正しく動作しない不具合を修正しました。
(Kenichi Sawada)
</li><li> FreeBSD で ps コマンドの出力が正しくない不具合を修正しました。
(ISHIDA Akio)
</li><li> Unix domain ソケットが残っている場合のエラーメッセージを強化し
ました。(Jun Kuriyama)
</li><li> 認証に失敗した場合のエラーメッセージを強化しました。(Tatsuo Ishii)
</li></ul>
<h4>レプリケーション</h4>
<ul>
<li> <a href="#REPLICATE_SELECT">replicate_select</a> を設定しても、常に false の挙動になる不具合を
修正しました。(Tatsuo Ishii)
</li><li> 拡張問い合わせプロトコルを使っていると、トランザクションを誤ってロー
ルバックしてしまう不具合を修正しました。(Yoshiyuki Asaba)
</li><li> 非同期クエリを使っていると pgpool が不安定になる不具合を修正し
ました。(Yoshiyuki Asaba)
</li><li> 拡張問合せプロトコルを使うと /* REPLICATION */などのヒント句が消えて
しまう不具合を修正しました。(Yoshiyuki Asaba)
</li><li> DEALLOCATE ALL を実行するとクラッシュする不具合を修正しました。
(Yoshiyuki Asaba)
</li><li> immediate shutdown するとハングアップする不具合を修正しました。
(Yoshiyuki Asaba)
</li><li> 高負荷時にオンラインリカバリを実施すると、リカバリプロセスがハ
ングアップする可能性のある不具合を修正しました。(Yoshiyuki Asaba)
</li><li> 拡張問合せプロトコルを使って SELECT を実行した際に、トランザク
ションブロック内でクエリがエラーになると、pgpool がハングアップする
可能性のある不具合を修正しました。(Yoshiyuki Asaba)
</li></ul>
<h4>マスタースレーブ</h4>
<ul>
<li> トランザクションブロック内で、SET, PREPARE, DEALLOCATE を実行す
ると、プロセスがダウンする不具合を修正しました。(Yoshiyuki Asaba)
</li><li> マスタースレーブモードでロードバランスが正しく動作していない不
具合を修正しました。(Yoshiyuki Asaba)
</li></ul>
<h4>パラレルクエリ</h4>
<ul>
<li> INSERT に失敗する不具合を修正しました。(Yoshiharu Mori)
</li><li> FROM 句に AS が含まれると構文エラーになる不具合を修正しました。(sho)
</li><li> クエリを複数回実行するとハングアップする不具合を修正しました。(Yoshiharu Mori)
</li><li> JOIN に失敗する不具合を修正しました。(Yoshiharu Mori)
</li><li> DISTINCT構文 の解析に失敗する不具合を修正しました。(Yoshiharu Mori)
</li></ul>
<!-- ================================================================================ -->
<!-- 2.0 -->
<!-- ================================================================================ -->
<hr><a name="release2.0.x"></a>
<!-- -------------------------------------------------------------------------------- -->
<h2>2.0.1 (hikitsuboshi) 2007/11/21</h2>
<!-- -------------------------------------------------------------------------------- -->
<ul>
<li> UPDATE もしくは DELETE を実行するとプロセスがダウンする不具合を
修正しました。(Yoshiyuki Asaba)
</li><li> <a href="#MASTER_SLAVE_MODE">master_slave</a> を true に設定している場合に、SQL 構文エラーを検知
した時にマスタにのみそのクエリを送信するようにしました。(Yoshiyuki Asaba)
</li></ul>
<!-- -------------------------------------------------------------------------------- -->
<h2>2.0 (hikitsuboshi) 2007/11/16</h2>
<!-- -------------------------------------------------------------------------------- -->
<h3>互換性</h3>
<ul>
<li> <a href="#IGNORE_LEADING_WHITE_SPACE">ignore_leading_white_space</a> のデフォルト値を true にしました。
(Yoshiyuki Asaba)
</li><li> replicate_strict を廃止しました。常に replicate_strict が true
の挙動になります。(Yoshiyuki Asaba)
</li></ul>
<h3>全般</h3>
<ul>
<li> pgpool.conf をリロードできるようにしました。リロード時に分散ルールも同時にリロードします。(Yoshiyuki Asaba)
</li><li> SQL パーサを PostgreSQL 8.3 に対応しました。(Yoshiyuki Asaba)
</li><li> ノードを切り離した際にユーザが設定したコマンドを実行できるよう
に、pgpool.conf に <a href="#FAILOVER_COMMAND">failover_command</a> というパラメータを追加しました。
(Yoshiyuki Asaba)
</li><li> ノードを復帰した際にユーザが設定したコマンドを実行できるように、
pgpool.conf に <a href="#FAILBACK_COMMAND">failback_command</a> というパラメータを追加しました。
(Yoshiyuki Asaba)
</li><li> pgpool.conf に <a href="#CLIENT_IDLE_LIMIT">client_idle_limit</a> というパラメータを追加しました。
このパラメータではクライアントからのクエリの最大待ち時間を設定することができます。(Tatsuo Ishii)
</li></ul>
<h3>レプリケーション</h3>
<ul>
<li> トランザクションブロックに囲まれていないクエリをレプリケーションさせる場合、
内部的にトランザクションを開始させるようにしました。(Yoshiyuki Asaba)
</li><li> レプリケーションを高速化させるようにしました。(Yoshiyuki Asaba)
</li><li> ノードを再同期させて復帰させる、オンラインリカバリ機能を実装し
ました。(Yoshiyuki Asaba)
</li><li> INSERT, UPDATE, DELETE した行数がすべて一致しなかった場合に、
トランザクションをアボートさせるようにしました。(Yoshiyuki Asaba)
<pre>x=# update t set a = a + 1;
ERROR: pgpool detected difference of the number of update tuples
HINT: check data consistency between master and other db node
</pre>
</li><li> 複数のバックエンドから異なる結果が返ってきた場合に、同じ結果が
多数返ってきた結果を信頼する多数決方式を実装しました。(Yoshiyuki Asaba)
</li><li> V2 問合せプロトコルでロードバランスできるようにしました。(Yoshiyuki Asaba)
</li></ul>
<h3>パラレルクエリ</h3>
<ul>
<li> パラレルモードで部分レプリケーションをサポートしました。(Yoshiharu Mori)
</li></ul>
<!-- ================================================================================ -->
<hr><a name="release1.3.x"></a>
<!-- -------------------------------------------------------------------------------- -->
<h2>1.3 (sohiboshi) 2007/10/23</h2>
<!-- -------------------------------------------------------------------------------- -->
<ul>
<li> 新しく <a href="AUTHENTICATION_TIMEOUT">authentication_timeout</a> という
パラメータを追加しました。(Yoshiyuki Asaba)
<ul>
<li>このパラメータでは認証時間のタイムアウトを設定します。
</li><li>デフォルト値は 60 (1 分)です。
</li></ul>
</li><li> スタートアップパケットの長さが 10000 バイト越えている場合には、接続を切断するようにしました。(Yoshiyuki Asaba)
</li><li> DEALLOCATE を実行するとまれに不正なメモリアクセスが発生する不具
合を修正しました。(Yoshiyuki Asaba)
</li><li> トランザクション内で SELECT を実行した後に SELECT を正しくロードバラ
ンスできない不具合を修正しました。(Yoshiyuki Asaba)
<ul>
<li> この不具合は 1.2 で混入した不具合です。
</li></ul>
</li><li> 64bit 環境でクエリキャッシュ機能を有効にすると、クラッシュする可能性のある不具合を修正しました(Yoshiyuki Asaba)
</li></ul>
<!-- ================================================================================ -->
<hr><a name="release1.2.x"></a>
<!-- -------------------------------------------------------------------------------- -->
<h2>1.2.1 (tomoboshi) 2007/09/28</h2>
<!-- -------------------------------------------------------------------------------- -->
<ul>
<li> 拡張問合せプロトコルの Parse メッセージの処理でデッドロックが発
生する可能性がある不具合を修正しました。(Yoshiyuki Asaba)
</li><li> Prepared statement を管理する領域がメモリリークしている不具合を
修正しました。(Yoshiyuki Asaba)
</li><li> 一部の OS でコンパイルエラーになる不具合を修正しました。(Yoshiyuki Asaba)
</li><li>master/slave モード内で SET, PREPARE, DEALLOCATE 文をレプリケーションさせるようにしました。(Yoshiyuki Asaba)
</li></ul>
<!-- -------------------------------------------------------------------------------- -->
<h2>1.2 (tomoboshi) 2007/08/01</h2>
<!-- -------------------------------------------------------------------------------- -->
<ul>
<li> pgpool.conf に <a href="#REPLICATE_SELECT">replicate_select</a> という新規パラメータを追加しま
した。デフォルト値は false です。(Yoshiyuki Asaba)
<ul>
<li> true に設定した場合は、ロードバランスされない SELECT 文をレプリケーションします
(pgpool-II 1.0 の挙動)。false の場合はマスタにのみ SELECT を送信します。
</li></ul>
</li><li> シグナル処理を安全に行うようにしました。(Yoshiyuki Asaba)
<ul>
<li>まれにゾンビプロセスが残ってしまったり、不安定になることがありました。
</li></ul>
</li><li> トランザクション中に SELECT 文がエラーになると、ハングアップしてしまう不具合を修正しました。(Yoshiyuki Asaba)
<ul>
<li> この不具合は 1.1 に入った不具合です。
</li></ul>
</li><li> PREPARE/EXECUTE が master/slave モードで正しく動作しない不具合
を修正しました。(Yoshiyuki Asaba)
</li><li> デッドロックを検知すると、kind mismatch error が発生する不具合
を修正しました。(Yoshiyuki Asaba)
</li><li> 拡張問い合わせプロトコルを使ったドライバを使用した場合に、
構文解析時に警告が発生する SQL 文を実行するとハングアップもしくは
プロセスがクラッシュする不具合を修正しました。(Yoshiyuki Asaba)
</li><li> コネクションキャッシュが一杯になるとメモリリークが発生する不具合を修正しました。(Yoshiyuki Asaba)
</li><li> セッションが残った状態で PostgreSQL を fast shutdown もしくは
immediate shutdown すると、残ったセッションがハングアップする不具合
を修正しました。(Yoshiyuki Asaba)
</li><li> ロードバランス先を接続開始時に決定し、同じセッション内ではすべ
て同じノードにクエリを送信するようにしました。(Yoshiyuki Asaba)
</li><li> <a href="#CONNECTION_LIFE_TIME">connection_life_time</a> を設定している場合に
バッファオーバランが発生する可能性がある不具合を修正しました。(Yoshiyuki Asaba)
</li></ul>
<!-- ================================================================================ -->
<hr><a name="release1.1.x"></a>
<h2>1.1.1 (amiboshi) 2007/06/15</h2>
<ul>
<li> <a href="#LOAD_BALANCE_MODE">load_balance_mode</a> を有効にしていると、"kind mismatch" エラーが
発生してしまう不具合を修正しました。これは 1.1 で入った不具合です。
(Yoshiyuki Asaba)
</li><li> プロトコルバージョン 2 を使ったドライバでレプリケーション使用す
ると、pgpool がハングアップする不具合を修正しました(Yoshiyuki Asaba)
</li><li> 拡張問合せプロトコルを使用すると、まれにデッドロックが発生する
不具合を修正しました(Yoshiyuki Asaba)
</li></ul>
<h2>1.1 (amiboshi) 2007/05/25</h2>
<ul>
<li> HBA 認証をサポートしました(Taiki Yamaguchi)
</li><li> <a href="#LOG_CONNECTIONS">log_connections</a> をサポートしました(Taiki Yamaguchi)
</li><li> <a href="#LOG_HOSTNAME">log_hostname</a> をサポートしました(Taiki Yamaguchi)
</li><li> ps コマンドで pgpool の状態がわかるようにしました(Taiki Yamaguchi)
</li><li> MacOS X でコンパイルエラーになる不具合を修正しました(Yoshiyuki Asaba)
</li><li> 拡張問い合わせプロトコルを使ったクエリをロードバランスできるようにしました(Yoshiyuki Asaba)
</li><li> レプリケーション設定時、SELECT は master にのみ送信するようにしました(Yoshiyuki Asaba)
<ul>
<li> もし SELECT をレプリケーションさせる場合は /*REPLICATION*/ のように
SELECT の前にコメントを付ける必要があります
</li></ul>
</li><li> レプリケーション設定時、SELECT nextval() および SELECT setval()
を自動的にレプリケーションさせるようにしました(Yoshiyuki Asaba)
</li><li> バックエンドへ接続中にシグナルに割り込まれると、フェイルオーバしてしまう不具合を修正しました(Yoshiyuki Asaba)
</li><li> PAM 認証のサンプルファイル pgpool.pam を $PREFIX/share/pgpool-II/ にインストールするようにしました(Taiki Yamaguchi)
</li><li> 巨大な SQL を実行しようとした場合に pgpool が無限ループに入る不具合を修正しました(Yoshiyuki Asaba)
</li></ul>
<!-- ================================================================================ -->
<hr><a name="release1.0.x"></a>
<h2>1.0.2 (suboshi) 2007/02/13</h2>
<ul>
<li> 巨大な SQL を実行しようとした場合に pgpool が無限ループに入る不具合を修正しました(Yoshiyuki Asaba)
</li><li> 拡張問合せプロトコルを使った場合にまれに pgpool が止まってしまう不具合を修正しました(Yoshiyuki Asaba)
</li><li> フェイルオーバ、フェイルバック時のログ出力を改善しました(Tatsuo Ishii)
</li><li> <a href="#pool_status">SHOW pool_status</a> の結果にバックエンドステータス情報を追加しました(Tatsuo Ishii)
</li><li> レプリケーション時に UPDATE/DELETE の件数が実際の件数とは異なった結果を返す不具合を修正しました(Tatsuo Ishii)
</li><li> 古い gcc を使うと libpq のリンクに失敗する不具合を修正しました (Yoshiyuki Asaba)
</li><li> PHP:PDO や DBD-Pg を使った場合に、自動 DEALLOCATE が失敗してしまう不具合を修正しました(Yoshiyuki Asaba)
</li><li> SELECT FOR UPDATE, SELECT INTO をロードバランスさせないようにしました。
また、SELECT の前にコメントがある場合もロードバランスさせないようにしました。
これは pgpool-I との互換性のためです。(Yoshiyuki Asaba)
</li><li> configure 時の libpq のデフォルトパスを pg_config コマンドを使って取得するようにしました。
なお、--with-pgsql 関連のオプションは次のバージョンでは廃止予定です(Yoshiyuki Asaba)
</li><li> コネクションプール再利用時に、ソケットが壊れている場合は再接続するようにしました(Yoshiyuki Asaba)
</li><li> PostgreSQL 7.4.x の libpq を使ってビルドしようとすると、
configure スクリプトでエラーとなってしまう不具合を修正しました(Yoshiyuki Asaba)
</li></ul>
<!-- ================================================================================ -->
</div>
<div class="copyright" style="clear: both">
<hr>
<copyright>
Copyright © 2003 – 2013 pgpool Global Development Group
</copyright>
</div>
</body>
</html>
|