Re: [HACKERS] Avoiding bad prepared-statement plans.

On Thu, Feb 25, 2010 at 22:11, Tom Lane wrote: > Alex Hunsaker writes: > Uh, no, this isn't about saving either parse time or bandwidth. > The discussion is about when to expend more planning time in hopes > of getting better plans. This is what im tripping over: > > Bruce's suggestion that we

Re: [HACKERS] A thought on Index Organized Tables

> > > Proving that a set of comparison operators are consistent just by > examining their runtime behavior is probably equivalent to solving the > halting problem. I can't see us doing it, or wanting to accept the > overhead of checking it even if it could be done. > The overhead of checking is v

Re: [HACKERS] A thought on Index Organized Tables

> No, we're not going there. That breaks the fundamental page content > manipulation algorithms, and falls down for tuples not yet stored in a > page (or being examined without a pointer to the page readily at hand), > and has no redeeming social value anyway compared to doing it in the > proven f

Re: [HACKERS] code cleanup: ss_currentScanDesc

Takahiro Itagaki writes: > ScanState.ss_currentScanDesc is currently used by only SeqScan and > BitmapHeapScan. Other scan nodes don't use the field at all, right? > Can we move the field into SeqScanState and BitmapHeapScanState > for code cleanup? This change will not improve any performance, >

Re: [HACKERS] Alpha4 Available Now

http://developer.postgresql.org/pgdocs/postgres/release-9-0.html Performance section: > Simplify the forms foo <> true and foo <> false to foo = false and > foo = true during query optimization. Will it work correct;ly when foo is NULL? -- Sent via pgsql-hackers mailing list (pgsql-hackers@po

[HACKERS] code cleanup: ss_currentScanDesc

ScanState.ss_currentScanDesc is currently used by only SeqScan and BitmapHeapScan. Other scan nodes don't use the field at all, right? Can we move the field into SeqScanState and BitmapHeapScanState for code cleanup? This change will not improve any performance, but it can clear up what we do actu

Re: [HACKERS] Avoiding bad prepared-statement plans.

Alex Hunsaker writes: > I did seem to miss the part where everyone thinks this is a crock... > But I don't remember seeing numbers on parse time or how much > bandwidth this would potentially save. People seem to think it would > be a big savings for just those 2 reasons? Or did I miss some othe

Re: [HACKERS] A thought on Index Organized Tables

Gokulakannan Somasundaram writes: > In the Function based indexes on those functions, which we are > suspecting to be a volatile one Or in the datatypes, which we suspect to be > broken, can we have additional checks to ensure that to ensure that this > does not happen? I mean, do you think,

Re: [HACKERS] A thought on Index Organized Tables

Gokulakannan Somasundaram writes: >> Actually, if you need to squeeze a few more bits into that word, the >> thing to do would be to get rid of storing the tuple length there. >> This would involve adding the same type of indirection header that >> we use for HeapTuples, so that the length would b

Re: [HACKERS] Avoiding bad prepared-statement plans.

On Thu, Feb 25, 2010 at 21:28, Alex Hunsaker wrote: > Not to mention you can already do this more or less client side with a > nice driver. > [ uninformed noise ... ] I did seem to miss the part where everyone thinks this is a crock... But I don't remember seeing numbers on parse time or how much

Re: [HACKERS] A thought on Index Organized Tables

On Fri, Feb 26, 2010 at 9:54 AM, Gokulakannan Somasundaram < gokul...@gmail.com> wrote: > > No, it's far from harmless. As soon as that heap TID gets filled with >> an unrelated tuple, you run the risk of indexscans alighting on and >> perhaps modifying the wrong tuple. >> >> > Tom, i think

Re: [HACKERS] Avoiding bad prepared-statement plans.

On Thu, Feb 25, 2010 at 20:40, Tom Lane wrote: > It's not going to be easier to implement.  Yeah, it would be easy to > provide a global switch via a GUC setting, but that's not going to be > helpful, because this is the sort of thing that really needs to be > managed per-query.  Almost any nontri

Re: [HACKERS] Avoiding bad prepared-statement plans.

Robert Haas writes: > On Thu, Feb 25, 2010 at 10:40 PM, Tom Lane wrote: >> I still like the idea of automatically replanning with the known >> parameter values, and noting whether the result plan was estimated to be >> noticeably cheaper than the generic plan, and giving up on generating >> custo

