[HACKERS] Parameterized aggregate subquery (was: Pull up aggregate subquery)

Purpose & Goal -- Allow planner to create NestLoop with parameterized aggregate subquery just like inner IndexScan pattern. This helps to avoid unnecessary aggregate process that would be filtered at the stage of upper join filter in such case: create table size_m as select i as id, re

Re: [HACKERS] Autoanalyze and OldestXmin

On Wed, Jun 8, 2011 at 10:45 PM, Tom Lane wrote: > Pavan Deolasee writes: > > I first thought that analyze and vacuum can not run concurrently on the > same > > table since they take a conflicting lock on the table. So even if we > ignore > > the analyze process while calculating the OldestXmin

Re: [HACKERS] Error in PQsetvalue

Hello, Merlin. You wrote: MM> On Wed, Jun 8, 2011 at 11:03 AM, Tom Lane wrote: >> Merlin Moncure writes: >>> On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote: Merlin Moncure writes: > I went ahead and tested andrew's second patch -- can we get this > reviewed and committed? >> >>>

Re: [HACKERS] smallserial / serial2

On Wed, 8 Jun 2011 19:29:42 -0400, Robert Haas wrote: You should also change the status to either "Waiting on Author" or "Ready for Committer" based on the content of the review. I think the latter would be appropriate since your review seems to have been favorable. Well - not being a review pr

Re: [HACKERS] literature on write-ahead logging

On Wed, Jun 8, 2011 at 11:24 PM, Robert Haas wrote: > I did a brief literature search for papers on breaking the > WAL-serialization bottleneck today and hit upon this: > > Aether: A Scalable Approach to Logging, Ryan Johnson, Ippokratis Pandis, et > al. > http://infoscience.epfl.ch/record/149436

Re: [HACKERS] Invalid byte sequence for encoding "UTF8", caused due to non wide-char-aware downcase_truncate_identifier() function on WINDOWS

On Wed, Jun 8, 2011 at 6:22 AM, Robert Haas wrote: > 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

Re: [HACKERS] WALInsertLock contention

On Wed, Jun 8, 2011 at 11:27 PM, Robert Haas wrote: > On Wed, Jun 8, 2011 at 11:20 PM, Merlin Moncure wrote: >> You're probably right.  I think though there is enough hypothetical >> upside to the private buffer case that it should be attempted just to >> see what breaks. The major tricky bit is

Re: [HACKERS] tuning autovacuum

On Wed, Jun 8, 2011 at 10:55 PM, Euler Taveira de Oliveira wrote: > Em 08-06-2011 20:35, Robert Haas escreveu: >> Is the hint correct?  I mean, what if there were 100 small tables that >> needed vacuuming all at the same time.  We'd hit this limit no matter >> how high you set autovacuum_max_worke

Re: [HACKERS] SSI work for 9.1

On Wed, Jun 08, 2011 at 09:17:04PM -0500, Kevin Grittner wrote: > A patch is attached which just covers the predicate lock acquisition, > where a snapshot is available without too much pain. There are two > functions which acquire predicate locks where a snapshot was not > readily available: _bt_s

Re: [HACKERS] SSI work for 9.1

"Kevin Grittner" wrote: > A patch is attached which just covers the predicate lock > acquisition This patch rolls that up with snapshot checking in the conflict detection function called on read. The only other two functions which use that macro check for conflicts on write, and I can't see w

Re: [HACKERS] WALInsertLock contention

On Wed, Jun 8, 2011 at 11:20 PM, Merlin Moncure wrote: > You're probably right.  I think though there is enough hypothetical > upside to the private buffer case that it should be attempted just to > see what breaks. The major tricky bit is dealing with the new > pin/unpin mechanics.  I'd like to g

[HACKERS] literature on write-ahead logging

I did a brief literature search for papers on breaking the WAL-serialization bottleneck today and hit upon this: Aether: A Scalable Approach to Logging, Ryan Johnson, Ippokratis Pandis, et al. http://infoscience.epfl.ch/record/149436/files/vldb10aether.pdf Section 5 appears to be the most relevan

