[HACKERS] Comment typo
This is a little patch to fix a typo in a comment. Best regards, Etsuro Fujit commentfix.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Doc typo: lexems - lexemes
On Sep 12, 2012 2:52 AM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Dan Scott wrote: I ran across a minor typo while reviewing the full-text search documentation. Attached is a patch to address the one usage of lexems in a sea of lexemes. Applied to HEAD. No back patch? Seems like a bugfix to me... /Magnus
[HACKERS] slow hashjoin - NTUP_PER_BUCKET again
Hello I try to identify of our slow queries - we have lot of queries like select count(*) from a,b where a.a = b.b; our servers has usually enough memory (we do OLAP) - we use some pooling for limiting memory expensive queries - and I found so hashjoin based queries are significantly slower than mergejoin queries. The profiler show me a most expensive function ExecScanHashBucket. When I decrease NTUP_PER_BUCKET from 10 to 3, then there was 2 times speedup of these queries. Can I expect some issue with using lower value in production? Regards Pavel Stehule -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Correction to comment regarding atomicity of an operation
On Tue, Sep 11, 2012 at 11:19 PM, Amit Kapila amit.kap...@huawei.comwrote: On Wednesday, September 12, 2012 5:33 AM Gurjeet Singh wrote: ** ** ** ** This comment in UpdateFullPageWrites() seems to be inaccurate: * It's safe to check the shared full_page_writes without the lock, * because we assume that there is no concurrently running process which * can update it. That assumption does not hold on any sane SMP system. Do you able to see any case where it can be updated when being accessed here. Now that I looked again, I don't see this being called by anyone other than Checkpointer or the Startup process (StartupXLOG()). This stack seemed like it could be called by multiple backend processes at the same time: UpdateFullPageWrites() UpdateSharedMemoryConfig() CheckpointWriteDelay() But looking closely, CheckpointWriteDelay() has this check at the beginning: if (!AmCheckpointerProcess()) return; which stops normal backends from calling UpdateFullPageWrites(). All this is not obvious from the comments in UpdateFullPageWrites(), but the comments for XLogCtlInsert.fullPageWrites make it clear that this shared variable is changed only by the Checkpointer. Thinking a bit more about the need for locks, I guess even the shared variables whose read/write ops are considered atomic need to be protected by locks so that the effects of NUMA architectures can be mitigated. Best regards, -- Gurjeet Singh http://gurjeet.singh.im/
Re: [HACKERS] Issue observed in cascade standby setup and analysis for same
On Friday, September 07, 2012 8:24 PM Amit Kapila wrote: On Thursday, September 06, 2012 9:58 PM Josh Berkus wrote: On 9/6/12 7:06 AM, Amit Kapila wrote: 1.Set up postgresql-9.2beta2 on all hosts. Did you retest this with 9.2rc1? Beta2 was a while ago Tested in 9.2rc1, the problem occurs incase I use database and backup of 9.2 Beta2. However when created fresh database and backup, it doesn't occur. This problem doesn't occur every time, so I will try more to reproduce it on 9.2 RC1 database as well. According to my analysis, this defect is not apparently visible in 9.2RC1 due to commit b8b69d89905e04b910bcd65efce1791477b45d35 by Tom. This can be visible in 9.2RC1 as well if checkpoint interval is long. So the conclusion point is on cascaded standby, the clients will not be allowed to connect till the Checkpoint interval of master incase there is no activity on master. So according to my analysis this defect still holds for 9.2RC1 as well and I shall raise a bug for it. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Doc typo: lexems - lexemes
Magnus Hagander wrote: Kevin Grittner wrote: Dan Scott wrote: I ran across a minor typo while reviewing the full-text search documentation. Attached is a patch to address the one usage of lexems in a sea of lexemes. Applied to HEAD. No back patch? Seems like a bugfix to me... I thought that minor changes to the docs were not back-patched. Did I misunderstand that or is there an exception for spelling corrections? I'm happy to follow any policy we have, but I guess I'm not clear enough what that is. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Doc typo: lexems - lexemes
On Sep 12, 2012 2:00 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Magnus Hagander wrote: Kevin Grittner wrote: Dan Scott wrote: I ran across a minor typo while reviewing the full-text search documentation. Attached is a patch to address the one usage of lexems in a sea of lexemes. Applied to HEAD. No back patch? Seems like a bugfix to me... I thought that minor changes to the docs were not back-patched. Did I misunderstand that or is there an exception for spelling corrections? I'm happy to follow any policy we have, but I guess I'm not clear enough what that is. I don't think there is a well covering policy. I'd treat it like a user facing message in the code, for example. Would you back patch the same thing if it was in an ereport? If so, I'd back patch it in the docs. It's docs that people are going to be referring to for years to come.. And the effort is close to zero to back patch it. If it was more complex, I'd think twice about it. /Magnus
Re: [HACKERS] Doc typo: lexems - lexemes
Magnus Hagander wrote: Kevin Grittner wrote: I'd back patch it in the docs. It's docs that people are going to be referring to for years to come.. And the effort is close to zero to back patch it. If it was more complex, I'd think twice about it. OK, done. Back-patched to 9.1 where the typo first appeared. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Doc typo: lexems - lexemes
On Wed, Sep 12, 2012 at 02:23:50PM +0200, Magnus Hagander wrote: On Sep 12, 2012 2:00 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Magnus Hagander wrote: Kevin Grittner wrote: Dan Scott wrote: I ran across a minor typo while reviewing the full-text search documentation. Attached is a patch to address the one usage of lexems in a sea of lexemes. Applied to HEAD. No back patch? Seems like a bugfix to me... I thought that minor changes to the docs were not back-patched. Did I misunderstand that or is there an exception for spelling corrections? I'm happy to follow any policy we have, but I guess I'm not clear enough what that is. I don't think there is a well covering policy. I'd treat it like a user facing message in the code, for example. Would you back patch the same thing if it was in an ereport? If so, I'd back patch it in the docs. It's docs that people are going to be referring to for years to come.. And the effort is close to zero to back patch it. If it was more complex, I'd think twice about it. Magnus, are you saying we don't backpatch wording improvements, but we do backpatch spelling corrections? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Doc typo: lexems - lexemes
On Wed, 2012-09-12 at 10:00 -0400, Bruce Momjian wrote: Magnus, are you saying we don't backpatch wording improvements, but we do backpatch spelling corrections? You could argue that a spelling correction is a bug fix but a wording improvement is a new feature. (Unless the old wording is wildly confusing or inaccurate.) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Doc typo: lexems - lexemes
On Wed, Sep 12, 2012 at 10:06:15AM -0400, Peter Eisentraut wrote: On Wed, 2012-09-12 at 10:00 -0400, Bruce Momjian wrote: Magnus, are you saying we don't backpatch wording improvements, but we do backpatch spelling corrections? You could argue that a spelling correction is a bug fix but a wording improvement is a new feature. (Unless the old wording is wildly confusing or inaccurate.) OK, that's what I thought. Just clarifying. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] missing semicolon at end of psql files
I was surprised to find that psql -f file.sql with a file such as this select 1; select 2 executes both commands even though the second one is not terminated. I realize that this is inconsistently handled throughout the system, for example libpq APIs don't care about the missing semicolon, but interactive psql does. But what bothered me about this is that if a file gets truncated by accident, there could be an unqualified DELETE or something similar at the end. Comments? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] git author vs committer
A while ago I wanted to cherry-pick a patch from master to a back-branch that was initially committed by someone else. That was rejected because our git server requires author==committer. I don't think that restriction is particularly useful and should be lifted. I'm not saying we should let anyone be an author, but within the pool of committers, I think we should let the mechanics of the git tools determine these fields. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 9.2 bug? variable not found in subplan target list
See test case at: http://titus.apartia.fr/stuff/pg_92_error_sql.txt Works fine on 9.1 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git author vs committer
Excerpts from Peter Eisentraut's message of mié sep 12 11:21:36 -0300 2012: A while ago I wanted to cherry-pick a patch from master to a back-branch that was initially committed by someone else. That was rejected because our git server requires author==committer. I don't think that restriction is particularly useful and should be lifted. I'm not saying we should let anyone be an author, but within the pool of committers, I think we should let the mechanics of the git tools determine these fields. +1. I had the same problem. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.2 bug? variable not found in subplan target list
On 09/12/2012 07:36 AM, Louis-David Mitterrand wrote: See test case at: http://titus.apartia.fr/stuff/pg_92_error_sql.txt Works fine on 9.1 I cannot absolutely say it is a bug as I haven't yet reviewed the relevant release notes but I can confirm that I also see your test-case working on 9.1 and failing on 9.2. Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] docs bug
It looks like commit 09ff76fcdb275769ac4d1a45a67416735613d04b that changed the name of pg_constraint.conisonly to connoinherit neglected to change the System Catalog docs :-( cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git author vs committer
On Wed, Sep 12, 2012 at 4:21 PM, Peter Eisentraut pete...@gmx.net wrote: A while ago I wanted to cherry-pick a patch from master to a back-branch that was initially committed by someone else. That was rejected because our git server requires author==committer. I don't think that restriction is particularly useful and should be lifted. I'm not saying we should let anyone be an author, but within the pool of committers, I think we should let the mechanics of the git tools determine these fields. Just to be clear, what you're saying is we want to change the policy that says committer must be on list of approved committers commiter==author to committer must be on list of approved committers author must be on list of approved committers? Assuming that's what you meant, there is no support for that in the scripts now, but if we agree that's a good thing it should be trivial to add it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 9.2 bug? variable not found in subplan target list
Louis-David Mitterrand vindex+lists-pgsql-hack...@apartia.org writes: See test case at: http://titus.apartia.fr/stuff/pg_92_error_sql.txt Works fine on 9.1 Thanks for the example. Looks like in commit 1bc16a946008a7cbb33a9a06a7c6765a807d7f59 I overlooked the need to twiddle the logic that computes the starting-point targetlist for window function evaluation. Will fix. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git author vs committer
Magnus Hagander mag...@hagander.net writes: Just to be clear, what you're saying is we want to change the policy that says committer must be on list of approved committers commiter==author to committer must be on list of approved committers author must be on list of approved committers? Works for me. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] missing semicolon at end of psql files
2012/9/12 Peter Eisentraut pete...@gmx.net I was surprised to find that psql -f file.sql with a file such as this select 1; select 2 executes both commands even though the second one is not terminated. I realize that this is inconsistently handled throughout the system, for example libpq APIs don't care about the missing semicolon, but interactive psql does. Furthermore, if the query string looks like ;;; the backend will return EmptyQueryResponse. But according to http://www.postgresql.org/docs/9.2/static/protocol-flow.html EmptyQueryResponse means An empty query string was recognized. But this is debatable what is meant by empty query string -- when strlen(query_string) == 0 or when the query_string does not contains any SQL command? But what bothered me about this is that if a file gets truncated by accident, there could be an unqualified DELETE or something similar at the end. Good point. The result can be disastrous. Comments? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- // Dmitriy.
Re: [HACKERS] missing semicolon at end of psql files
Peter Eisentraut pete...@gmx.net writes: I was surprised to find that psql -f file.sql with a file such as this select 1; select 2 executes both commands even though the second one is not terminated. I realize that this is inconsistently handled throughout the system, for example libpq APIs don't care about the missing semicolon, but interactive psql does. But what bothered me about this is that if a file gets truncated by accident, there could be an unqualified DELETE or something similar at the end. Comments? I'm a little dubious about changing this behavior. As you say, it's not like we're consistent about requiring semicolons everywhere, and frankly I think the argument about truncated files is specious. I've never heard of that actually happening to anybody. What would you have it do instead? Throw an error? Silently drop the last command (which would be the same thing, if nobody was paying attention to the error message)? I think the compatibility lossage from either would outweigh the benefit. Now having said that, I've occasionally wished I could *continue* a command across file boundaries. But I don't think it's worth the compatibility issues it'd create. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ossp-uuid Contrib Patch
On Mon, Sep 10, 2012 at 04:23:00PM -0700, David E. Wheeler wrote: Well given that OSSP seems to be abandon ware (no activity since July 2008), it might be time to dump it in favor of something else. Perhaps this would be a good time to bring up my uuid code again. I've got a module for uuid support for postgres. Originally written for 8.4 but I've kept it updated. It's available at https://pd.if.org/git/uuid.git and for anonymous git cloning git clone https://pd.f.org/git/uuid The install directions are perhaps a bit lacking, but after the git checkout: cd uuid make cd postgres make sudo make install psql -c 'create extension pduuid' Installing to different schemas is supported also. The postgres/README file describes the supported features. Briefly, my code supports uuid generation of version 1, 3, 4, and 5 uuids, casting to and from numeric, bit string, and bytea values, and provides a uuid_recent() function to get the most recent uuid generated in that backend. The code is entirely in the public domain. At one point, it compiled on Windows and MacOS, but I haven't tested that recently. I don't think I have changed anything that would affect compiling on those platforms. IIRC, the only platform dependent code is in figuring out a local mac address and a sub-second timestamp. Comments or suggestions welcome. -- nw -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Correction to comment regarding atomicity of an operation
On Wed, Sep 12, 2012 at 06:44:37AM -0400, Gurjeet Singh wrote: Thinking a bit more about the need for locks, I guess even the shared variables whose read/write ops are considered atomic need to be protected by locks so that the effects of NUMA architectures can be mitigated. src/backend/storage/lmgr/README.barrier has nice coverage of such issues. NUMA does not change the picture. CPU architecture specifications define ordering constraints for instructions that touch memory. NUMA is a property of specific system implementations that changes performance characteristics, but not functional guarantees, of those instructions. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Correction to comment regarding atomicity of an operation
On Wed, Sep 12, 2012 at 4:08 PM, Noah Misch n...@leadboat.com wrote: On Wed, Sep 12, 2012 at 06:44:37AM -0400, Gurjeet Singh wrote: Thinking a bit more about the need for locks, I guess even the shared variables whose read/write ops are considered atomic need to be protected by locks so that the effects of NUMA architectures can be mitigated. src/backend/storage/lmgr/README.barrier has nice coverage of such issues. NUMA does not change the picture. CPU architecture specifications define ordering constraints for instructions that touch memory. NUMA is a property of specific system implementations that changes performance characteristics, but not functional guarantees, of those instructions. I read-up a bit more on the topic, and it seems that the pure NUMA based machines have never been sold in the market, quite possibly because of the difficulty to write programs for them. The NUMA machines in use are effectively ccNUMA (cc for cache-coherent). So when people talk about NUMA (like, I think you are doing above), they mean the ccNUMA. So, based on what little I know about it, I think there are differences between functional guarantees provided by ccNUMA and those provided by non-ccNUMA (regular NUMA). I may be totally off here, so please correct me if needed. http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access#Cache_coherent_NUMA_.28ccNUMA.29 -- Gurjeet Singh http://gurjeet.singh.im/
Re: [HACKERS] [GENERAL] Estimated rows question
On Sat, Sep 1, 2012 at 8:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: [ sorry for slow response, but I'd not gotten time to think about this... ] Sam Ross ellip...@gmail.com writes: I was wondering why it seems that the query planner can't see, based on the histograms, that two join-columns have a very small intersection, and adjust its row estimation accordingly. The reason why not is that eqjoinsel() doesn't take any such consideration into account. It's possible that it'd be a good idea to teach it to do so. I'm not entirely convinced though. It would add a fair amount of expense to that function, as well as adding some possibly shaky assumptions, and I'm not sure how often we'd get a usefully-better estimate in practice. OTOH, there are a lot of shaky assumptions in eqjoinsel() already, and we did decide this was worth worrying about in mergejoin cost estimation. Do you want to try it and submit a patch for testing? regards, tom lane Thanks for the answer, and sorry for the slow reply - I'm not sure I have the necessary expertise, but I'll be happy to give it a shot. Is there an already-assembled library of queries that is used to test purported improvements to the planner, or is it expected that I come up with a convincing test-set myself? Sam -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] Estimated rows question
Sam Ross ellip...@gmail.com writes: On Sat, Sep 1, 2012 at 8:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Do you want to try it and submit a patch for testing? Thanks for the answer, and sorry for the slow reply - I'm not sure I have the necessary expertise, but I'll be happy to give it a shot. Is there an already-assembled library of queries that is used to test purported improvements to the planner, or is it expected that I come up with a convincing test-set myself? No, we don't really have much in that line :-(. There's the regression tests of course, but they're mostly about functionality not quality of statistical estimates. In practice, as long as a proposed change made the estimates demonstrably better in some reasonable scenarios, and didn't slow it down very much, that would probably be enough. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] Estimated rows question
On Wed, Sep 12, 2012 at 07:19:06PM -0400, Tom Lane wrote: Sam Ross ellip...@gmail.com writes: On Sat, Sep 1, 2012 at 8:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: Do you want to try it and submit a patch for testing? Thanks for the answer, and sorry for the slow reply - I'm not sure I have the necessary expertise, but I'll be happy to give it a shot. Is there an already-assembled library of queries that is used to test purported improvements to the planner, or is it expected that I come up with a convincing test-set myself? No, we don't really have much in that line :-(. Does anyone? If so, who? Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] git author vs committer
On Wed, 2012-09-12 at 19:13 +0200, Magnus Hagander wrote: Just to be clear, what you're saying is we want to change the policy that says committer must be on list of approved committers commiter==author to committer must be on list of approved committers author must be on list of approved committers? Yes, that would be my request. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] missing semicolon at end of psql files
On Wed, 2012-09-12 at 17:20 +0300, Heikki Linnakangas wrote: On 12.09.2012 17:10, Peter Eisentraut wrote: I was surprised to find that psql -f file.sql with a file such as this select 1; select 2 executes both commands even though the second one is not terminated. I realize that this is inconsistently handled throughout the system, for example libpq APIs don't care about the missing semicolon, but interactive psql does. Even interactive psql doesn't require a semicolon at the end; it's just that without it, it doesn't know whether you're still adding to the command or if it's finished. But you can also use \g: ostgres=# select 1 postgres-# \g ?column? -- 1 (1 row) A \g is equivalent to a semicolon, at least as far as saying, execute this command now. Note that postgres=# select 1 postgres-# press Ctrl-D here does not execute the command before quitting. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comment typo
Etsuro Fujita wrote: This is a little patch to fix a typo in a comment. Applied to HEAD and 9.2, which as far back as it went. I figured it was easy and eliminated any back-patch issues for subsequent changes. Thanks! -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Comment typo
Thanks! Best regards, Etsuro Fujita -Original Message- From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kevin Grittner Sent: Thursday, September 13, 2012 12:40 PM To: fujita.ets...@lab.ntt.co.jp; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Comment typo Etsuro Fujita wrote: This is a little patch to fix a typo in a comment. Applied to HEAD and 9.2, which as far back as it went. I figured it was easy and eliminated any back-patch issues for subsequent changes. Thanks! -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
On Wednesday, September 12, 2012 10:15 PM Fujii Masao On Wed, Sep 12, 2012 at 8:54 PM, amit.kap...@huawei.com wrote: The following bug has been logged on the website: Bug reference: 7534 Logged by: Amit Kapila Email address: amit.kap...@huawei.com PostgreSQL version: 9.2.0 Operating system: Suse 10 Description: 1. Both master and standby machine are connected normally, 2. then you use the command: ifconfig ip down; make the network card of master and standby down, Observation master can detect connect abnormal, but the standby can't detect connect abnormal and show a connected channel long time. What about setting keepalives_xxx libpq parameters? http://www.postgresql.org/docs/devel/static/libpq-connect.html#LIBPQ-PARAMKE YWORDS Keepalives are not a perfect solution for the termination of connection, but it would help to a certain extent. We have tried by enabling keepalive, but it didn't worked maybe because walreceiver is trying to send reveiver status. It fails in sending that after many attempts of same. If you need something like walreceiver-version of replication_timeout, such feature has not been implemented yet. Please feel free to implement that! I would like to implement such feature for walreceiver, but there is one confusion that whether to use same configuration parameter(replication_timeout) for walrecevier as for master or introduce a new configuration parameter (receiver_replication_timeout). The only point in having different timeout parameters for walsender and walreceiver is for the case of standby which has both walsender and walreceiver to send logs to cascaded standby, in such case somebody might want to have different timeout parameters for walsender and walreceiver. OTOH it will create confusion to have too many parameters. My opinion is to have one timeout parameter for both walsender and walrecevier. Let me know your suggestion/opinion about same. Note- I am marking cc to pgsql-hackers, as it will be a feature request. With Regards, Amit Kapila. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