Re: [HACKERS] A thought on Index Organized Tables

> No, it's far from harmless. As soon as that heap TID gets filled with > an unrelated tuple, you run the risk of indexscans alighting on and > perhaps modifying the wrong tuple. > > Tom, In the Function based indexes on those functions, which we are suspecting to be a volatile one Or in the

Re: [HACKERS] A thought on Index Organized Tables

> >> > First of all, volatility is not the only issue. The ordering ops could also > be incorrect, e.g., violate the transitivity property. there is no reliable > way to determine if a function is volatile and/or incorrectly specified. > No it is the only issue. If you create a datatype with volat

Re: [HACKERS] visibility maps and heap_prune

On Fri, Feb 26, 2010 at 8:19 AM, Bruce Momjian wrote: > > Whatever happened to this? It was in the first 9.0 commitfest but was > returned with feedback but never updated: > > Though Alex did some useful tests and review, and in fact confirmed that the VACUUM time dropped from 16494 msec to 366

Re: [HACKERS] Path separator

I assume we never came to any conclusion on this. --- Magnus Hagander wrote: > Tom Lane wrote: > > Magnus Hagander writes: > >>> Answering myself here: the filesize for the "frontend only" part is > >>> about 2k on this sys

Re: [HACKERS] Allow vacuumdb to only analyze

Jaime Casanova wrote: > On Thu, Feb 25, 2010 at 5:09 PM, Bruce Momjian wrote: > > > > This is implemented in 9.0 from vacuumdb: > > > > ? ? ? ? ?-Z, --analyze-only ? ? ? ? ? ? ?only update optimizer hints > > > > maybe just noise, but it's not better to say "optimizer statistics" > instead of "op

Re: [HACKERS] A thought on Index Organized Tables

Tom, Actually, if you need to squeeze a few more bits into that word, the > thing to do would be to get rid of storing the tuple length there. > This would involve adding the same type of indirection header that > we use for HeapTuples, so that the length would be available at need > without going

Re: [HACKERS] Avoiding bad prepared-statement plans.

On Thu, Feb 25, 2010 at 10:40 PM, Tom Lane wrote: > Robert Haas writes: >> I actually think there isn't any clean line.  Obscene is in the eye of >> the beholder.  Frankly, I think this discussion is getting off into >> the weeds.  It would be nice, perhaps, to have a feature that will >> detect

Re: [HACKERS] Allow vacuumdb to only analyze

On Thu, Feb 25, 2010 at 5:09 PM, Bruce Momjian wrote: > > This is implemented in 9.0 from vacuumdb: > >          -Z, --analyze-only              only update optimizer hints > maybe just noise, but it's not better to say "optimizer statistics" instead of "optimizer hints"? -- Atentamente, Jaime

Re: [HACKERS] visibility maps and heap_prune

On Thu, Feb 25, 2010 at 10:32 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Thu, Feb 25, 2010 at 9:49 PM, Bruce Momjian wrote: >> > Whatever happened to this? ?It was in the first 9.0 commitfest but was >> > returned with feedback but never updated: >> > >> > ? ? ? ?https://commitfest.postg

Re: [HACKERS] Avoiding bad prepared-statement plans.

Robert Haas writes: > I actually think there isn't any clean line. Obscene is in the eye of > the beholder. Frankly, I think this discussion is getting off into > the weeds. It would be nice, perhaps, to have a feature that will > detect when the generic plan is the suxxor and attempt to find a

Re: [HACKERS] visibility maps and heap_prune

Robert Haas wrote: > On Thu, Feb 25, 2010 at 9:49 PM, Bruce Momjian wrote: > > Whatever happened to this? ?It was in the first 9.0 commitfest but was > > returned with feedback but never updated: > > > > ? ? ? ?https://commitfest.postgresql.org/action/patch_view?id=75 > > Well, the patch author c

Re: [HACKERS] visibility maps and heap_prune

On Thu, Feb 25, 2010 at 9:49 PM, Bruce Momjian wrote: > Whatever happened to this?  It was in the first 9.0 commitfest but was > returned with feedback but never updated: > >        https://commitfest.postgresql.org/action/patch_view?id=75 Well, the patch author chose not to pursue it. It's clea