Re: [HACKERS] WALInsertLock contention

On Wed, Jun 8, 2011 at 10:21 PM, Robert Haas wrote: > On Wed, Jun 8, 2011 at 6:49 PM, Jim Nasby wrote: >>> If backend A needs to evict a buffer with a fake LSN, it can go find >>> the WAL that needs to be serialized, do that, flush WAL, and then >>> evict the buffer. >> >> Isn't the only time tha

Re: [HACKERS] tuning autovacuum

Em 08-06-2011 20:35, Robert Haas escreveu: Is the hint correct? I mean, what if there were 100 small tables that needed vacuuming all at the same time. We'd hit this limit no matter how high you set autovacuum_max_workers, but it wouldn't be right to set it to 101 just because every once in a b

Re: [HACKERS] gcc 4.6 and hot standby

On Thu, Jun 9, 2011 at 5:31 AM, Tom Lane wrote: > So it's interesting that this only happens with a particular gcc version, > because it's not apparent to me why it works properly for anybody. > Isn't hitting a zero record length an expected case when we run ahead of > the amount of WAL produced b

Re: [HACKERS] WALInsertLock contention

On Wed, Jun 8, 2011 at 6:49 PM, Jim Nasby wrote: >> If backend A needs to evict a buffer with a fake LSN, it can go find >> the WAL that needs to be serialized, do that, flush WAL, and then >> evict the buffer. > > Isn't the only time that you'd need to evict if you ran out of buffers? Sure, but

Re: [HACKERS] SSI work for 9.1

> Dan Ports wrote: > On Wed, Jun 08, 2011 at 05:48:26PM -0500, Kevin Grittner wrote: >> (1) Pass snapshot in to some predicate.c functions. The particular >> functions have yet to be determined, but certainly any which >> acquire predicate locks, and probably all which are guarded by the >> SkipSe

Re: [HACKERS] tuning autovacuum

On Wed, Jun 8, 2011 at 9:50 PM, Tom Lane wrote: > Robert Haas writes: >> I think it'd be really useful to expose some more data in this area >> though.  One random idea is - remember the time at which a table was >> first observed to need vacuuming. Clear the timestamp when it gets >> vacuumed.  

Re: [HACKERS] tuning autovacuum

Robert Haas writes: > I think it'd be really useful to expose some more data in this area > though. One random idea is - remember the time at which a table was > first observed to need vacuuming. Clear the timestamp when it gets > vacuumed. Then you can do: As far as I recall that logic, there

Re: [HACKERS] SSI work for 9.1

On Wed, Jun 08, 2011 at 05:48:26PM -0500, Kevin Grittner wrote: > (1) Pass snapshot in to some predicate.c functions. The particular > functions have yet to be determined, but certainly any which acquire > predicate locks, and probably all which are guarded by the > SkipSerialization() macro. Sk

Re: [HACKERS] Proposal: Another attempt at vacuum improvements

On Wed, Jun 8, 2011 at 1:19 AM, Pavan Deolasee wrote: > I went on to create a WIP patch based on our discussion. There are > couple of issues that I stumbled upon while testing it. > > 1. The start-of-index-vacuum LSN that we want to track must be noted > even before the heap scan is started. This

Re: [HACKERS] tuning autovacuum

On Wed, Jun 8, 2011 at 5:54 PM, Euler Taveira de Oliveira wrote: > LOG: maximum number of autovacuum workers reached > HINT: Consider increasing autovacuum_max_workers (currently 5). > > Comments? Is the hint correct? I mean, what if there were 100 small tables that needed vacuuming all at the s

Re: [HACKERS] smallserial / serial2

On Wed, Jun 8, 2011 at 6:36 PM, Brar Piening wrote: >>> New patch attached. > > Review for '20110607_serial2_v2.diff': I see you added this review to the CommitFest application - excellent. You should also change the status to either "Waiting on Author" or "Ready for Committer" based on the cont

Re: [HACKERS] smallserial / serial2

