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

Thanks Robert. Rajib Deka SIEMENS Ltd. Robert V Chandran Tower, First Floor, West Wing, #149, Velechery Tambaram Main Road, Pallikaranai, Chennai-100, INDIA. www.siemens.com Mob: +91-9176780669 | E-Mail: rajib.d...@siemens.com -Original Message- From: Robert Haas [mailto:robertmh...@gmai

Re: [HACKERS] pgbench \for or similar loop

Kevin Grittner wrote: I'm not clear on exactly what you're proposing there, but the thing I've considered doing is having threads to try to keep a FIFO queue populated with a configurable transaction mix, while a configurable number of worker threads pull those transactions off the queue and...

Re: [HACKERS] pgbench \for or similar loop

Alvaro Herrera wrote: Why do we have pgbench at all in the first place? Surely we could rewrite it in plpgsql with proper stored procedures. pgbench gives you a driver program with the following useful properties: 1) Multiple processes are spawned and each gets its own connection 2) A time

Re: [HACKERS] fsync reliability

On 04/21/2011 04:26 AM, Simon Riggs wrote: However, that begs the question of what happens with WAL. At present, we do nothing to ensure that "the entry in the directory containing the file has also reached disk". Well, we do, but it's not obvious why that is unless you've stared at this

Re: [HACKERS] "stored procedures"

