Re: [BUGS] Completely broken replica after PANIC: WAL contains references to invalid pages
On 11 June 2013 04:36, Sergey Konoplev gray...@gmail.com wrote: Hi, On Thu, May 9, 2013 at 7:28 PM, Sergey Konoplev gray...@gmail.com wrote: On Tue, Apr 2, 2013 at 11:26 AM, Andres Freund and...@2ndquadrant.com wrote: The attached patch fixes this although I don't like the way it knowledge of the point up to which StartupSUBTRANS zeroes pages is handled. One month has passed since the patched version was installed in our production environment and can confirm that everything works perfect. Thank you very much for your prompt help, Andres. Are there any plans to commit this patch and what version it is going to be done to? Thank you. I'll be committing this soon, since we're likely coming up to the next point release soon. Thanks for the reminder. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
On Mon, Jun 10, 2013 at 11:43 PM, Simon Riggs si...@2ndquadrant.com wrote: On 11 June 2013 04:36, Sergey Konoplev gray...@gmail.com wrote: Are there any plans to commit this patch and what version it is going to be done to? I'll be committing this soon, since we're likely coming up to the next point release soon. I see, thank you. Just curious, what is the planned date for the next minor release, and BTW where is it possible to see the roadmap for minor releases? Thanks for the reminder. You are welcome. -- Kind regards, Sergey Konoplev PostgreSQL Consultant and DBA Profile: http://www.linkedin.com/in/grayhemp Phone: USA +1 (415) 867-9984, Russia +7 (901) 903-0499, +7 (988) 888-1979 Skype: gray-hemp Jabber: gray...@gmail.com -- 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 #8202: can't install database
Please share the installation log from the system temp. On Tue, Jun 4, 2013 at 10:10 AM, mre...@sisdh.com wrote: The following bug has been logged on the website: Bug reference: 8202 Logged by: mrenda delta pamungkas Email address: mre...@sisdh.com PostgreSQL version: 8.4.17 Operating system: windows 7 64 bit Description: http://img822.imageshack.us/img822/5497/postgresqld.png -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sandeep -- 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 in Prepared statement with DELETE RETURNING and rule on view
On Tuesday, June 11, 2013 12:15 AM Tom Lane wrote: [ got around to looking at this thread finally ] Amit Kapila amit.kap...@huawei.com writes: What happens when you change ON DELETE rule of the view that really deletes elements is that command type after applying rule remains same which means Delete, so it can set the Tag. The point here is that in extended-query mode, we've defined that only the same statement that sets the command tag can return RETURNING rows. In the case at hand, the original DELETE isn't executed at all, being replaced by an UPDATE according to the rule. But we don't change the returned command tag to UPDATE, and we don't let the UPDATE's RETURNING clause return anything to the client. Both of these rules are meant to ensure unsurprising behavior as seen from the client side. We could debate changing them, but I'd be pretty worried about breaking user applications if we did. There are only 2 points I could think of supporting such behavior: 1. Explain on Delete statement will show Update, so returning command tag as Update is not wrong. 2. Maintaining consistency between psql and client interface. I think user's have facility to obtain information about prepared statement by using PQdescribePrepared() to know what they could expect in result. At the same time, things don't look terribly consistent because in psql (which uses simple query protocol) you *do* see the RETURNING results. That's because simple query protocol doesn't have a restriction that only one resultset can be returned from a single query. So it's a lot more wild-west as to what will really happen, and application code is expected to just deal with that. psql doesn't have a problem with multiple query results because it doesn't particularly care what they are; it's just going to print each one. Apps that are supposed to actually make sense of the data have more of an issue with that. The extended query protocol was explicitly designed to lock things down better so that interactions would be more predictable. The main thing I'm noticing in looking at this is that the documentation doesn't seem to explain anywhere the restriction to getting RETURNING results back from only the primary query. We ought to fix that. I could think of below text that can be mentioned either in Create Rule (Notes Section) page or in Extended Query section: For extended-query mode, if the RULE changes the original statement, command tag will not be modified and RETURNING clause will not return rows. With Regards, Amit Kapila. -- 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] Completely broken replica after PANIC: WAL contains references to invalid pages
Sergey Konoplev gray...@gmail.com writes: Just curious, what is the planned date for the next minor release, and BTW where is it possible to see the roadmap for minor releases? There is no planned date, and certainly no roadmap. We make minor releases when the core team judges that enough (or severe enough) fixes have accumulated since the last time. Historically we've averaged about four minor releases a year, but that's not set in stone anywhere. 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] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
Hiroshi Inoue has developed the attached patch to correct the issue that was reported. More of the dialogue can be found in the pgsql-odbc list. The root issue: Inoue, Hiroshi in...@tpf.co.jp mailto:in...@tpf.co.jp wrote: It's also preferrable to fix the crash at backend. The crash is caused by execute commands after commit. Regarding testing: Is there any test code that I could leverage to put together a test case which can quickly invoke the backend problem that I'm seeing? Perhaps something that is used in the pgsqlODBC project or something else you or others might have sitting around? I would like to have a testapp/function that could help verify that the issue has been fixed in a future backend patch/release. It seems difficult to provide a test code. However I can reproduce the crash by changing 1 line of psqlodbc driver source code with a test case. For example, the crash is fixed by the attached patch. I've never explicitly used EXECUTE. Could I construct a plpgsql script which could use EXECUTE in a similar manner as psqlODBC, thus creating a test case that would have greater portability? Oops it's an Execute message used in extended query protocol not a *EXECUTE* command. printtup_holdable_cursor.patch Description: Binary data -- 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] Memory-leak in BackgroundWriter(and Checkpointer)
Any idea when it will be available in official PostgreSQL release 9.1.x or 9.2.x ? -- View this message in context: http://postgresql.1045698.n5.nabble.com/Memory-leak-in-BackgroundWriter-and-Checkpointer-tp5757869p5758783.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
Re: [BUGS] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
On 11.06.2013 19:04, Joshua Berry wrote: Hiroshi Inoue has developed the attached patch to correct the issue that was reported. More of the dialogue can be found in the pgsql-odbc list. I tried to follow that thread over at pgsql-odbc, but couldn't quite understand what the problem is. Did you have a test program to reproduce it? Or failing that, what is the sequence of protocol messages that causes the problem? - Heikki -- 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] [ODBC] Segmentation Fault in Postgres server when using psqlODBC
On 2013-06-11 19:20:57 +0300, Heikki Linnakangas wrote: On 11.06.2013 19:04, Joshua Berry wrote: Hiroshi Inoue has developed the attached patch to correct the issue that was reported. More of the dialogue can be found in the pgsql-odbc list. I tried to follow that thread over at pgsql-odbc, but couldn't quite understand what the problem is. Did you have a test program to reproduce it? Or failing that, what is the sequence of protocol messages that causes the problem? I'd guess creating a SQL level WITH HOLD cursor and then fetching that via the extended protocol, outside the transaction, should do the trick. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] pgScript bug
Hello! I've found pgScript bug: SET @now = '2013-06-01 12:00:00.0'; SET @now = '@now'; SELECT @now::timestamp; This code is executed indefinitely . pgAdmin v1.16.1 for Windows, postgres 9.2 Debian 6.0 With best regards, Konstantin
Re: [BUGS] Memory-leak in BackgroundWriter(and Checkpointer)
* Pawel Kozik (pawel.ko...@alcatel-lucent.com) wrote: Any idea when it will be available in official PostgreSQL release 9.1.x or 9.2.x ? Yes, the next set of point releases should include Tom's patch to fix this leak. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] Inconsistent PL error handling
On 5/9/13 5:40 PM, Dave Page wrote: Whilst working on a build issue with pl/python, I noticed an inconsistency in the way the server reacts to attempts to use PLs for which the interpreter doesn't exist. Not sure how feasible it would be to fix this, but the Python case doesn't seem ideal: psql.bin (9.3beta1) Type help for help. postgres=# CREATE LANGUAGE plperl; ERROR: could not load library /opt/PostgreSQL/9.3/lib/postgresql/plperl.so: libperl.so: cannot open shared object file: No such file or directory postgres=# CREATE LANGUAGE plpython3u; CREATE LANGUAGE postgres=# CREATE FUNCTION pyversion() RETURNS text AS $$ import sys return sys.version $$ LANGUAGE 'plpython3u'; The connection to the server was lost. Attempting reset: Failed. ! I can't reproduce that. For me, a missing plpython install results in the same kind of error message as a missing plperl install. -- 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 #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica
On Fri, Jun 7, 2013 at 6:08 AM, Federico Campoli feder...@brandwatch.comwrote:
On 06/06/13 21:22, Jeff Janes wrote:
I'd probably approach this with a combination of strace -T -ttt -p
PID and lsof -p PID on the PID of the start-up process, to see
which file descriptors it is waiting for read or writes on, and what the
underlying names of the files for those file descriptors are.
Cheers,
Jeff
I've generated a strace from the startup process a new profile report and
a new log file.
It's quite big so you can download here
http://d01.megashares.com/dl/**BqZLh5H/HS_data_lag.tarhttp://d01.megashares.com/dl/BqZLh5H/HS_data_lag.tar
I've monitored the startup process lsof and the only files accessed are
the recovering wal and the relation affected by the master's activity.
You didn't need to strace the entire operation, just a sampling for ~1
minute in the middle of it should be enough.
It looks like it is basically idle before 1370603193.846487, so I ignored
that part. Of the remaining 472 seconds covered (during which time it
replays ~19 WAL files), the sum of the system call times covers only 210
seconds, so the rest is presumably CPU time (although the error due to
rounding and instrumentation vagaries could be quite high).
Even during the active part, quite a bit of the time is still spent idle
(poll([{fd=3, events=POLLIN}], 1, 5000)). And the biggest remaining
chunk is spent on lseek(11,, but again I don't know how much to trust
that as any individual call is at the limit of measurability so it could
just be the accumulation of instrumentation errors, not real time.
zcat pg_HS_strace.out.gz | perl -lne '/([\d.]+)/ and $_
1370603193.846487 and print $1\t$_'|sort -rn|perl -lne '$sum+=$_; print
$sum\t$_' |less
zcat pg_HS_strace.out.gz | perl -lne '/ ([^,]+,).*([\d.]+)/ and $_
1370603193.846487 and $h{$1}+=$2; END {print $h{$_}\t$_ foreach keys
%h}'|sort -g
For the warm stand-by, if I cut of the uninteresting parts at the beginning
and end (1370604295.966518 and
1370605296.458290), then it applies ~33 WAL files in 1000 seconds, so it
doesn't seem to be any faster than the hot standby.
Are you sure the strace covered the events of interest?
Do you have output of vmstat or sar for the period of interest? It would
be interesting to see what the user time and wait time are.
Regarding the warm standby, I've repeated the test on my sandbox with the
slave in warm standby and I've noticed a replication lag spike.
This does not affect the production,same database version and architecture
from debian package.
I'm not sure what you are saying here. Both HS and WS lag on your test
machine, but only HS does on the production? And the straces you posted
are from the test machine?
In any case, nothing really stands out here. Other than the idle periods,
no one thing seems to be dominating the time.
Cheers,
Jeff
[BUGS] BUG #8225: logging options don't change after reload
The following bug has been logged on the website: Bug reference: 8225 Logged by: Jeff Frost Email address: j...@pgexperts.com PostgreSQL version: 9.1.8 Operating system: various Description: I've seen this a few times on client servers but still can't seem to boil it down to a nice reproducible test case. What happens is that we change various logging options in postgresql.conf, then reload, and every so often, the settings don't seem to take effect even though they are logged as being changed. Here's an example from a recent logging run: grep -hi checkpoint *.csv 2013-05-31 12:58:33.051 MDT,,,5398,,5189c940.1516,8,,2013-05-07 21:40:48 MDT,,0,LOG,0,parameter log_checkpoints changed to on, 2013-05-31 15:18:36.131 MDT,,,5398,,5189c940.1516,22,,2013-05-07 21:40:48 MDT,,0,LOG,0,parameter log_checkpoints removed from configuration file, reset to default, So, note that log_checkpoints was logged as being changed, then 2hrs 20mins later it's logged as being set back to default, but there's not a single checkpoint logged in that time period. I checked and checkpoint_timeout is indeed set to 300s. Also, in addition, we change the log_filename to datacollection-%H and while that also shows up in the log during the reload: 2013-05-31 12:58:33.051 MDT,,,5398,,5189c940.1516,9,,2013-05-07 21:40:48 MDT,,0,LOG,0,parameter log_filename changed to datacollection-%H, and the logfile is created, postgresql continues to log to the old filename for the duration of the logging run. I've seen this on recent 9.0, 9.1 and 9.2 versions. This particular run was on 9.1.8. -- 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 #8225: logging options don't change after reload
On 06/11/13 15:27, j...@pgexperts.com wrote: The following bug has been logged on the website: Bug reference: 8225 Logged by: Jeff Frost Email address: j...@pgexperts.com PostgreSQL version: 9.1.8 Operating system: various Description: I've seen this a few times on client servers but still can't seem to boil it down to a nice reproducible test case. What happens is that we change various logging options in postgresql.conf, then reload, and every so often, the settings don't seem to take effect even though they are logged as being changed. Here's an example from a recent logging run: grep -hi checkpoint *.csv 2013-05-31 12:58:33.051 MDT,,,5398,,5189c940.1516,8,,2013-05-07 21:40:48 MDT,,0,LOG,0,parameter log_checkpoints changed to on, 2013-05-31 15:18:36.131 MDT,,,5398,,5189c940.1516,22,,2013-05-07 21:40:48 MDT,,0,LOG,0,parameter log_checkpoints removed from configuration file, reset to default, So, note that log_checkpoints was logged as being changed, then 2hrs 20mins later it's logged as being set back to default, but there's not a single checkpoint logged in that time period. I checked and checkpoint_timeout is indeed set to 300s. Also, in addition, we change the log_filename to datacollection-%H and while that also shows up in the log during the reload: 2013-05-31 12:58:33.051 MDT,,,5398,,5189c940.1516,9,,2013-05-07 21:40:48 MDT,,0,LOG,0,parameter log_filename changed to datacollection-%H, and the logfile is created, postgresql continues to log to the old filename for the duration of the logging run. I've seen this on recent 9.0, 9.1 and 9.2 versions. This particular run was on 9.1.8. Oh sorry, that should specify Various linux version meaning: Ubuntu 12.04, Ubuntu 10.04, CentOS 5/6, Scientific Linux 6. -- Jeff Frost j...@pgexperts.com CTO, PostgreSQL Experts, Inc. Phone: 1-888-PG-EXPRT x506 FAX: 415-762-5122 http://www.pgexperts.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