Re: [HACKERS] Avoiding bad prepared-statement plans.

On Thu, Feb 25, 2010 at 9:48 PM, Jeroen Vermeulen wrote: > Robert Haas wrote: >> >> On Wed, Feb 17, 2010 at 5:52 PM, Jeroen Vermeulen wrote: >>> >>> I may have cut this out of my original email for brevity... my impression >>> is >>> that the planner's estimate is likely to err on the side of sca

Re: [HACKERS] Assertion failure in walreceiver

On Thu, Feb 25, 2010 at 7:31 AM, Heikki Linnakangas wrote: > While we're at it, the error message doesn't seem right: > > FATAL:  recovery connections cannot start because the > recovery_connections parameter is disabled on the WAL source server > > recovery_connections is on by default, the real

Re: [HACKERS] A thought: should we run pgindent now?

On Thu, Feb 25, 2010 at 9:03 PM, Bruce Momjian wrote: > Done.  The diff is here: > >        http://momjian.us/tmp/pgindent.diff > > and I checked into CVS a copy of the typedef list I used from Andrew > Dunstan. Cool, thanks. Let the rebasing (if any) begin. ...Robert -- Sent via pgsql-hacker

Re: [HACKERS] Why isn't stats_temp_directory automatically created?

Tom Lane wrote: > Bruce Momjian writes: > > I assume we decided we didn't want this. > > I thought the risk/reward ratio was pretty bad. Yea, the symlink issue killed it for me. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com P

Re: [HACKERS] Why isn't stats_temp_directory automatically created?

Bruce Momjian writes: > I assume we decided we didn't want this. I thought the risk/reward ratio was pretty bad. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailp

Re: [HACKERS] visibility maps and heap_prune

Whatever happened to this? It was in the first 9.0 commitfest but was returned with feedback but never updated: https://commitfest.postgresql.org/action/patch_view?id=75 --- Pavan Deolasee wrote: > ISTM that the PD

Re: [HACKERS] Avoiding bad prepared-statement plans.

Robert Haas wrote: On Wed, Feb 17, 2010 at 5:52 PM, Jeroen Vermeulen wrote: I may have cut this out of my original email for brevity... my impression is that the planner's estimate is likely to err on the side of scalability, not best-case response time; and that this is more likely to happen t

Re: [HACKERS] Why isn't stats_temp_directory automatically created?

I assume we decided we didn't want this. --- Tom Lane wrote: > Fujii Masao writes: > > Here is the revised patch; If stats_temp_directory indicates the symlink, > > we pursue the chain of symlinks and create the referenced

Re: [HACKERS] A thought: should we run pgindent now?

Robert Haas wrote: > On Thu, Feb 25, 2010 at 4:48 PM, Bruce Momjian wrote: > > Robert Haas wrote: > >> On Thu, Feb 25, 2010 at 3:17 PM, Bruce Momjian wrote: > >> > Robert Haas wrote: > >> >> On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan > >> >> wrote: > >> >> > Bruce Momjian wrote: > >> >> >

Re: [HACKERS] A thought on Index Organized Tables

Karl Schnaitter writes: > Of course, PG can't "support" indexing with incorrect functions. However, > it's worthwhile to guard against too much damage being done if the user's > function has a bug. Maybe I'm wrong? Maybe an index tuple with a dangling > pointer is actually harmless? No, it's far

Re: [HACKERS] psql with "Function Type" in \df

Did we ever get tab completion support for these backslash commands? --- David Fetter wrote: > On Fri, Apr 17, 2009 at 04:42:31PM -0400, Alvaro Herrera wrote: > > David Fetter wrote: > > > > > Is this any better? > > > > S

Re: [HACKERS] A thought on Index Organized Tables

Karl Schnaitter writes: > If it's of any interest, I can say something about the hint bits in the > index tuple header. In my implementation, my decision was to use only one > hint bit. It went into the unused 13th bit of the IndexTuple header. When > the hint bit is set, it means that > (xmin is

Re: [HACKERS] A thought on Index Organized Tables

On Thu, Feb 25, 2010 at 3:59 PM, Gokulakannan Somasundaram < gokul...@gmail.com> wrote: > I disagree with that, Gokul -- if the ordering operators are volatile or >> just incorrect, during DELETE, you could set xmax in the wrong IndexTuple. >> Then there will be another IndexTuple that says it's v