>> What about cancelling? Cancel the current running query, or the whole >> procedure (I'm assuming the latter?  How would that work? > > Good question.  If you're imagining that the SP could decide to cancel a > database request partway through, it seems even further afield from what > could reaso

Re: [HACKERS] Patch for pg_upgrade to turn off autovacuum

On Apr 21, 2011, at 6:22 PM, Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian writes: >>> Tom Lane wrote: Huh? Why would that be? Seems like you've done something in the wrong place if that's an issue. >> >>> Yeah, it is complicated. I don't really care if autovacuum runs on

Re: [HACKERS] "stored procedures"

On Apr 21, 2011, at 3:51 PM, Merlin Moncure wrote: > If you do it that (base it on AT) way, then you can't: > 1) call any utility command (vacuum, etc) > 2) run for an arbitrary amount of time > 3) discard any locks (except advisory) > 4) deal with serialization isolation/mvcc snapshot issues that

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On the big picture of scheduling issues, I have never seen a major piece of software ship every 6 months without being incredibly buggy. I'd lose serious faith in this project if that happens here. Since I've never seen a major operating system ship usefully more than about once every two yea

Re: [HACKERS] "stored procedures"

Josh Berkus writes: > On 4/21/11 3:07 PM, Tom Lane wrote: >> Maybe we should think about the SP controlling a second backend (or even >> multiple backends?) that's executing the "transactional" operations. >> dblink on steroids, as it were. > This is how people are doing this now (using dblink I

Re: [HACKERS] gincostestimate

Jeff Janes writes: > The problem is that numEntries in src/backend/utils/adt/selfuncs.c is > zero and eventually causes a division by zero and a cost estimate of > nan. > ... > I don't know what the solution is. Simply setting numEntries to 1 if > ginStats.nEntries zero solves this particular pro

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On 04/21/2011 12:39 PM, Robert Haas wrote: In fact, I've been wondering if we shouldn't consider extending the support window for 8.2 past the currently-planned December 2011. There seem to be quite a lot of people running that release precisely because the casting changes in 8.3 were so painful,

Re: [HACKERS] best way to test new index?

On 4/21/11 1:28 PM, Kevin Grittner wrote: > That said, I would start by making sure that basic things like > CREATE INDEX and DROP INDEX work. Then I would test that INSERT, > UPDATE, and DELETE do the right things with the index. Then I would > make sure that vacuum did the right thing. Then I

Re: [HACKERS] "stored procedures"

On 4/21/11 3:07 PM, Tom Lane wrote: > Maybe we should think about the SP controlling a second backend (or even > multiple backends?) that's executing the "transactional" operations. > dblink on steroids, as it were. This is how people are doing this now (using dblink I mean). -- Josh Berkus Post

Re: [HACKERS] "stored procedures"

> Robert Haas writes: >> EDB has an implementation of this in Advanced Server. A stored >> procedure can issue a COMMIT, which commits the current transaction >> and begins a new one. This might or might not be what people are >> imagining for this feature. If we end up doing something else, on

Re: [HACKERS] Patch for pg_upgrade to turn off autovacuum

On Thu, 2011-04-21 at 18:22 -0400, Bruce Momjian wrote: > I can also control the > behavior based on the catalog version number, which seems the most > logical. It seems like we want a simple "use -b if available; else don't". Is that right? If so, switching based on the version seems reasonable.

Re: [HACKERS] Patch for pg_upgrade to turn off autovacuum

Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Huh? Why would that be? Seems like you've done something in the wrong > >> place if that's an issue. > > > Yeah, it is complicated. I don't really care if autovacuum runs on the > > old cluster (we only move the files while the s

Re: [HACKERS] Patch for pg_upgrade to turn off autovacuum

Bruce Momjian writes: > Tom Lane wrote: >> Huh? Why would that be? Seems like you've done something in the wrong >> place if that's an issue. > Yeah, it is complicated. I don't really care if autovacuum runs on the > old cluster (we only move the files while the server is down). We only > wan

Re: [HACKERS] Patch for pg_upgrade to turn off autovacuum

Tom Lane wrote: > Bruce Momjian writes: > >> The attached patch adds a new postmaster/postgres binary upgrade mode > >> (-b) which disables autovacuum, allows only super-user connections, and > >> prevents pg_upgrade_support oid assignment when not in upgrade mode. > >> It also modifies pg_upgrad

Re: [HACKERS] "stored procedures"

Merlin Moncure writes: > On Thu, Apr 21, 2011 at 1:13 PM, Tom Lane wrote: >> 3. What sort of primitive operations do you expect the SP to be >> able to execute "outside a transaction"?  The plpgsql model where >> all the primitive operations are really SQL ain't gonna work. > Does this mean you

Re: [HACKERS] Patch for pg_upgrade to turn off autovacuum

Bruce Momjian writes: >> The attached patch adds a new postmaster/postgres binary upgrade mode >> (-b) which disables autovacuum, allows only super-user connections, and >> prevents pg_upgrade_support oid assignment when not in upgrade mode. >> It also modifies pg_upgrade to use this new mode rat

Re: [HACKERS] EOL for 8.2 (was Re: Formatting Curmudgeons WAS: MMAP Buffers)

On tor, 2011-04-21 at 22:17 +0100, Greg Stark wrote: > However your theory was all predicated on the idea that supporting 8.2 > was not much incremental effort and Dave said that's not true so this > is all moot. Doing it Windows-excluded seems not worth the effort --- > unless... what version of P

Re: [HACKERS] Patch for pg_upgrade to turn off autovacuum

Bruce Momjian wrote: > Bruce Momjian wrote: > > Robert Haas wrote: > > > On Thu, Mar 31, 2011 at 12:11 PM, Bruce Momjian wrote: > > > > Robert Haas wrote: > > > >> On Thu, Mar 31, 2011 at 11:32 AM, Heikki Linnakangas > > > >> wrote: > > > >> >> ?I think the maintenance > > > >> >> overhead of an

Re: EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

On tor, 2011-04-21 at 13:39 -0400, Tom Lane wrote: > Josh Berkus writes: > > Better that someone should just focus on whipping Robert's (or was it > > Greg's?) replace-the-missing-casts package into shape as an extension. > > I think Peter originated that, actually. My recollection is that there

Re: [HACKERS] "stored procedures"

Peter Eisentraut wrote: So the topic of "real" "stored procedures" came up again. Meaning a function-like object that executes outside of a regular transaction, with the ability to start and stop SQL transactions itself. I would like to collect some specs on this feature. So does anyone have l