On Jun 8, 2011, at 5:36 PM, Brar Piening wrote: > Pros > Mike Pultz (patch author): "since serial4 and serial8 are simply > pseudo-types- effectively there for convenience, I’d argue that it should > simply be there for completeness" > Robert Haas: "We should be trying to put all types on equal f

Re: [HACKERS] gcc 4.6 and hot standby

On Wed, Jun 8, 2011 at 16:20, Mark Kirkwood wrote: > On 09/06/11 06:58, Alex Hunsaker wrote: >> >> Yeah :-). However ill note it looks like its the default compiler for >> fedora 15, ubuntu natty and debian sid. >> > > FWIW Ubuntu natty uses gcc 4.5.2, probably just as as well in the light of > yo

Re: [HACKERS] WALInsertLock contention

On Jun 8, 2011, at 10:15 AM, Robert Haas wrote: >> That suggests to me that you have to keep them pinned anyways. I'm >> still a bit fuzzy on how the per-backend buffers being in shm conveys >> any advantage. IOW, (trying not to be obtuse) under what >> circumstances would backend A want to read

[HACKERS] SSI work for 9.1

>From a review of recent emails I've put together a list of what I'm going to try to do this evening, in order of attack. It's ambitious and I may well not get to the end tonight, but I wanted to get the issues on record in list form. If someone spots one I'm missing or thinks I should change the

Re: [HACKERS] Autoanalyze and OldestXmin

On Jun 8, 2011, at 10:33 AM, Greg Stark wrote: > This is kind of like the other property it would be nice to know about > transactions: that they've locked all the tables they're going to lock. That sounds like something I've wanted for a very long time: the ability for a transaction to say exact

Re: [HACKERS] smallserial / serial2

On Tue, 7 Jun 2011 20:35:12 -0400, Mike Pultz wrote: New patch attached. Review for '20110607_serial2_v2.diff': Submission review - Is the patch in context diff format? Yes. - Does it apply cleanly to the current git master? Yes. - Does it include reasonable tests, necessary doc patches,

Re: [HACKERS] SSI heap_insert and page-level predicate locks

Heikki Linnakangas wrote: > heap_insert() calls CheckForSerializableConflictIn(), which checks if > there is a predicate lock on the whole relation, or on the page we're > inserting to. It does not check for tuple-level locks, because there > can't be any locks on a tuple that didn't exist befo

Re: [HACKERS] gcc 4.6 and hot standby

On 09/06/11 06:58, Alex Hunsaker wrote: Yeah :-). However ill note it looks like its the default compiler for fedora 15, ubuntu natty and debian sid. FWIW Ubuntu natty uses gcc 4.5.2, probably just as as well in the light of your findings :-) Cheers Mark -- Sent via pgsql-hackers mailing

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

Joshua Berkus writes: > Simon, >> The point I have made is that I disagree with a feature freeze date >> fixed ahead of time without regard to the content of the forthcoming >> release. I've not said I disagree with feature freezes altogether, >> which would be utterly ridiculous. Fixed dates are

Re: [HACKERS] tuning autovacuum

On Jun 9, 2011 12:01 AM, "Euler Taveira de Oliveira" wrote: > > Hi, > > There are some releases that autovacuum was enabled by default and, up to now there is an easy way to estimate the number of autovacuum workers. I tune it observing if the number of slots are saturated for a period of time. I'

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

Simon Riggs writes: > On Wed, Jun 8, 2011 at 6:02 AM, Tom Lane wrote: >> Just to set the record straight on this ... the vxid patch went in on >> 2007-09-05: >> http://archives.postgresql.org/pgsql-committers/2007-09/msg00026.php >> which was a day shy of a month before we wrapped 8.3beta1: >> ht

[HACKERS] tuning autovacuum

Hi, There are some releases that autovacuum was enabled by default and, up to now there is an easy way to estimate the number of autovacuum workers. I tune it observing if the number of slots are saturated for a period of time. I'm having a hard time trying to do this. I want to add a LOG mess

Re: [HACKERS] gcc 4.6 and hot standby

Alex Hunsaker writes: >> On Wed, Jun 8, 2011 at 12:49, Tom Lane wrote: >>> It might be useful to strace the postmaster and walreceiver processes >>> just to see if any signal is actually being sent or received. > Find it attached. Well, the trace shows exactly what I thought was happening: each

