[HACKERS] REVIEW proposal: a validator for configuration files

Hi Alexey, I was taking a quick look at this patch, and have a question for ya. I have a default config from initdb, there is a new setting at the end but its commented out. root@storm: /db/pg92 # /etc/rc.d/postgresql start Starting PostgreSQL: root@storm: /db/pg92 # more serverlog LOG: datab

Re: [HACKERS] regular logging of checkpoint progress

On Tue, Sep 6, 2011 at 3:02 AM, Andy Colson wrote: > Several people thought a view or some-non-log option would be better. +1 > Tomas > replied "but I need to go back in time to post diagnose a problem", and I > saw no replies to that. You can go back in time if you periodically collect the inf

Re: [HACKERS] memory-related bugs

On Tue, Sep 06, 2011 at 03:00:42PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Sat, Mar 12, 2011 at 12:44:29PM -0500, Tom Lane wrote: > >> I wonder whether we should instead fix this by copying the correct tuple > >> length. > > > Seems like a step in the wrong direction. We only use typl

[HACKERS] REVIEW Single pass vacuum - take 2

On 08/22/2011 01:22 AM, Pavan Deolasee wrote: Hi All, Here is a revised patch based on our earlier discussion. I implemented Robert's idea of tracking the vacuum generation number in the line pointer itself. For LP_DEAD line pointers, the lp_off/lp_len is unused (and always set to 0 for heap tup

Re: [HACKERS] postgresql.conf archive_command example

On Sat, Sep 3, 2011 at 5:10 AM, Kevin Grittner wrote: > (2)  It should copy, not move, with protection against overwriting > an existing file. I agree that basically archive_command should not overwrite an existing file. But if the size of existing file is less than 16MB, it should do that. Other

Re: [HACKERS] Cascaded standby message

On Wed, Sep 7, 2011 at 5:22 AM, Simon Riggs wrote: > Fujii - the original goal here was to avoid having a unexplained > disconnection in the logs. The only way to do this cleanly is to have > a disconnection reason passed to the walsender, rather than just a > blind signal. Looks like we need to m

Re: [HACKERS] Back branch update releases this week; beta postponed

Tom Lane wrote: > Bernd Helmle writes: > > --On 10. April 2011 13:53:52 -0400 Tom Lane wrote: > >> The core team has therefore decided to wrap back-branch > >> update releases this Thursday for release Monday 4/18. > > > Hmm, I would like to see the patch for > >

Re: [HACKERS] [GENERAL] pg_upgrade problem

Tom Lane wrote: > hubert depesz lubaczewski writes: > > Worked a bit to get the ltree problem down to smallest possible, > > repeatable, situation. > > I looked at this again and verified that indeed, commit > 8eee65c996048848c20f6637c1d12b319a4ce244 introduced an incompatible > change into the

Re: [HACKERS] Large C files

On 7 September 2011 01:18, Bruce Momjian wrote: > I am confused how moving a function from one C file to another could > cause breakage? I'm really concerned about silent breakage, however unlikely - that is also Simon and Robert's concern, and rightly so. If it's possible in principle to guard a

Re: [HACKERS] Large C files

Peter Geoghegan wrote: > On 7 September 2011 00:13, Peter Geoghegan wrote: > > * Within TUs, we unshadow a previously shadowed variable, so we link > > to a global variable rather than one local to the original/other new > > file. Unlikely to be a problem. Here's what I get when I compile > > xlog

Re: [HACKERS] Large C files

On 7 September 2011 00:13, Peter Geoghegan wrote: > * Within TUs, we unshadow a previously shadowed variable, so we link > to a global variable rather than one local to the original/other new > file. Unlikely to be a problem. Here's what I get when I compile > xlog.c in the usual way with the addi

Re: [HACKERS] Review: prepare plans of embedded sql on function start

Hi Pavel, I can get: ERROR: permission denied to set parameter "plpgsql.prepare_plans" with this script: set plpgsql.prepare_plans to on_start; create or replace function test1(a integer) returns integer as $$ begin return a+1; end; $$ language plpgsql; If test1() exists, then this script

Re: [HACKERS] pgpass comment suggestion