Re: [HACKERS] EOL for 8.2 (was Re: Formatting Curmudgeons WAS: MMAP Buffers)

On 04/21/2011 05:17 PM, Greg Stark wrote: what version of Postgres was shipped in the last supported releases of major distributions? I think it was 8.1 in Ubuntu Hardy and 8.4 in Ubuntu Lucid so that's irrelevant. What about Redhat and Debian? IIRC RedHat has a ten year EOL policy, so what

Re: [HACKERS] EOL for 8.2 (was Re: Formatting Curmudgeons WAS: MMAP Buffers)

Greg Stark writes: > Fwiw I would have agreed with you on the basic question. Just because > we've said that users can count on N years of support doesn't mean > there's anything binding us to *not* support things for N+x years. Certainly. The question is what's the point --- and perhaps even mo

Re: [HACKERS] EOL for 8.2 (was Re: Formatting Curmudgeons WAS: MMAP Buffers)

On Thu, Apr 21, 2011 at 6:18 PM, Robert Haas wrote: > However, I can see that I'm way, way in the minority on this one, so > never mind!  It was just a thought... > Fwiw I would have agreed with you on the basic question. Just because we've said that users can count on N years of support doesn't

Re: EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

On Thu, Apr 21, 2011 at 12:35 PM, Tom Lane wrote: > > But I'm still unclear on what would really be accomplished > by extending support for it.  Sooner or later we have to get people > to migrate up from it, and I see no reason to think that supporting > it for just a year more will change anythin

Re: [HACKERS] "stored procedures"

On Thu, Apr 21, 2011 at 3:51 PM, Merlin Moncure wrote: > On Thu, Apr 21, 2011 at 2:37 PM, Robert Haas wrote: >> On Thu, Apr 21, 2011 at 2:13 PM, Tom Lane wrote: >>> "Kevin Grittner" writes: Josh Berkus wrote: > ** question: if an SP is called by another SP, what is its > transacti

[HACKERS] Patch for pg_upgrade to turn off autovacuum

Bruce Momjian wrote: > Robert Haas wrote: > > On Thu, Mar 31, 2011 at 12:11 PM, Bruce Momjian wrote: > > > Robert Haas wrote: > > >> On Thu, Mar 31, 2011 at 11:32 AM, Heikki Linnakangas > > >> wrote: > > >> >> ?I think the maintenance > > >> >> overhead of an invisible variable is too much. > > >

Re: [HACKERS] best way to test new index?

Yves Weißig wrote: > Am 21.04.2011 20:56, schrieb Kevin Grittner: >> Yves Weißig wrote: >> >>> what is the best way to test a new developed index structure? >> >> Are you talking about a new AM (like btree, hash, GiST, or GIN)? > > Yes I do! The tests are going to depend somewhat on what the

Re: [HACKERS] "stored procedures"

On Thu, Apr 21, 2011 at 2:37 PM, Robert Haas wrote: > On Thu, Apr 21, 2011 at 2:13 PM, Tom Lane wrote: >> "Kevin Grittner" writes: >>> Josh Berkus wrote: ** question: if an SP is called by another SP, what is its transaction context? >> >>> Entering or leaving an SP should not start o

Re: [HACKERS] my signature

On Thu, Apr 21, 2011 at 3:07 PM, Cédric Villemain wrote: > Yes, please. > Robert, it wasn't well phrased and I apologize for the bad choice of my words. No problem. Please be assured that I have no desire to make it appear that EnterpriseDB is the only PostgreSQL company out there. I've been us

Re: [HACKERS] "stored procedures"

On Thu, Apr 21, 2011 at 2:13 PM, Tom Lane wrote: > "Kevin Grittner" writes: >> Josh Berkus wrote: >>> ** question: if an SP is called by another SP, what is its >>> transaction context? > >> Entering or leaving an SP should not start or end a transaction. > > That all sounds mighty hand-wavy and

