{"ref":"refs/heads/master","commits":[{"author":{"name":"Peter Eisentraut","email":"c50e6bf7013fce877ffb25104d778a36de31e297@gmx.net"},"message":"Fix archive_command example\n\nThe given archive_command example didn't use %p or %f, which wouldn't\nreally work in practice.","url":"https://api.github.com/repos/tvondra/postgres/commits/27ef415a716d75de3213cb6bcd6cf20e24eb0f4f","sha":"27ef415a716d75de3213cb6bcd6cf20e24eb0f4f"},{"author":{"name":"Tom Lane","email":"ffeaa947aef224da9ba99b6a18bdd74288df0e3e@sss.pgh.pa.us"},"message":"Don't assume that a tuple's header size is unchanged during toasting.\n\nThis assumption can be wrong when the toaster is passed a raw on-disk\ntuple, because the tuple might pre-date an ALTER TABLE ADD COLUMN operation\nthat added columns without rewriting the table.  In such a case the tuple's\nnatts value is smaller than what we expect from the tuple descriptor, and\nso its t_hoff value could be smaller too.  In fact, the tuple might not\nhave a null bitmap at all, and yet our current opinion of it is that it\ncontains some trailing nulls.\n\nIn such a situation, toast_insert_or_update did the wrong thing, because\nto save a few lines of code it would use the old t_hoff value as the offset\nwhere heap_fill_tuple should start filling data.  This did not leave enough\nroom for the new nulls bitmap, with the result that the first few bytes of\ndata could be overwritten with null flag bits, as in a recent report from\nHubert Depesz Lubaczewski.\n\nThe particular case reported requires ALTER TABLE ADD COLUMN followed by\nCREATE TABLE AS SELECT * FROM ... or INSERT ... SELECT * FROM ..., and\nfurther requires that there be some out-of-line toasted fields in one of\nthe tuples to be copied; else we'll not reach the troublesome code.\nThe problem can only manifest in this form in 8.4 and later, because\nbefore commit a77eaa6a95009a3441e0d475d1980259d45da072, CREATE TABLE AS or\nINSERT/SELECT wouldn't result in raw disk tuples getting passed directly\nto heap_insert --- there would always have been at least a junkfilter in\nbetween, and that would reconstitute the tuple header with an up-to-date\nt_natts and hence t_hoff.  But I'm backpatching the tuptoaster change all\nthe way anyway, because I'm not convinced there are no older code paths\nthat present a similar risk.","url":"https://api.github.com/repos/tvondra/postgres/commits/039680affb1b925e8e5c9578b0ab05fa326452fe","sha":"039680affb1b925e8e5c9578b0ab05fa326452fe"},{"author":{"name":"Magnus Hagander","email":"9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net"},"message":"Make psql \\d on a sequence show the table/column owning it","url":"https://api.github.com/repos/tvondra/postgres/commits/6f81a1f6688c2901d82c02158e9c865f5538246d","sha":"6f81a1f6688c2901d82c02158e9c865f5538246d"},{"author":{"name":"Magnus Hagander","email":"9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net"},"message":"Show statistics target for columns in \\d+ on a table","url":"https://api.github.com/repos/tvondra/postgres/commits/ebcadba29fd1aeef76a4c0c4d1d2adad62fe945a","sha":"ebcadba29fd1aeef76a4c0c4d1d2adad62fe945a"},{"author":{"name":"Magnus Hagander","email":"9f4ca770b638615ac5c3e0d2da16b77c80c2f2c6@hagander.net"},"message":"Update regression tests for \\d+ modification\n\nNoted by Tom","url":"https://api.github.com/repos/tvondra/postgres/commits/3a6e4076b73b16575373c4a99d3301cdb929fd03","sha":"3a6e4076b73b16575373c4a99d3301cdb929fd03"}],"head":"3a6e4076b73b16575373c4a99d3301cdb929fd03","size":5,"push_id":48871542}