Re: [HACKERS] strict version of version_stamp.pl

David Fetter writes: > -} elsif ($minor eq "devel") { > -$dotneeded = 0; > -$numericminor = 0; > -} elsif ($minor =~ m/^alpha\d+$/) { > -$dotneeded = 0; > -$numericminor = 0; > -} elsif ($minor =~ m/^beta\d+$/) { > -$dotneeded = 0; > -$numericminor = 0; > -} elsif ($minor =

Re: [HACKERS] A thought on Index Organized Tables

> > I disagree with that, Gokul -- if the ordering operators are volatile or > just incorrect, during DELETE, you could set xmax in the wrong IndexTuple. > Then there will be another IndexTuple that says it's visible, but it points > to a non-visible heap tuple. I think you should follow the pointe

Re: [HACKERS] A thought on Index Organized Tables

If it's of any interest, I can say something about the hint bits in the index tuple header. In my implementation, my decision was to use only one hint bit. It went into the unused 13th bit of the IndexTuple header. When the hint bit is set, it means that (xmin is committed OR xmin = InvalidTransac

Re: [HACKERS] A thought on Index Organized Tables

Greg Stark writes: > 2) Now that we don't have vacuum full the command-id is kind of a > waste. Not really. > We could replace it with some kind of local memory data > structure which is capable of spilling to disk. The performance costs of that would probably outweigh any space savings. > I t

Re: [HACKERS] A thought on Index Organized Tables