[HACKERS] patch for 9.2: enhanced errors

Hello Attached patch implements a new erros's fields that describes table, colums related to error. This enhanced info is limited to constraints and RI. example: postgres=# create table omega(a int unique not null check (a > 10)); NOTICE: 0: CREATE TABLE / UNIQUE will create implicit index

Re: [HACKERS] could not truncate directory "pg_serial": apparent wraparound

Heikki Linnakangas wrote: > On 08.06.2011 03:28, Kevin Grittner wrote: >> 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 have

Re: [HACKERS] Another pgindent run before beta2?

On 06/08/2011 02:29 PM, Tom Lane wrote: Should we consider doing $SUBJECT? Given the plan to branch off 9.1 after we make the beta release, I think it's now or never for a second pgindent run for 9.1. OK, I have made sure the list on the buildfarm is up to date. ch

Re: [HACKERS] could not truncate directory "pg_serial": apparent wraparound

On 08.06.2011 03:28, Kevin Grittner wrote: 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 d

Re: [HACKERS] contrib/citext versus collations

I wrote: > On further reflection, I'm wondering exactly how much goodness to chop > off there. What I'd originally been thinking was to just lobotomize the > case-folding step, and allow citext's comparison operators to still > respond to input collation when comparing the folded strings. However

Re: [HACKERS] gcc 4.6 and hot standby

Alex Hunsaker writes: > So I tracked it down to "-fgcse", that is CFLAGS="-O2 -fno-gcse" > ./configure works. I then took a few guesses and compiled all of > postgres with -O2, then manually recompiled xlog.c with -f-no-gcse. > that combination seems to work. Huh, interesting. So the bug must be

Re: [HACKERS] gcc 4.6 and hot standby

On Wed, Jun 8, 2011 at 12:49, Tom Lane wrote: > Alex Hunsaker writes: >> So I've been delaying moving some production boxes over to 9.0.4 from >> 2011-06-08 11:41:03 MDT [6078]: [1-1] user= FATAL:  terminating >> walreceiver process due to administrator command >> [ repeats... ] > >> I suppose th

Re: [HACKERS] gcc 4.6 and hot standby

On Wed, Jun 8, 2011 at 12:12, Alex Hunsaker wrote: > So I've been delaying moving some production boxes over to 9.0.4 from > 9.0.2 because hot standby fails with: > (this is on the "hot standby" machine that connects to the master) > [ ...] > 2011-06-08 11:41:03 MDT [6072]: [18-1] user= LOG:  inva

Re: [HACKERS] gcc 4.6 and hot standby

Alex Hunsaker writes: > So I've been delaying moving some production boxes over to 9.0.4 from > 2011-06-08 11:41:03 MDT [6078]: [1-1] user= FATAL: terminating > walreceiver process due to administrator command > [ repeats... ] > I suppose the next step is to narrow it down to a specific flag -O2

Re: [HACKERS] Another pgindent run before beta2?

On Wed, Jun 8, 2011 at 20:32, Robert Haas wrote: > On Wed, Jun 8, 2011 at 2:29 PM, Tom Lane wrote: >> Should we consider doing $SUBJECT?  Given the plan to branch off 9.1 >> after we make the beta release, I think it's now or never for a second >> pgindent run for 9.1. > > +1. +1. --  Magnus H

Re: [HACKERS] Another pgindent run before beta2?

On Wed, Jun 8, 2011 at 2:29 PM, Tom Lane wrote: > Should we consider doing $SUBJECT?  Given the plan to branch off 9.1 > after we make the beta release, I think it's now or never for a second > pgindent run for 9.1. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Pos

[HACKERS] Another pgindent run before beta2?

Should we consider doing $SUBJECT? Given the plan to branch off 9.1 after we make the beta release, I think it's now or never for a second pgindent run for 9.1. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] Postmaster holding unlinked files for pg_largeobject table

