Re: [HACKERS] pgindent weirdness

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/access/heap/hio.c > @@ -150,7 +150,7

Re: [HACKERS] Foreign table permissions and cloning

(2011/04/15 3:43), Robert Haas wrote: On Fri, Apr 1, 2011 at 1:29 AM, Shigeru HANADA wrote: In addition to the 2nd GRANT above, "GRANT SELECT (colour) ON stuff TO user_a" (omitting TABLE) will succeed too because parser assumes that the target object is a regular table if object type was TABLE

Re: [HACKERS] Insufficient description in collation mismatch error

On Wed, Apr 20, 2011 at 1:37 AM, Tom Lane wrote: >> postgres=# SELECT things, count(*) FROM stuff GROUP BY things COLLATE "C"; >> ERROR:  column "stuff.things" must appear in the GROUP BY clause or be >> used in an aggregate function >> LINE 1: SELECT things, count(*) FROM stuff GROUP BY things CO

Re: [HACKERS] time-delayed standbys

On Wed, Apr 20, 2011 at 3:47 AM, Robert Haas wrote: > While I was out at the MySQL conference last week, I heard that one of > the forthcoming MySQL features is "time-delayed replication": Incidentally, this is a popular Oracle feature. It's a poor man's "flashback" and similar to how some filesy

Re: [HACKERS] time-delayed standbys

Hello yesterday I was asked about this feature +1 Regards Pavel 2011/4/20 Robert Haas : > While I was out at the MySQL conference last week, I heard that one of > the forthcoming MySQL features is "time-delayed replication": > > http://forge.mysql.com/worklog/task.php?id=344 > > That is, a sta

[HACKERS] unexpected default ACL type 83

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. Regards, -- Shigeru Hanada diff --git a/src/backend/catalog/aclchk.c b/src/backe

Re: [HACKERS] time-delayed standbys

On Wed, Apr 20, 2011 at 12:24 PM, Greg Stark wrote: > I haven't read the patch but are you delaying delivering the log or > delaying replaying it? I think you actually want the latter so in case > of a real failure you can choose between replaying the last 5 minutes > and recovering everything or

Re: [HACKERS] Build farm coverage for isolation tests

On 04/19/2011 11:53 AM, Kevin Grittner wrote: Andrew Dunstan wrote: I think the best thing might be to add a new step which runs the isolation check or installcheck. It would only need a small amount of perl code adde3d to the client to accomplish, and nothing on the server side. Since I'm

Re: [HACKERS] time-delayed standbys

Greg Stark writes: > On Wed, Apr 20, 2011 at 3:47 AM, Robert Haas wrote: > >> While I was out at the MySQL conference last week, I heard that one of >> the forthcoming MySQL features is "time-delayed replication": > > Incidentally, this is a popular Oracle feature. It's a poor man's > "flashback

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

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_, "Chinese (Traditional)_Macao S.A.R..950"); > fai

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] time-delayed standbys

On Wed, Apr 20, 2011 at 7:42 AM, Greg Stark wrote: > On Wed, Apr 20, 2011 at 12:24 PM, Greg Stark wrote: >> I haven't read the patch but are you delaying delivering the log or >> delaying replaying it? I think you actually want the latter so in case >> of a real failure you can choose between rep

[HACKERS] database system identifier differs between the primary and standby

Hello List, We are getting the following log while configuring hot standby, 2011-04-20 17:34:40 ETC/GMT FATAL: the database system is starting up 2011-04-20 17:34:41 ETC/GMT FATAL: database system identifier differs between the primary and standby 2011-04-20 17:34:41 ETC/GMT DETAIL: The pr

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

Hiroshi Inoue writes: > I see another issue for the behavior. > For example, the following code in src/backend/utis/adt/pg_locale.c > won't work as expected in case the current locale is Hong Kong, Macao or > UAE because the last setlocale() in the code would fail. I can > find such save & restor

Re: [HACKERS] database system identifier differs between the primary and standby

On Wed, Apr 20, 2011 at 9:28 AM, rajibdk wrote: > We are getting the following log while configuring hot standby, > > 2011-04-20 17:34:40 ETC/GMT FATAL:  the database system is starting up > 2011-04-20 17:34:41 ETC/GMT FATAL:  database system identifier differs > between the primary and standby >

Re: [HACKERS] pgbench \for or similar loop

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 problem, which is to allow every client, not just psql, to do this. Cheers, David. -- David Fetter http:/

Re: [HACKERS] Build farm coverage for isolation tests

Andrew Dunstan wrote: > http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2011-04-20%2010%3A17%3A02&stg=isolation-check On a cursory scan, that looks like a successful run of the right test suite. Was there anything in particular I should be checking there? > I'll include thi

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

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 post a new > >> version of > >> this one. ?It will remove

Re: [HACKERS] Foreign table permissions and cloning

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] TO role" also work for > foreign tables as well as r

Re: [HACKERS] pgbench \for or similar loop

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 problem, which > is to allow every client, not just psql, to do this. then

Re: [HACKERS] Build farm coverage for isolation tests

On 04/20/2011 09:54 AM, Kevin Grittner wrote: Andrew Dunstan wrote: http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2011-04-20%2010%3A17%3A02&stg=isolation-check On a cursory scan, that looks like a successful run of the right test suite. Was there anything in particular I

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

Greg Stark writes: > On Tue, Apr 19, 2011 at 4:29 PM, Tom Lane wrote: >>  Namely, that when reindexing an >> existing index, there cannot be any need to advance the index's >> indcheckxmin horizon. > Note that if isvalid is not set then we don't know anything about the > hot chains since the con

Re: [HACKERS] time-delayed standbys

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 peek at them to see the time. Or we could have the master send its time to the slave as

Re: [HACKERS] pgbench \for or similar loop

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, but it doesn't solve the fundamental problem, which > is to a

Re: [HACKERS] time-delayed standbys

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 peek at them to see the time. > Or we could have the master s

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

On Wed, Apr 20, 2011 at 3:02 PM, Tom Lane wrote: > Hmm, good point.  We can probably handle this by tweaking the logic in > reindex_index that changes indisvalid so that it will force indcheckxmin > on when indisvalid had been false and there were any possibly-broken > HOT chains. I'm not followi

Re: [HACKERS] time-delayed standbys

On Wed, Apr 20, 2011 at 3:19 PM, Tom Lane wrote: > My idea of how to manage it would be to have walreceiver explicitly > track the clock difference from the master, which it can do since > walsender puts its current time into every message header.  You can use > the slave's clock for comparisons s

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

Greg Stark writes: > On Wed, Apr 20, 2011 at 3:02 PM, Tom Lane wrote: >> Hmm, good point.  We can probably handle this by tweaking the logic in >> reindex_index that changes indisvalid so that it will force indcheckxmin >> on when indisvalid had been false and there were any possibly-broken >> HO

Re: [HACKERS] time-delayed standbys

Greg Stark writes: > Ah, so we did put the master's clock in every message? Yes, we did. > Then this > should be simple, no? Just compare the master's timestamp from the > record to the last master's clock seen in the messages. That sounds > equivalent but a lot safer than trying to keep a conve

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

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 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] 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] 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

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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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

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] 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

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] 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 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

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] 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 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] 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] 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

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] 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 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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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 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 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] 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

[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

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

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

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 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: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 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 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 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 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] 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 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] 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 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, > 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 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] 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

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] 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

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] 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] 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] 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] 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

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] 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

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] 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

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

  1   2   >