Re: pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

Andres Freund writes: > The one I noticed was: > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=treepie=2018-03-28%2002%3A43%3A00 > ... > which probably is just collation related and will stably fail? Yeah, magpie is still showing that after the latest commits. A bit

Re: pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

Andres Freund writes: > There's also a few of that annoying postgres_fdw thing. Some of my > critters hit that regularly :(. We need to figure out what's going on > there. Yeah, really. I've made several sustained attempts to reproduce that locally, on every machine I have,

pgsql: Use pg_stat_get_xact* functions within xacts

Use pg_stat_get_xact* functions within xacts Resolve build farm failures from c203d6cf81b4d7e43, diagnosed by Tom Lane. The output of pg_stat_get_xact_tuples_hot_updated() and friends is not guaranteed to show anything after the transaction completes. Data is flushed slowly to stats collector,

Re: pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

On 2018-03-27 23:40:25 -0400, Tom Lane wrote: > Andres Freund writes: > > Note there appear to be some independent failures? > > It looks to me like the hard failures from this patch are all on your JIT > critters. The one I noticed was:

pgsql: Quick adaption of JIT tuple deforming to the fast default patch.

Quick adaption of JIT tuple deforming to the fast default patch. Instead using memset to set tts_isnull, call the new slot_getmissingattrs(). Also fix a bug (= instead of >=) in the code generation. Normally = is correct, but when repeatedly deforming fields not in a tuple (e.g. deform up to

Re: pgsql: Add catversion bump missed in 16828d5c0.

On Wed, Mar 28, 2018 at 12:39 PM, Andres Freund wrote: > Add catversion bump missed in 16828d5c0. > > Given that pg_attribute changed its layout... Oops. Thanks. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7

pgsql: Add catversion bump missed in 16828d5c0.

Add catversion bump missed in 16828d5c0. Given that pg_attribute changed its layout... Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b4013b8e4a271816ba87aa56f46dbc04a083d962 Modified Files -- src/include/catalog/catversion.h | 2 +- 1 file changed, 1

Re: pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

Hi, On 2018-03-28 11:37:49 +1030, Andrew Dunstan wrote: > Please do. K, not 100% sure I'll get it done today, I'm neck deep looking at something else. But if not, I'll surely get it done tomorrow morning PST. Note there appear to be some independent failures? > I guess I need to do some

Re: pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

Hi, On 2018-03-28 00:56:10 +, Andrew Dunstan wrote: > Fast ALTER TABLE ADD COLUMN with a non-NULL default > src/backend/executor/execExprInterp.c | 2 +- I bet this'll break JITed tuple deforming... We'll have to emit a call to the new slot missingattrs function, instead of using

pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

Fast ALTER TABLE ADD COLUMN with a non-NULL default Currently adding a column to a table with a non-NULL default results in a rewrite of the table. For large tables this can be both expensive and disruptive. This patch removes the need for the rewrite as long as the default value is not volatile.

pgsql: Update pgindent's typedefs blacklist, and make it easier to adju

Update pgindent's typedefs blacklist, and make it easier to adjust. It seems that all buildfarm members are now using the code path, so that none of them report "bool" as a typedef. We still need it to be treated that way, so adjust pgindent to force that whether or not it's in the given list.

Re: pgsql: Allow HOT updates for some expression indexes

I wrote: > The test script appears to imagine that pgstats outputs update > instantaneously. Oh, wait, it's looking at pg_stat_xact, which is the *local*, unsent stats information. So your problem is actually the reverse of that: if the test runs too slowly, it fails, because at some point the

Re: pgsql: Allow HOT updates for some expression indexes

Simon Riggs writes: > On 27 March 2018 at 20:11, Simon Riggs wrote: >> Buildfarm failure seen, investigating > Error on FreeBSD only , perhaps timing-related as a result of using > pg_stat_get_xact_tuples_hot_updated() > in tests. It's by now

pgsql: Allow memory contexts to have both fixed and variable ident stri

Allow memory contexts to have both fixed and variable ident strings. Originally, we treated memory context names as potentially variable in all cases, and therefore always copied them into the context header. Commit 9fa6f00b1 rethought this a little bit and invented a distinction between fixed

Re: pgsql: Allow HOT updates for some expression indexes

On 27 March 2018 at 20:11, Simon Riggs wrote: > Buildfarm failure seen, investigating Error on FreeBSD only , perhaps timing-related as a result of using pg_stat_get_xact_tuples_hot_updated() in tests. Will wait to collect other failures -- Simon Riggs

pgsql: libpq: PQhost to return active connected host or hostaddr

libpq: PQhost to return active connected host or hostaddr Previously, PQhost didn't return the connected host details when the connection type was CHT_HOST_ADDRESS (i.e., via hostaddr). Instead, it returned the complete host connection parameter (which could contain multiple hosts) or the

Re: pgsql: Skip temp tables from basebackup.

Thanks for everyone, pushed. Let us follow the pgbuildfarm David Steele wrote: On 3/27/18 10:24 AM, Teodor Sigaev wrote: Hm, seems, Windows doesn't like this patch https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2018-03-27 sorry for wrong URL

pgsql: Fix count of skipped test of basebackup on Windows

Fix count of skipped test of basebackup on Windows Commit 920a5e500a119b03356fb1fb64a677eb1aa5fc6f add tests which should be skipped on Windows boxes, but patch doesn't contain right count of them. David Steel Branch -- master Details ---

Re: pgsql: Skip temp tables from basebackup.

On 3/27/18 10:24 AM, Teodor Sigaev wrote: >> Hm, seems, Windows doesn't like this patch >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2018-03-27 >> > > sorry for wrong URL > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2018-03-27%2013%3A30%3A24 Looks

Re: pgsql: Skip temp tables from basebackup.

> "Teodor" == Teodor Sigaev writes: Teodor> Hm, seems, Windows doesn't like this patch You added two tests to the SKIP: block without updating the number of tests that would be skipped, so the final count of tests comes out wrong. skip "symlinks not supported on

Re: pgsql: Skip temp tables from basebackup.

David Steele writes: > Will do. Probably a path problem, which hopefully I can fix with the new > function Andrew wrote. Looks to me more like a failure-to-count-the-number-of-tests problem. There's no test reported as "not ok". regards, tom lane

pgsql: Skip temp tables from basebackup.

Skip temp tables from basebackup. Do not store temp tables in basebackup, they will not be visible anyway, so, there are not reasons to store them. Author: David Steel Reviewed by: me Discussion: https://www.postgresql.org/message-id/flat/5ea4d26a-a453-c1b7-eff9-5a3ef8f8a...@pgmasters.net