Alvaro Herrera writes: > Okay, here's a patch implementing this idea. It seems to work quite > well, and it solves the problem in a limited testing scenario -- I > haven't yet tested on the customer machines. This seems mostly sane, except I think you have not considered the issue of when to cle

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On Wed, Jun 8, 2011 at 1:10 PM, Simon Riggs wrote: > Why do you address this to me? Many others have been committing > patches against raised issues well after feature freeze. No one other than you has proposed committing anything nearly as invasive as this, and the great majority of what we've c

[HACKERS] gcc 4.6 and hot standby

So I've been delaying moving some production boxes over to 9.0.4 from 9.0.2 because hot standby fails with: (this is on the "hot standby" machine that connects to the master) 2011-06-08 11:40:48 MDT [6072]: [2-1] user= LOG: entering standby mode 2011-06-08 11:40:48 MDT [6072]: [3-1] user= DEBUG:

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On 06/07/2011 11:55 AM, 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 book. The probabili

Re: [HACKERS] Postmaster holding unlinked files for pg_largeobject table

Excerpts from Tom Lane's message of mar jun 07 12:26:34 -0400 2011: > It's not *that* many levels: in fact, I think md.c is the only level > that would just have to pass it through without doing anything useful. > I think that working from there is a saner and more efficient approach > than what y

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

Simon, > The point I have made is that I disagree with a feature freeze date > fixed ahead of time without regard to the content of the forthcoming > release. I've not said I disagree with feature freezes altogether, > which would be utterly ridiculous. Fixed dates are IMHO much less > important t

Re: [HACKERS] [PATCH] Allow star syntax in GROUP BY, as a shorthand for all table columns

Marti Raudsepp writes: > This patch enables the syntax "GROUP BY tablename.*" in cases where > earlier you'd get the error "field must appear in the GROUP BY clause > or be used in an aggregate function" Is this really necessary now that we know about "GROUP BY primary key"? > The patch is so tr

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On Wed, Jun 8, 2011 at 5:44 PM, Robert Haas wrote: > On Wed, Jun 8, 2011 at 12:25 PM, Simon Riggs wrote: >> As a result of this, I've been insulted, told I have no respect for >> process and even suggested there was a threat of patch war. > > Well, you've pretty much said flat out you don't like

Re: [HACKERS] Autoanalyze and OldestXmin

Pavan Deolasee writes: > I first thought that analyze and vacuum can not run concurrently on the same > table since they take a conflicting lock on the table. So even if we ignore > the analyze process while calculating the OldestXmin for vacuum, we should > be fine since we know they are working

[HACKERS] [PATCH] Allow star syntax in GROUP BY, as a shorthand for all table columns

Hi, This patch enables the syntax "GROUP BY tablename.*" in cases where earlier you'd get the error "field must appear in the GROUP BY clause or be used in an aggregate function" I've often needed to write queries like this: SELECT a.x, a.y, a.z, sum(b.w) FROM a JOIN b USING (a_id) GROUP BY a.x

Re: [HACKERS] Autoanalyze and OldestXmin

On Wed, Jun 8, 2011 at 9:03 PM, Greg Stark wrote: > > On Jun 8, 2011 1:49 PM, "Pavan Deolasee" wrote: > > > > > > Hi All, > > > There is a PROC_IN_ANALYZE flag, but we don't seem to be using it > anywhere. Since acquire_sample_rows() returns palloced tuples, can't we let > OldestXmin advance af

Re: [HACKERS] Domains versus polymorphic functions, redux

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 l

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On Wed, Jun 8, 2011 at 5:32 PM, Robert Haas wrote: > It took me > about 3 days to write the patch.  I've now spent the better part of a > day on this scheduling discussion.  I would rather have spent that > time improving the patch.  Or working on some other patch.  Or getting > 9.1 out the door.

Re: [HACKERS] Error in PQsetvalue