Re: [HACKERS] my signature

Le 21 avril 2011 20:17, Andrew Dunstan a écrit : > > > On 04/21/2011 01:06 PM, Robert Haas wrote: >> >> Heck, even the name "PostgreSQL Experts, Inc." could be taken to imply >> that the rest of us are all chumps. >> > > Not really. We don't claim to have all of them (yet). EDB on the other hand >

Re: [HACKERS] best way to test new index?

Yes I do! Am 21.04.2011 20:56, schrieb Kevin Grittner: > Yves Weißig wrote: > >> what is the best way to test a new developed index structure? > > Are you talking about a new AM (like btree, hash, GiST, or GIN)? > > -Kevin > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql

Re: [HACKERS] best way to test new index?

Yves Weißig wrote: > what is the best way to test a new developed index structure? Are you talking about a new AM (like btree, hash, GiST, or GIN)? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/ma

[HACKERS] best way to test new index?

Hello pgsql-hackers, what is the best way to test a new developed index structure? Greets, Yves -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] "stored procedures"

2011/4/21 Tom Lane : > "Kevin Grittner" writes: >> Josh Berkus wrote: >>> ** question: if an SP is called by another SP, what is its >>> transaction context? > >> Entering or leaving an SP should not start or end a transaction. > > That all sounds mighty hand-wavy and at serious risk of tripping

Re: [HACKERS] "stored procedures"

On Thu, Apr 21, 2011 at 1:13 PM, Tom Lane wrote: > 3. What sort of primitive operations do you expect the SP to be > able to execute "outside a transaction"?  The plpgsql model where > all the primitive operations are really SQL ain't gonna work. > I'm less sure what to do about #3.  The most attr

Re: [HACKERS] my signature

Bruce Momjian wrote: > Merlin Moncure wrote: > > On Thu, Apr 21, 2011 at 12:06 PM, Robert Haas wrote: > > > On Thu, Apr 21, 2011 at 12:26 PM, C?dric Villemain > > > wrote: > > >> Robert, Please don't add confusion to your signature : PostgreSQL is a > > >> community project not an enterprise prod

Re: [HACKERS] my signature

Merlin Moncure wrote: > On Thu, Apr 21, 2011 at 12:06 PM, Robert Haas wrote: > > On Thu, Apr 21, 2011 at 12:26 PM, C?dric Villemain > > wrote: > >> Robert, Please don't add confusion to your signature : PostgreSQL is a > >> community project not an enterprise product. > >> -- > >> C?dric Villemai

Re: [HACKERS] my signature

On Thu, Apr 21, 2011 at 12:06 PM, Robert Haas wrote: > On Thu, Apr 21, 2011 at 12:26 PM, Cédric Villemain > wrote: >> Robert, Please don't add confusion to your signature : PostgreSQL is a >> community project not an enterprise product. >> -- >> Cédric Villemain               2ndQuadrant >> http:

Re: [HACKERS] my signature

On 04/21/2011 01:06 PM, Robert Haas wrote: Heck, even the name "PostgreSQL Experts, Inc." could be taken to imply that the rest of us are all chumps. Not really. We don't claim to have all of them (yet). EDB on the other hand uses the definite article in its slogan, as does CommandPrompt.

Re: [HACKERS] "stored procedures"

"Kevin Grittner" writes: > Josh Berkus wrote: >> ** question: if an SP is called by another SP, what is its >> transaction context? > Entering or leaving an SP should not start or end a transaction. That all sounds mighty hand-wavy and at serious risk of tripping over implementation details.

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

--On 12. April 2011 10:58:25 -0400 Tom Lane wrote: Hmm, I would like to see the patch for going in for 8.4.8. Simon, was there a reason you only back-patched that to 9.0? So it seems we have shipped 8.4.8 without a fix for t

Re: [HACKERS] "stored procedures"

