* New upstream bug fix release: (LP: #693157) - Force the default wal_sync_method to be fdatasync on Linux. The default on Linux has actually been fdatasync for many years, but recent kernel changes caused PostgreSQL to choose open_datasync instead. This choice did not result in any performance improvement, and caused outright failures on certain filesystems, notably ext4 with the data=journal mount option. - Fix assorted bugs in WAL replay logic for GIN indexes. This could result in "bad buffer id: 0" failures or corruption of index contents during replication. - Fix recovery from base backup when the starting checkpoint WAL record is not in the same WAL segment as its redo point. - Fix persistent slowdown of autovacuum workers when multiple workers remain active for a long time. The effective vacuum_cost_limit for an autovacuum worker could drop to nearly zero if it processed enough tables, causing it to run extremely slowly. - Add support for detecting register-stack overrun on IA64. The IA64 architecture has two hardware stacks. Full prevention of stack-overrun failures requires checking both. - Add a check for stack overflow in copyObject(). Certain code paths could crash due to stack overflow given a sufficiently complex query. - Fix detection of page splits in temporary GiST indexes. It is possible to have a "concurrent" page split in a temporary index, if for example there is an open cursor scanning the index when an insertion is done. GiST failed to detect this case and hence could deliver wrong results when execution of the cursor continued. - Fix error checking during early connection processing. The check for too many child processes was skipped in some cases, possibly leading to postmaster crash when attempting to add the new child process to fixed-size arrays. - Improve efficiency of window functions. Certain cases where a large number of tuples needed to be read in advance, but work_mem was large enough to allow them all to be held in memory, were unexpectedly slow. percent_rank(), cume_dist() and ntile() in particular were subject to this problem. - Avoid memory leakage while "ANALYZE"'ing complex index expressions. - Ensure an index that uses a whole-row Var still depends on its table. An index declared like create index i on t (foo(t.-)) would not automatically get dropped when its table was dropped. - Do not "inline" a SQL function with multiple OUT parameters. This avoids a possible crash due to loss of information about the expected result rowtype. - Behave correctly if ORDER BY, LIMIT, FOR UPDATE, or WITH is attached to the VALUES part of INSERT ... VALUES. - Fix constant-folding of COALESCE() expressions. The planner would sometimes attempt to evaluate sub-expressions that in fact could never be reached, possibly leading to unexpected errors. - Fix postmaster crash when connection acceptance (accept() or one of the calls made immediately after it) fails, and the postmaster was compiled with GSSAPI support. - Fix missed unlink of temporary files when log_temp_files is active. If an error occurred while attempting to emit the log message, the unlink was not done, resulting in accumulation of temp files. - Add print functionality for InhRelation nodes. This avoids a failure when debug_print_parse is enabled and certain types of query are executed. - Fix incorrect calculation of distance from a point to a horizontal line segment. This bug affected several different geometric distance-measurement operators. - Fix incorrect calculation of transaction status in ecpg. - Fix PL/pgSQL's handling of "simple" expressions to not fail in recursion or error-recovery cases. - Fix PL/Python's handling of set-returning functions. Attempts to call SPI functions within the iterator generating a set result would fail. - Fix bug in "contrib/cube"'s GiST picksplit algorithm. This could result in considerable inefficiency, though not actually incorrect answers, in a GiST index on a cube column. If you have such an index, consider "REINDEX"ing it after installing this update. - Don't emit "identifier will be truncated" notices in "contrib/dblink" except when creating new connections. - Fix potential coredump on missing public key in "contrib/pgcrypto". - Fix memory leak in "contrib/xml2"'s XPath query functions.
If you are building from a <acronym>CVS</acronym> tree instead of
281
If you are building from a <productname>Git</productname> tree instead of
277
282
using a released source package, or if you want to do server development,
278
283
you also need the following packages:
279
284
294
299
</indexterm>
295
300
296
301
GNU <application>Flex</> and <application>Bison</>
297
are needed to build from a CVS checkout, or if you changed the actual
302
are needed to build from a Git checkout, or if you changed the actual
298
303
scanner and parser definition files. If you need them, be sure
299
304
to get <application>Flex</> 2.5.4 or later and
300
305
<application>Bison</> 1.875 or later. Other <application>lex</>
307
312
<primary>perl</primary>
308
313
</indexterm>
309
314
310
<application>Perl</> is also needed to build from a CVS checkout,
315
<application>Perl</> 5.8 or later is needed to build from a Git checkout,
311
316
or if you changed the input files for any of the build steps that
312
317
use Perl scripts. If building on Windows you will need
313
318
<application>Perl</> in any case.
360
365
361
366
<para>
362
367
You can also get the source directly from the version control repository, see
363
<xref linkend="cvs">.
368
<xref linkend="sourcerepo">.
364
369
</para>
365
370
</sect1>
366
371
]]>
2269
2274
-bash-3.00$ createlang plpgsql template1
2270
2275
createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plpgsql.so": A memory address is not in the address space for the process.
2271
2276
</screen>
2272
Running as a non-owner in the group posessing the PostgreSQL
2277
Running as a non-owner in the group possessing the PostgreSQL
2273
2278
installation:
2274
2279
<screen>
2275
2280
-bash-3.00$ createlang plpgsql template1
2525
2530
<para>
2526
2531
Aside from the PostgreSQL source distribution, you will need GNU
2527
2532
make (HP's make will not do), and either GCC or HP's full ANSI C
2528
compiler. If you intend to build from CVS sources rather than a
2533
compiler. If you intend to build from Git sources rather than a
2529
2534
distribution tarball, you will also need Flex (GNU lex) and Bison
2530
2535
(GNU yacc). We also recommend making sure you are fairly
2531
2536
up-to-date on HP patches. At a minimum, if you are building 64