Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, 2011-04-20 at 21:09 -0400, Robert Haas wrote: > But > even then I think we'd have this problem of people being unwilling to > give up on jamming stuff into a release, regardless of the scheduling > impact of doing so. I actually think the problem of getting releases > out on time is a *muc

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 20, 2011 at 11:39:47AM -0700, Josh Berkus wrote: [...] > Review of design concepts and WIP patches has *always* been a problem > for this project [...] > We tell people to submit a design concept, but then such submissions are > often ig

[HACKERS] smallserial / serial2

I use tables all the time that have sequences on smallint's; I'd like to simplify my create files by not having to create the sequence first, but I also don't want to give up those 2 bytes per column! Can this be added? Mike --- postgresql-9.0.4/src/backend/parser/parse_utilcmd.

Re: [HACKERS] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

On Apr 20, 2011, at 11:37 PM, Tom Lane wrote: > >> But one might well wonder why we didn't decide on: >> CREATE TABLE n OF TYPE t; >> ...rather than the actual syntax: >> CREATE TABLE n OF t; >> ...which has brevity to recommend it, but likewise isn't terribly clear. > >> I presume someone will

Re: [HACKERS] Extension Packaging

On Apr 20, 2011, at 8:25 PM, David E. Wheeler wrote: > Okay. What about building something into PGXS that could handle these kinds > of things? I just can't help but wonder if there isn't some better way to do > the kinds of things that Daniele and I have resorted to to use a PostgreSQL > versi

Re: [HACKERS] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

Robert Haas writes: > On Wed, Apr 20, 2011 at 10:51 PM, Tom Lane wrote: >> How about "ALTER TABLE tabname [NOT] OF TYPE typename"? It's at least a >> smidgeon less ambiguous. > I thought of that, but I hate to make CREATE TABLE and ALTER TABLE > almost-but-not-quite symmetrical. Oh, good point.

Re: [HACKERS] Extension Packaging

On Apr 20, 2011, at 8:04 PM, Daniele Varrazzo wrote: > Specifically, I parse the version from the control file using: > >PGMP_VERSION=$(shell grep default_version pgmp.control | sed -e > "s/default_version = '\(.*\)'/\1/") Oh, that's not bad. Thanks. > so the Makefile doesn't have to be mai

Re: [HACKERS] Extension Packaging

On Apr 20, 2011, at 8:16 PM, Tom Lane wrote: > I'm not interested in kluging things up after the fact to try to somehow > reverse that mindset and make pre-extension-world and post-extension-world > scripts compatible. That looks like long-term pain in return for very > small short-term gain to m

Re: [HACKERS] time-delayed standbys

On Wed, Apr 20, 2011 at 11:15 AM, Tom Lane wrote: > Robert Haas writes: >> I am a bit concerned about the reliability of this approach.  If there >> is some network lag, or some lag in processing from the master, we >> could easily get the idea that there is time skew between the machines >> when

Re: [HACKERS] Extension Packaging

"David E. Wheeler" writes: > * I would love to be able to maintain a single file for the default > version of an extension. Basically, this wasn't and isn't on the list of considerations. There has never been any expectation that a contrib module could use the exact same SQL script for every Pos

Re: [HACKERS] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

On Wed, Apr 20, 2011 at 10:51 PM, Tom Lane wrote: > Robert Haas writes: >> I've now committed this part; the actual fix for pg_dump is still >> outstanding.  I am not too in love with the syntax you've chosen here, >> but since I don't have a better idea I'll wait and see if anyone else >> wants

Re: [HACKERS] Extension Packaging

On Thu, Apr 21, 2011 at 1:14 AM, David E. Wheeler wrote: > I finally got round to updating a couple of my extensions to support 9.1 > extensions. Unlike the contrib extensions, these needed to target older > versions of PostgreSQL, as well. Case in point, the semver data type; you > might find

Re: [HACKERS] Typed table DDL loose ends

On Wed, Apr 20, 2011 at 10:53 AM, Noah Misch wrote: > On Mon, Apr 18, 2011 at 10:44:53PM +0300, Peter Eisentraut wrote: >> On Sat, 2011-04-09 at 21:57 -0400, Noah Misch wrote: >> > * Inheriting from a typed table blocks further type DDL >> >   CREATE TYPE t AS (x int); >> >   CREATE TABLE parent O

