Re: [BUGS] BUG #8397: pg_basebackup -x from new standby server sometimes causes Segmentation fault
Thanks for the response. On Sat, 24 Aug 2013 17:04:21 +0200 Magnus Hagander mag...@hagander.net wrote: (1) create new standby server dir by pg_basebackup without -x (2) start new standby server (3) pg_basebackup from new standby server with -x (!) when new standby has no WAL files in pg_xlog, new standby's wal sender crash (snip) Though pg_basebackup does not have to work in this rare case, we should insert something like if (nWalFiles = 0) ereport(...);. Yes, we definitely need better error checking there - a crash is never the right answer. Does this happen only when you take a backup really quickly after setting up the new standby, It's just this first case. Therefore, we recognize that it is the problem of how to use. regards, or is there some scenario further in it's lifetime when it can happen? In the first case, throwing a hard error seems quite reasonable, but if it's repeatable, perhaps there is something better we can do? Also, while we definitely need a sanity check at this point, might it be worth it to put a second check earlier in the process as well - since AFAICT this error gets thrown only after all the data has been sent arlready. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ __ haru...@sraoss.co.jp(SRA OSS, Inc. http://www.sraoss.co.jp) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8396: Window function results differ when selecting from table and view, with where clause
p...@weotta.com writes: When I select from a view, the where clause in my select statement does not restrict the rows processed by window functions referenced inside the view definition. Thus, if window functions are involved, using a where clause when selecting from a view and using a where clause when selecting directly from the underlying table produces different results. I don't see anything even a little bit surprising about this. A WHERE clause applied to a view should hide some rows that would appear in the view output without it, but it should certainly never change the contents of the rows it does let through. Now, if you put the WHERE clause before the window functions (and WHERE is semantically prior to the evaluation of a SELECT list at the same syntactic level), then the WHERE clause does filter the rows before the window functions see 'em. But a WHERE clause supplied at an outer syntactic level acts after the window functions are processed. Another way to put it is that your query with the view is equivalent to select * from ( select plant_id as plant_id , row_number() over ( partition by city order by plant_id ) as plant_number , count(*) over ( partition by city ) as of_plants_in_city , city as city from plant ) as plant_extend where plant_id = 'FOLSOM' ; which is not at all the same thing as select plant_id as plant_id , row_number() over ( partition by city order by plant_id ) as plant_number , count(*) over ( partition by city ) as of_plants_in_city , city as city from plant where plant_id = 'FOLSOM' ; precisely because the former specifies applying the WHERE filter after the window functions run, while the latter specifies applying it before. The fact that the results do change when you put the WHERE restriction before the window functions is exactly why the optimization discussed in that stackoverflow thread you mention isn't made. In some cases it would theoretically be possible to prove that moving the filtering wouldn't change the results, but Postgres isn't smart enough to do that --- and even if it were, it would not push down the WHERE clause in either this example or the stackoverflow one, because it could/would change the results. Or in short, this isn't a bug, but a counterexample to the stackoverflow discussion. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8397: pg_basebackup -x from new standby server sometimes causes Segmentation fault
On Sun, Aug 25, 2013 at 9:05 AM, TAKATSUKA Haruka haru...@sraoss.co.jp wrote: Thanks for the response. On Sat, 24 Aug 2013 17:04:21 +0200 Magnus Hagander mag...@hagander.net wrote: (1) create new standby server dir by pg_basebackup without -x (2) start new standby server (3) pg_basebackup from new standby server with -x (!) when new standby has no WAL files in pg_xlog, new standby's wal sender crash (snip) Though pg_basebackup does not have to work in this rare case, we should insert something like if (nWalFiles = 0) ereport(...);. Yes, we definitely need better error checking there - a crash is never the right answer. Does this happen only when you take a backup really quickly after setting up the new standby, It's just this first case. Therefore, we recognize that it is the problem of how to use. Yeah. Ok, for now I have the patch I applied yesterday that makes it an error instead of a crash per your suggestion. And if I failed to mention it, thanks for the report! -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] uuid.h: present but cannot be compiled
checking ossp/uuid.h usability... no checking ossp/uuid.h presence... no checking for ossp/uuid.h... no checking uuid.h usability... no checking uuid.h presence... yes configure: WARNING: uuid.h: present but cannot be compiled configure: WARNING: uuid.h: check for missing prerequisite headers? configure: WARNING: uuid.h: see the Autoconf documentation configure: WARNING: uuid.h: section Present But Cannot Be Compiled configure: WARNING: uuid.h: proceeding with the preprocessor's result configure: WARNING: uuid.h: in the future, the compiler will take precedence configure: WARNING: ## ## configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ## configure: WARNING: ## ## checking for uuid.h... yes on os x 10.8.4 installing with homebrew == Downloading http://ftp.postgresql.org/pub/source/v9.2.4/postgresql-9.2.4.tar.bz2 == ./configure --disable-debug --prefix=/usr/local/Cellar/postgresql/9.2.4 --datadir=/usr/local/Cellar/postgresql/9.2.4/share/postgresql --docdir=/usr/local/Cellar/postgresql/9.2.4/share/doc/postgresql --enable-thread-safety --with-bonjour --with-gssapi --with-krb5 --with-ldap --with-openssl --with-pam --with-libxml --with-libxslt --with-ossp-uuid --with-python --with-perl --with-tcl ARCHFLAGS='-arch x86_64'