On Thu, Feb 25, 2010 at 9:25 PM, Tom Lane wrote: >  We've sweated > blood to get that struct down to where it is; there's no way to make it > smaller without giving up some really fundamental things, for example > the ability to do UPDATE :-( Oh, this is a tangent but I think there are some more

Re: [HACKERS] A thought on Index Organized Tables

> The other >> problem is the extra write load created by needing to update the index's >> copies of the hint bits; not to mention extra writes to freeze the xids >> when they get old enough. >> > But Tom, i remember that the vacuum was faster when index had visibility > info, since we need not tou

Re: [HACKERS] strict version of version_stamp.pl

On Thu, Feb 25, 2010 at 05:39:10PM -0500, Bruce Momjian wrote: > > David, I am sorry this didn't get applied, and the code has drifted too > much to apply it now. Would you be able to make a new patch to make our > Perl files strict? Please find updated patch attached. It passes strict, warning

Re: [HACKERS] strict version of version_stamp.pl

David, I am sorry this didn't get applied, and the code has drifted too much to apply it now. Would you be able to make a new patch to make our Perl files strict? --- David Fetter wrote: > On Fri, May 08, 2009 at 09:04:18PM

Re: [HACKERS] feature request

I have read that 8.5 will have replication, so is just a feature request. regards Omar Bettin - Original Message - From: "Robert Haas" To: "Omar Bettin" Cc: Sent: Thursday, February 25, 2010 11:22 PM Subject: Re: [HACKERS] feature request On Thu, Feb 25, 2010 at 5:17 PM, Omar Bet

Re: [HACKERS] feature request

On Thu, Feb 25, 2010 at 5:17 PM, Omar Bettin wrote: > ...could be > STORE WHERE [condition] FROM [table] INTO [database] That still doesn't work, because a PostgreSQL backend doesn't have any obvious way to access another database. You'd need to use dblink or something. Eventually (but not any

Re: [HACKERS] feature request

...could be STORE WHERE [condition] FROM [table] INTO [database] regards Omar Bettin - Original Message - From: "Robert Haas" To: "Omar Bettin" Cc: Sent: Thursday, February 25, 2010 11:11 PM Subject: Re: [HACKERS] feature request On Thu, Feb 25, 2010 at 4:35 PM, Omar Bettin wrot

Re: [HACKERS] A thought on Index Organized Tables

> Wait a second, which idea are we currently talking about? No heap at > all, or just the ability to check visibility without visiting the heap? > I was talking about the indexes with snapshot > > If it's a genuine IOT (ie no separate heap), then you are not going to > be able to get away witho

Re: [HACKERS] feature request

On Thu, Feb 25, 2010 at 4:35 PM, Omar Bettin wrote: > hello to everyone, > is a bit late for an italian, but after an long day debugging I had an idea. > Why not introduce a special SQL command like > STORE WHERE [condition] FROM [table] > removing all data that meet the condition and storing them

Re: [HACKERS] Allow vacuumdb to only analyze

decibel wrote: > One of the talks at PGCon (update in place?) recommended running > vacuumdb -z to analyze all tables to rebuild statistics. Problem with > that is it also vacuums everything. ISTM it'd be useful to be able to > just vacuum all databases in a cluster, so I hacked it into vacuu

Re: [HACKERS] A thought: should we run pgindent now?

On Thu, Feb 25, 2010 at 4:48 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Thu, Feb 25, 2010 at 3:17 PM, Bruce Momjian wrote: >> > Robert Haas wrote: >> >> On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan >> >> wrote: >> >> > Bruce Momjian wrote: >> >> >>> I have a TODO on fixing some of

Re: [HACKERS] A thought: should we run pgindent now?

Bruce Momjian writes: > Robert Haas wrote: >> Does that mean you're going to do it, or are you waiting for some sort >> of OK? I believe everyone who expressed an opinion is in favor. > I was waiting a few hours to get feedback. I will do it at 0100 GMT > (2000 EST). You can do it now as far a

[HACKERS] feature request

hello to everyone, is a bit late for an italian, but after an long day debugging I had an idea. Why not introduce a special SQL command like STORE WHERE [condition] FROM [table] removing all data that meet the condition and storing them into another database? Then, if a query that needs the store

Re: [HACKERS] A thought: should we run pgindent now?

Robert Haas wrote: > On Thu, Feb 25, 2010 at 3:17 PM, Bruce Momjian wrote: > > Robert Haas wrote: > >> On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan > >> wrote: > >> > Bruce Momjian wrote: > >> >>> I have a TODO on fixing some of the typedef finding. But I can generate > >> >>> an up to date

Re: [HACKERS] Streaming replication and pg_xlogfile_name()

On Thu, February 25, 2010 17:34, Fujii Masao wrote: > > I attached the revised patch which uses lastPageTLI instead of curFileTLI > as the timeline of the last applied record. > With this patch the standby compiles, tests, installs OK. I wanted to check with you if the following is expected. With

Re: [HACKERS] A thought on Index Organized Tables

Greg Stark writes: > In indexes we currently get away with a reduced header which has few > of the 6 bytes of info bits. However the only reason we can do is > because we impose arbitrary limitations that work for indexes but > wouldn't be reasonable for tables. Such as a lower maximum number of >

Re: [HACKERS] pg_stop_backup does not complete

Looks like we arrived at the best solution here. I don't think it was clear to users that pg_stop_backup() was issuing an archive_command and hence they wouldn't be likely to understand the delay or correct a problem. This gives them the information they need at the time they need it. -

Re: [HACKERS] A thought on Index Organized Tables

On Thu, Feb 25, 2010 at 8:09 PM, Gokulakannan Somasundaram wrote: >   I think, somewhere things have been misunderstood. we only need 8 > bytes more per index entry. I thought Postgres has a 8 byte transaction id, > but it is only 4 bytes, so we only need to save the insertion and deletion

Re: [HACKERS] A thought on Index Organized Tables

Gokulakannan Somasundaram writes: > I think, somewhere things have been misunderstood. we only need 8 > bytes more per index entry. I thought Postgres has a 8 byte transaction id, > but it is only 4 bytes, so we only need to save the insertion and deletion > xids. So 8 bytes more per tup

Re: [HACKERS] A thought: should we run pgindent now?

On Thu, Feb 25, 2010 at 3:17 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan wrote: >> > Bruce Momjian wrote: >> >>> I have a TODO on fixing some of the typedef finding. But I can generate >> >>> an up to date version of the list Bruce last used i

Re: [HACKERS] Streaming rep - why log shipping is necessary?

>> If you're adventurous enough, it's actually possible to set an >> archive_command that checks the status of the standby and returns >> failure as long as the standby still needs the given WAL segment. That >> way the primary doesn't recycle segments that are still needed by the >> standby, and

Re: [HACKERS] A thought: should we run pgindent now?

Robert Haas wrote: > On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan wrote: > > Bruce Momjian wrote: > >>> I have a TODO on fixing some of the typedef finding. But I can generate > >>> an up to date version of the list Bruce last used in a day or two, and > >>> then > >>> get this better whacked

Re: [HACKERS] A thought on Index Organized Tables

> 1) transaction information in index > >This seems like a lot of bloat in indexes. It also means breaking > a lot of other optimizations such as being able to read the tuples > directly from the heap page without locking. I'm not sure how much > those are worth though. But adding 24 bytes to e

