Re: [BUGS] [SQL] pg_dump: aborting because of server version mismatch

On 05/02/2012 12:55 PM, Mitesh Shah wrote: Hi, I am trying to create a daily backup cron script but it fails with an error as below: Any pointers to resolve this will be greatly appreciated. Thanks, Mitesh Shah mitesh.s...@stripes39.com *(1) Error:* bash-3.2$

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

Simon Riggs writes: > OK, I agree. I still think this is about solving a non-problem. > The implementation I would prefer would be to put the check in > START_CRIT_SECTION(); so we actually fail before we enter the section. ... and this is proposing adding significant overhead to solve a non-pr

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

On 11 May 2012 17:48, Heikki Linnakangas wrote: > On 11.05.2012 18:18, Simon Riggs wrote: >> >> On 11 May 2012 15:14, Heikki Linnakangas >>  wrote: >>> >>> On 11.05.2012 16:56, Simon Riggs wrote: On 11 May 2012 11:07, Heikki Linnakangas    wrote: > I wonder if we sho

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

On 11.05.2012 18:18, Simon Riggs wrote: On 11 May 2012 15:14, Heikki Linnakangas wrote: On 11.05.2012 16:56, Simon Riggs wrote: On 11 May 2012 11:07, Heikki Linnakangas wrote: I wonder if we should reserve a few of the lwlock "slots" for critical sections, to make this less likely to h

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

On 11 May 2012 15:14, Heikki Linnakangas wrote: > On 11.05.2012 16:56, Simon Riggs wrote: >> >> On 11 May 2012 11:07, Heikki Linnakangas >>  wrote: >> >>> I wonder if we should reserve a few of the lwlock "slots" for critical >>> sections, to make this less likely to happen. Not only in this case

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

On Fri, May 11, 2012 at 10:19 AM, Tom Lane wrote: > Heikki Linnakangas writes: >> On 11.05.2012 16:52, Tom Lane wrote: >>> IMO, no part of the system should ever get within an order of magnitude >>> of holding 100 LWLocks concurrently. > >> I agree we should never get anywhere near that limit. Bu

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

Heikki Linnakangas writes: > On 11.05.2012 16:52, Tom Lane wrote: >> IMO, no part of the system should ever get within an order of magnitude >> of holding 100 LWLocks concurrently. > I agree we should never get anywhere near that limit. But if we do - > because of another bug like this one - it

Re: [BUGS] BUG #6624: Tab completion of identifier containing single backslash triggers warnings

On Thu, May 10, 2012 at 9:50 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 2, 2012 at 6:29 PM, Tom Lane wrote: >>> The only way we could suppress such warnings would be if we made >>> tab-complete.c use E'' strings for literals containing name prefixes; >>> which is perhaps doable but

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

On 11.05.2012 16:56, Simon Riggs wrote: On 11 May 2012 11:07, Heikki Linnakangas wrote: I wonder if we should reserve a few of the lwlock "slots" for critical sections, to make this less likely to happen. Not only in this case, but in general. We haven't seen this problem often, but it would

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

On 11.05.2012 16:52, Tom Lane wrote: Heikki Linnakangas writes: I wonder if we should reserve a few of the lwlock "slots" for critical sections, to make this less likely to happen. Not only in this case, but in general. We haven't seen this problem often, but it would be quite trivial to reserv

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

On 11 May 2012 11:07, Heikki Linnakangas wrote: > I wonder if we should reserve a few of the lwlock "slots" for critical > sections, to make this less likely to happen. Not only in this case, but in > general. We haven't seen this problem often, but it would be quite trivial > to reserve a few sl

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

Heikki Linnakangas writes: > I wonder if we should reserve a few of the lwlock "slots" for critical > sections, to make this less likely to happen. Not only in this case, but > in general. We haven't seen this problem often, but it would be quite > trivial to reserve a few slots. I'm against t

Re: [BUGS] BUG #6635: TRUNCATE didn't recreate init fork.

On Thu, May 10, 2012 at 1:32 AM, wrote: > When I executed TRUNCATE command to unlogged table, > init fork of new relfilenode (include toast) wasn't created. Fixed, thanks for the report! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pg

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

On 08.05.2012 04:15, Ryan Kelly wrote: On Mon, May 07, 2012 at 05:31:40PM +0100, tom Tom wrote: Nope, this was just a benchmark script that caused this, any sane person would use an intbig index instead I guess. A better error message would be nice though, I was pretty confused when this happene

Re: [BUGS] BUG #6629: Creating a gist index fails with "too many LWLocks taken"

On 07.05.2012 18:51, Tom Lane wrote: Heikki Linnakangas writes: We could rearrange the page splitting algorithm to release locks earlier, before traversing to the next parent level. That seems like a good idea just on concurrency grounds; I'm worried about both the performance implications an