Peter Eisentraut wrote: > On tis, 2011-09-06 at 17:33 -0400, Bruce Momjian wrote: > > +(You can add a reminder comment to the file by copying the line above > > and > > +preceeding it with #.) > > Fix spelling please. Fixed, thanks. -- Bruce Momjian http://momjian.us Ente

Re: [HACKERS] Large C files

On 07/09/11 01:13, Peter Geoghegan wrote: > On 6 September 2011 08:29, Peter Eisentraut wrote: >> I was thinking about splitting up plpython.c, but it's not even on that >> list. ;-) > > IIRC the obesity of that file is something that Jan Urbański intends > to fix, or is at least concerned about.

Re: [HACKERS] Large C files

On 6 September 2011 21:07, Robert Haas wrote: > On Tue, Sep 6, 2011 at 3:56 PM, Simon Riggs wrote: >> The only way I would entertain thoughts of major refactoring would be >> if comprehensive tests were contributed, so we could verify everything >> still works afterwards. > > That sounds like a r

Re: [HACKERS] [PATCH] Log crashed backend's query (activity string)

On Tue, Sep 6, 2011 at 6:05 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 6, 2011 at 5:34 PM, Tom Lane wrote: >>> And I doubt >>> that the goal is worth taking risks for. > >> I am unable to count the number of times that I have had a customer >> come to me and say "well, the backend

Re: [HACKERS] [PATCH] Log crashed backend's query (activity string)

Robert Haas wrote: > Tom Lane wrote: >> Marti Raudsepp writes: >>> This patch adds the backend's current running query to the >>> "backend crash" message. >> >> Sorry, this patch is entirely unacceptable. We cannot have the >> postmaster's functioning depending on the contents of shared >> memo

Re: [HACKERS] [PATCH] Log crashed backend's query (activity string)

Robert Haas writes: > On Tue, Sep 6, 2011 at 5:34 PM, Tom Lane wrote: >> And I doubt >> that the goal is worth taking risks for. > I am unable to count the number of times that I have had a customer > come to me and say "well, the backend crashed". And I go look at > their logs and I have no id

Re: [HACKERS] [PATCH] Log crashed backend's query (activity string)

On Wed, Sep 7, 2011 at 00:34, Tom Lane wrote: > No, I don't think your attempts to validate the data are > adequate, nor do I believe they can be made adequate. Can you think of any concrete situations that would fail the current validation? As far as I can tell, the only pointer I'm following f

Re: [HACKERS] [PATCH] Log crashed backend's query (activity string)

On Tue, Sep 6, 2011 at 5:34 PM, Tom Lane wrote: > Marti Raudsepp writes: >> This patch adds the backend's current running query to the "backend >> crash" message. > > Sorry, this patch is entirely unacceptable.  We cannot have the > postmaster's functioning depending on the contents of shared mem

Re: [HACKERS] pgpass comment suggestion

On tis, 2011-09-06 at 17:33 -0400, Bruce Momjian wrote: > +(You can add a reminder comment to the file by copying the line above and > +preceeding it with #.) Fix spelling please. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] timezone GUC

On Tue, Sep 6, 2011 at 5:16 PM, Tom Lane wrote: > I wrote: >> Robert Haas writes: >>> I am (and, I think, Alvaro is also) of the opinion that the behavior >>> here is still not really right. > >> I don't see a practical way to do better unless we can find a less >> horridly inefficient way of imp

Re: [HACKERS] [PATCH] Log crashed backend's query (activity string)

Marti Raudsepp writes: > This patch adds the backend's current running query to the "backend > crash" message. Sorry, this patch is entirely unacceptable. We cannot have the postmaster's functioning depending on the contents of shared memory still being valid ... most especially not when we know

[HACKERS] pgpass comment suggestion

There was a discussion months ago about helping people document the pgpass columns, so I added a documentation sentence suggestion the use of a comment. Patch attached and applied to 9.1 and head. -- Bruce Momjian http://momjian.us EnterpriseDB http://ent

Re: [HACKERS] getting carriage return character in vacuumo

Martijn van Oosterhout wrote: -- Start of PGP signed section. > On Fri, Apr 08, 2011 at 02:10:56PM -0400, Tom Lane wrote: > > Muhammad Usama writes: > > > While using the vacuumlo utility I encountered a redundant carriage > > > return(\r') character in the output. It is required in any scenario?

Re: [HACKERS] timezone GUC

I wrote: > Robert Haas writes: >> I am (and, I think, Alvaro is also) of the opinion that the behavior >> here is still not really right. > I don't see a practical way to do better unless we can find a less > horridly inefficient way of implementing identify_system_timezone(). Although there's a

Re: [HACKERS] [PATCH] Log crashed backend's query (activity string)

On Tue, Sep 6, 2011 at 4:52 PM, Marti Raudsepp wrote: > This patch adds the backend's current running query to the "backend > crash" message. > > The crashing query is often a good starting point in debugging the > cause, and much more easily accessible than core dumps. > > Example output: > LOG:

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On Tue, Sep 6, 2011 at 4:40 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera >> wrote: >>> Pity we can't use git notes. > >> I spent some time looking at this this morning, and my reaction is >>  yaggh!! > > Yeah, we had this same discussion si

[HACKERS] [PATCH] Log crashed backend's query (activity string)

Hi list, This patch adds the backend's current running query to the "backend crash" message. The crashing query is often a good starting point in debugging the cause, and much more easily accessible than core dumps. Example output: LOG: server process (PID 31451) was terminated by signal 9: Kil

Re: [HACKERS] timezone GUC

Robert Haas writes: > On Tue, Sep 6, 2011 at 3:31 PM, Tom Lane wrote: >> Bruce Momjian writes: >>> Was this dealt with? >> Yes, as much as I think is reasonable anyway.  See >> commit e05b866447899211a0c2df31bf0671faac4fc3e5. > I am (and, I think, Alvaro is also) of the opinion that the behavi

Re: [HACKERS] postgresql.conf archive_command example

Dimitri Fontaine wrote: > I think the solution to that problem is to provide a default > archive command that just does the very simple thing, namely > moving the WAL file to some place given as parameter. Some > *local* mount point. I think we've been mostly in agreement, but I have a few qu

Re: [HACKERS] postgresql.conf archive_command example

Dimitri Fontaine wrote: > "Kevin Grittner" writes: >> (1) We're talking about a new /bin executable to do this which >> could be referenced in an archive_command string or run from a >> script called by archive_command, right? > > That, or an internal implementation. That would be a function i

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

Robert Haas writes: > On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera > wrote: >> Pity we can't use git notes. > I spent some time looking at this this morning, and my reaction is > yaggh!! Yeah, we had this same discussion six weeks ago. http://archives.postgresql.org/pgsql-hackers/2

Re: [HACKERS] [GENERAL] pg_upgrade problem

hubert depesz lubaczewski writes: > Worked a bit to get the ltree problem down to smallest possible, repeatable, > situation. I looked at this again and verified that indeed, commit 8eee65c996048848c20f6637c1d12b319a4ce244 introduced an incompatible change into the on-disk format of ltree column

Re: [HACKERS] WAL "low watermark" during base backup

On Mon, Sep 5, 2011 at 11:38 AM, Magnus Hagander wrote: > On Sun, Sep 4, 2011 at 19:02, Simon Riggs wrote: >> On Fri, Sep 2, 2011 at 6:52 PM, Magnus Hagander wrote: >> >>> Attached patch implements a "low watermark wal location" in the >>> walsender shmem array. Setting this value in a walsender

Re: [HACKERS] timezone GUC

On Tue, Sep 6, 2011 at 3:31 PM, Tom Lane wrote: > Bruce Momjian writes: >> Was this dealt with? > > Yes, as much as I think is reasonable anyway.  See > commit e05b866447899211a0c2df31bf0671faac4fc3e5. I am (and, I think, Alvaro is also) of the opinion that the behavior here is still not really

Re: [HACKERS] Cascaded standby message

On Fri, Sep 2, 2011 at 1:19 PM, Magnus Hagander wrote: > From what I can tell, everytime I start a postmaster on HEAD (at least > when i've set wal_level=archive, and max_wal_senders > 0), I get the > message: > LOG:  terminating all walsender processes to force cascaded standby(s) > to update ti

Re: [HACKERS] savepoint commit performance

On Tue, Sep 6, 2011 at 9:12 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Sep 5, 2011 at 1:56 PM, Andy Colson wrote: >>> This patch: >>> >>> https://commitfest.postgresql.org/action/patch_view?id=605 >>> >>> Seems to have been after thoughts, and back burner stuff, and forgotten >>> about

Re: [HACKERS] regular logging of checkpoint progress

On Tue, Sep 6, 2011 at 3:48 AM, Robert Haas wrote: > On Mon, Sep 5, 2011 at 2:02 PM, Andy Colson wrote: >> Taking into account Noah's and Greg's "Displaying accumulated autovacuum >> cost" patch is also sending to logs, do we all now agree that this is proper >> way? > > My general impression of

Re: [HACKERS] savepoint commit performance

Robert Haas writes: > On Mon, Sep 5, 2011 at 1:56 PM, Andy Colson wrote: >> This patch: >> >> https://commitfest.postgresql.org/action/patch_view?id=605 >> >> Seems to have been after thoughts, and back burner stuff, and forgotten >> about... >> >> Has it already been commit? >> >> http://arc

Re: [HACKERS] Large C files

On Tue, Sep 6, 2011 at 3:56 PM, Simon Riggs wrote: > The only way I would entertain thoughts of major refactoring would be > if comprehensive tests were contributed, so we could verify everything > still works afterwards. That sounds like a really good idea. Mind you, I don't have a very clear i

Re: [HACKERS] Large C files

On Tue, Sep 6, 2011 at 3:05 PM, Bruce Momjian wrote: > Peter Eisentraut wrote: >> On l?r, 2011-09-03 at 19:18 -0400, Bruce Momjian wrote: >> > FYI, here are all the C files with over 6k lines: >> > >> > -  45133 ./interfaces/ecpg/preproc/preproc.c >> > -  33651 ./backend/parser/gram.c >> > -  1755

Re: [HACKERS] Redundant bitmap index scans on smallint column

On Tue, Sep 6, 2011 at 19:51, Tom Lane wrote: > Marti Raudsepp writes: >> So it seems the more fundamental issue is that b=0 and b='0' >> conditions are normalized differently when b is smallint. > > That's not a "fundamental issue", if by that you mean that it's a bug to > be fixed. That was a

Re: [HACKERS] timezone GUC

Bruce Momjian writes: > Was this dealt with? Yes, as much as I think is reasonable anyway. See commit e05b866447899211a0c2df31bf0671faac4fc3e5. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [COMMITTERS] pgsql: Clean up the #include mess a little.

Excerpts from Ants Aasma's message of mar sep 06 12:40:04 -0300 2011: > On Mon, Sep 5, 2011 at 4:55 PM, Greg Stark wrote: > > What I wouldn't mind seeing is a graph of all includes and what they > > include. This might help figure out what layering violations there are > > like the one that caused

Re: [HACKERS] timezone GUC

Tom Lane wrote: > Robert Haas writes: > > If you have the timezone configured to a non-default value in > > postgresql.conf, and you comment it out and reload, it says: > > > LOG: parameter "TimeZone" removed from configuration file, reset to default > > > ...but at least when I tested it, it d

Re: [HACKERS] memory-related bugs

[ Sorry for letting this slip through the cracks ... I think I got distracted by collation bugs :-( ] Noah Misch writes: > On Sat, Mar 12, 2011 at 12:44:29PM -0500, Tom Lane wrote: >> Noah Misch writes: >>> A suitably-instrumented run of "make installcheck-world" under valgrind >>> turned >>>

Re: [HACKERS] Alpha 1 for 9.2

> Yes, it has always been a time vs. value question. I am not sure how I > feel on the matter but I am away too often to help anyway. I think the alphas have been extremely valuable for testing. And with some of the stuff going into CF1 and CF2 for 9.2, we really need some early testing. Or, t

Re: [HACKERS] WIP: SP-GiST, Space-Partitioned GiST

On Tue, Sep 6, 2011 at 10:21 PM, Andreas Joseph Krogh wrote: > Sorry for not getting the might-be-obvious here, but will this patch > bring indexed substring-search to PG? So queries conceptually equal to > this will be possible to index: WHERE som_col @@ > ':substr1:&:substr2!substr3:' meaning "c

Re: [HACKERS] [PATCH] Generate column names for subquery expressions

Here's version 2 of the patch, mainly to silence compiler warnings about missing "case" statements from a switch over SubLinkType enum. Also expanded commit message a little and changed whitespace to be more consistent with nearby code. Regards, Marti From 9f987efacfe2cd2af82722775127605e690df976

Re: [HACKERS] WIP: SP-GiST, Space-Partitioned GiST

On 09/06/2011 07:34 PM, Oleg Bartunov wrote: > Here is the latest spgist patch, which has all planned features as > well as > all overhead, introduced by concurrency and recovery, so performance > measurement should be realistic now. > > Oleg Sorry for not getting the might-be-obvious here, but wi

Re: [HACKERS] Transforming IN (...) to ORs, volatility

Heikki Linnakangas wrote: > On 06.09.2011 20:53, Bruce Momjian wrote: > > Tom Lane wrote: > >> Bruce Momjian writes: > >>> Uh, have we addressed this? I don't think so. > >> > >> No. IIRC, I didn't like Heikki's proposed patch, so it's on my head > >> to come up with something better. > > > > Yo

Re: [HACKERS] Transforming IN (...) to ORs, volatility

On 06.09.2011 20:53, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian writes: Uh, have we addressed this? I don't think so. No. IIRC, I didn't like Heikki's proposed patch, so it's on my head to come up with something better. You can blame me for getting it into the parser. It used to

Re: [HACKERS] Transforming IN (...) to ORs, volatility

Tom Lane wrote: > Bruce Momjian writes: > > Uh, have we addressed this? I don't think so. > > No. IIRC, I didn't like Heikki's proposed patch, so it's on my head > to come up with something better. You can blame me for getting it into the parser. It used to be in gram.y! -- Bruce Momjian

Re: [HACKERS] Transforming IN (...) to ORs, volatility

Bruce Momjian writes: > Uh, have we addressed this? I don't think so. No. IIRC, I didn't like Heikki's proposed patch, so it's on my head to come up with something better. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Transforming IN (...) to ORs, volatility

Heikki Linnakangas wrote: > Nope, this hasn't been addressed. FWIW, I put it on the todo list when I > stopped working on it. Oh, I see it now. Thanks. --- > > On 06.09.2011 20:48, Bruce Momjian wrote: > > > > Uh, have we

Re: [HACKERS] Transforming IN (...) to ORs, volatility

Nope, this hasn't been addressed. FWIW, I put it on the todo list when I stopped working on it. On 06.09.2011 20:48, Bruce Momjian wrote: Uh, have we addressed this? I don't think so. --- Heikki Linnakangas wrote: On 0

Re: [HACKERS] Transforming IN (...) to ORs, volatility

Uh, have we addressed this? I don't think so. --- Heikki Linnakangas wrote: > On 02.04.2011 20:48, Tom Lane wrote: > > Heikki Linnakangas writes: > >> We sometimes transform IN-clauses to a list of ORs: > >> postgres=# exp

Re: [HACKERS] Alpha 1 for 9.2

Robert Haas wrote: > 2011/9/6 Bruce Momjian : > > Devrim G?ND?Z wrote: > >> Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? > > > > We talked about it on core and no one seems interested in doing the > > packaging. ?:-( > > Well I don't particularly mind pushing a tag and bundli

Re: [HACKERS] Alpha 1 for 9.2

2011/9/6 Bruce Momjian : > Devrim GÜNDÜZ wrote: >> Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? > > We talked about it on core and no one seems interested in doing the > packaging.  :-( Well I don't particularly mind pushing a tag and bundling it, but I guess the question is

Re: [HACKERS] WIP: SP-GiST, Space-Partitioned GiST

Here is the latest spgist patch, which has all planned features as well as all overhead, introduced by concurrency and recovery, so performance measurement should be realistic now. Oleg On Mon, 5 Sep 2011, Oleg Bartunov wrote: I attached wrong patch in previous message, sorry ! Here is a las

Re: [HACKERS] Redundant bitmap index scans on smallint column

Marti Raudsepp writes: > On Mon, Sep 5, 2011 at 21:01, Tom Lane wrote: >> What we have to start with is WHERE b = 0::smallint, which the planner >> is able to prove implies the index predicate WHERE b = 0::integer, >> so both indexes are considered.  But the check for predicate redundancy >> in

Re: [HACKERS] Couple document fixes

David Fetter writes: > On Mon, Sep 05, 2011 at 10:07:29PM -0300, Alvaro Herrera wrote: >> What would be the point? > Removing the legacy "char" type, per original post. :) Removing it is the wrong solution. The idea of renaming it to char1 might be an appropriate balance of pain versus benefit.

Re: [HACKERS] B-tree parent pointer and checkpoints

On Tue, Sep 6, 2011 at 10:03 AM, Bruce Momjian wrote: > Robert Haas wrote: >> On Tue, Sep 6, 2011 at 9:45 AM, Heikki Linnakangas >> wrote: >> >> Do you really need to hold the page locks for all that time, or could >> >> you cheat? ?Like... release the locks on the split pages but then go >> >> b

Re: [HACKERS] Alpha 1 for 9.2

On Tue, 2011-09-06 at 10:06 -0400, Bruce Momjian wrote: > > Devrim GNDZ wrote: > > Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? > > We talked about it on core and no one seems interested in doing the > packaging. :-( Oh, what if noone will be interested in packaging until

Re: [HACKERS] spinlocks on HP-UX

> That would be great. What I've been using as a test case is pgbench > -S -c $NUM_CPU_CORES -j $NUM_CPU_CORES with scale factor 100 and > shared_buffers=8GB. > > I think what you'd want to compare is the performance of unpatched > master, vs. the performance with this line added to s_lock.h for

Re: [HACKERS] Alpha 1 for 9.2

Devrim G?ND?Z wrote: > Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? We talked about it on core and no one seems interested in doing the packaging. :-( -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's

Re: [HACKERS] Large C files

Peter Eisentraut wrote: > On l?r, 2011-09-03 at 19:18 -0400, Bruce Momjian wrote: > > FYI, here are all the C files with over 6k lines: > > > > - 45133 ./interfaces/ecpg/preproc/preproc.c > > - 33651 ./backend/parser/gram.c > > - 17551 ./backend/parser/scan.c > >14209 ./bin/pg_dump/pg_dump.

Re: [HACKERS] B-tree parent pointer and checkpoints

Robert Haas wrote: > On Tue, Sep 6, 2011 at 9:45 AM, Heikki Linnakangas > wrote: > >> Do you really need to hold the page locks for all that time, or could > >> you cheat? ?Like... release the locks on the split pages but then go > >> back and reacquire them to clear the flag... > > > > Hmm, there

Re: [HACKERS] Rectifying wrong Date outputs

Bruce Momjian wrote: > Piyush Newe wrote: > > Hi, > > > > I was randomly testing some date related stuff on PG & observed that the > > outputs were wrong. > > > > e.g. > > postgres=# SELECT TO_DATE('01-jan-2010', 'DD-MON-YY'); > > to_date > > > > 3910-01-01 <- Look at th

Re: [HACKERS] WIP: Fast GiST index build

Hi! > Unlogged tables seems to me to follow a similar goal. Obviously GiST > indexes are not supported there. > Do you know the technical reason? > GiST using serial numbers of operations for concurrency. In current implementation xlog record ids are used in capacity of that numbers. In unlogged

[HACKERS] Alpha 1 for 9.2

Hi, Is there a plan to wrap up 9.2 Alpha 1 before the next commitfest? Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http:/

Re: [HACKERS] B-tree parent pointer and checkpoints

On Tue, Sep 6, 2011 at 9:45 AM, Heikki Linnakangas wrote: >> Do you really need to hold the page locks for all that time, or could >> you cheat?  Like... release the locks on the split pages but then go >> back and reacquire them to clear the flag... > > Hmm, there's two issues with that: > > 1. W

Re: [HACKERS] spinlocks on HP-UX

On Tue, Sep 6, 2011 at 4:33 AM, Tatsuo Ishii wrote: > I am interested in this thread because I may be able to borrow a big > IBM machine and might be able to do some tests on it if it somewhat > contributes enhancing PostgreSQL. Is there anything I can do for this? That would be great. What I've

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On 09/06/2011 09:35 AM, Robert Haas wrote: [git notes is more than cumbersome ] As much as I'd like to have something like this, I'm inclined to think that it will take a whole lot more time to get this facility working than it's really worth. Unless someone has a strong opinion the other w

Re: [HACKERS] B-tree parent pointer and checkpoints

On 06.09.2011 16:40, Robert Haas wrote: On Tue, Sep 6, 2011 at 6:21 AM, Heikki Linnakangas wrote: The way it would work is that on page split the right page is flagged with MISSING_DOWNLINK flag. When the downlink is inserted into the parent, the flag is cleared in the same critical section as

Re: [HACKERS] WIP: Fast GiST index build

Hi, Unlogged tables seems to me to follow a similar goal. Obviously GiST indexes are not supported there. Do you know the technical reason? Do you see some synergy in your work on fast GiST index building and unlogged tables? Yours, Stefan 2011/9/6 Alexander Korotkov : > Small bugfix: in gistBuf

Re: [HACKERS] B-tree parent pointer and checkpoints

On Tue, Sep 6, 2011 at 6:21 AM, Heikki Linnakangas wrote: > Nope. > > On a closer look, this isn't only a problem for page deletion. Page > splitting also barfs if it can't find the parent of a page. As the code > stands, a missing downlink is not harmless, but causes all sorts of trouble. > > The

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On Tue, Sep 6, 2011 at 12:41 AM, Alvaro Herrera wrote: >> > Pity we can't use git notes. >> >> Well, I guess there's no law that says we can't.  Should I give it a try? > > I don't see why not :-)  (But my guess is that you're going to need to > publish some pull and push instructions, because I g

Re: [HACKERS] [GENERAL] pg_upgrade problem

Hi, Worked a bit to get the ltree problem down to smallest possible, repeatable, situation. Initial setup: 1. PostgreSQL 8.3.11, configured with: ./configure\ --prefix=/opt/pgsql-8.3.11-int \ --disable-rpath\ --without-perl

Re: [HACKERS] [GENERAL] pg_upgrade problem

On Mon, Sep 05, 2011 at 05:26:00PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Odd it is dying in the memory freeing at executor close --- not in the > > ltree code. > > Doesn't seem odd. The glibc complaint previously shown already > indicates this is a memory stomp problem. > > --enabl

Re: [HACKERS] B-tree parent pointer and checkpoints

On 05.09.2011 21:55, Bruce Momjian wrote: Heikki Linnakangas wrote: On 11.03.2011 19:41, Tom Lane wrote: Heikki Linnakangas writes: On 11.03.2011 17:59, Tom Lane wrote: But that will be fixed during WAL replay. Not under the circumstances that started the original thread: 1. Backend s

Re: [HACKERS] Redundant bitmap index scans on smallint column

On Mon, Sep 5, 2011 at 21:01, Tom Lane wrote: > What we have to start with is WHERE b = 0::smallint, which the planner > is able to prove implies the index predicate WHERE b = 0::integer, > so both indexes are considered.  But the check for predicate redundancy > in choose_bitmap_and() only uses s

Re: [HACKERS] spinlocks on HP-UX

Hi, I am interested in this thread because I may be able to borrow a big IBM machine and might be able to do some tests on it if it somewhat contributes enhancing PostgreSQL. Is there anything I can do for this? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japa

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On 2011-09-06 04:55, Robert Haas wrote: On Mon, Sep 5, 2011 at 10:52 PM, Alvaro Herrera wrote: Excerpts from Robert Haas's message of lun sep 05 23:27:16 -0300 2011: On Mon, Sep 5, 2011 at 9:14 AM, Yeb Havinga wrote: I didn't see my name as one of the reviewers in the commit message. If tha

Re: [HACKERS] Large C files

On lör, 2011-09-03 at 19:18 -0400, Bruce Momjian wrote: > FYI, here are all the C files with over 6k lines: > > - 45133 ./interfaces/ecpg/preproc/preproc.c > - 33651 ./backend/parser/gram.c > - 17551 ./backend/parser/scan.c >14209 ./bin/pg_dump/pg_dump.c >10590 ./backend/access/transam/