[HACKERS] [RFC,PATCH] Avoid manual shift-and-test logic in AllocSetFreeIndex

Move the shift-and-test login into a separate fls() function, which can use __builtin_clz() if it's available. This requires a new check for __builtin_clz in the configure script. Results in a ~2% performance increase on PowerPC. Signed-off-by: Jeremy Kerr --- configure.in |

Re: [HACKERS] Synchronous replication: status of standby side

Kolb, Harald (NSN - DE/Munich) wrote: > Hi, > > will there be a possibility to retrieve the standby situation in case of > synchronous replication ? > We would need a command or similar to report the current state and state > changes > (like: syncing, in-sync, replication broken, ..). > Observin

Re: [HACKERS] Managing multiple branches in git

Tom Lane wrote: > Andrew Dunstan writes: > > The only reason Tom sees a single line history is because he uses an > > addon tool for CVS called cvs2cl: see . > > It's not part of CVS, and I'm not sure how many others use it. I sure > > don't. > > FWIW, I believ

Re: [HACKERS] 8.4b2 tsearch2 strange error

> > I found the cause of this one --- the new code for estimating the > > selectivity of @@ was not guarding against the possibility that the > > given TSQuery is empty, as it is in this example. > > Shouldn't be this in regression test? > > > I'm still unable to reproduce the "tuple offset out o

Re: [HACKERS] Improving the ngettext() patch

