[BUGS] BUG #8450: pg_basebackup blocks until WAL archiving successful
The following bug has been logged on the website: Bug reference: 8450 Logged by: Stuart Bishop Email address: stu...@stuartbishop.net PostgreSQL version: 9.1.9 Operating system: all Description: Hi. pg_basebackup blocks until all necessary WAL files have been archived by archive_command. This can take a few minutes under normal circumstances, and indefinitely if archive_command is failing. I would like to be able to disable this check, as I am streaming backups to a system that can time out my connection if it does not receive new data for a short while. This makes unattended backups problematic. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8446: CST FATAL: the database system is in recovery mode
The following bug has been logged on the website: Bug reference: 8446 Logged by: diaoqiwei Email address: dqwhappy...@163.com PostgreSQL version: 9.0.0 Operating system: centos Description: 2013-09-11 01:03:19 CST PANIC: stuck spinlock (0x2af93779bcd8) detected at dynahash.c:981 2013-09-11 01:03:19 CST STATEMENT: select user_id,user_password,user_nameen,user_namecn,user_officephone,user_mobile from oa_user where user_state=0 and user_nameen=$1 2013-09-11 01:03:22 CST PANIC: stuck spinlock (0x2af93779bcd8) detected at dynahash.c:981 2013-09-11 01:03:22 CST STATEMENT: select user_id,user_password,user_nameen,user_namecn,user_officephone,user_mobile from oa_user where user_state=0 and user_nameen=$1 2013-09-11 01:03:27 CST PANIC: stuck spinlock (0x2af93779bcd8) detected at dynahash.c:981 2013-09-11 01:03:27 CST STATEMENT: select user_id,user_password,user_nameen,user_namecn,user_officephone,user_mobile from oa_user where user_state=0 and user_nameen=$1 2013-09-11 01:03:30 CST LOG: server process (PID 14539) was terminated by signal 6: Aborted 2013-09-11 01:03:30 CST LOG: terminating any other active server processes 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode 2013-09-11 01:03:30 CST FATAL: the database system is in recovery mode -- 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] Re: BUG #8444: ERROR: table name tblb specified more than once in subquery
David Johnston pol...@yahoo.com writes: Here is a minimal query that demonstrates the problem. In 9.1 it works: chris=# select * FROM current_user u join (current_user u cross join current_user v) x on true; On 9.3 it fails: ERROR: table name u specified more than once This is an intentional change that came in with the LATERAL feature. The query is illegal per SQL spec but we used to allow it anyway, on the theory that the table name u inside the aliased join x wasn't visible anywhere that the other u was visible, so the duplicate alias name was harmless. But in the presence of LATERAL it's not harmless; consider select * FROM current_user u join (current_user u cross join LATERAL (select u.x) v) x on true; Which instance of u does the lateral reference refer to? (I think there was some discussion of this in the pgsql-hackers list about a year ago, but I couldn't find it in a desultory search.) 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
[BUGS] Re: BUG #8444: ERROR: table name tblb specified more than once in subquery
Tom Lane-2 wrote David Johnston lt; polobo@ gt; writes: Here is a minimal query that demonstrates the problem. In 9.1 it works: chris=# select * FROM current_user u join (current_user u cross join current_user v) x on true; On 9.3 it fails: ERROR: table name u specified more than once This is an intentional change that came in with the LATERAL feature. The query is illegal per SQL spec but we used to allow it anyway, on the theory that the table name u inside the aliased join x wasn't visible anywhere that the other u was visible, so the duplicate alias name was harmless. But in the presence of LATERAL it's not harmless; consider select * FROM current_user u join (current_user u cross join LATERAL (select u.x) v) x on true; Which instance of u does the lateral reference refer to? (I think there was some discussion of this in the pgsql-hackers list about a year ago, but I couldn't find it in a desultory search.) regards, tom lane I do vaguely recall that said discussion exists. However, this and the -general thread for the same issue both seem to indicate that the actual order of the joining affects whether the error is thrown...I guess the way LATERAL works this does make sense - somewhat. While the behavior is intentional not mentioning it in the release notes, section E.1.2. Migration to Version 9.3 is an oversight that should be corrected. Might be worth finding and linking to the thread in the release notes so that people affected by this change go and look to figure out why it was made. Given your example involves a LATERAL sub-clause my first thought is that any non-LATERAL (and thus all previous version) queries would be unaffected. If I find a link I'll come back and post it for reference from here and -general at least. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-8444-ERROR-table-name-tblb-specified-more-than-once-in-subquery-tp5770540p5770710.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.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] BUG #8451: quantile extension: memory corruption?
The following bug has been logged on the website:
Bug reference: 8451
Logged by: strexxx
Email address: stephane.wust...@lip6.fr
PostgreSQL version: 9.1.9
Operating system: Linux 3.8.0-27-generic #40-Ubuntu SMP x86_64
Description:
A query such as this one
COPY (SELECT e,quantile(EXTRACT(EPOCH
FROM(d)),ARRAY[0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1]) AS d FROM (SELECT
e,max(time)-min(time) AS d FROM bb RIGHT JOIN (SELECT s,e FROM ss RIGHT JOIN
(SELECT e FROM ee WHERE h ~* 'blah') AS i0 USING(e)) AS i0 USING
(sessionid) GROUP BY e,ei) AS i1 GROUP BY e) TO 'full_path/d.csv' WITH
CSV;
generates this
...
403,{0.101187,0.139183,0.189162,0.271442,0.405427,0.731997,1.178445,2.52971,4.288747,9.544644,8996.364885}
404,{8996.364885,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322}
437,{0.10007,0.204397,0.266877,0.48238,0.669026,0.911554,1.275652,1.656346,2.445659,3.909159,58915.291602}
438,{58915.291602,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322}
440,{58915.291602,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322,3.16202013338398e-322}
...
for row that gets corrupted, the value d, for which quantiles are computed
over, is NULL (there is no such row matching conditions and JOIN).
I would expect the quantiles to be NULL as well.
Additionally there is a strange pattern: the last value of the row preceding
a corrupted one, is repeated as the first value of the corrupted rows that
comes after.
The other values correspond to something somewhat close to 2^-1068 (why ?)
...
This subquery corresponding to one of the corrupted case works correctly
(from my understanding)
SELECT s,quantile(EXTRACT(EPOCH
FROM(d)),ARRAY[0,0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,1]) AS d FROM (SELECT
s,max(time)-min(time) AS d FROM bb WHERE s = 440 GROUP BY s,e) AS i1 GROUP
BY s;
s | d
---+--
(0 rows)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