I'm pretty close to agreement with Josh, I think. Josh Berkus wrote: > Delta between SPs and Functions for PostgreSQL: > > * SPs are executed using CALL or EXECUTE, and not SELECT. Agreed, although some products will search for a matching procedure name if the start of a statement doesn't ma

Re: EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

Josh Berkus writes: > Better that someone should just focus on whipping Robert's (or was it > Greg's?) replace-the-missing-casts package into shape as an extension. I think Peter originated that, actually. My recollection is that there didn't seem to be any way to extend it to a complete solutio

Re: EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

Dave Page writes: > On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane wrote: >> I agree that the incremental effort would not be so large, but what >> makes you think that the situation will change given another year? > It would also make at least one packager very unhappy as the 8.2 > Windows build is

Re: [HACKERS] "stored procedures"

Hello 2011/4/21 Josh Berkus : > Peter, > >> I would like to collect some specs on this feature.  So does anyone have >> links to documentation of existing implementations, or their own spec >> writeup?  A lot of people appear to have a very clear idea of this >> concept in their own head, so let's

Re: [HACKERS] "stored procedures"

Peter, > I would like to collect some specs on this feature. So does anyone have > links to documentation of existing implementations, or their own spec > writeup? A lot of people appear to have a very clear idea of this > concept in their own head, so let's start collecting those. Delta betwee

Re: [HACKERS] my signature

On Apr 21, 2011, at 10:06 AM, Robert Haas wrote: > Heck, even the name "PostgreSQL Experts, Inc." could be taken to imply > that the rest of us are all chumps. Send me your résumé, we’ll talk. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] fsync reliability

On Thu, Apr 21, 2011 at 12:53 PM, Simon Riggs wrote: > On Thu, Apr 21, 2011 at 5:45 PM, Robert Haas wrote: >> On Thu, Apr 21, 2011 at 11:55 AM, Tom Lane wrote: >>> The traditional standard is that the filesystem is supposed to take >>> care of its own metadata, and even Linux filesystems have pr

Re: EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