Re: [HACKERS] A thought: should we run pgindent now?

On Thu, Feb 18, 2010 at 11:51 PM, Andrew Dunstan wrote: > Bruce Momjian wrote: >>> I have a TODO on fixing some of the typedef finding. But I can generate >>> an up to date version of the list Bruce last used in a day or two, and then >>> get this better whacked into shape for another run at the m

Re: [HACKERS] [GENERAL] Boolean partition constraint behaving strangely

Dominik Sander writes: > I have an issue with a table partitioned by one boolean column. The > query planner only seems to skip the non matching table if expired > (the column I use for the partition) is true. Hm, interesting case. The reason it's behaving asymmetrically is the fix for this bug:

Re: [HACKERS] tie user processes to postmaster was:(Re: [HACKERS] scheduler in core)

On Tue, Feb 23, 2010 at 11:08 AM, Alvaro Herrera wrote: > Steve Atkins wrote: > >> Would having a higher level process manager be adequate - one >> that spawns the postmaster and a list of associated processes >> (queue manager, job scheduler, random user daemons that are >> used for database appl

Re: [HACKERS] pg_stop_backup does not complete

Joshua D. Drake wrote: > On Wed, 2010-02-24 at 12:32 -0800, Josh Berkus wrote: > > > pg_stop_backup() doesn't complete until all the WAL segments needed to > > > restore from the backup are archived. If archive_command is failing, > > > that never happens. > > > > OK, so we need a way out of that

Re: [HACKERS] pg_stop_backup does not complete

Greg Stark wrote: In an ideal world it would be best if pg_stop_backup could actually print the error status of the archiving command. Is there any way for it to get ahold of the fact that the archiving is failing? This is in the area I mentioned I'd proposed a patch to improve not too long

Re: [HACKERS] plperl.on_init - bug or just me?

On 25/02/10 17:10, Andrew Dunstan wrote: Richard Huxton wrote: Presumably "Safe" just clamps down and my sub isn't marked as acceptable. Is this intended, or am I doing something stupid? It's intended (at least by me). Also, please see the recent discussion about loading extra stuff into th

Re: [HACKERS] plperl.on_init - bug or just me?

Richard Huxton wrote: From memory and the thread below, I thought one of the key uses was to let me use a module from trusted plperl. http://archives.postgresql.org/pgsql-hackers/2010-02/msg00167.php The example below has a TestModule that just exports one sub - visible from plerlu but not

[HACKERS] plperl.on_init - bug or just me?

From memory and the thread below, I thought one of the key uses was to let me use a module from trusted plperl. http://archives.postgresql.org/pgsql-hackers/2010-02/msg00167.php The example below has a TestModule that just exports one sub - visible from plerlu but not plperl. Presumably "Safe

Re: [HACKERS] pg_stop_backup does not complete

Heikki Linnakangas wrote: > Josh Berkus wrote: > > OK, can you go through the reasons why pg_stop_backup would not > > complete? > > pg_stop_backup() doesn't complete until all the WAL segments needed to > restore from the backup are archived. If archive_command is failing, > that never happens.

Re: [HACKERS] Streaming replication and pg_xlogfile_name()

On Thu, Feb 25, 2010 at 11:57 AM, Fujii Masao wrote: > On Tue, Feb 23, 2010 at 4:08 PM, Heikki Linnakangas > wrote: >>> So it's not the TLI of the first record in the file, isn't it? >> >> Hmm, or is it the TLI of the last record? Not sure. Anyway, if there's a >> TLI switch in the current WAL fi

Re: [HACKERS] Odd CVS revision number

Andrew Dunstan wrote: > For some unknown reason, we have some version 2.x files in > doc/src/sgml: > , > which is why > you saw this. Most likely, somebody incremented the rev number by hand in the dawn of time. Your doc also says:

Re: [HACKERS] Streaming replication and pg_xlogfile_name()

On Thu, Feb 25, 2010 at 6:33 PM, Simon Riggs wrote: > If we expose the timeline as part of an "xlog location", then we should > do that everywhere as a change for 9.0. Everywhere? You mean changing the format of the return value of all the following functions? - pg_start_backup() - pg_stop_backu

Re: [HACKERS] NaN/Inf fix for ECPG

Boszormenyi Zoltan writes: > Can you try whether the first patch (missing float.h from data.c) > solves the problem? And together with the 2nd one? In that > patch I fixed the order of float.h and math.h in nan_test.pgc, > which is the opposite of the order found in e.g. backend/utils/adt/float.c.

Re: [HACKERS] Odd CVS revision number

Heikki Linnakangas wrote: I just noticed that the revision numbering for the new src/doc/sgml/recovery-config.sgml file I added started from 2 for some reason. The first revision was 2.1, and when I just updated it the new revision became 2.2. It seems to work fine, but I've never seen CVS rev

Re: [HACKERS] Recent vendor SSL renegotiation patches break PostgreSQL

Magnus Hagander writes: > I backpatched it to 8.2, which is as far as it applied fairly cleanly. > Before that, we don't have GUC_UNIT_KB for example, so it'll be a > different format of the patch as well. I'm not sure it's important > enough to go back beyond that... Hm, I'd kinda like to have i

Re: [HACKERS] pg_stop_backup does not complete

On Wed, Feb 24, 2010 at 11:14 PM, Josh Berkus wrote: > > Right.  I'm pointing out that production and "trying out 9.0 for the > first time" are actually different circumstances, and we need to be able > to handle both gracefully.  Since, if people have a bad experience > trying it out for the firs

Re: [HACKERS] Recent vendor SSL renegotiation patches break PostgreSQL

On Thu, Feb 25, 2010 at 15:27, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Feb 24, 2010 at 17:47, Tom Lane wrote: >>> I see that ssl_ciphers is made to go away when USE_SSL isn't set, >>> so the most consistent thing in the near term would be to do the same. > >> The difference is that

Re: [HACKERS] Odd CVS revision number

Heikki Linnakangas writes: > I just noticed that the revision numbering for the new > src/doc/sgml/recovery-config.sgml file I added started from 2 for some > reason. The first revision was 2.1, and when I just updated it the new > revision became 2.2. > It seems to work fine, but I've never seen

Re: [HACKERS] Recent vendor SSL renegotiation patches break PostgreSQL

Magnus Hagander writes: > On Wed, Feb 24, 2010 at 17:47, Tom Lane wrote: >> I see that ssl_ciphers is made to go away when USE_SSL isn't set, >> so the most consistent thing in the near term would be to do the same. > The difference is that ssl_ciphers is only set in postgresql.conf, so > it doe

Re: [HACKERS] psql with GSS can crash

On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala wrote: > Hi all, > > I got following stack: > >  fd7ffed14b70 strlen () + 40 >  fd7ffed71665 snprintf () + e5 >  fd7fff36d088 pg_GSS_startup () + 88 >  fd7fff36d43a pg_fe_sendauth () + 15a >  fd7fff36e557 PQconnectPoll () + 3b7 >  ff

[HACKERS] psql with GSS can crash

Hi all, I got following stack: fd7ffed14b70 strlen () + 40 fd7ffed71665 snprintf () + e5 fd7fff36d088 pg_GSS_startup () + 88 fd7fff36d43a pg_fe_sendauth () + 15a fd7fff36e557 PQconnectPoll () + 3b7 fd7fff36e152 connectDBComplete () + a2 fd7fff36dc32 PQsetdbLogi

Re: [HACKERS] NaN/Inf fix for ECPG

Le 17 févr. 2010 à 12:18, Boszormenyi Zoltan a écrit : > > > Is this buildfarm member for detecting bugs in the already > obsolete NetBSD 5.0 BETA, or what? The final 5.0 and > two bugfix releases are already out for a while. The owner > of that particular machine should upgrade. I upgraded p

Re: [HACKERS] Assertion failure in walreceiver

On Thu, Feb 25, 2010 at 7:31 AM, Heikki Linnakangas wrote: > Committed removal of that and the assertion. You still can't use a copy > of the data directory taken right after initdb, because the initial > checkpoint record has the flag set indicating that archiving is not > enabled. While we're at

Re: [HACKERS] Recent vendor SSL renegotiation patches break PostgreSQL

On Thu, Feb 25, 2010 at 10:42, Magnus Hagander wrote: > On Wed, Feb 24, 2010 at 17:47, Tom Lane wrote: >> Magnus Hagander writes: >> Fair enough, USERSET it is then. > > Done. Will run some tests and then apply. And applied. I backpatched it to 8.2, which is as far as it applied fairly cleanly

Re: [HACKERS] A thought on Index Organized Tables

Gokulakannan Somasundaram wrote: > Say a checkpoint has occured in between and flushed the dirty pages into > disk, while the updater waits to update the visibility map. Now there will > be no replay for the insert/update/delete right? Yeah, good catch, that could happen. -- Heikki Linnakangas

Re: [HACKERS] A thought on Index Organized Tables

Gokulakannan Somasundaram wrote: >> The replay of the heap insert/update/delete record updates the >> visibility map. >> > So are you planning to make that section, which writes the xlog and updates > the visibility map inside a PANIC section right? The xlog record is already written in a critical

Re: [HACKERS] A thought on Index Organized Tables

Gokulakannan Somasundaram wrote: > OK. Say a session doing the update, which is the fist update on the page, > resets the PD_ALL_VISIBLE and just before updating the visibility map > crashes. The subsequent inserts/updates/deletes, will see the PD_ALL_VISIBLE > flag cleared and never care to update

Re: [HACKERS] NaN/Inf fix for ECPG

I wrote: > As Rémi says, isnan((double)(0.0 / 0.0)) == true for him. > Michael: IIRC, IEEE754 explicit about that the (0.0/0.0) division > produces NaN. How about doing it explicitely in ECPG? > I came up with three patches, they are attached. Can you try whether the first patch (missing float

Re: [HACKERS] A thought on Index Organized Tables

> The replay of the heap insert/update/delete record updates the > visibility map. > > Say a checkpoint has occured in between and flushed the dirty pages into disk, while the updater waits to update the visibility map. Now there will be no replay for the insert/update/delete right?

Re: [HACKERS] Streaming replication and pg_xlogfile_name()

On Thu, 2010-02-25 at 12:02 +0900, Fujii Masao wrote: > On Wed, Feb 24, 2010 at 7:56 AM, Simon Riggs wrote: > > On Thu, 2010-01-28 at 10:28 +0200, Heikki Linnakangas wrote: > >> Fujii Masao wrote: > >> > In relation to the functions added recently, I found an annoying problem; > >> > pg_xlogfile_n

Re: [HACKERS] A thought on Index Organized Tables

> The replay of the heap insert/update/delete record updates the > visibility map. > > So are you planning to make that section, which writes the xlog and updates the visibility map inside a PANIC section right?

Re: [HACKERS] A thought on Index Organized Tables

> Yes. When a bit is cleared, that's OK, because a cleared bit just means > "you need to check visibility in the heap tuple". When a bit is set, > however, it's important that it doesn't hit the disk before the > corresponding heap page update. That's why visibilitymap_set() sets the > LSN on the p

Re: [HACKERS] testing cvs HEAD - HS/SR - xlog timeline 0 pg_xlogfile_name_offset

On Thu, Feb 25, 2010 at 7:22 PM, Heikki Linnakangas wrote: > Yeah. The current pg_*_last_location() functions don't cut it though, > you need to retain logs back to the redo location of the last > restartpoint. That's what %r returns. Maybe we should add another function? +1 It would be useful i

Re: [HACKERS] NaN/Inf fix for ECPG

Le 25 févr. 2010 à 11:26, Boszormenyi Zoltan a écrit : > > NAN on NetBSD/x86-64 is defined as: > > extern const union __float_u __nanf; > #define NAN __nanf.__val > Same here: math.h:extern const union __float_u __nanf; math.h:#define NAN __nanf.__val > I would guess that

Re: [HACKERS] NaN/Inf fix for ECPG

Rémi Zara írta: > Le 24 févr. 2010 à 18:58, Boszormenyi Zoltan a écrit : > >> Here's the attached test code. Compile it with >> >> gcc -Wall -o nantest nantest.c -lm >> >> and run it. It tests NAN anf INFINITY values with isinf() and isnan(). >> The expected output is: >> >> == >

  1   2   >