Re: [HACKERS] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

Robert Haas writes: > I've now committed this part; the actual fix for pg_dump is still > outstanding. I am not too in love with the syntax you've chosen here, > but since I don't have a better idea I'll wait and see if anyone else > wants to bikeshed. How about "ALTER TABLE tabname [NOT] OF TYP

Re: [HACKERS] unexpected default ACL type 83

On Wed, Apr 20, 2011 at 7:34 AM, Shigeru Hanada wrote: > I found that DROP OWNED BY can cause $SUBJECT. > > How to reproduce the error: > > > CREATE USER foo; > ALTER DEFAULT PRIVILEGES GRANT ALL ON SEQUENCES TO foo; > DROP OWNED BY foo; > > > Attached patch would fix this issue. Nice c

Re: [HACKERS] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

On Wed, Apr 20, 2011 at 6:36 PM, Noah Misch wrote: > On Wed, Apr 20, 2011 at 01:10:19PM -0400, Robert Haas wrote: >> On Wed, Apr 20, 2011 at 9:57 AM, Noah Misch wrote: >> > On Tue, Apr 19, 2011 at 10:36:14PM -0400, Robert Haas wrote: >> >> On Mon, Apr 18, 2011 at 7:50 PM, Noah Misch wrote: >> >>

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 7:00 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mié abr 20 16:22:24 -0300 2011: > >> > If people PERCEIVE there is a problem, THERE IS A PROBLEM. >> >> Absolutely.  And I am perfectly well aware that we have screwed this >> up from time to time.  But

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 3:42 PM, Josh Berkus wrote: > On 4/20/11 12:35 PM, Tom Lane wrote: >> Well, no, that's not the whole story.  To me, what the above idea >> implies is shifting more of the burden of fixing up patches away from >> the committer and back to the patch author.  Instead of spendi

[HACKERS] Extension Packaging

Hackers, I finally got round to updating a couple of my extensions to support 9.1 extensions. Unlike the contrib extensions, these needed to target older versions of PostgreSQL, as well. Case in point, the semver data type; you might find the Makefile of particular interest: https://github.c

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Excerpts from Robert Haas's message of mié abr 20 16:22:24 -0300 2011: > > If people PERCEIVE there is a problem, THERE IS A PROBLEM. > > Absolutely. And I am perfectly well aware that we have screwed this > up from time to time. But I also know that I have spent a very large > amount of time o

Re: [HACKERS] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

On Wed, Apr 20, 2011 at 01:10:19PM -0400, Robert Haas wrote: > On Wed, Apr 20, 2011 at 9:57 AM, Noah Misch wrote: > > On Tue, Apr 19, 2011 at 10:36:14PM -0400, Robert Haas wrote: > >> On Mon, Apr 18, 2011 at 7:50 PM, Noah Misch wrote: > >> > On Fri, Apr 15, 2011 at 11:58:30AM -0400, Noah Misch wr

Re: [HACKERS] pgindent weirdness

On 04/20/2011 05:29 PM, Tom Lane wrote: Andrew Dunstan writes: On 04/20/2011 04:28 PM, Bruce Momjian wrote: So the list of possible additions Andrew supplied are cases where we never reference those typedefs --- seems like a cleanup opportunity. I think the best cleanup idea is Aidan's, nam

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: > Andrew Dunstan writes: > > On 04/20/2011 04:28 PM, Bruce Momjian wrote: > >> So the list of possible additions Andrew supplied are cases where we > >> never reference those typedefs --- seems like a cleanup opportunity. > > > I think the best cleanup idea is Aidan's, namely is w

Re: [HACKERS] Re: [COMMITTERS] pgsql: setlocale() on Windows doesn't work correctly if the locale name