On 6/8/2011 12:03 PM, Tom Lane wrote: Merlin Moncure writes: On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote: Merlin Moncure writes: I went ahead and tested andrew's second patch -- can we get this reviewed and committed? Add it to the upcoming commitfest. It's a client crashing bug i

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On Wed, Jun 8, 2011 at 12:25 PM, Simon Riggs wrote: > As a result of this, I've been insulted, told I have no respect for > process and even suggested there was a threat of patch war. Well, you've pretty much said flat out you don't like the process, and you don't agree with having a firm feature

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On Wed, Jun 8, 2011 at 5:33 AM, Bruce Momjian wrote: > One more thing --- when Tom applied that patch during 8.3 beta it was > with everyone's agreement, so the policy should be that if we are going > to break the rules, everyone has to agree --- if anyone disagrees, the > rules stand. I spoke a

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On Wed, Jun 8, 2011 at 6:02 AM, Tom Lane wrote: > 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 >

Re: [HACKERS] Error in PQsetvalue

On Wed, Jun 8, 2011 at 11:03 AM, Tom Lane wrote: > Merlin Moncure writes: >> On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote: >>> Merlin Moncure writes: I went ahead and tested andrew's second patch -- can we get this reviewed and committed? > >>> Add it to the upcoming commitfest. >

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On Wed, Jun 8, 2011 at 11:39 AM, Jim Nasby wrote: > On Jun 7, 2011, at 8:24 AM, Stephen Frost wrote: >> * 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 obv

Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD

On Tue, Jun 7, 2011 at 12:42, Alex Hunsaker wrote: > 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.opensour

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On Wed, Jun 8, 2011 at 5:19 AM, Bruce Momjian wrote: > 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 perspec

Re: [HACKERS] reindex creates predicate lock on index root

Tom Lane wrote: > "Kevin Grittner" writes: >> *** a/src/backend/storage/lmgr/predicate.c >> --- b/src/backend/storage/lmgr/predicate.c >> *** >> *** 274,279 >> --- 274,280 >> #define SkipSerialization(relation) \ >> ((!IsolationIsSerializable()) \ >> || ((MySeria

Re: [HACKERS] Range Types and extensions

Jeff Davis writes: > It looks like the type input function may be a problem, because it > doesn't look like it knows what the collation is yet. In other words, > PG_GET_COLLATION() is zero for the type input function. Yeah, we've assumed that I/O functions do not need to know collation.

Re: [HACKERS] Error in PQsetvalue

Merlin Moncure writes: > On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote: >> Merlin Moncure writes: >>> I went ahead and tested andrew's second patch -- can we get this >>> reviewed and committed? >> Add it to the upcoming commitfest. > It's a client crashing bug in PQsetvalue that goes back t

Re: [HACKERS] SSI heap_insert and page-level predicate locks

Alvaro Herrera wrote: > Excerpts from Heikki Linnakangas's message of mié jun 08 05:45:35 -0400 2011: >> On 08.06.2011 12:36, Dan Ports wrote: > >>> The only thing I'd be worried about is that at some future point >>> we might add heap page locks -- say, for sequential scans that >>> don't read t

Re: [HACKERS] Range Types and extensions

On Tue, 2011-06-07 at 10:20 -0700, Jeff Davis wrote: > > BTW, Jeff, have you worked out the implications of collations for > > textual range types? > > Well, "it seems to work" is about as far as I've gotten. > > As far as the implications, I'll need to do a little more research and > thinking. B

Re: [HACKERS] Error in PQsetvalue

