On 08.06.2011 06:37, Kevin Grittner wrote:
You're right; that one was a false alarm. While REINDEX was reading
the heap to build the index it got an SIREAD lock on a *heap* page.
We never take locks on heap pages directly, so it must've been a
promotion from heap tuple locks.
While that co
On Wed, Feb 16, 2011 at 11:02 PM, Robert Haas wrote:
> I've been thinking about the problem of $SUBJECT, and while I know
> it's too early to think seriously about any 9.2 development, I want to
> get my thoughts down in writing while they're fresh in my head.
>
> It seems to me that there are two
On Thu, May 26, 2011 at 4:10 PM, Pavan Deolasee
wrote:
>
> So are there any other objections/suggestions ? Anyone else cares to
> look at the brief design that we discussed above ? Otherwise, I would
> go ahead and work on this in the coming days. Of course, I will keep
> the list posted about an
Robert Creager writes:
> On Jun 7, 2011, at 3:01 PM, Tom Lane wrote:
>> Robert Creager writes:
>> configure:7158: checking for flags to link embedded Perl
>> configure:7174: result: -L/usr/local/lib
>> -L/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE -lperl -ldl
>> -lm -lutil -lc
Excerpts from Kevin Grittner's message of mar jun 07 20:45:43 -0400 2011:
> During testing of the SSI DDL changes I noticed that a REINDEX INDEX
> created a predicate lock on page 0 of the index.
Err, in a btree, page 0 is the metapage, not the root. The root page
moves around, but it's never pag
Bruce Momjian writes:
> Simon is right that we slipped the vxid patch into 8.3 when a Postgres
> user I talked to at Linuxworld mentioned high vacuum freeze activity and
> simple calculations showed the many read-only queries could cause high
> xid usage. Fortunately we already had a patch availa
Bruce Momjian wrote:
> Simon is right that we slipped the vxid patch into 8.3 when a Postgres
> user I talked to at Linuxworld mentioned high vacuum freeze activity and
> simple calculations showed the many read-only queries could cause high
> xid usage. Fortunately we already had a patch availabl
Robert Haas wrote:
> On Mon, Jun 6, 2011 at 10:49 AM, Simon Riggs wrote:
> > My point was that we have in the past implemented performance changes
> > to increase scalability at the last minute, and also that our personal
> > risk perspectives are not always set in stone.
> >
> > Robert has highli
Dan Ports wrote:
> On Tue, Jun 07, 2011 at 07:45:43PM -0500, Kevin Grittner wrote:
>> During testing of the SSI DDL changes I noticed that a REINDEX
>> INDEX created a predicate lock on page 0 of the index.
>
> Really? That surprises me, and I couldn't reproduce it just now.
You're right; tha
On Tue, Jun 07, 2011 at 07:45:43PM -0500, Kevin Grittner wrote:
> During testing of the SSI DDL changes I noticed that a REINDEX INDEX
> created a predicate lock on page 0 of the index.
Really? That surprises me, and I couldn't reproduce it just now.
Dan
--
Dan R. K. Ports MIT CSAI
On Tue, Jun 7, 2011 at 9:54 PM, Simon Riggs wrote:
> On Tue, Jun 7, 2011 at 1:24 PM, Robert Haas wrote:
>
>> One other thought is that I think that this patch might cause a
>> user-visible behavior change. Right now, when you hit the end of
>> recovery, you most typically get a message saying -
"Kevin Grittner" writes:
> During testing of the SSI DDL changes I noticed that a REINDEX INDEX
> created a predicate lock on page 0 of the index. This is pretty
> harmless, but mildly annoying. There are a few other places where
> it would be good to suppress predicate locks; these are listed o
On Tue, Jun 7, 2011 at 9:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane wrote:
>>> Note that I changed coerce_type's behavior for both ANYARRAY and ANYENUM
>>> targets, but the latter behavioral change is unreachable since the other
>>> routines in parse
Robert Haas writes:
> On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane wrote:
>> Note that I changed coerce_type's behavior for both ANYARRAY and ANYENUM
>> targets, but the latter behavioral change is unreachable since the other
>> routines in parse_coerce.c will not match a domain-over-enum to ANYENUM.
Excerpts from Robert Haas's message of mar jun 07 13:53:23 -0400 2011:
> On Tue, Jun 7, 2011 at 1:45 PM, Thom Brown wrote:
> > Speaking of which, is it now safe to remove the "NOT VALID constraints
> > don't dump properly" issue from the blocker list since the fix has
> > been committed?
>
> I ho
2011/6/7 Jeevan Chalke :
> since we smash the identifier to lower case using
> downcase_truncate_identifier() function, the solution is to make this
> function should be wide-char aware, like LOWER() function functionality.
>
> I see some discussion related to downcase_truncate_identifier() and
> w
On Tue, Jun 7, 2011 at 6:28 PM, Tom Lane wrote:
> I wrote:
>> Anyway, I think we're out of time to do anything about the issue for
>> 9.1. I think what we'd better do is force a downcast in the context
>> of matching to an ANYARRAY parameter, and leave the other cases to
>> revisit later.
>
> Att
During testing of the SSI DDL changes I noticed that a REINDEX INDEX
created a predicate lock on page 0 of the index. This is pretty
harmless, but mildly annoying. There are a few other places where
it would be good to suppress predicate locks; these are listed on
the R&D section of the Wiki. I
Sorry, forgot the documentation- I guess that stuff doesn't magically
happen!
New patch attached.
Mike
From: Brar Piening [mailto:b...@gmx.de]
Sent: Tuesday, June 07, 2011 6:58 PM
To: Mike Pultz
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] smallserial / serial2
On Wed, 2
We had a report of the subject message during testing a while back
and attempted to address the issue. It can result in a LOG level
message and the accumulation of files in the pg_serial SLRU
subdirectory. We haven't seen a recurrence, until I hit it during
testing of the just-posted patch for SS
Heikki Linnakangas wrote:
> On 07.06.2011 21:10, Kevin Grittner wrote:
>> I think that leaves me with all the answers I need to get a new
>> patch out this evening (U.S. Central Time).
>
> Great, I'll review it in my morning (in about 12h)
Attached. Passes all the usual regression tests I ru
On Wed, 20 Apr 2011 21:27:27 -0400, Mike Pultz wrote:
Can this be added?
Probably not - since it's not a complete patch ;-)
I tried to test this one but was unable to find a complete version of
the patch in my local mail archives and in the official archives
(http://archives.postgresql.or
I wrote:
> Anyway, I think we're out of time to do anything about the issue for
> 9.1. I think what we'd better do is force a downcast in the context
> of matching to an ANYARRAY parameter, and leave the other cases to
> revisit later.
Attached is a draft patch to do the above. It's only lightly
On Tue, Jun 7, 2011 at 3:43 PM, Simon Riggs wrote:
> On Tue, Jun 7, 2011 at 8:24 PM, Greg Stark wrote:
>> On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs wrote:
>>> But I think you've hit the important point here. The problem is not
>>> whether VACUUM waits for the pin, its that the pins can be hel
On 6/7/11 1:11 PM, Simon Riggs wrote:
>> that appear low risk. I seriously doubt that I would consider *any*
>> > meaningful change in the locking area to be low risk.
> That's a shame. We'll fix it in 9.2 then.
I will point out that we bounced Alvaro's FK patch, which *was*
submitted in time for
On Tue, Jun 7, 2011 at 5:43 PM, Simon Riggs wrote:
> On Tue, Jun 7, 2011 at 9:52 PM, Robert Haas wrote:
>> If we were to fix ONLY the vxid issue in 9.1 as you were advocating
>
> Sensible debate is impossible when you don't read what I've written.
I've read every word you've written on this thre
Excerpts from Tom Lane's message of mar jun 07 14:22:13 -0400 2011:
> Alex Hunsaker writes:
> > Im looking at the "raw" perl 5.10.0 source... I wonder if apple is
> > shipping a modified version?
>
> You could find out by digging around at
> http://www.opensource.apple.com/
> polecat appears to b
On Tue, Jun 7, 2011 at 9:52 PM, Robert Haas wrote:
> If we were to fix ONLY the vxid issue in 9.1 as you were advocating
Sensible debate is impossible when you don't read what I've written.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Tra
Robert Creager writes:
>>> Another question worth asking here is whether PG is picking up perl
>>> 5.10.0 or 5.8.9, both of which are shipped in this OSX release.
> Hmm... This might be a problem:
> which perl
> /opt/local/bin/perl
> type -a perl
> /opt/local/bin/perl
> /usr/bin/perl
> /opt/l
On Tue, Jun 7, 2011 at 12:51 PM, Simon Riggs wrote:
> Stefan/Robert's observation that we perform a
> VirtualXactLockTableInsert() to no real benefit is a good one.
>
> It leads to the following simple patch to remove one lock table hit
> per transaction. It's a lot smaller impact on the LockMgr l
Greg Stark writes:
> On Mon, Jun 6, 2011 at 9:14 PM, Tom Lane wrote:
>> The most workable alternative that I can see is to lobotomize citext so
>> that it always does lower-casing according to the database's "default"
>> collation, which would allow us to pretend that its notion of equality
>> is
On Tue, Jun 7, 2011 at 9:00 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Moving on from that, I have proposed other solutions. Koichi, Jignesh
>> and and then Robert have shown measurements of the huge contention in
>> this area of our software. Robert's patch addresses the problems, as
>> do Koi
On Tue, Jun 7, 2011 at 3:44 PM, Jignesh Shah wrote:
> On Mon, Jun 6, 2011 at 11:20 PM, Jignesh Shah wrote:
>> Okay I tried it out with sysbench read scaling test..
>> Note I had tried that earlier on 9.0
>> http://jkshah.blogspot.com/2010/11/postgresql-90-simple-select-scaling.html
>>
>> And on t
Simon Riggs writes:
> Moving on from that, I have proposed other solutions. Koichi, Jignesh
> and and then Robert have shown measurements of the huge contention in
> this area of our software. Robert's patch addresses the problems, as
> do Koichi's and my latest patch. I would like to see us do
>
On Tue, Jun 7, 2011 at 7:55 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Before you arrived, it was quite normal to suggest tuning patches
>> after feature freeze.
>
> *Low risk* tuning patches make sense at this stage, yes. Fooling with
> the lock mechanisms doesn't qualify as low risk in my bo
On Mon, Jun 6, 2011 at 9:14 PM, Tom Lane wrote:
> The most workable alternative that I can see is to lobotomize citext so
> that it always does lower-casing according to the database's "default"
> collation, which would allow us to pretend that its notion of equality
> is not collation-sensitive a
Robert Haas writes:
> I plead guilty to taking my eye off the ball post-beta1. I busted my
> ass for two months stabilizing other people's code after CF4 was over,
> and then I moved on to other things. I will try to get my eye back on
> the ball - but actually I'm not sure there's all that much
On Tue, Jun 7, 2011 at 8:24 PM, Greg Stark wrote:
> On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs wrote:
>> But I think you've hit the important point here. The problem is not
>> whether VACUUM waits for the pin, its that the pins can be held for
>> extended periods.
>
> Yes
>
>> It makes more sen
On Mon, Jun 6, 2011 at 11:20 PM, Jignesh Shah wrote:
>
> Okay I tried it out with sysbench read scaling test..
> Note I had tried that earlier on 9.0
> http://jkshah.blogspot.com/2010/11/postgresql-90-simple-select-scaling.html
>
> And on that test I found that doing that test on anything bigger
On 06/05/2011 08:50 AM, Mitsuru IWASAKI wrote:
It seems that I don't have enough time to complete this work.
You don't need to keep cc'ing me, and I'm very happy if postgres to be
the first DBMS which support buffer cache hibernation feature.
Thanks for submitting the patch, and we'll see w
On Mon, Jun 6, 2011 at 11:30 PM, Simon Riggs wrote:
> But I think you've hit the important point here. The problem is not
> whether VACUUM waits for the pin, its that the pins can be held for
> extended periods.
Yes
> It makes more sense to try to limit pin hold times than it does to
> come up w
Simon Riggs writes:
> Before you arrived, it was quite normal to suggest tuning patches
> after feature freeze.
*Low risk* tuning patches make sense at this stage, yes. Fooling with
the lock mechanisms doesn't qualify as low risk in my book. The
probability of undetected subtle problems is just
On Tue, Jun 7, 2011 at 2:06 PM, Simon Riggs wrote:
> On Tue, Jun 7, 2011 at 6:33 PM, Robert Haas wrote:
>> On Tue, Jun 7, 2011 at 1:27 PM, Joshua Berkus wrote:
>>> As long as we have solidarity of the committers that this is not allowed,
>>> however, this is not a real problem. And it appears
On 06/07/2011 02:22 PM, Tom Lane wrote:
Alex Hunsaker writes:
Im looking at the "raw" perl 5.10.0 source... I wonder if apple is
shipping a modified version?
You could find out by digging around at
http://www.opensource.apple.com/
polecat appears to be running OSX 10.6.7, so this is what you
On Tue, Jun 7, 2011 at 12:22, Tom Lane wrote:
> Alex Hunsaker writes:
>> Im looking at the "raw" perl 5.10.0 source... I wonder if apple is
>> shipping a modified version?
>
> You could find out by digging around at
> http://www.opensource.apple.com/
> polecat appears to be running OSX 10.6.7, so
Simon Riggs wrote:
> Before you arrived, it was quite normal to suggest tuning patches
> after feature freeze.
I've worn a lot of hats in the practical end of this industry, and
regardless of which perspective I look at this from, I can't think
of anything so destructive to productivity, devel
Jeff Davis wrote:
On Mon, 2011-06-06 at 14:42 -0700, Darren Duncan wrote:
Can Pg be changed to support "." in operator names as long as they don't just
appear by themselves? What would this break to do so?
Someone else would have to comment on that. My feeling is that it might
create problems
On 07.06.2011 21:10, Kevin Grittner wrote:
I think that leaves me
with all the answers I need to get a new patch out this evening
(U.S. Central Time).
Great, I'll review it in my morning (in about 12h)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hack
Jeff Davis wrote:
On Tue, 2011-06-07 at 11:15 -0400, Tom Lane wrote:
Merlin Moncure writes:
right. hm -- can you have multiple range type definitions for a
particular type?
In principle, sure, if the type has multiple useful sort orderings.
Right. Additionally, you might want to use differe
* Simon Riggs (si...@2ndquadrant.com) wrote:
> Before you arrived, it was quite normal to suggest tuning patches
> after feature freeze.
I haven't been around as long as some, but I think I've been around
longer than Robert, and I can say that I don't recall serious
performance patches, particular
Alex Hunsaker writes:
> Im looking at the "raw" perl 5.10.0 source... I wonder if apple is
> shipping a modified version?
You could find out by digging around at
http://www.opensource.apple.com/
polecat appears to be running OSX 10.6.7, so this is what you want:
http://www.opensource.apple.com/ta
Tom Lane wrote:
> Just to answer the question (independently of Heikki's concern
> about whether this is needed at all): it depends on the
> information you have. If all you have is the index OID, then yeah
> a catcache lookup in pg_index is probably the best thing. If you
> have an open Relati
On Tue, Jun 7, 2011 at 11:48, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Mon, Jun 6, 2011 at 21:16, Robert Creager
>> wrote:
>>> (gdb) bt
>>> #0 0x000100a505e4 in Perl_get_hash_seed ()
>>> #1 0x000100a69b94 in perl_parse ()
>
>> I don't suppose /dev/urandom blocks on OS X?
>
> The
Heikki Linnakangas wrote:
> Predicate locks on indexes are only needed to lock key ranges, to
> notice later insertions into the range, right? For locks on tuples
> that do exist, we have locks on the heap. If we're just about to
> delete every tuple in the heap, that doesn't need to conflict wi
"Kevin Grittner" writes:
> I think I've caught up with the rest of the class on why this isn't
> sane in DropAllPredicateLocksFromTableImpl, but I wonder about
> CheckTableForSerializableConflictIn. We *do* expect to be throwing
> errors in here, and we need some way to tell whether an index is
>
On Tue, Jun 7, 2011 at 6:33 PM, Robert Haas wrote:
> On Tue, Jun 7, 2011 at 1:27 PM, Joshua Berkus wrote:
>> As long as we have solidarity of the committers that this is not allowed,
>> however, this is not a real problem. And it appears that we do. In the
>> future, it shouldn't even be nece
On 07.06.2011 20:42, Kevin Grittner wrote:
Heikki Linnakangas wrote:
It makes me a bit uncomfortable to do catalog cache lookups while
holding all the lwlocks.
I think I've caught up with the rest of the class on why this isn't
sane in DropAllPredicateLocksFromTableImpl, but I wonder about
C
Jeff Davis writes:
> On Mon, 2011-06-06 at 14:42 -0700, Darren Duncan wrote:
>> Can Pg be changed to support "." in operator names as long as they don't
>> just
>> appear by themselves? What would this break to do so?
> Someone else would have to comment on that.
DOT_DOT is already a token in
Robert Haas writes:
> On Tue, Jun 7, 2011 at 1:27 PM, Joshua Berkus wrote:
>> As long as we have solidarity of the committers that this is not allowed,
>> however, this is not a real problem. And it appears that we do. In the
>> future, it shouldn't even be necessary to discuss it.
> Solidar
On Tue, Jun 7, 2011 at 1:45 PM, Thom Brown wrote:
> Speaking of which, is it now safe to remove the "NOT VALID constraints
> don't dump properly" issue from the blocker list since the fix has
> been committed?
I hope so, because I just did that (before noticing this email from you).
--
Robert H
On Tue, Jun 7, 2011 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I think at the next developer meeting we're going to
>> get to hear Tom argue that overlapping the end of beta with the
>> beginning of the next release cycle is a mistake and we should go back
>> to the old system where
On Tue, Jun 7, 2011 at 5:40 PM, Andrew Dunstan wrote:
>
>
> On 06/07/2011 01:18 PM, Alex Hunsaker wrote:
>>
>> I don't suppose /dev/urandom blocks on OS X? Granted, I may have
>> missed something in translation with the macro fest that is perl...
>
>
> I wondered if we were possibly exhausting so
Alex Hunsaker writes:
> On Mon, Jun 6, 2011 at 21:16, Robert Creager
> wrote:
>> (gdb) bt
>> #0 Â 0x000100a505e4 in Perl_get_hash_seed ()
>> #1 Â 0x000100a69b94 in perl_parse ()
> I don't suppose /dev/urandom blocks on OS X?
The man page for it avers not, and besides it's hard to belie
On Tuesday, June 07, 2011 19:40:21 Andrew Dunstan wrote:
> On 06/07/2011 01:18 PM, Alex Hunsaker wrote:
> > I don't suppose /dev/urandom blocks on OS X? Granted, I may have
> > missed something in translation with the macro fest that is perl...
>
> I wondered if we were possibly exhausting some e
On 7 June 2011 19:32, Tom Lane wrote:
> Joshua Berkus writes:
>> Actually, the summer is *excellent* from a publicity perspective ... at
>> least, June and July are. Both of those months are full of US conferences
>> whose PR we can piggyback on to make a splash.
>
>> August is really the only
Heikki Linnakangas wrote:
> It makes me a bit uncomfortable to do catalog cache lookups while
> holding all the lwlocks.
I think I've caught up with the rest of the class on why this isn't
sane in DropAllPredicateLocksFromTableImpl, but I wonder about
CheckTableForSerializableConflictIn. We
On 06/07/2011 01:18 PM, Alex Hunsaker wrote:
I don't suppose /dev/urandom blocks on OS X? Granted, I may have
missed something in translation with the macro fest that is perl...
I wondered if we were possibly exhausting some entropy pool. It seems
like this would be just such a bad bug th
On Tue, Jun 7, 2011 at 1:27 PM, Joshua Berkus wrote:
> As long as we have solidarity of the committers that this is not allowed,
> however, this is not a real problem. And it appears that we do. In the
> future, it shouldn't even be necessary to discuss it.
Solidarity?
Simon - who was a comm
Joshua Berkus writes:
> Actually, the summer is *excellent* from a publicity perspective ... at
> least, June and July are. Both of those months are full of US conferences
> whose PR we can piggyback on to make a splash.
> August is really the only "bad" month from a PR perspective, because we
On Mon, 2011-06-06 at 14:42 -0700, Darren Duncan wrote:
> On this note, here's a *big* thing that needs discussion ...
[ refering to the concept of "discrete" versus "continuous" ranges ]
Yes, there has been much discussion on this topic already.
The solution right now is that they both behave l
Robert,
> Oh, I get that. I'm just dismayed that we can't have a discussion
> about the patch without getting sidetracked into a conversation about
> whether we should throw feature freeze out the window.
That's not something you can change. Whatever the patch is, even if it's a
psql improveme
Robert Haas writes:
> ... I think at the next developer meeting we're going to
> get to hear Tom argue that overlapping the end of beta with the
> beginning of the next release cycle is a mistake and we should go back
> to the old system where we yell at everyone to shut up unless they're
> helpin
> iew. The
> reason we usually skip the summer isn't actually a wholesale lack of
> people - it's because it's not so good from a publicity perspective,
> and it's hard to get all the packagers around at the same time.
Actually, the summer is *excellent* from a publicity perspective ... at least,
On Tue, 2011-06-07 at 11:15 -0400, Tom Lane wrote:
> Merlin Moncure writes:
> > right. hm -- can you have multiple range type definitions for a
> > particular type?
>
> In principle, sure, if the type has multiple useful sort orderings.
Right. Additionally, you might want to use different "canon
On Mon, Jun 6, 2011 at 21:16, Robert Creager wrote:
> That's weird. Why it should hang there I have no idea. Did it hang at the
> same spot both times? Can you get a backtrace?
>
> I think so, but I didn't pay much attention :-(
> GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52
Simon Riggs writes:
> Please consider this as a serious proposal for tuning in 9.1.
Look: it is at least four months too late for anything of the sort in 9.1.
We should be fixing bugs, and nothing else, if we ever want to get 9.1
out the door. Performance improvements don't qualify, especially n
On 07.06.2011 20:03, Kevin Grittner wrote:
Heikki Linnakangas wrote:
We've also already removed the reserved entry for scratch space
This and Tom's concerns have me wondering if we should bracket the
two sections of code where we use the reserved lock target entry
with HOLD_INTERRUPTS() and
Heikki Linnakangas wrote:
> We've also already removed the reserved entry for scratch space
This and Tom's concerns have me wondering if we should bracket the
two sections of code where we use the reserved lock target entry
with HOLD_INTERRUPTS() and RESUME_INTERRUPTS(). In an assert-enable
b
On Tue, Jun 7, 2011 at 11:56 AM, Joshua D. Drake wrote:
> On 06/06/2011 04:43 PM, Robert Haas wrote:
>>
>> On Mon, Jun 6, 2011 at 6:53 PM, Alvaro Herrera
>> wrote:
>>>
>>> Excerpts from Robert Haas's message of vie jun 03 09:17:08 -0400 2011:
I've now spent enough time working on this
On Tue, Jun 7, 2011 at 12:51 PM, Simon Riggs wrote:
> On Mon, Jun 6, 2011 at 8:50 PM, Dave Page wrote:
>> On Mon, Jun 6, 2011 at 8:40 PM, Stefan Kaltenbrunner
>> wrote:
>>> On 06/06/2011 09:24 PM, Dave Page wrote:
On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine
wrote:
> So, to t
On Mon, Jun 6, 2011 at 8:50 PM, Dave Page wrote:
> On Mon, Jun 6, 2011 at 8:40 PM, Stefan Kaltenbrunner
> wrote:
>> On 06/06/2011 09:24 PM, Dave Page wrote:
>>> On Mon, Jun 6, 2011 at 8:12 PM, Dimitri Fontaine
>>> wrote:
So, to the question “do we want hard deadlines?” I think the answer i
Andrew Dunstan writes:
> On 06/07/2011 12:35 AM, Tom Lane wrote:
>> You sure it's hung on that statement, and not the following one?
>> The following one would be trying to load plperlu into a backend
>> already using plperl, which is an area that it wouldn't exactly
>> be surprising to find platf
On 06/07/2011 12:35 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 06/06/2011 07:30 PM, Robert Creager wrote:
[4de65a8f.607a:3] LOG: statement: CREATE OR REPLACE FUNCTION bar() RETURNS
integer AS $$
#die 'BANG!'; # causes server process to exit(2)
# alternative - causes server process to ex
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun jun 06 12:49:46 -0400 2011:
>> Hmm, there's already a mechanism for closing "temp" FDs at the end of a
>> query ... maybe blind writes could use temp-like FDs?
> I don't think it can be made to work exactly like that. If I understa
This is the second time I've had this happen in the last week or so. I have a 'regular' postgresql server running, and then test test setup (both llvm ang gcc). It's chewing up 1 core on my MBP, never completing. 502 229 1 0 0:00.50 ?? 0:00.60 /Library/PostgreSQL/8.3/bin/postgr
On Jun 6, 2011, at 7:29 PM, Andrew Dunstan wrote:
>
>
> On 06/06/2011 07:30 PM, Robert Creager wrote:
>> [4de65a8f.607a:1] LOG: connection received: host=[local]
>> [4de65a8f.607a:2] LOG: connection authorized: user=Robert
>> database=pl_regression
>> [4de65a8f.607a:3] LOG: statement: CREAT
On Jun 3, 2011 8:38 PM, "Bruce Momjian" wrote:
>
> I realize we just read the pages from the kernel to maintain sequential
> I/O, but do we actually read the contents of the page if we know it
> doesn't need vacuuming? If so, do we need to?
I dont follow. What's your question?
Tom's final versi
On Tue, Jun 7, 2011 at 4:57 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 07.06.2011 10:55, Simon Riggs wrote:
>>> How would that help?
>
>> It doesn't matter whether the pages are zeroed while they sit in memory.
>> And if you write a full page of WAL data, any wasted bytes at the end o
Heikki Linnakangas writes:
> On 07.06.2011 10:55, Simon Riggs wrote:
>> How would that help?
> It doesn't matter whether the pages are zeroed while they sit in memory.
> And if you write a full page of WAL data, any wasted bytes at the end of
> the page don't matter, because they're ignored at
On 06/06/2011 04:43 PM, Robert Haas wrote:
On Mon, Jun 6, 2011 at 6:53 PM, Alvaro Herrera
wrote:
Excerpts from Robert Haas's message of vie jun 03 09:17:08 -0400 2011:
I've now spent enough time working on this issue now to be convinced
that the approach has merit, if we can work out the kink
On 07.06.2011 10:55, Simon Riggs wrote:
On Tue, Jun 7, 2011 at 8:27 AM, Heikki Linnakangas
wrote:
You would only need to do it just before you write out the WAL. I guess
you'd need to grab WALInsertLock in XLogWrite() to prevent more WAL records
from being inserted on the page until you're don
Tom Lane wrote:
> "Kevin Grittner" writes:
>> What am I missing?
>
> Out-of-memory. Query cancel. The attempted catalog access
> failing because it results in a detected deadlock. I could
> probably think of several more if I spent ten minutes on it; and
> that's not even considering genuin
Merlin Moncure writes:
> On Mon, Jun 6, 2011 at 6:23 PM, Tom Lane wrote:
>> By my count there are only about 20 datatypes in core for which it looks
>> sensible to provide a range type (ie, it's a non-deprecated,
>> non-composite type with a standard default btree opclass). For that
>> many, we
"Kevin Grittner" writes:
> Tom Lane wrote:
>> If you don't believe that a catcache lookup will ever fail, I will
>> contract to break the patch.
> As you probably know by now by reaching the end of the thread, this
> code is going away based on Heikki's arguments; but for my
> understanding, so
On Mon, Jun 6, 2011 at 6:23 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> I vote for at minimum the type itself and ANYRANGE to be in core.
>> From there you could make it like arrays where the range type is
>> automatically generated for each POD type. I would consider that for
>> sure on bas
Tom Lane wrote:
> If you don't believe that a catcache lookup will ever fail, I will
> contract to break the patch.
As you probably know by now by reaching the end of the thread, this
code is going away based on Heikki's arguments; but for my
understanding, so that I don't make a bad assumptio
Heikki Linnakangas writes:
> It makes me a bit uncomfortable to do catalog cache lookups while
> holding all the lwlocks. We've also already removed the reserved entry
> for scratch space while we do that - if a cache lookup errors out, we'll
> leave behind quite a mess. I guess it shouldn't fa
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> I note that if 2nd Quadrant is interested in having a game-changing
> platform without having to wait a full year for 9.2, they can obviously
> distribute a modified version of Postgres that integrates Robert's
> patch.
Having thought about th
"Kevin Grittner" wrote:
> Heikki Linnakangas wrote:
>
>> I think the logic is actually wrong at the moment: When you
>> reindex a single index, DropAllPredicateLocksFromTableImpl() will
>> transfer all locks belonging to any index on the same table, and
>> any finer-granularity locks on the heap.
On Tue, Jun 7, 2011 at 1:24 PM, Robert Haas wrote:
> One other thought is that I think that this patch might cause a
> user-visible behavior change. Right now, when you hit the end of
> recovery, you most typically get a message saying - record with zero
> length. Not always, but often. If we
1 - 100 of 108 matches
Mail list logo