Tom Lane writes: > ereport(ERROR, > (errcode(ERRCODE_TOO_MANY_ARGUMENTS), > errmsg(ngettext("functions cannot have more than %d > argument", > "functions cannot have more than %d > arguments", >

Re: [HACKERS] 8.4b2 tsearch2 strange error

> I found the cause of this one --- the new code for estimating the > selectivity of @@ was not guarding against the possibility that the > given TSQuery is empty, as it is in this example. Shouldn't be this in regression test? > I'm still unable to reproduce the "tuple offset out of range" error

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

On Wed, Jun 3, 2009 at 5:24 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner >> wrote: >>> I'm finding that even the ones that had a plan time in the range of >>> 260 ms go down to 15 ms to 85 ms once the statistics are cached. > >> I had some performan

Re: [HACKERS] Locks on temp table and PREPARE

Tom Lane wrote: Emmanuel Cecchet writes: But when the transaction prepares, we know that. What would prevent us to do at prepare time the same cleanup that commit does? The entire point of PREPARE is that it's *not* committed yet. Agreed but all objects that were created and droppe

Re: [HACKERS] [PATCH v2] Add bit operations util header

Hi Tom, > The other thing I didn't like about the patch was the assumption that > it's okay to have a "static inline" function in a header. You can > get away with that in gcc but *not* in other compilers. Gee, you user-space guys have it tough! :D Point taken, will rework. > Look at the exist

Re: [HACKERS] [GENERAL] trouble with to_char('L')

Tom Lane wrote: > Hiroshi Inoue writes: >> Tom Lane wrote: >>> * This seems to be assuming that the user has set LC_MONETARY and >>> LC_NUMERIC the same. What if they're different? > >> Strictky speaking they should be handled individually. > > I thought about this some more, and I wonder why y

Re: [HACKERS] It's June 1; do you know where your release is?

Dave Page wrote: On Wed, Jun 3, 2009 at 11:54 PM, Andrew Dunstan wrote: Update: the problem is apparently occurring during the call to perl_parse() in plperl_init_interp(). Not sure if you saw the previous thread on this, but here's a backtrace that gives some more detail: http://a

Re: [HACKERS] User-facing aspects of serializable transactions

Added to TODO: Consider improving serialized transaction behavior to avoid anomalies * http://archives.postgresql.org/pgsql-hackers/2009-05/msg01136.php * http://archives.postgresql.org/pgsql-hackers/2009-06/msg00035.php -

Re: [HACKERS] It's June 1; do you know where your release is?

On Wed, Jun 3, 2009 at 11:54 PM, Andrew Dunstan wrote: > > > Update: the problem is apparently occurring during the call to perl_parse() > in plperl_init_interp(). > Not sure if you saw the previous thread on this, but here's a backtrace that gives some more detail: http://archives.postgresql.org

Re: [HACKERS] 8.4b2 tsearch2 strange error

Tom Lane wrote: > Tatsuo Ishii writes: >>> initdb -E UTF-8 --no-locale /path/to/database > >> So locale is "C". I believe we are not customizing >> default_text_search_config. I'm not think of any nondefault >> configuration settings. > > Huh. So that should be the same case I tested here. I

Re: [HACKERS] It's June 1; do you know where your release is?

Andrew Dunstan wrote: Andrew Dunstan wrote: Josh Berkus wrote: * plperl fails with Perl 5.10 on Windows o tgl says: no reports of this with pre-8.4 Postgres, but I bet that's just because no one tried it o dpage says: I'm rolling back the Windows installers to

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

On 06/03/2009 10:42 PM, Kevin Grittner wrote: Robert Haas wrote: When you say, "don't fit in cache", exactly what cache are you talking about? It seems to me that the statistics should be far smaller than the underlying tables, so if even your statistics don't fit in shared buffers (let alone

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

On 06/03/2009 08:57 PM, Gregory Stark wrote: "Kevin Grittner" writes: Andres Freund wrote: long plan times (minutes and up) Wow. I thought I had some pretty complex queries, including some which join using several views, each of which has several joins; but I've never gone to multiple secon

Re: [HACKERS] 8.4b2 tsearch2 strange error

On Wed, 3 Jun 2009, Tom Lane wrote: Tatsuo Ishii writes: initdb -E UTF-8 --no-locale /path/to/database So locale is "C". I believe we are not customizing default_text_search_config. I'm not think of any nondefault configuration settings. Huh. So that should be the same case I tested here

Re: [HACKERS] 8.4b2 tsearch2 strange error

Tatsuo Ishii writes: >> initdb -E UTF-8 --no-locale /path/to/database > So locale is "C". I believe we are not customizing > default_text_search_config. I'm not think of any nondefault > configuration settings. Huh. So that should be the same case I tested here. I wonder why I can't duplicate

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Greg Stark writes: > It does seem like it ought to be possible to truncate strings in the > histogram since any string between the actual values us equally good. Yeah, that was the justification for dropping the wide values --- that and the theory that they'd be unlikely to be most-common value

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Doesn't that still add up to 3GB for a table's stats in the worst case? 1kb * 1,000 buckets * 1,500 attributes * 2 (histogram + mfv) Except you can't actually get 1500 toast pointers on a page. I suppose with games with nulls you could make this worst case happen though. It does seem like i

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

On 06/03/2009 07:05 PM, Kevin Grittner wrote: Andres Freund wrote: long plan times (minutes and up) Wow. I thought I had some pretty complex queries, including some which join using several views, each of which has several joins; but I've never gone to multiple seconds on plan time (much le

Re: [HACKERS] 8.4b2 tsearch2 strange error

> Hmm. I can confirm the "unrecognized operator" failure (though I get > "8" not "-50" ... uninitialized memory?). The "tuple out of range" > failures are not happening here though. Perhaps it is locale dependent? > What locale are you using, and what is your default_text_search_config > setting

Re: [HACKERS] Locks on temp table and PREPARE

Emmanuel Cecchet writes: > But when the transaction prepares, we know that. What would prevent us > to do at prepare time the same cleanup that commit does? The entire point of PREPARE is that it's *not* committed yet. regards, tom lane -- Sent via pgsql-hackers mailin

Re: [HACKERS] Locks on temp table and PREPARE

Tom Lane wrote: Emmanuel Cecchet writes: Tom Lane wrote: True, but the problem is that the tuple might still be live to (some snapshots in) that transaction, so we can't inject a duplicate tuple without risking confusing it. In this particular case that isn't an issue because the tran

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Robert Haas writes: > On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner > wrote: >> I'm finding that even the ones that had a plan time in the range of >> 260 ms go down to 15 ms to 85 ms once the statistics are cached. > I had some performance results back when we were last looking at > default_st

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

"Kevin Grittner" writes: > Since he can't share the schema, and hasn't even given much of a hint, > I don't know whether one (or more) of the columns is a bytea filled > with 100 MB values; and I don't remember any description of the > hardware environment either. Since the behavior seems so > ou

Re: [HACKERS] Postgres delays function returning large set of data

Hello can you send source code? There are two types of C SRF functions. One returns row ro by row, second store returned rows and returns block. What did you use? ignore comments (in czech please) and look on code - http://www.postgres.cz/index.php/Iter%C3%A1tor_pole regards Pavel Stehule 2009/

Re: [HACKERS] Locks on temp table and PREPARE

Emmanuel Cecchet wrote: > Tom Lane wrote: >> True, but the problem is that the tuple might still be live to (some >> snapshots in) that transaction, so we can't inject a duplicate tuple >> without risking confusing it. In this particular case that isn't an >> issue because the transaction is done

Re: [HACKERS] Locks on temp table and PREPARE

Emmanuel Cecchet writes: > Tom Lane wrote: >> True, but the problem is that the tuple might still be live to (some >> snapshots in) that transaction, so we can't inject a duplicate tuple >> without risking confusing it. In this particular case that isn't an >> issue because the transaction is don

[HACKERS] Improving the ngettext() patch

After looking through the current uses of ngettext(), I think that it wouldn't be too difficult to modify the patch to address the concerns I had about it. What I propose doing is to add an additional elog.h function errmsg_plural(const char *fmt_singular, const char *fmt_plural, un

Re: [HACKERS] Locks on temp table and PREPARE

Tom Lane wrote: True, but the problem is that the tuple might still be live to (some snapshots in) that transaction, so we can't inject a duplicate tuple without risking confusing it. In this particular case that isn't an issue because the transaction is done executing, but the tqual.c rules don

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Robert Haas wrote: > When you say, "don't fit in cache", exactly what > cache are you talking about? It seems to me that the statistics > should be far smaller than the underlying tables, so if even your > statistics don't fit in shared buffers (let alone main memory), it > doesn't really matt

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

On Wed, Jun 3, 2009 at 3:18 PM, Kevin Grittner wrote: > Gregory Stark wrote: > >> My money's still on very large statistics targets. If you have a lot >> of columns and 1,000-element arrays for each column that can get big >> pretty quickly. > > I'm finding that even the ones that had a plan time

Re: [HACKERS] list_head naming conflict gcc 4.2/perl/solaris

Zdenek Kotala píše v po 01. 06. 2009 v 22:45 +0200: > Tom Lane píše v po 01. 06. 2009 v 16:09 -0400: > > Zdenek Kotala writes: > > > > What is , and why is it being imported by the Perl headers? > > It seems that problem is with Perl. It includes sys/mode.h. The new > change for gcc 4.2 is tha

Re: [HACKERS] Managing multiple branches in git

My last post on the git issue... If any one wants to ask specific questions, feel free to e-mail me directly... But this thread has digressed to way too much hand-waving... If any of your are not familiar with git and want to get an overview of it, this might be a good place to start: h

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Gregory Stark wrote: > My money's still on very large statistics targets. If you have a lot > of columns and 1,000-element arrays for each column that can get big > pretty quickly. I'm finding that even the ones that had a plan time in the range of 260 ms go down to 15 ms to 85 ms once the st

Re: [HACKERS] PostgreSQL Developer meeting minutes up

Robert Haas wrote: > But I > wonder if it would make more sense to include some kind of metadata in > the commit message (or some other property of the commit? does git > support that?) to make it not depend on that. >From elsewhere in this thread[1], 'The "git cherry-pick" ... "-x" flag adds a n

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Gregory Stark writes: > But that doesn't explain the bitmap ops being important. Hm. Actually > having a lot of columns and then joining a lot of tables could mean > having fairly large bitmapsets. Yeah, but then you have a lot of *other* expensive operations too, such as the aforementioned stati

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

"Kevin Grittner" writes: > Andres Freund wrote: > >> long plan times (minutes and up) > > Wow. I thought I had some pretty complex queries, including some > which join using several views, each of which has several joins; but > I've never gone to multiple seconds on plan time (much less mu

Re: [HACKERS] 8.4b2 tsearch2 strange error

Tatsuo Ishii writes: > STATEMENT: SELECT msg_sid, hdr_from, hdr_to, hdr_subject, msg_date, > folder_id, msgnum FROM msginfo LEFT JOIN msg_folderinfo USING (msg_sid) WHERE > plainto_tsquery(E'a') @@ body_index > NOTICE: text-search query contains only stop words or doesn't contain > lexemes, i

Re: [HACKERS] [GENERAL] trouble with to_char('L')

Hiroshi Inoue writes: > Tom Lane wrote: >> * This seems to be assuming that the user has set LC_MONETARY and >> LC_NUMERIC the same. What if they're different? > Strictky speaking they should be handled individually. I thought about this some more, and I wonder why you did it like this at all.

Re: [HACKERS] It's June 1; do you know where your release is?

Tom Lane wrote: > Magnus Hagander writes: >> Josh Berkus wrote: >>> * Path separator consistency on Windows >>> >>> -- This discussion does not appear to have concluded. Magnus, Dave? > >> We've lived with this for a long time, it's nothing new. And it's not >> critical. Bump to 8.5. > > This i

Re: [HACKERS] It's June 1; do you know where your release is?

Magnus Hagander writes: > Josh Berkus wrote: >> * Path separator consistency on Windows >> >> -- This discussion does not appear to have concluded. Magnus, Dave? > We've lived with this for a long time, it's nothing new. And it's not > critical. Bump to 8.5. This is partly my fault, since I ob

Re: [HACKERS] It's June 1; do you know where your release is?

Josh Berkus writes: > More suggested dispositions: > * contrib/seg and contrib/cube GiST index support have performance issues > -- If it's just a performance issue, I don't think this issue should > block 8.4.0; it can be fixed in 8.4.1 if necessary, since we'll probably > want to backpa

Re: [HACKERS] Managing multiple branches in git

Magnus Hagander wrote: Andrew Dunstan wrote: Dave Page wrote: On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera wrote: Well, it sounds about perfect for my use case too (which is approximately the same as Tom's), but the description makes it sound unsupported. It doesn't wor

Re: [HACKERS] Managing multiple branches in git

Hi, On 06/03/2009 07:26 PM, Andrew Dunstan wrote: Andres Freund wrote: The git for windows installation includes a functional unix-alike shell (mingw, not cygwin or such). Some core part of git are still written in shell, so it would not work without that anyway. Ah. Ok. Good to know. Does it

Re: [HACKERS] pg_migrator status for 8.4

Alvaro Herrera writes: > Bruce Momjian wrote: >> pg_migrator will require a reindex if: >> o an index is of type hash or gin >> o an index uses bpchar_pattern_ops > What about varchar_pattern_ops and text_pattern_ops? Are they not > affected? Nope. See http://archives.postgresql.org/pgsql-co

Re: [HACKERS] Managing multiple branches in git

Andres Freund wrote: The git for windows installation includes a functional unix-alike shell (mingw, not cygwin or such). Some core part of git are still written in shell, so it would not work without that anyway. Ah. Ok. Good to know. Does it contain a builtin "ln" command? And does that

Re: [HACKERS] Managing multiple branches in git

Andrew Dunstan wrote: > > > Dave Page wrote: >> On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera >> wrote: >> >> >>> Well, it sounds about perfect for my use case too (which is >>> approximately the same as Tom's), but the description makes it sound >>> unsupported. It doesn't work on Windows w

Re: [HACKERS] Managing multiple branches in git

Markus Wanner wrote: > Hi, > > Quoting "David E. Wheeler" : >> Monotone? > > ..one of the sources of inspiration for Linus to write git. He was not > satisfied with its speed and he didn't like C++ and SQL. Plus the main > contributors weren't around at the time Linus was on the mailing list.

Re: [HACKERS] 8.4b2 tsearch2 strange error

Tatsuo Ishii writes: > Sorry for delay. I have put a database dump at: > http://sylpheed.sraoss.jp/tmp/dump.sql.gz > We got following errors using this database: Hmm. I can confirm the "unrecognized operator" failure (though I get "8" not "-50" ... uninitialized memory?). The "tuple out of ran

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Andres Freund wrote: > long plan times (minutes and up) Wow. I thought I had some pretty complex queries, including some which join using several views, each of which has several joins; but I've never gone to multiple seconds on plan time (much less multiple minutes!) without very high stati

Re: [HACKERS] pg_migrator status for 8.4

Bruce Momjian wrote: > pg_migrator will require a reindex if: > > o an index is of type hash or gin > o an index uses bpchar_pattern_ops What about varchar_pattern_ops and text_pattern_ops? Are they not affected? -- Alvaro Herrerahttp://www.C

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

On 06/03/2009 06:42 PM, Tom Lane wrote: Andres Freund writes: On 06/03/2009 06:21 PM, Tom Lane wrote: I find this *really* hard to believe, because I've never seen the bitmap support operations show up noticeably at all in profiles. What sort of queries are you testing? Many left joins fro

Re: [HACKERS] Managing multiple branches in git

Andrew Dunstan writes: > You have carefully left out the first sentence of my reply. Neither of > the committers who actually do much work on Windows (namely Magnus and > me) commit direct from *any* version of Windows. Nonetheless, that might not be true in future. I'd be a bit worried about

Re: [HACKERS] Managing multiple branches in git

On 06/03/2009 06:38 PM, Andrew Dunstan wrote: Andres Freund wrote: On 06/03/2009 06:17 PM, Andrew Dunstan wrote: Tom Lane wrote: I think the appropriate question is why doesn't it work on Windows, and is that fixable? Without having looked, I'm guessing the issue is that it depends on hardlink

Re: [HACKERS] Question about STRICT

Tom Lane wrote: Gevik Babakhani writes: Perhaps it is an idea to have something like: "RAISE ERROR ON NULL INPUT" [ shrug... ] There's really been no demand for that. If you want a particular function to do it, you can put suitable tests and error reports into that function. I can't see

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Andres Freund writes: > On 06/03/2009 06:21 PM, Tom Lane wrote: >> I find this *really* hard to believe, because I've never seen the bitmap >> support operations show up noticeably at all in profiles. What sort of >> queries are you testing? > Many left joins from one base relation to additional

Re: [HACKERS] Managing multiple branches in git

Andres Freund wrote: On 06/03/2009 06:17 PM, Andrew Dunstan wrote: Tom Lane wrote: I think the appropriate question is why doesn't it work on Windows, and is that fixable? Without having looked, I'm guessing the issue is that it depends on hardlinks or symlinks --- and we know those are avail

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Hi, On 06/03/2009 06:21 PM, Tom Lane wrote: Andres Freund writes: When switching bitmapword and companions in bitmap.h to u64 and s64 respectively I get an improvement up to 15% in queries with 16+ joins. I find this *really* hard to believe, because I've never seen the bitmap support operati

Re: [HACKERS] Managing multiple branches in git

Tom Lane wrote: Dave Page writes: On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera wrote: Well, it sounds about perfect for my use case too (which is approximately the same as Tom's), but the description makes it sound unsupported. It doesn't work on Windows which doesn't bother me p

Re: [HACKERS] Managing multiple branches in git

On 06/03/2009 06:17 PM, Andrew Dunstan wrote: Tom Lane wrote: I think the appropriate question is why doesn't it work on Windows, and is that fixable? Without having looked, I'm guessing the issue is that it depends on hardlinks or symlinks --- and we know those are available, as long as you're

Re: [HACKERS] Plan time Improvement - 64bit bitmapset

Andres Freund writes: > When switching bitmapword and companions in bitmap.h to u64 and s64 > respectively I get an improvement up to 15% in queries with 16+ joins. I find this *really* hard to believe, because I've never seen the bitmap support operations show up noticeably at all in profiles.

Re: [HACKERS] Managing multiple branches in git

On Wed, Jun 3, 2009 at 5:14 PM, Dave Page wrote: > It's a simple perl script that uses symlinks: > http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/workdir/git-new-workdir Err, shell script even. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers maili

Re: [HACKERS] Managing multiple branches in git

On Wed, Jun 3, 2009 at 5:01 PM, Tom Lane wrote: > Dave Page writes: >> On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera >> wrote: >>> Well, it sounds about perfect for my use case too (which is >>> approximately the same as Tom's), but the description makes it sound >>> unsupported.  It doesn't wo

Re: [HACKERS] Managing multiple branches in git

Dave Page wrote: On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera wrote: Well, it sounds about perfect for my use case too (which is approximately the same as Tom's), but the description makes it sound unsupported. It doesn't work on Windows which doesn't bother me personally but may be a

Re: [HACKERS] Managing multiple branches in git

On Wed, 2009-06-03 at 12:01 -0400, Tom Lane wrote: > I think the appropriate question is why doesn't it work on Windows, > and is that fixable? Without having looked, I'm guessing the issue > is that it depends on hardlinks or symlinks --- and we know those are > available, as long as you're usin

Re: [HACKERS] Managing multiple branches in git

Dave Page writes: > On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera > wrote: >> Well, it sounds about perfect for my use case too (which is >> approximately the same as Tom's), but the description makes it sound >> unsupported.  It doesn't work on Windows which doesn't bother me >> personally but

Re: [HACKERS] [PATCH v2] Add bit operations util header

Florian Weimer writes: > * Jeremy Kerr: >> Because now we have to test the compiler *and* the version as well? > This builtin is not architecture-specific, so you'd save the > architecture check. The appropriate way to handle it would be a configure probe to see if the function is available, thu

Re: [HACKERS] PostgreSQL Developer meeting minutes up

* Marko Kreen [090603 11:28]: > I'm not certain, but I remember using cherry pick and seeing > several commits in result. This seems to be a point that needs > to be checked. I'm not sure what you're recalling, but git cherry-pick takes a single commit, and applies it as a single commit (or, w

[HACKERS] Postgres delays function returning large set of data

Hello, First some background: For my application I need to collect and retrieve data at a very fast rate, faster than postgres can produce, but I also have the need to store and access a large range of metadata about the large sets of data I am storing. I am therefore attempting to use postgres

[HACKERS] Plan time Improvement - 64bit bitmapset

Hi, While analyzing some complex query and switching away from using the materialized views to their underlying ones I got interested in the long plan times (minutes and up) and did some profiling work. The queries are high dimensional star-schema-alike queries (unfortunately quite private (hea

Re: [HACKERS] Question about STRICT

Gevik Babakhani writes: > Perhaps it is an idea to have something like: > "RAISE ERROR ON NULL INPUT" [ shrug... ] There's really been no demand for that. If you want a particular function to do it, you can put suitable tests and error reports into that function. I can't see us adding extra

[HACKERS] Synchronous replication: status of standby side

Hi, will there be a possibility to retrieve the standby situation in case of synchronous replication ? We would need a command or similar to report the current state and state changes (like: syncing, in-sync, replication broken, ..). Observing and scaning the logfile would not be appropriate. Ar

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On 6/3/09, Aidan Van Dyk wrote: > * Marko Kreen [090603 11:12]: > > Well, thats good to know, but this also seems to mean it's rather bad > > tool for back-patching, as you risk including random unwanted commits > > too that happened in the HEAD meantime. But also, it's very good > > tool fo

Re: [HACKERS] PostgreSQL Developer meeting minutes up

* Marko Kreen [090603 11:12]: > Well, thats good to know, but this also seems to mean it's rather bad > tool for back-patching, as you risk including random unwanted commits > too that happened in the HEAD meantime. But also, it's very good > tool for forward-patching. It doesn't "pull in comm

Re: [HACKERS] Managing multiple branches in git

On Wed, Jun 3, 2009 at 4:01 PM, Alvaro Herrera wrote: > Well, it sounds about perfect for my use case too (which is > approximately the same as Tom's), but the description makes it sound > unsupported.  It doesn't work on Windows which doesn't bother me > personally but may be a showstopper more

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On 6/3/09, Aidan Van Dyk wrote: > * Marko Kreen [090603 10:26]: > > Thats true, but it's not representable in VCS, unless you use cherry-pick, > > which is just UI around patch transport. But considering separate > > local trees (with can optionally contain local per-fix branches), > > it is

Re: [HACKERS] Warnings in compile

Tom Lane wrote: > Michael Meskes writes: > > On Mon, May 25, 2009 at 10:19:40AM -0400, Tom Lane wrote: > >> That sounds both dangerous and against our coding conventions. The > >> standard way to do that is "do { ... } while (0)" > > > Which won't work here as the macros have continue and break

Re: [HACKERS] Managing multiple branches in git

Robert Haas escribió: > On Tue, Jun 2, 2009 at 7:54 PM, Alvaro Herrera > wrote: > > I think these are the two usable options.  They will probably end up > > ...wait a minute. I just went and Googled this git-new-workdir thing > and it looks like it's almost exactly what we need. According to

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On Wed, Jun 3, 2009 at 10:20 AM, Marko Kreen wrote: > Various scenarios with git cherry-pick and similar tools would still > result in duplicate commits, so we would need a git log post-processor > anyway if we want to somehow group them together for eg. weekly commit > summary.  And such post-pro

Re: [HACKERS] PostgreSQL Developer meeting minutes up

Robert Haas wrote: > On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander wrote: >>> I'm not sure whether we should mark the old branches getting merges >>> down or the new branches getting merged up. I suspect I'm missing >>> something but I don't see any reason one is better than the other. >> If yo

Re: [HACKERS] PostgreSQL Developer meeting minutes up

* Marko Kreen [090603 10:26]: > Thats true, but it's not representable in VCS, unless you use cherry-pick, > which is just UI around patch transport. But considering separate > local trees (with can optionally contain local per-fix branches), > it is possible to separate the fix-developement fr

Re: [HACKERS] PostgreSQL Developer meeting minutes up

* Magnus Hagander [090603 10:13]: > > Right, if it adds additional metadata that lets the tools do their magic > better, and it's still easy to filter out, I don't see a downside. Note, that it could (and likely will) have a downside when you get to doing real merge-based development... A "merge

Re: [HACKERS] Managing multiple branches in git

Robert Haas wrote: > The problem with making each release a separate directory is that, > just like using separate repositories, it will defeat one of the main > strengths of git, which is the ability to move around commits easily. > git-new-workdir is the only solution to the problem of having mul

Re: [HACKERS] display previous query string of idle-in-transaction

Greg Stark wrote: > Should this patch be on the commitfest page for 8.5? Or is there a > consensus already that it's a bad idea? > > Personally I actually think this makes a lot of sense to do. +1 It at least gives one a reasonable chance to get a useful clue -Kevin -- Sent via pgsql-

Re: [HACKERS] Allow vacuumdb to only analyze

Robert Haas wrote: > I noticed in Bruce's talk that there are a number of post-migration > steps which are currently partially manual. Ideally we'd like to > automate them all, preferably in some sort of well-thought-out order. > I actually suspect this is something like: analyze each database, >

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On 6/3/09, Magnus Hagander wrote: > Robert Haas wrote: > > On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander > wrote: > > >>> I'm not sure whether we should mark the old branches getting merges > >>> down or the new branches getting merged up. I suspect I'm missing > >>> something but I don't

Re: [HACKERS] display previous query string of idle-in-transaction

Should this patch be on the commitfest page for 8.5? Or is there a consensus already that it's a bad idea? Personally I actually think this makes a lot of sense to do. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On Wed, Jun 3, 2009 at 10:13 AM, Magnus Hagander wrote: > Greg Stark wrote: >> On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund wrote: >>> "git log --no-merges" hides the actual merge commits if that is what you >>> want. >> >> Ooh! Life seems so much sweeter now! >> >> Given that we don't have to s

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On 6/3/09, Greg Stark wrote: > On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund wrote: > > "git log --no-merges" hides the actual merge commits if that is what you > > want. > > > Ooh! Life seems so much sweeter now! > > Given that we don't have to see them then I'm all for marking bug fix > pat

Re: [HACKERS] PostgreSQL Developer meeting minutes up

Greg Stark wrote: > On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund wrote: >> "git log --no-merges" hides the actual merge commits if that is what you >> want. > > Ooh! Life seems so much sweeter now! > > Given that we don't have to see them then I'm all for marking bug fix > patches which were ap

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On Wed, Jun 3, 2009 at 1:19 PM, Andres Freund wrote: > "git log --no-merges" hides the actual merge commits if that is what you > want. Ooh! Life seems so much sweeter now! Given that we don't have to see them then I'm all for marking bug fix patches which were applied to multiple branches as me

Re: [HACKERS] Locks on temp table and PREPARE

Tom Lane wrote: Emmanuel Cecchet writes: Take PG 8.3.0 and try: BEGIN; CREATE TEMP TABLE foo (x int) ON COMMIT DROP; PREPARE TRANSACTION 't1'; [BEGIN;] <-- doesn't really matter if you start a new transaction or not CREATE TEMP TABLE foo (x int); <-- blocks until t1 commits I have been

Re: [HACKERS] Locks on temp table and PREPARE

Emmanuel Cecchet writes: > Tom Lane wrote: >> AFAIK that doesn't really have anything to do with the temp-ness of the >> table; it'd be the same with a regular table. The problem is you have >> an in-doubt tuple in pg_class for pg_temp_NNN.foo, and you are trying >> to create another one for the

[HACKERS] pg_migrator status for 8.4

I believe pg_migrator has advanced as far as it is going to for 8.4 and I am expecting to enter beta next week. Here are the known pg_migrator limitations: --- Currently pg_migrator only supports upgrades from 8.3.X to 8.4.X

Re: [HACKERS] Managing multiple branches in git

On 06/03/2009 01:48 PM, Florian Weimer wrote: I wondered for a second about symlinking .git from several checkout directories to a common master, but AFAICT .git stores both the "repository" and status information about the current checkout, so that's not gonna work. "git clone --reference" stor

Re: [HACKERS] PostgreSQL Developer meeting minutes up

Hi, On 06/03/2009 02:08 PM, Greg Stark wrote: On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner wrote: That would make the git history match Tom's "same commit message" implicit CVS history that cvs2pcl was giving him. I find git-log's output including merge commits kind of strange and annoying my

Re: [HACKERS] PostgreSQL Developer meeting minutes up

On Wed, Jun 3, 2009 at 12:10 PM, Markus Wanner wrote: > If you create separate commits during the conversion, rename that file on > the master branch This is all completely irrelevant to the CVS import. I don't think we've ever renamed files because CVS can't handle it cleanly. It does sound to

  1   2   >