On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane wrote: > Merlin Moncure writes: >> I went ahead and tested andrew's second patch -- can we get this >> reviewed and committed? > > Add it to the upcoming commitfest. It's a client crashing bug in PQsetvalue that goes back to 9.0 :(. In short (apologies

Re: [HACKERS] reindex creates predicate lock on index root

"Kevin Grittner" writes: > Heikki Linnakangas wrote: >> You can have one snapshot pushed to the active snapshot stack, and >> do a DDL operation like reindex using a different snapshot. You'll >> have to check the snapshot in the HeapScanDesc. > Will look at that. Do you think it makes more se

Re: [HACKERS] reducing the overhead of frequent table locks - now, with WIP patch

On Jun 7, 2011, at 8:24 AM, Stephen Frost wrote: > * 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

Re: [HACKERS] reindex creates predicate lock on index root

Heikki Linnakangas wrote: >> The attached patch has not yet been tested, but I'll test it >> today along with the latest committed code. > > You can't use GetActiveSnapshot() for this. Yeah, it didn't take much testing to find that out. I had a naive assumption that the GetActiveSnapshot woul

Re: [HACKERS] SSI heap_insert and page-level predicate locks

Excerpts from Heikki Linnakangas's message of mié jun 08 05:45:35 -0400 2011: > On 08.06.2011 12:36, Dan Ports wrote: > > The only thing I'd be worried about is that at some future point we > > might add heap page locks -- say, for sequential scans that don't read > > the entire relation -- and ex

Re: [HACKERS] Autoanalyze and OldestXmin

On Jun 8, 2011 1:49 PM, "Pavan Deolasee" wrote: > > > Hi All, > There is a PROC_IN_ANALYZE flag, but we don't seem to be using it anywhere. Since acquire_sample_rows() returns palloced tuples, can't we let OldestXmin advance after scanning a page by ignoring procs with the flag set, just like we

Re: [HACKERS] Error in PQsetvalue

Merlin Moncure writes: > I went ahead and tested andrew's second patch -- can we get this > reviewed and committed? Add it to the upcoming commitfest. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscri

Re: [HACKERS] reindex creates predicate lock on index root

On 08.06.2011 18:09, Kevin Grittner wrote: Robert Haas wrote: I'm wondering if this shouldn't be linked to whether the scan is using an MVCC snapshot, rather than inserting exceptions for specific operations. Yeah, that was raised before somewhere and I spaced it. Grabbing predicate locks f

Re: [HACKERS] reindex creates predicate lock on index root

"Kevin Grittner" writes: > *** a/src/backend/storage/lmgr/predicate.c > --- b/src/backend/storage/lmgr/predicate.c > *** > *** 274,279 > --- 274,280 > #define SkipSerialization(relation) \ > ((!IsolationIsSerializable()) \ > || ((MySerializableXact == InvalidSer

Re: [HACKERS] WALInsertLock contention

On Wed, Jun 8, 2011 at 10:18 AM, Merlin Moncure wrote: > One point i'm missing though.  Getting back to your original idea, how > does writing to shmem prevent you from having to keep buffers pinned? > I'm reading your comment here: > "Those buffers are stamped with a fake LSN that > points back t

Re: [HACKERS] Error in PQsetvalue

On Mon, Jun 6, 2011 at 1:42 PM, Merlin Moncure wrote: > On Mon, Jun 6, 2011 at 7:09 AM, Pavel Golub wrote: >> Sorry for delay in answer. Yeah, I'm glad to. Should I apply this >> patch by myself? > > sure, run it against your test case and make sure it works. if so, we > can pass it up the chain

Re: [HACKERS] reindex creates predicate lock on index root

Robert Haas wrote: > I'm wondering if this shouldn't be linked to whether the scan is > using an MVCC snapshot, rather than inserting exceptions for > specific operations. Yeah, that was raised before somewhere and I spaced it. Grabbing predicate locks for non-MVCC snapshots is nonsense, and

Re: [HACKERS] SIREAD lock versus ACCESS EXCLUSIVE lock

Heikki Linnakangas wrote: > (sorry for repeatedly replying to self. I'll go for a coffee after > this...) That's so nice of you to try to make me feel better for the serious brain fade I suffered yesterday. ;-) > On 08.06.2011 14:18, Heikki Linnakangas wrote: >> Committed after adjusting th

Re: [HACKERS] WALInsertLock contention

On Wed, Jun 8, 2011 at 7:44 AM, Robert Haas wrote: > On Wed, Jun 8, 2011 at 1:59 AM, Merlin Moncure wrote: >> There's probably an obvious explanation that I'm not seeing, ... > > Yep.  :-) > >> but if >> you're not delegating the work of writing the buffers out to someone >> else, why do you need

Re: [HACKERS] SSI heap_insert and page-level predicate locks

On Wed, Jun 8, 2011 at 5:36 AM, Dan Ports wrote: > On Wed, Jun 08, 2011 at 11:23:48AM +0300, Heikki Linnakangas wrote: >> AFAICS, the check for page lock is actually unnecessary. A page-level >> lock on a heap only occurs when tuple-level locks are promoted. It is >> just a coarser-grain represent

Re: [HACKERS] reindex creates predicate lock on index root

On Wed, Jun 8, 2011 at 4:59 AM, Dan Ports wrote: > On Tue, Jun 07, 2011 at 10:14:30PM -0400, Tom Lane wrote: >> Do you mean page zero, as in the metapage (for most index types), or do >> you mean the root page?  If the former, how is that not an outright bug, >> since it corresponds to no data?  I

[HACKERS] Autoanalyze and OldestXmin

Hi All, I was running some pgbench tests and observed this phenomenon. This might be a known issue, but I thought its nevertheless worth mentioning. Auto-analyze process grabs a MVCC snapshot. If it runs on a very large table, it may take considerable time and would stop the OldestXmin from advan

Re: [HACKERS] WALInsertLock contention

On Wed, Jun 8, 2011 at 1:59 AM, Merlin Moncure wrote: > There's probably an obvious explanation that I'm not seeing, ... Yep. :-) > but if > you're not delegating the work of writing the buffers out to someone > else, why do you need to lock the per backend buffer at all?  That is, > why does i