(2011/04/20 15:30), Heikki Linnakangas wrote: > On 20.04.2011 06:48, Hiroshi Inoue wrote: >> I can find no concrete reference to problems about locale >>names containing dots. Is the following an example? > > Yes. > >> In my environment (Windows Vista using VC8) >> >> setlocale(LC_, "

Re: [HACKERS] Re: [COMMITTERS] pgsql: setlocale() on Windows doesn't work correctly if the locale name

(2011/04/20 22:08), Tom Lane wrote: > Hiroshi Inoue writes: >> In my environment (Windows Vista using VC8) > >>setlocale(LC_, "Chinese (Traditional)_MCO.950"); >> works and >>setlocale(LC_, NULL); >> returns >>Chinese (Traditional)_Macao S.A.R..950 >> but >>setlocale(LC_XX

Re: [HACKERS] pgindent weirdness

Andrew Dunstan writes: > On 04/20/2011 04:28 PM, Bruce Momjian wrote: >> So the list of possible additions Andrew supplied are cases where we >> never reference those typedefs --- seems like a cleanup opportunity. > I think the best cleanup idea is Aidan's, namely is we have declared > "typdef s

Re: [HACKERS] CLUSTER versus broken HOT chains

I wrote: > I believe I've worked out what's going on in bug #5985. > ... > So this leads me to a few thoughts: > 1. Now that we have the seqscan-and-sort code path, it'd be possible to > support CLUSTER on a not-indisvalid index, at least when it's a btree > index. We just have to force it into t

Re: [HACKERS] pgindent weirdness

On 04/20/2011 04:28 PM, Bruce Momjian wrote: So the list of possible additions Andrew supplied are cases where we never reference those typedefs --- seems like a cleanup opportunity. I think the best cleanup idea is Aidan's, namely is we have declared "typdef struct foo { ... } foo;" we sho

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, 2011-04-20 at 16:25 -0400, Tom Lane wrote: > But ignoring scheduling difficulties, my point here is that > it seems like the shorter the cycle, the better, for a lot of > purposes. Can we do any better than once-a-month, or is that the > limit given that people need flexible schedules with

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On 04/20/2011 12:22 PM, Robert Haas wrote: Well, you aren't fighting alone. We have significant problems in this area. As you said, we always have. There is also a bizarre, almost insane objection to using tools that "aren't invented here" to solve problems. The problems you (Josh) present are

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, 2011-04-20 at 15:09 -0400, Robert Haas wrote: > This would amount to reducing the amount of time we spend > in-CommitFest from 50% to slightly less than 25%. That would > certainly be pleasant from my point of view, but for the average patch > to get the same amount of attention, we'd need

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Tom, > True, and any fixed day of the week would let out X number of people > anyway. But ignoring scheduling difficulties, my point here is that > it seems like the shorter the cycle, the better, for a lot of purposes. > Can we do any better than once-a-month, or is that the limit given that > p

Re: [HACKERS] Still more REINDEX fun

Simon Riggs writes: > On Wed, Apr 20, 2011 at 7:41 PM, Tom Lane wrote: >> It's still true though that you have to be REINDEXing system catalogs to >> be at risk, else you shouldn't be seeing any IN_PROGRESS tuples. > So the fix seems to be that we make REINDEX on a system catalog lock > the whol

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, 2011-04-20 at 11:39 -0700, Josh Berkus wrote: > Maybe we don't want to use ReviewBoard specifically. Maybe we want > to use bugzilla or Crucible or Redmine something more specific for > patch/spec review. But I think it's time to try something else, maybe > several other things. I had s

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: > Andrew Dunstan writes: > > On 04/20/2011 01:16 PM, Bruce Momjian wrote: > >>> This implies to me that we changed something about how we handle this > >>> since we did the 9.0 runs, but I don't know what it was. Should I? > > >> I think Andrew also supplied the typedef list for

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Andrew Dunstan writes: > On 04/20/2011 04:09 PM, Magnus Hagander wrote: >> On Wed, Apr 20, 2011 at 21:54, Tom Lane wrote: >>> BTW, just as a thought experiment: what about a one-day CF once a week? >>> "Patch Tuesdays", if you will. Spend all day reviewing/committing, >>> bounce back whatever is

Re: [HACKERS] pl/python tracebacks v2

On Wed, 2011-04-06 at 23:54 +0200, Jan Urbański wrote: > > Ouch, just today I found a flaw in this, namely that it assumes the > > lineno from the traceback always refers to the PL/Python function. If > > you create a PL/Python function that imports some code, runs it, and > > that code raises an e

Re: [HACKERS] Still more REINDEX fun

On Wed, Apr 20, 2011 at 7:41 PM, Tom Lane wrote: > It's still true though that you have to be REINDEXing system catalogs to > be at risk, else you shouldn't be seeing any IN_PROGRESS tuples. So the fix seems to be that we make REINDEX on a system catalog lock the whole catalog table. Anything e

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On 04/20/2011 04:09 PM, Magnus Hagander wrote: On Wed, Apr 20, 2011 at 21:54, Tom Lane wrote: Peter Eisentraut writes: I would imagine one commit fest per month, but it's only a week long. BTW, just as a thought experiment: what about a one-day CF once a week? "Patch Tuesdays", if you will

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 21:54, Tom Lane wrote: > Peter Eisentraut writes: >> I would imagine one commit fest per month, but >> it's only a week long. > > BTW, just as a thought experiment: what about a one-day CF once a week? > "Patch Tuesdays", if you will.  Spend all day reviewing/committing, >

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Peter Eisentraut writes: > I would imagine one commit fest per month, but > it's only a week long. BTW, just as a thought experiment: what about a one-day CF once a week? "Patch Tuesdays", if you will. Spend all day reviewing/committing, bounce back whatever is not ready, patch authors try again

Re: [HACKERS] pgindent weirdness

Andrew Dunstan writes: > On 04/20/2011 01:16 PM, Bruce Momjian wrote: >>> This implies to me that we changed something about how we handle this >>> since we did the 9.0 runs, but I don't know what it was. Should I? >> I think Andrew also supplied the typedef list for the 9.0 run. > Yes. But in

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 3:05 PM, Josh Berkus wrote: > On 4/20/11 12:00 PM, Robert Haas wrote: >> Please provide the evidence that this is a problem that exists now, as >> opposed to seven years ago. > > Since you're clearly already made up your mind that no problem exists, I > don't have the energ

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Robert, > Absolutely. And I am perfectly well aware that we have screwed this > up from time to time. But I also know that I have spent a very large > amount of time over the last few years trying to improve things. It > would be nice to know whether that has had any impact. If it hasn't, > th

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On 4/20/11 12:35 PM, Tom Lane wrote: > Well, no, that's not the whole story. To me, what the above idea > implies is shifting more of the burden of fixing up patches away from > the committer and back to the patch author. Instead of spending time > fixing up not-quite-ready patches myself, I'd be

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Robert Haas writes: > On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund wrote: >> On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote: >>> Yeah, maybe. To do that, we'd have to strongly resist the temptation to >>> spend a lot of time fixing up submitted patches --- if it's not pretty >>> darn

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wednesday, April 20, 2011 08:53:34 PM Andres Freund wrote: > On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote: > > > I think we should put less temporal emphasis on the finishing part, but > > > use the time better. I would imagine one commit fest per month, but > > > it's only a week lo

Re: [HACKERS] pgbench \for or similar loop

On Wed, Apr 20, 2011 at 2:23 PM, David Fetter wrote: > On Wed, Apr 20, 2011 at 02:12:25PM -0400, Robert Haas wrote: >> On Wed, Apr 20, 2011 at 2:10 PM, David Fetter wrote: >> > It is precisely this kind of issue that leads me to believe it would >> > be counter-productive to come up with any clie

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 3:13 PM, Joshua D. Drake wrote: > On 04/20/2011 12:05 PM, Josh Berkus wrote: >> >> On 4/20/11 12:00 PM, Robert Haas wrote: >>> >>> Please provide the evidence that this is a problem that exists now, as >>> opposed to seven years ago. >> >> Since you're clearly already made

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wednesday, April 20, 2011 09:09:48 PM Robert Haas wrote: > On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund wrote: > > On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote: > >> Yeah, maybe. To do that, we'd have to strongly resist the temptation to > >> spend a lot of time fixing up submitte

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On 04/20/2011 12:05 PM, Josh Berkus wrote: On 4/20/11 12:00 PM, Robert Haas wrote: Please provide the evidence that this is a problem that exists now, as opposed to seven years ago. Since you're clearly already made up your mind that no problem exists, I don't have the energy to fight it out wi

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wednesday, April 20, 2011 08:39:47 PM Josh Berkus wrote: > Robert, > > > Unfortunately, my memory of this project only goes back to about > > September 2008, which isn't far enough to remember why CommitFests > > were created in the first place. So Alvaro may be correct in saying > > that thin

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 2:53 PM, Andres Freund wrote: > On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote: >> > I think we should put less temporal emphasis on the finishing part, but >> > use the time better.  I would imagine one commit fest per month, but >> > it's only a week long.  Then

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On 4/20/11 12:00 PM, Robert Haas wrote: > Please provide the evidence that this is a problem that exists now, as > opposed to seven years ago. Since you're clearly already made up your mind that no problem exists, I don't have the energy to fight it out with you. -- Josh Berkus PostgreSQL Expert

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 2:39 PM, Josh Berkus wrote: > Review of design concepts and WIP patches has *always* been a problem > for this project.  Andrew Sullivan bitched about it at some length back > in 2004 ("Why there is no traffic on pgsql-replicationhooks", but > Andrew's blog is down now unfo

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wednesday, April 20, 2011 08:50:04 PM Tom Lane wrote: > > I think we should put less temporal emphasis on the finishing part, but > > use the time better. I would imagine one commit fest per month, but > > it's only a week long. Then everyone can really concentrate on the > > commit fest, peop

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Peter Eisentraut writes: > I think we should put less temporal emphasis on the finishing part, but > use the time better. I would imagine one commit fest per month, but > it's only a week long. Then everyone can really concentrate on the > commit fest, people get faster feedback, but there is ul

[HACKERS] Still more REINDEX fun

What with the recent discussions, I've been looking harder at the REINDEX code's interactions with HOT, and I've found another problem altogether. To wit, IndexBuildHeapScan considers the DELETE_IN_PROGRESS case to be comparable to RECENTLY_DEAD, but that analogy fails for HOT-updated tuples. If

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Robert, > Unfortunately, my memory of this project only goes back to about > September 2008, which isn't far enough to remember why CommitFests > were created in the first place. So Alvaro may be correct in saying > that things have mutated over time, but that isn't necessarily a bad > thing. Ma

Re: [HACKERS] pgindent weirdness

On 04/20/2011 01:10 PM, Tom Lane wrote: Aidan Van Dyk writes: Since the general form seems to be to declare things as: typedef struct foo { ... } foo; Is there any reason why we see any struct foo in the sources other than in the typedef line? It gives an escape hatch in case you need a

Re: [HACKERS] pgbench \for or similar loop

On Wed, Apr 20, 2011 at 02:12:25PM -0400, Robert Haas wrote: > On Wed, Apr 20, 2011 at 2:10 PM, David Fetter wrote: > > It is precisely this kind of issue that leads me to believe it would > > be counter-productive to come up with any client-specific hacks. > > These definitional issues exist on

Re: [HACKERS] pgindent weirdnessf

On 04/20/2011 01:59 PM, Bruce Momjian wrote: I do, agree, though, it would be nice to find out what changed that caused this. I am 100% certain that it's the tools that have changed. I bet if I were to hunt in my pile of old DVDs and find installation media for Fedora 6 or thereabouts and

Re: [HACKERS] pgbench \for or similar loop

On Wed, Apr 20, 2011 at 2:10 PM, David Fetter wrote: > It is precisely this kind of issue that leads me to believe it would > be counter-productive to come up with any client-specific hacks. These definitional issues exist on the server, too, and weren't considered early enough there either. Pre

Re: [HACKERS] pgbench \for or similar loop

On Wed, Apr 20, 2011 at 01:35:03PM -0400, Robert Haas wrote: > On Wed, Apr 20, 2011 at 10:46 AM, Merlin Moncure wrote: > > On Wed, Apr 20, 2011 at 9:14 AM, Alvaro Herrera > > wrote: > >> Excerpts from David Fetter's message of mié abr 20 10:54:56 -0300 2011: > >>> On Wed, Apr 20, 2011 at 08:05:07

Re: [HACKERS] pgindent weirdnessf

Robert Haas wrote: > On Wed, Apr 20, 2011 at 12:33 PM, Andrew Dunstan wrote: > > You can contribute to the list by running a buildfarm animal on your machine > > and running its find_typedefs occasionally. This is not just about me. I > > have asked on numerous occasions for other people to contri

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, 2011-04-20 at 12:21 -0400, Tom Lane wrote: > Well, I absolutely think that we need to encourage people to get > feedback at the design and prototype stages. The problem with the > commitfest mechanism for that is that when you are trying to work out > a patch, you don't want to wait around

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, 2011-04-20 at 17:52 +0100, Greg Stark wrote: > I admit though this whole concept of "finished patches" seems foreign > to me. I always have additional stuff I want to do and if the patch > sits on the shelf I'm essentially stuck unable to work on the next > great thing that that patch enabl

Re: [HACKERS] pgbench \for or similar loop

On Wed, Apr 20, 2011 at 10:46 AM, Merlin Moncure wrote: > On Wed, Apr 20, 2011 at 9:14 AM, Alvaro Herrera > wrote: >> Excerpts from David Fetter's message of mié abr 20 10:54:56 -0300 2011: >>> On Wed, Apr 20, 2011 at 08:05:07AM +0200, Pavel Stehule wrote: >>> > Hello >>> > >>> > I played with ps

Re: [HACKERS] pgindent weirdness

On 04/20/2011 01:16 PM, Bruce Momjian wrote: This implies to me that we changed something about how we handle this since we did the 9.0 runs, but I don't know what it was. Should I? I think Andrew also supplied the typedef list for the 9.0 run. Yes. But in November, the server where all m

Re: [HACKERS] pgindent weirdnessf

On Wed, Apr 20, 2011 at 12:33 PM, Andrew Dunstan wrote: > You can contribute to the list by running a buildfarm animal on your machine > and running its find_typedefs occasionally. This is not just about me. I > have asked on numerous occasions for other people to contribute, and the > response ha

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 12:21 PM, Tom Lane wrote: > Alvaro Herrera writes: >> I think this is historical revisionism. ... >> Somewhere down the line this seems to have been forgotten and we are now >> using commitfests just to track finished patches. > >> So if we want to stick to the original pr

Re: [HACKERS] pgindent weirdness

On 04/20/2011 01:12 PM, Robert Haas wrote: On Wed, Apr 20, 2011 at 11:15 AM, Andrew Dunstan wrote: I did carefully warn you about the need to check the effects of the changes when I committed the new list. It looks like quite a few of the deletions come into this category, for example just l

Re: [HACKERS] pgindent weirdness

Robert Haas wrote: > On Wed, Apr 20, 2011 at 11:15 AM, Andrew Dunstan wrote: > > I did carefully warn you about the need to check the effects of the changes > > when I committed the new list. > > > > It looks like quite a few of the deletions come into this category, for > > example just looking a

Re: [HACKERS] pgindent weirdness

On Wed, Apr 20, 2011 at 11:15 AM, Andrew Dunstan wrote: > I did carefully warn you about the need to check the effects of the changes > when I committed the new list. > > It looks like quite a few of the deletions come into this category, for > example just looking at the diff here >

Re: [HACKERS] pg_dump --binary-upgrade vs. ALTER TYPE ... DROP ATTRIBUTE

On Wed, Apr 20, 2011 at 9:57 AM, Noah Misch wrote: > On Tue, Apr 19, 2011 at 10:36:14PM -0400, Robert Haas wrote: >> On Mon, Apr 18, 2011 at 7:50 PM, Noah Misch wrote: >> > On Fri, Apr 15, 2011 at 11:58:30AM -0400, Noah Misch wrote: >> >> When we're done with the relkind-restriction patch, I'll p

Re: [HACKERS] pgindent weirdness

Aidan Van Dyk writes: > Since the general form seems to be to declare things as: >typedef struct foo { ... } foo; > Is there any reason why we see any struct foo in the sources other > than in the typedef line? It gives an escape hatch in case you need a forward reference to the struct, ie y

Re: [HACKERS] pgindent weirdness

On Wed, Apr 20, 2011 at 12:38 PM, Andrew Dunstan wrote: >> So in the case at hand, we actually *need* to remove the "struct" from >> RelationGetBufferForTuple's declaration, so that BulkInsertStateData >> gets used as a typedef name in that way. Since the general form seems to be to declare thin

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 5:21 PM, Tom Lane wrote: > Well, I absolutely think that we need to encourage people to get > feedback at the design and prototype stages.  The problem with the > commitfest mechanism for that is that when you are trying to work out a > patch, you don't want to wait around

Re: [HACKERS] pgindent weirdness

On 04/20/2011 12:29 PM, Tom Lane wrote: Andrew Dunstan writes: But in any case, *none* of the individual files knows about BulkInsertStateData as a typedef: ... And the reason is actually fairly obvious on closer inspection. The only place we actually use the BulkInsertStateData typedef (as o

Re: [HACKERS] pgindent weirdnessf

On 04/20/2011 11:48 AM, Bruce Momjian wrote: I assume you are using -g, right? Of course I did. I wouldn't have any symbols at all if I didn't. The BulkInsertStateData typedef looks pretty normal: typedef struct BulkInsertStateData { BufferAccessStrategy strate

Re: [HACKERS] pgindent weirdness

Andrew Dunstan writes: > But in any case, *none* of the individual files knows about > BulkInsertStateData as a typedef: > ... > And the reason is actually fairly obvious on closer inspection. The only > place we actually use the BulkInsertStateData typedef (as opposed to the > struct declarati

Re: [HACKERS] pgindent weirdness

On 04/20/2011 11:43 AM, Tom Lane wrote: Andrew Dunstan writes: On 04/20/2011 05:48 AM, Bruce Momjian wrote: BulkInsertStateData is not listed in the typedef list supplied by Andrew; see src/tools/pgindent/typedefs.list. CC'ing him. This might be because the typdef is listed in two files:

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Alvaro Herrera writes: > I think this is historical revisionism. ... > Somewhere down the line this seems to have been forgotten and we are now > using commitfests just to track finished patches. > So if we want to stick to the original principles we should have some > sort of "different set of r

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Now having said that, there seems to be a pgindent bug here too, in that > >> it's throwing a space into > >> > >> Buffer > >> RelationGetBufferForTuple(Relation relation, Size len, > >> Buffer otherBuffer, int options, > >> struct

Re: [HACKERS] pgbench \for or similar loop

On Wed, Apr 20, 2011 at 04:00:12PM +0200, Pavel Stehule wrote: > 2011/4/20 David Fetter : > > On Wed, Apr 20, 2011 at 08:05:07AM +0200, Pavel Stehule wrote: > >> Hello > >> > >> I played with psql extensions two years ago - it can do it > > > > It's interesting, but it doesn't solve the fundamental

Re: [HACKERS] pgindent weirdness

Bruce Momjian writes: > Tom Lane wrote: >> Now having said that, there seems to be a pgindent bug here too, in that >> it's throwing a space into >> >> Buffer >> RelationGetBufferForTuple(Relation relation, Size len, >> Buffer otherBuffer, int options, >> struct BulkInsertStateData * bistate) >>

Re: [HACKERS] REINDEX vs broken HOT chains, redux

Greg Stark writes: > On Wed, Apr 20, 2011 at 3:35 PM, Tom Lane wrote: >> System indexes really >> shouldn't be that much different from ordinary indexes.  The property >> we actually are relying on is that there can't be any HOT chains that >> break the index, because it existed before any update

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Excerpts from Tom Lane's message of mar abr 19 03:34:34 -0300 2011: > As Robert noted, the purpose of the commitfest mechanism is mostly to > ensure that patches that *are* committable, or close to it, don't fall > through the cracks. I'm not sure we're doing anybody any favors by > trying to sho

Re: [HACKERS] time-delayed standbys

On Wed, Apr 20, 2011 at 3:41 PM, Tom Lane wrote: > Greg Stark writes: >> Ah, so we did put the master's clock in every message? > > Yes, we did. And by "we" I mean "you" I realize I'm tossing in comments from the peanut gallery to you and especially Robert who worked on this stuff a lot alre

Re: [HACKERS] pgindent weirdness

Tom Lane wrote: > Andrew Dunstan writes: > > On 04/20/2011 05:48 AM, Bruce Momjian wrote: > >> BulkInsertStateData is not listed in the typedef list supplied by > >> Andrew; see src/tools/pgindent/typedefs.list. CC'ing him. This might > >> be because the typdef is listed in two files: > > > It'

Re: [HACKERS] pgindent weirdnessf

Andrew Dunstan wrote: > It's tagged as a structure type by objdump, but not as a typedef: > > <1><40055>: Abbrev Number: 4 (DW_TAG_typedef) > <40056> DW_AT_name: (indirect string, offset: 0x6bf6): > BulkInsertState > <4005a> DW_AT_decl_file : 30 > <4005b> DW_AT_

Re: [HACKERS] REINDEX vs broken HOT chains, redux

On Wed, Apr 20, 2011 at 3:35 PM, Tom Lane wrote: > System indexes really > shouldn't be that much different from ordinary indexes.  The property > we actually are relying on is that there can't be any HOT chains that > break the index, because it existed before any updates could have > happened.  

Re: [HACKERS] pgindent weirdness

Andrew Dunstan writes: > On 04/20/2011 05:48 AM, Bruce Momjian wrote: >> BulkInsertStateData is not listed in the typedef list supplied by >> Andrew; see src/tools/pgindent/typedefs.list. CC'ing him. This might >> be because the typdef is listed in two files: > It's tagged as a structure type b

Re: [HACKERS] pgindent weirdness

On 04/20/2011 05:48 AM, Bruce Momjian wrote: Robert Haas wrote: pgindent seems to have muffed it when it comes to BulkInsertStateData: diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c index 2849992..72a69e5 100644 --- a/src/backend/access/heap/hio.c +++ b/src/backend

Re: [HACKERS] time-delayed standbys

Robert Haas writes: > I am a bit concerned about the reliability of this approach. If there > is some network lag, or some lag in processing from the master, we > could easily get the idea that there is time skew between the machines > when there really isn't. And our perception of the time skew

Re: [HACKERS] Foreign table permissions and cloning

On Wed, Apr 20, 2011 at 9:59 AM, Tom Lane wrote: > Shigeru Hanada writes: >> Attached patch implements along specifications below.  It also includes >> documents and regression tests.  Some of regression tests might be >> redundant and removable. > >> 1) "GRANT privilege [(column_list)] ON [TABLE

Re: [HACKERS] time-delayed standbys

On Wed, Apr 20, 2011 at 10:19 AM, Tom Lane wrote: > Greg Stark writes: >> On Wed, Apr 20, 2011 at 2:19 PM, Robert Haas wrote: >>> How would we keep track of the most recent timestamp received from the >>> master without replaying the WAL records? > >> Well as we receive them we would have to pee

Re: [HACKERS] Typed table DDL loose ends

On Mon, Apr 18, 2011 at 10:44:53PM +0300, Peter Eisentraut wrote: > On Sat, 2011-04-09 at 21:57 -0400, Noah Misch wrote: > > * Inheriting from a typed table blocks further type DDL > > CREATE TYPE t AS (x int); > > CREATE TABLE parent OF t; > > CREATE TABLE child () INHERITS (parent); > > A

Re: [HACKERS] pgbench \for or similar loop

On Wed, Apr 20, 2011 at 9:14 AM, Alvaro Herrera wrote: > Excerpts from David Fetter's message of mié abr 20 10:54:56 -0300 2011: >> On Wed, Apr 20, 2011 at 08:05:07AM +0200, Pavel Stehule wrote: >> > Hello >> > >> > I played with psql extensions two years ago - it can do it >> >> It's interesting,

Re: [HACKERS] Typed table DDL loose ends

On Wed, Apr 20, 2011 at 12:26:01AM +0300, Peter Eisentraut wrote: > On Mon, 2011-04-18 at 19:34 -0400, Noah Misch wrote: > > On Mon, Apr 18, 2011 at 10:44:53PM +0300, Peter Eisentraut wrote: > > > On Sat, 2011-04-09 at 21:57 -0400, Noah Misch wrote: > > > > * Users can CREATE TABLE OF on a type the

  1   2   >