Re: [HACKERS] pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Alvaro Herrera writes: > The reason this is like this is that the indent binary modifies the > prototype exactly like the function definition, and then the awk program > that's used in the pipeline "pulls up" the second line: > # Move prototype names to the same line as return type. Useful for

Re: [HACKERS] TODO: fix priority of ordering of read and write light-weight locks

Jeff Janes writes: > The wiki todo has the topic "Fix priority ordering of read and write > light-weight locks" and > references http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php > (lwlocks and starvation) > Having read the referenced discussion, I'm trying to figure out what > re

Re: [HACKERS] pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Tom Lane escribió: > Ah. That's a bit idiosyncratic to pgindent. What it does for a > function definition makes sense, I think: it lines up all the > parameters to start in the same column: > > static int > myfunction(int foo, >int bar) > > What is not obvious is that the same amou

Re: [HACKERS] "Hot standby"?

On 08/11/2009 11:19 PM, Robert Haas wrote: On Tue, Aug 11, 2009 at 9:44 PM, Greg Stark wrote: No! This is *not* what "hot standby" means, at least not in the Oracle world. I'm perplexed by this. For example: http://en.wikipedia.org/wiki/Hot_standby Admittedly, wikipedia is not an

Re: [HACKERS] pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Robert Haas writes: > On Tue, Aug 11, 2009 at 10:08 PM, Tom Lane wrote: >> If that's not it, you'd need to mention details. > Well, one thing I've noticed is that when a function prototype wraps > around to the next line, you often change the number of spaces in the > hanging indent. Ah. That's

Re: [HACKERS] "Hot standby"?

On Tue, Aug 11, 2009 at 9:44 PM, Greg Stark wrote: > On Tue, Aug 11, 2009 at 10:13 PM, Robert Haas wrote: >> On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus wrote: >>> So really, the "streaming replication" patch should be called "hot >>> standby", >> >> No.  AIUI, hot standby means that when your pri

[HACKERS] TODO: fix priority of ordering of read and write light-weight locks

The wiki todo has the topic "Fix priority ordering of read and write light-weight locks" and references http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php (lwlocks and starvation) Having read the referenced discussion, I'm trying to figure out what remains to be done. Tom proposed

[HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

On Tue, Aug 11, 2009 at 10:08 PM, Tom Lane wrote: > Robert Haas writes: >> What is a bit frustrating to me is that a number of Tom's changes to >> the first two patches were trivial whitespace changes that required me >> to rebase for no obvious reason.   Either those changes were made >> accident

Re: [HACKERS] pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Robert Haas writes: > What is a bit frustrating to me is that a number of Tom's changes to > the first two patches were trivial whitespace changes that required me > to rebase for no obvious reason. Either those changes were made > accidentally as Tom was fooling around with what I had done, or

Re: [HACKERS] "Hot standby"?

As I see it we potentially have the following modes to deal with: Archive file mode asynchronous archive Archive file mode asynchronous standby slave Streaming mode asynchronous standby slave Streaming mode synchronousstandby slave Archive file mode asynchronous read-

Re: [HACKERS] WIP: getting rid of the pg_database flat file

Alvaro Herrera writes: > Tom Lane wrote: >> To actually get rid of the pg_database flat file, we'd need to take the >> further step of teaching the AV launcher to read pg_database for itself, >> or else refactor things so that the AV workers can do that for it. >> (Alvaro, any comments about the b

Re: [HACKERS] dependencies for generated header files

Robert Haas writes: > Given that the anum.h stuff is gone, "vastly" might be an > overstatement. I'm pretty surprised to find out that people don't > like the idea of having dependencies be correct from anywhere in the > tree. Even if I'm the only developer who does partial builds, the > cost se

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Tom Lane wrote: > Bruce Momjian writes: > > I compared 8.3 CVS against 8.4 CVS and see the removal of a column in > > pg_amop.h for exacly the lines you listed: > > Ah. The removal of amopreqcheck was so long ago I'd forgotten about it ;-) > Yeah, the column additions/removals since 8.3 would gi

[HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Robert Haas wrote: > What is a bit frustrating to me is that a number of Tom's changes to > the first two patches were trivial whitespace changes that required me > to rebase for no obvious reason. Either those changes were made > accidentally as Tom was fooling around with what I had done, or th

Re: [HACKERS] Hot standby and synchronous replication status

Hi, On Wed, Aug 12, 2009 at 6:50 AM, Robert Haas wrote: > I don't really know how you COULD pick a safe default location. > Presumably any location that's in the default postgresql.conf file > would be under $PGDATA, which kind of defeats the purpose of the whole > thing.  In other words, you're a

Re: [HACKERS] dependencies for generated header files

Robert Haas escribió: > Given that the anum.h stuff is gone, "vastly" might be an > overstatement. I'm pretty surprised to find out that people don't > like the idea of having dependencies be correct from anywhere in the > tree. Even if I'm the only developer who does partial builds, the > cost

Re: [HACKERS] "Hot standby"?

On Tue, Aug 11, 2009 at 10:13 PM, Robert Haas wrote: > On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus wrote: >> So really, the "streaming replication" patch should be called "hot >> standby", > > No.  AIUI, hot standby means that when your primary falls over, the > secondary automatically promotes it

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Robert Haas wrote: On Tue, Aug 11, 2009 at 8:10 PM, Greg Stark wrote: Of course in all likelihood tom would have rewritten their first patch anyways... Maybe I'm taking life too seriously at the moment, but I find this comment kind of snide and unhelpful. Yes, you're taking li

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Bruce Momjian writes: > I compared 8.3 CVS against 8.4 CVS and see the removal of a column in > pg_amop.h for exacly the lines you listed: Ah. The removal of amopreqcheck was so long ago I'd forgotten about it ;-) Yeah, the column additions/removals since 8.3 would give pgindent an excuse to fid

Re: [HACKERS] WIP: getting rid of the pg_database flat file

Tom Lane wrote: > To actually get rid of the pg_database flat file, we'd need to take the > further step of teaching the AV launcher to read pg_database for itself, > or else refactor things so that the AV workers can do that for it. > (Alvaro, any comments about the best way to proceed there?) H

Re: [HACKERS] dependencies for generated header files

On Tue, Aug 11, 2009 at 9:19 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Aug 11, 2009 at 9:00 PM, Tom Lane wrote: >>> Surely the answer to that is "you should be configuring with >>> --enable-depend". > >> Uhm, the point is that this is broken even with ---enable-depend. > > Oh, okay, bu

[HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

On Tue, Aug 11, 2009 at 8:10 PM, Greg Stark wrote: > Of course > in all likelihood tom would have rewritten their first patch > anyways... Maybe I'm taking life too seriously at the moment, but I find this comment kind of snide and unhelpful. I just went through the experience of getting a series

Re: [HACKERS] Alpha 1 release notes

Robert Haas writes: > Hmm, I thought we had some examples in there, but now that I look we > only have an example for COSTS OFF, not for FORMAT. That does seem > like an oversight. I thought about adding one when I committed the patch, but concluded that there was no point until the output forma

Re: [HACKERS] dependencies for generated header files

Robert Haas writes: > On Tue, Aug 11, 2009 at 9:00 PM, Tom Lane wrote: >> Surely the answer to that is "you should be configuring with >> --enable-depend". > Uhm, the point is that this is broken even with ---enable-depend. Oh, okay, but that's only for *generated* header files. I'm not excite

Re: [HACKERS] WIP: getting rid of the pg_database flat file

Andrew Dunstan writes: > Tom Lane wrote: >> Really? And how would pgbouncer be depending on that? > auth_file > The name of the file to load user names and passwords from. The file format > is the same as the PostgreSQL pg_auth/pg_pwd file, so this setting can be > pointed directly

Re: [HACKERS] pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Greg Stark writes: > What would happen if we ran pgindent immediately after every commit? > So nobody would ever see a checkout that wasn't pgindent-clean? > The only losers I see would be people working on multi-part patches. ... which we're trying to encourage ... Actually, the case that star

Re: [HACKERS] Alpha 1 release notes

On Tue, Aug 11, 2009 at 8:32 PM, Alvaro Herrera wrote: > Mike wrote: > >> The thing that caused me the most trouble was that the "," wasn't very >> noticeable sitting near the end of this line: >> >> EXPLAIN [ ( { ANALYZE boolean | VERBOSE boolean | COSTS boolean | >> FORMAT { TEXT | XML | JSON } }

Re: [HACKERS] dependencies for generated header files

On Tue, Aug 11, 2009 at 5:56 PM, Alvaro Herrera wrote: > Robert Haas escribió: > >> *shrug*  You don't have to accept the patch, but I'm unclear as to how >> make from a subdirectory will ever work reliably without something >> like this.  The problem occurs when .c files have dependencies on >> fi

Re: [HACKERS] dependencies for generated header files

On Tue, Aug 11, 2009 at 9:00 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Aug 11, 2009 at 4:38 PM, Peter Eisentraut wrote: >>> I'm not convinced by this use case. > >> Well, my original motivation for developing this patch was that I >> often go into a subdirectory and start hacking on a .

Re: [HACKERS] dependencies for generated header files

Robert Haas writes: > On Tue, Aug 11, 2009 at 4:38 PM, Peter Eisentraut wrote: >> I'm not convinced by this use case. > Well, my original motivation for developing this patch was that I > often go into a subdirectory and start hacking on a .c file and then > type make to rebuild just that subdire

Re: [HACKERS] WIP: getting rid of the pg_database flat file

Tom Lane wrote: Andrew Dunstan writes: Tom Lane wrote: I'd also like to look into getting rid of the pg_auth flat file. That would be sad for many users of pgbouncer. Really? And how would pgbouncer be depending on that? " auth_file The name of t

Re: [HACKERS] WIP: getting rid of the pg_database flat file

On Wednesday 12 August 2009 02:30:53 Tom Lane wrote: > Andrew Dunstan writes: > > Tom Lane wrote: > >> I'd also like to look into getting rid of the pg_auth flat file. > > That would be sad for many users of pgbouncer. > Really? And how would pgbouncer be depending on that? One can currently use

Re: [HACKERS] Collation

David Fetter wrote: > Folks, > > While trying unsuccessfully to help someone in IRC, they pointed me to > this: > > http://www.flexiguided.de/publications.pgcollkey.en.html > > Is anybody working with the kind people of FlexiGuided GmbH to see > about integrating this feature more tightly with P

Re: [HACKERS] WIP: getting rid of the pg_database flat file

Andrew Dunstan writes: > Tom Lane wrote: >> I'd also like to look into getting rid of the pg_auth flat file. > That would be sad for many users of pgbouncer. Really? And how would pgbouncer be depending on that? regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Alpha 1 release notes

On 8/11/09 3:27 PM, Peter Eisentraut wrote: > OK, since there was no clear consensus or volunteer for preparing release > notes for alpha 1, I have started something. Let me know what you think. Actually, the "consensus" was that Bruce was not going to share, so Robert and I didn't want to bothe

Re: [HACKERS] Alpha 1 release notes

Mike wrote: > The thing that caused me the most trouble was that the "," wasn't very > noticeable sitting near the end of this line: > > EXPLAIN [ ( { ANALYZE boolean | VERBOSE boolean | COSTS boolean | > FORMAT { TEXT | XML | JSON } } [, ...] ) ] statement > > It may just be me, but I read that

Re: [HACKERS] Alpha 1 release notes

If I didn't read this email I would still be trying to figure out how to use the explain XML patch. Thanks Albert. I found the syntax for the explain xml format to be quite difficult to understand at first, it would be nice to give an example or two, ie: EXPLAIN (ANALYZE, FORMAT XML) SELECT * FRO

[HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

On Tue, Aug 11, 2009 at 4:56 PM, Tom Lane wrote: > A more aggressive approach would be to run pgindent immediately after > the close of *each* commitfest, but that would tend to break patches > that had gotten punted to the next fest. What would happen if we ran pgindent immediately after every c

Re: [HACKERS] "Hot standby"?

Robert Haas wrote: > On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus wrote: > > So really, the "streaming replication" patch should be called "hot > > standby", > > No. AIUI, hot standby means that when your primary falls over, the > secondary automatically promotes itself and takes over. It requir

Re: [HACKERS] WIP: getting rid of the pg_database flat file

Tom Lane wrote: I'd also like to look into getting rid of the pg_auth flat file. That would be sad for many users of pgbouncer. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pg

Re: [HACKERS] HEAD docs

On Tuesday 11 August 2009 15:37:42 Andrew Dunstan wrote: > have the latest docs at > stopped > being built? It sure looks like it somehow. Fixed -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to y

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Alvaro Herrera wrote: > Andrew Dunstan escribi?: > > > > > > Tom Lane wrote: > > >Andrew Dunstan writes: > > >>Robert Haas wrote: > > >>>Where it really bit me as when it reindented the DATA() statements > > >>>that were touched by ALTER TABLE ... SET STATISTICS DISTINCT. It's > > >>>not so har

Re: [HACKERS] Alpha 1 release notes

A Dimecres, 12 d'agost de 2009, Peter Eisentraut va escriure: > OK, since there was no clear consensus or volunteer for preparing release > notes for alpha 1, I have started something. Let me know what you think. > > (reStructuredText, if you want to play around) Maybe I'd be interesting to add d

[HACKERS] WIP: getting rid of the pg_database flat file

In the discussion of bug #4919 I wrote: > In some sense this is a bootstrap problem: what does it take to get to > the point of being able to read pg_database and its indexes? That is > necessarily not dependent on the particular database we want to join. > Maybe we could solve it by having the re

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Tom Lane wrote: > Alvaro Herrera writes: > > Andrew Dunstan escribi?: > >> Here's the extract attached. I replace tabs with a literal '\t' so > >> I could see what it was doing. I can't make much head or tail of it > >> either. > > > pgindent uses entab/detab, which counts spaces and replaces th

Re: [HACKERS] Quick pointer required re indexing geometry

Dimitri Fontaine wrote: Paul Matthews writes: Witting a box@>point function easy. Having a spot of trouble trying to figure out where and how to graft this into the GiST stuff. Could someone please point me in the general direction? You want index support for it, I supp

Re: [HACKERS] "Hot standby"?

On Wed, Aug 12, 2009 at 12:11:28AM +0300, Peter Eisentraut wrote: > On Tuesday 11 August 2009 18:16:04 Gianni Ciolli wrote: > > As for "warm/hot", it depends on what you exactly mean with "get > > ready": > > > > (A) If you mean "it is possible to connect to the second node", then > > Simon's p

[HACKERS] Collation

Folks, While trying unsuccessfully to help someone in IRC, they pointed me to this: http://www.flexiguided.de/publications.pgcollkey.en.html Is anybody working with the kind people of FlexiGuided GmbH to see about integrating this feature more tightly with PostgreSQL? If not, how would we make

[HACKERS] Alpha 1 release notes

OK, since there was no clear consensus or volunteer for preparing release notes for alpha 1, I have started something. Let me know what you think. (reStructuredText, if you want to play around) .. -*- mode: rst -*- = Release 8.5alpha1 = .. last commit: Simplify an

Re: [HACKERS] [COMMITTERS] pgsql: Ship documentation without intermediate tarballs Documentation

On Monday 10 August 2009 18:59:51 Tom Lane wrote: > After doing "make" then "make distclean" in doc/src/sgml, I see the > following undesirable files left behind: > > -rw-rw-r-- 1 tgl tgl 58 Aug 10 11:51 version.sgml > -rw-rw-r-- 1 tgl tgl 38548 Aug 10 11:51 features-unsupported.sgml > -rw-rw-

[HACKERS] TODO item: Allow more complex user/database default GUC settings

Hi, There's a longstanding TODO item, in subject. Previous discussion was here: http://archives.postgresql.org/pgsql-hackers/2006-09/msg02341.php In looking what it would take to implement it, I find that it is trivial. The only part that looks complex is the UI for it. Is anyone interested i

Re: [HACKERS] "Hot standby"?

>> Incidentally, we billed pg_dump as hot backup at some point. It *is* "hot backup" as in taken while the database is running and fully accessible. > mysql calls "mysqlhotcopy" a script that locks and flushes all tables, > then makes a copy of the database directory (all queries being locked >

Re: [HACKERS] Re: pgsql: Ship documentation without intermediate tarballs Documentation

Peter Eisentraut wrote: > On Monday 10 August 2009 23:03:12 Alvaro Herrera wrote: > > Hmm, I notice that this rule to install manpages is pretty slow: > Yeah, that was really freakishly complicated. Fixed now. It is much better now, thanks. -- Alvaro Herrerahttp

Re: [HACKERS] "Hot standby"?

Pierre Frédéric Caillaud wrote: Incidentally, we billed pg_dump as hot backup at some point. mysql calls "mysqlhotcopy" a script that locks and flushes all tables, then makes a copy of the database directory (all queries being locked out while this is in progress, of course). Doesn't

Re: [HACKERS] machine-readable explain output v4

Robert Haas wrote: On Tue, Aug 11, 2009 at 3:59 PM, Andrew Dunstan wrote: Good. I had a look at this for a little while yesterday. I built it, did an install, loaded auto_explain and then ran the regression tests. I didn't like the output much. It looks like the XML has been dumbed down to

Re: [HACKERS] Hot standby and synchronous replication status

On Tue, Aug 11, 2009 at 5:40 PM, Dimitri Fontaine wrote: > Le 11 août 09 à 23:30, Robert Haas a écrit : > >> On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine >> wrote: >>> >>> We should somehow provide a default archive and restore command >>> integrated >>> into the main product, so that it's as

Re: [HACKERS] dependencies for generated header files

Robert Haas escribió: > *shrug* You don't have to accept the patch, but I'm unclear as to how > make from a subdirectory will ever work reliably without something > like this. The problem occurs when .c files have dependencies on > files that are generated by a Makefile in some other subdirector

Re: [HACKERS] Hot standby and synchronous replication status

On Tue, 2009-08-11 at 17:30 -0400, Robert Haas wrote: > On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine > wrote: > > We should somehow provide a default archive and restore command integrated > > into the main product, so that it's as easy as turning it 'on' in the > > configuration for users to

Re: [HACKERS] machine-readable explain output v4

Robert Haas wrote: > Andrew Dunstan wrote: >> find it more tiresome to read. In effect we are swapping horizontal >> expansion for vertical expansion. It would be nicer to be able to >> fit a plan into a screen. > > Isn't that what text format is for? In my experience XML which represents an

Re: [HACKERS] Re: pgsql: Ship documentation without intermediate tarballs Documentation

On Monday 10 August 2009 23:03:12 Alvaro Herrera wrote: > Hmm, I notice that this rule to install manpages is pretty slow: > > for file in /pgsql/source/00head/doc/src/sgml/man1/*.1 > /pgsql/source/00head/doc/src/sgml/man3/*.3 > /pgsql/source/00head/doc/src/sgml/man7/*.7; do /bin/sh > /pgsql/source

Re: [HACKERS] Hot standby and synchronous replication status

Le 11 août 09 à 23:30, Robert Haas a écrit : On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine> wrote: We should somehow provide a default archive and restore command integrated into the main product, so that it's as easy as turning it 'on' in the configuration for users to have something trus

Re: [HACKERS] machine-readable explain output v4

On Tue, Aug 11, 2009 at 3:59 PM, Andrew Dunstan wrote: > Good. I had a look at this for a little while yesterday. I built it, did an > install, loaded auto_explain and then ran the regression tests. I didn't > like the output much. It looks like the XML has been dumbed down to fit a > data model th

Re: [HACKERS] Any tutorial or FAQ on building an extension?

On Tue, Aug 11, 2009 at 4:00 PM, Kevin Grittner wrote: > Matt Culbreth wrote: > >> My new component intercepts this, and decides if it wants to do >> something > >> If it does, it passes the request over to my new server (via >> sockets), does its work, and pass back the results > > That's still t

Re: [HACKERS] Hot standby and synchronous replication status

On Tue, Aug 11, 2009 at 5:20 PM, Dimitri Fontaine wrote: > We should somehow provide a default archive and restore command integrated > into the main product, so that it's as easy as turning it 'on' in the > configuration for users to have something trustworthy: PostgreSQL will keep > past logs int

Re: [HACKERS] dependencies for generated header files

On Tue, Aug 11, 2009 at 4:38 PM, Peter Eisentraut wrote: > On Sunday 28 June 2009 21:21:35 Robert Haas wrote: >> I think that our dependencies for generated header files (gram.h, >> fmgroids.h, probes.h) are not as good as they could be.  What we do >> right now is make src/backend/Makefile rebuild

Re: [HACKERS] "Hot standby"?

Incidentally, we billed pg_dump as hot backup at some point. mysql calls "mysqlhotcopy" a script that locks and flushes all tables, then makes a copy of the database directory (all queries being locked out while this is in progress, of course). -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] Hot standby and synchronous replication status

Hi, Le 11 août 09 à 07:50, Heikki Linnakangas a écrit : >2009/8/11 Robert Haas > We should probably have a separate discussion about what the least > committable unit would be for this patch. I wonder if it might be > sufficient to provide a facility for streaming WAL, plus a standalone > t

Re: [HACKERS] autogenerating headers & bki stuff

On Tue, Aug 11, 2009 at 4:52 PM, Peter Eisentraut wrote: > On Tuesday 30 June 2009 06:59:51 Robert Haas wrote: >> The attached patch merges all of the logic currently in genbki.sh and >> Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl > > I can't really convince myself to like this c

Re: [HACKERS] autogenerating headers & bki stuff

Peter Eisentraut escribió: > On Tuesday 30 June 2009 06:59:51 Robert Haas wrote: > > The attached patch merges all of the logic currently in genbki.sh and > > Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl > > I can't really convince myself to like this change. I think there is so

Re: [HACKERS] "Hot standby"?

On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus wrote: > So really, the "streaming replication" patch should be called "hot > standby", No. AIUI, hot standby means that when your primary falls over, the secondary automatically promotes itself and takes over. It requires things like heartbeat monito

Re: [HACKERS] "Hot standby"?

On Tuesday 11 August 2009 18:16:04 Gianni Ciolli wrote: > As for "warm/hot", it depends on what you exactly mean with "get > ready": > > (A) If you mean "it is possible to connect to the second node", then > Simon's patch is "hot". Yeah, but by that definiton doing a pg_dump/pg_restore every h

Re: [HACKERS] "Hot standby"?

On Tue, Aug 11, 2009 at 01:14:56PM -0400, Robert Haas wrote: > On Tue, Aug 11, 2009 at 1:08 PM, Josh Berkus wrote: > > I believe we're just copying Oracle's terminology.  While that > > terminology is not consistent, it is understood by the industry.  Oracle > > defined their Hot Standby to have bo

Re: [HACKERS] Shipping documentation untarred

On Tuesday 11 August 2009 17:02:01 Tom Lane wrote: > Having all the derived files in the build directory definitely seems > to me to reduce the complexity and surprise factor, so +1 for changing. I've looked at that briefly, and it's a bit more complicated than it would appear. I will figure thi

Re: [HACKERS] autogenerating headers & bki stuff

On Tuesday 30 June 2009 06:59:51 Robert Haas wrote: > The attached patch merges all of the logic currently in genbki.sh and > Gen_fmgrtab.{sh,pl} into a single script called gen_catalog.pl I can't really convince myself to like this change. I think there is some merit that these scripts are sepa

Re: [HACKERS] machine-readable explain output v4

On Tuesday 11 August 2009 21:59:48 Andrew Dunstan wrote: > Tom Lane wrote: > > Mike writes: > >> Have any tool authors stepped up and committed resources to utilizing > >> this feature in the near term? > > > > I don't think anyone's promised much. If you want to have a go at using > > it, we'd b

Re: [HACKERS] dependencies for generated header files

On Sunday 28 June 2009 21:21:35 Robert Haas wrote: > I think that our dependencies for generated header files (gram.h, > fmgroids.h, probes.h) are not as good as they could be. What we do > right now is make src/backend/Makefile rebuild these before recursing > through its subdirectories. This wo

Re: [HACKERS] "Hot standby"?

On Tue, Aug 11, 2009 at 4:07 PM, Josh Berkus wrote: > All, > > So really, the "streaming replication" patch should be called "hot > standby", and the "hot standby" patch should be called "read only slaves"? > > And *why* can't we call it log-based replication? +1 *) it _is_ used to replicate a da

Re: [HACKERS] "Hot standby"?

All, So really, the "streaming replication" patch should be called "hot standby", and the "hot standby" patch should be called "read only slaves"? And *why* can't we call it log-based replication? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Any tutorial or FAQ on building an extension?

Matt Culbreth wrote: > My new component intercepts this, and decides if it wants to do > something > If it does, it passes the request over to my new server (via > sockets), does its work, and pass back the results That's still too vague to allow people to give very specific advice. For ex

Re: [HACKERS] machine-readable explain output v4

Tom Lane wrote: Mike writes: Have any tool authors stepped up and committed resources to utilizing this feature in the near term? I don't think anyone's promised much. If you want to have a go at using it, we'd be very happy. I'm guessing that my vision likely exceeds the scop

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Alvaro Herrera writes: > Andrew Dunstan escribió: >> Here's the extract attached. I replace tabs with a literal '\t' so >> I could see what it was doing. I can't make much head or tail of it >> either. > pgindent uses entab/detab, which counts spaces and replaces them with > tabs. It is wildly

Re: [HACKERS] "Hot standby"?

Mark Mielke wrote: > This patch does not provide streaming replication? There's a separate effort to provide asynchronous and synchronous streaming replication. Different patch. > "Hot standby" to me means "the slave is as close to up-to-date as > possible and can potentially take over at a

Re: [HACKERS] "Hot standby"?

Mark Mielke escribió: > I don't think I was confused before - but I am confused now. :-) > > This patch does not provide streaming replication? No. What it does is allow you to query the slave while it's still replaying transactions. There's another patch allowing you to do "stream replication

Re: [HACKERS] "Hot standby"?

On 08/11/2009 02:52 PM, Robert Haas wrote: On Tue, Aug 11, 2009 at 2:48 PM, Mark Mielke wrote: I remember this debate from 6 months ago. :-) I prefer not to try and fit square pegs into round holes. Streaming replication sounds like the best description. It may not be the keywords that new

Re: [HACKERS] Any tutorial or FAQ on building an extension?

On Aug 11, 1:11 pm, j...@agliodbs.com (Josh Berkus) wrote: > > Is there an easier way of going about this other than replacing the > > postmaster / postgres components? > > I'd start with creating my own extended version to psql (the client > library), I suppose.  But since I don't really know what

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Andrew Dunstan escribió: > > > Tom Lane wrote: > >Andrew Dunstan writes: > >>Robert Haas wrote: > >>>Where it really bit me as when it reindented the DATA() statements > >>>that were touched by ALTER TABLE ... SET STATISTICS DISTINCT. It's > >>>not so hard to compare code, but comparing DATA()

Re: [HACKERS] "Hot standby"?

On Tue, Aug 11, 2009 at 2:10 PM, Ron Mayer wrote: > David Fetter wrote: >> On Tue, Aug 11, 2009 at 08:56:38AM -0500, Kevin Grittner wrote: >>> Bruce Momjian wrote: >>> OK, so it is "warm slave". > > Why isn't it just a "read only slave".  Do some systems > have read-only slave databases that

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Andrew Dunstan writes: > Robert Haas wrote: >> Where it really bit me as when it reindented the DATA() statements >> that were touched by ALTER TABLE ... SET STATISTICS DISTINCT. It's >> not so hard to compare code, but comparing DATA() lines is the pits. > Oh? Maybe that's a problem we need to

Re: [HACKERS] "Hot standby"?

On Tue, Aug 11, 2009 at 2:48 PM, Mark Mielke wrote: > On 08/11/2009 09:56 AM, Kevin Grittner wrote: > > Bruce Momjian wrote: > > > > OK, so it is "warm slave". > > > > That is technically accurate, given the preceding definitions, but it > has disturbing connotations. Enough so, in my view, to me

Re: [HACKERS] "Hot standby"?

On 08/11/2009 09:56 AM, Kevin Grittner wrote: Bruce Momjian wrote: OK, so it is "warm slave". That is technically accurate, given the preceding definitions, but it has disturbing connotations. Enough so, in my view, to merit getting a little more creative in the naming. How about

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Robert Haas wrote: On Tue, Aug 11, 2009 at 12:52 PM, Andrew Dunstan wrote: Robert Haas wrote: I'm not sure there's a good solution to this problem short of making pgindent easy enough that we can make it a requirement for patch submission, and I'm not sure that's practical. But in an

Re: [HACKERS] machine-readable explain output v4

Mike writes: > Have any tool authors stepped up and committed resources to utilizing > this feature in the near term? I don't think anyone's promised much. If you want to have a go at using it, we'd be very happy. > I'm guessing that my vision likely exceeds the scope of this feature in > its i

Re: [HACKERS] machine-readable explain output v4

On Tue, 11 Aug 2009 13:11:47 -0400 Robert Haas wrote: > Unfortunately, I have to admit to total confusion. The idea in the > last paragraph seems reasonable to me, but since I don't understand > the other alternative, I can't say whether it's better or worse. I > wonder if we would be better of

Re: [HACKERS] "Hot standby"?

David Fetter wrote: > On Tue, Aug 11, 2009 at 08:56:38AM -0500, Kevin Grittner wrote: >> Bruce Momjian wrote: >> >>> OK, so it is "warm slave". Why isn't it just a "read only slave". Do some systems have read-only slave databases that can't serve as a warm standby system as well as this one c

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

On Tue, Aug 11, 2009 at 12:52 PM, Andrew Dunstan wrote: > Robert Haas wrote: >> >> I'm not sure there's a >> good solution to this problem short of making pgindent easy enough >> that we can make it a requirement for patch submission, and I'm not >> sure that's practical. >> >> But in any case, I t

Re: [HACKERS] "Hot standby"?

On Tue, Aug 11, 2009 at 1:08 PM, Josh Berkus wrote: > I believe we're just copying Oracle's terminology.  While that > terminology is not consistent, it is understood by the industry.  Oracle > defined their Hot Standby to have both asynchronous and synchronous modes: > http://www.oracle.com/techno

Re: [HACKERS] Any tutorial or FAQ on building an extension?

> Is there an easier way of going about this other than replacing the > postmaster / postgres components? I'd start with creating my own extended version to psql (the client library), I suppose. But since I don't really know what kind of "transformations" you have in mind, any advice is going to

Re: [HACKERS] machine-readable explain output v4

On Tue, Aug 11, 2009 at 12:11 PM, Tom Lane wrote: > Robert Haas writes: >> I think I might be starting to understand what you're getting at here. >>  Let me check: I think what you're saying is that the Expr node is >> potentially useful to clients for identifying where in the tree the >> Exprs ar

Re: [HACKERS] "Hot standby"?

Peter, I believe we're just copying Oracle's terminology. While that terminology is not consistent, it is understood by the industry. Oracle defined their Hot Standby to have both asynchronous and synchronous modes: http://www.oracle.com/technology/products/rdb/htdocs/dbms/hotstandby.html The o

Re: [HACKERS] Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)

Robert Haas wrote: I'm not sure there's a good solution to this problem short of making pgindent easy enough that we can make it a requirement for patch submission, and I'm not sure that's practical. But in any case, I think running pgindent immediately after the last CommitFest rather than af

  1   2   >