Re: [HACKERS] SIREAD lock versus ACCESS EXCLUSIVE lock

(sorry for repeatedly replying to self. I'll go for a coffee after this...) On 08.06.2011 14:18, Heikki Linnakangas wrote: Committed after adjusting that comment. I did a lot of other cosmetic changes too, please double-check that I didn't screw up anything. Also, it would be nice to have some

Re: [HACKERS] SIREAD lock versus ACCESS EXCLUSIVE lock

On 08.06.2011 14:18, Heikki Linnakangas wrote: I just looked back at your old email where you listed the different DDL operations, and notice that we missed VACUUM FULL as well (http://archives.postgresql.org/message-id/4dbd7e9102250003d...@gw.wicourts.gov). I'll look into that. Never mind

Re: [HACKERS] SIREAD lock versus ACCESS EXCLUSIVE lock

On 08.06.2011 03:16, Kevin Grittner wrote: + /* +* It's OK to remove the old lock first because of the ACCESS +* EXCLUSIVE lock on the heap relation when this is called. It is +* desirable to do so be

[HACKERS] .gitignore for some of cygwin files

After compilation I got big list of differences about binaries and other files. You may see it in patch. Regards, Radekdiff --git a/.gitignore b/.gitignore old mode 100644 new mode 100755 index 81c4d5e..75e1d9a --- a/.gitignore +++ b/.gitignore @@ -20,6 +20,14 @@ lcov.info *.vcproj win32ver.rc

Re: [HACKERS] SSI heap_insert and page-level predicate locks

On 08.06.2011 12:36, Dan Ports wrote: On Wed, Jun 08, 2011 at 11:23:48AM +0300, Heikki Linnakangas wrote: AFAICS, the check for page lock is actually unnecessary. A page-level lock on a heap only occurs when tuple-level locks are promoted. It is just a coarser-grain representation of holding loc

Re: [HACKERS] SSI heap_insert and page-level predicate locks

On Wed, Jun 08, 2011 at 11:23:48AM +0300, Heikki Linnakangas wrote: > AFAICS, the check for page lock is actually unnecessary. A page-level > lock on a heap only occurs when tuple-level locks are promoted. It is > just a coarser-grain representation of holding locks on all tuples on > the page,

Re: [HACKERS] [Pgbuildfarm-members] CREATE FUNCTION hang on test machine polecat on HEAD

On Jun 7, 2011, at 3:01 PM, Tom Lane wrote: > Robert Creager writes: > > The configure log mentioned upthread says it's finding /usr/bin/perl, > so apparently the buildfarm is running with a different PATH than you're > using here. But that log also shows > > configure:7158: checking for flag

Re: [HACKERS] smallserial / serial2

Yup- it's 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, 20 Apr 2011 21:27:27 -0400, Mike Pultz wrote: Ca

  1   2   >