On Thu, Apr 21, 2011 at 12:59 PM, Tom Lane wrote: > [ man, this thread has totally outlived its title, could we change that? >  I'll start with this subtopic ] > > Robert Haas writes: >> In fact, I've been wondering if we shouldn't consider extending the >> support window for 8.2 past the current

Re: EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

On Thu, Apr 21, 2011 at 06:04:09PM +0100, Dave Page wrote: > On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane wrote: > > [ man, this thread has totally outlived its title, could we change that? > > ?I'll start with this subtopic ] > > > > Robert Haas writes: > >> In fact, I've been wondering if we shoul

Re: EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

All, >>> In fact, I've been wondering if we shouldn't consider extending the >>> support window for 8.2 past the currently-planned December 2011. >>> There seem to be quite a lot of people running that release precisely >>> because the casting changes in 8.3 were so painful, and I think the >>> in

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:05 AM, Robert Haas wrote: > I agree.  I am in favor of a shorter release cycle.  But I think that > a shorter release cycle won't work well if there is still four month > long integration period at the end of each series of CommitFests.  The > problem is a bit circular h

[HACKERS] my signature

On Thu, Apr 21, 2011 at 12:26 PM, Cédric Villemain wrote: > Robert, Please don't add confusion to your signature : PostgreSQL is a > community project not an enterprise product. > -- > Cédric Villemain               2ndQuadrant > http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Supp

Re: EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

On Thu, Apr 21, 2011 at 5:59 PM, Tom Lane wrote: > [ man, this thread has totally outlived its title, could we change that? >  I'll start with this subtopic ] > > Robert Haas writes: >> In fact, I've been wondering if we shouldn't consider extending the >> support window for 8.2 past the currentl

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thursday, April 21, 2011 06:39:44 PM Robert Haas wrote: > On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund wrote: > > On Thursday, April 21, 2011 05:43:16 PM Robert Haas wrote: > >> On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom > > > > wrote: > >> > On Thu, Apr 21, 2011 at 11:16:45AM -04

EOL for 8.2 (was Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers)

[ man, this thread has totally outlived its title, could we change that? I'll start with this subtopic ] Robert Haas writes: > In fact, I've been wondering if we shouldn't consider extending the > support window for 8.2 past the currently-planned December 2011. > There seem to be quite a lot of

Re: [HACKERS] fsync reliability

On Thu, Apr 21, 2011 at 5:45 PM, Robert Haas wrote: > On Thu, Apr 21, 2011 at 11:55 AM, Tom Lane wrote: >> The traditional standard is that the filesystem is supposed to take >> care of its own metadata, and even Linux filesystems have pretty much >> figured that out.  I don't really see a need f

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund wrote: > One could argue that its causing bad PR for postgres. I have seen several > parties planning to migrate away or not migrate to postgres because of > performance evaluations they made. With 7.4, 8.0 and 8.2. In 2010. Well evaluating based on

Re: [HACKERS] fsync reliability

On Thu, Apr 21, 2011 at 4:55 PM, Tom Lane wrote: > The traditional standard is that the filesystem is supposed to take > care of its own metadata, and even Linux filesystems have pretty much > figured that out.  I don't really see a need for us to be nursemaiding > the filesystem.  At most there'

Re: [HACKERS] fsync reliability

On Thu, Apr 21, 2011 at 11:55 AM, Tom Lane wrote: > The traditional standard is that the filesystem is supposed to take > care of its own metadata, and even Linux filesystems have pretty much > figured that out.  I don't really see a need for us to be nursemaiding > the filesystem.  At most there'

Re: [HACKERS] "stored procedures"

On Thu, Apr 21, 2011 at 12:38 PM, Tom Lane wrote: > Robert Haas writes: >> EDB has an implementation of this in Advanced Server.  A stored >> procedure can issue a COMMIT, which commits the current transaction >> and begins a new one.  This might or might not be what people are >> imagining for t

Re: [HACKERS] getting to beta

On Thu, Apr 21, 2011 at 12:32 PM, Kevin Grittner wrote: > Robert Haas wrote: > >> 1. All of the SSI patches have been dealt with. > > I'll add the non-serializable UPDATE performance issue.  Dan has > been benchmarking to try to find a worst case; I don't want to speak > for him too much, but as

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:48 AM, Andres Freund wrote: > On Thursday, April 21, 2011 05:43:16 PM Robert Haas wrote: >> On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom > wrote: >> > On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote: >> >> Robert Haas writes: >> >> > I agree.  I am in f

Re: [HACKERS] "stored procedures"

Robert Haas writes: > EDB has an implementation of this in Advanced Server. A stored > procedure can issue a COMMIT, which commits the current transaction > and begins a new one. This might or might not be what people are > imagining for this feature. If we end up doing something else, one > th

Re: [HACKERS] getting to beta

Robert Haas wrote: > 1. All of the SSI patches have been dealt with. I'll add the non-serializable UPDATE performance issue. Dan has been benchmarking to try to find a worst case; I don't want to speak for him too much, but as he was headed off to lecture a class he sent me results so far, an

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

2011/4/21 Robert Haas : > On Thu, Apr 21, 2011 at 6:38 AM, Simon Riggs wrote: >> On Thu, Apr 21, 2011 at 10:31 AM, rajibdk wrote: >>> What does that database system identifier means? Is it related to DB >>> transactions’ or unique to a version? >> >> Regrettably, it means you didn't follow the do

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:46 AM, Tom Lane wrote: > But aren't those two sides of the same coin, ie, people's natural > tendency to work to a deadline?  If you approve of a lot of patches > showing up just in time for a commitfest, why don't you approve of > big patches showing up just in time for

Re: [HACKERS] hot backups: am I doing it wrong, or do we have a problem with pg_clog?

On Thu, Apr 21, 2011 at 8:19 AM, Robert Haas wrote: > On Thu, Apr 21, 2011 at 7:15 AM, Daniel Farina wrote: >> To start at the end of this story: "DETAIL:  Could not read from file >> "pg_clog/007D" at offset 65536: Success." >> >> This is a message we received on a a standby that we were bringin

Re: [HACKERS] fsync reliability

Simon Riggs writes: > Daniel Farina points out to me that the Linux man page for fsync() says > "Calling fsync() does not necessarily ensure that the entry in the directory >containing the file has also reached disk. For that an > explicit fsync() on a >file descriptor for the dir

Re: [HACKERS] "stored procedures"

On Thu, Apr 21, 2011 at 11:24 AM, Peter Eisentraut wrote: > So the topic of "real" "stored procedures" came up again.  Meaning a > function-like object that executes outside of a regular transaction, > with the ability to start and stop SQL transactions itself. > > I would like to collect some spe

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thursday, April 21, 2011 05:43:16 PM Robert Haas wrote: > On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom wrote: > > On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote: > >> Robert Haas writes: > >> > I agree. I am in favor of a shorter release cycle. > >> I'm not. I don't think t

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

[ another thought on this topic ] Robert Haas writes: > I think that it's not too bad if the process of a release getting out > the door results in effectively missing one CommitFest. ... > But that isn't going to work if people do > the same sort of throwing everything into the kitchen sink at t

Re: [HACKERS] getting to beta

On Thu, Apr 21, 2011 at 11:38 AM, Peter Eisentraut wrote: > On Tue, 2011-04-19 at 18:18 -0400, Robert Haas wrote: >> 2. The typed tables stuff vs. pg_upgrade still needs work.  I would be >> just as happy if Tom or Peter wanted to fix this, mostly for fear of >> getting flak over the details of th

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:37 AM, Ross J. Reedstrom wrote: > On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote: >> Robert Haas writes: >> > On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote: >> >> I think to really address that problem, you need to think about shorter >> >> release

Re: [HACKERS] "stored procedures"

Hi Peter 2011/4/21 Peter Eisentraut : > So the topic of "real" "stored procedures" came up again.  Meaning a > function-like object that executes outside of a regular transaction, > with the ability to start and stop SQL transactions itself. > > I would like to collect some specs on this feature.

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:16 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote: >>> I think to really address that problem, you need to think about shorter >>> release cycles overall, like every 6 months.  Otherwise, the current 12 >>> to 14 mo

Re: [HACKERS] getting to beta

On Tue, 2011-04-19 at 18:18 -0400, Robert Haas wrote: > 2. The typed tables stuff vs. pg_upgrade still needs work. I would be > just as happy if Tom or Peter wanted to fix this, mostly for fear of > getting flak over the details of the fixes, but if not I will do it. Noah Misch is hot on the trai

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 11:16:45AM -0400, Tom Lane wrote: > Robert Haas writes: > > On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote: > >> I think to really address that problem, you need to think about shorter > >> release cycles overall, like every 6 months. �Otherwise, the current 12 >

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On 04/21/2011 11:16 AM, Tom Lane wrote: Robert Haas writes: On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote: I think to really address that problem, you need to think about shorter release cycles overall, like every 6 months. Otherwise, the current 12 to 14 month horizon is just to

[HACKERS] "stored procedures"

So the topic of "real" "stored procedures" came up again. Meaning a function-like object that executes outside of a regular transaction, with the ability to start and stop SQL transactions itself. I would like to collect some specs on this feature. So does anyone have links to documentation of e

Re: [HACKERS] hot backups: am I doing it wrong, or do we have a problem with pg_clog?

On Thu, Apr 21, 2011 at 7:15 AM, Daniel Farina wrote: > To start at the end of this story: "DETAIL:  Could not read from file > "pg_clog/007D" at offset 65536: Success." > > This is a message we received on a a standby that we were bringing > online as part of a test.  The clog file was present, b

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Robert Haas writes: > On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote: >> I think to really address that problem, you need to think about shorter >> release cycles overall, like every 6 months.  Otherwise, the current 12 >> to 14 month horizon is just too long psychologically. > I agree.

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

On Thu, Apr 21, 2011 at 6:38 AM, Simon Riggs wrote: > On Thu, Apr 21, 2011 at 10:31 AM, rajibdk wrote: >> What does that database system identifier means? Is it related to DB >> transactions’ or unique to a version? > > Regrettably, it means you didn't follow the documented procedure. > > It isn'

Re: [HACKERS] Typed table DDL loose ends

On Wed, 2011-04-20 at 10:44 -0400, Noah Misch wrote: > If we add that ownership check, we'll protect some operations on the > type. The > cost is localized divergence from our principle that types have no > usage > restrictions. I'm of the opinion that it's not worth introducing that > policy > e

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, Apr 21, 2011 at 2:43 AM, Peter Eisentraut wrote: > 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 actual

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, 2011-04-21 at 08:42 -0500, Kevin Grittner wrote: > > you need to think about shorter release cycles overall, like every > > 6 months. > > With the current time between feature freeze and release, that > wouldn't leave a lot of time for development. Presumably, one would aim to cut all th

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Thu, 2011-04-21 at 14:01 +0100, Simon Riggs wrote: > We should be encouraging people to spend more time on more useful > features, not an endless stream of trivial patches, integration and > release processes. Hence the proposal to cut that time down and make it count better. Which direction w

Re: [HACKERS] [GENERAL] Defining input function for new datatype

Nick Raj writes: > 1 Datum mpoint_in(PG_FUNCTION_ARGS) > 2 { > 3 > 4mpoint *result; > 5char *pnt=(char *)malloc (sizeof (20)); > 6char *ts=(char *)malloc (sizeof (20)); (1) You should *not* use malloc here. There is seldom any reason to use malloc directly at all

Re: [HACKERS] hot backups: am I doing it wrong, or do we have a problem with pg_clog?

Hi, On Thursday, April 21, 2011 01:15:48 PM Daniel Farina wrote: > Any ideas? Or does it sound like I'm making some bookkeeping errors > and should review my code again? It does work most of the time. I > have not gotten a sense how often this reproduces just yet. I would suggest taking both, y

Re: [HACKERS] smallserial / serial2

"Mike Pultz" writes: > 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! A sequence that can only go to 32K doesn't seem all that generally u

Re: [HACKERS] hot backups: am I doing it wrong, or do we have a problem with pg_clog?

On Thu, Apr 21, 2011 at 6:15 AM, Daniel Farina wrote: > To start at the end of this story: "DETAIL:  Could not read from file > "pg_clog/007D" at offset 65536: Success." > > This is a message we received on a a standby that we were bringing > online as part of a test.  The clog file was present, b

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

Peter Eisentraut wrote: > you need to think about shorter release cycles overall, like every > 6 months. With the current time between feature freeze and release, that wouldn't leave a lot of time for development. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] fsync reliability

Excerpts from Simon Riggs's message of jue abr 21 05:26:06 -0300 2011: > ISTM that we can easily do this, since we preallocate WAL files during > RemoveOldXlogFiles() and rarely extend the number of files. > So it seems easily possible to fsync the pg_xlog directory at the end > of RemoveOldXlogFi

Re: [HACKERS] Formatting Curmudgeons WAS: MMAP Buffers

On Wed, Apr 20, 2011 at 8:54 PM, 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] Defining input function for new datatype

Hello 2011/4/21 Nick Raj : > Hi, > I am defining a new data type called mpoint > i.e. > typedef struct mpoint > { >     Point p; >     Timestamp t; > } mpoint; > > For defining input/output function > > 1 Datum mpoint_in(PG_FUNCTION_ARGS) > 2 { > 3 > 4    mpoint *result; > 5    cha

  1   2   >