[HACKERS] pgbench hard coded constants

pgbench has #defines for number of branches, tellers, and accounts. There are used to populate the tables with -i, but when running actual benchmark it has values separately hard-coded in the query metacommands. This patch makes the metacommands obtain their values from the relevant #defines. It

Re: [HACKERS] Linux LSB init script

On Mon, 31 Aug 2009, Kevin Grittner wrote: My counter-argument to that would be that the SuSE distribution's version of PostgreSQL is so out-of-date that we don't install it. Given that it's also RPM based, is it possible to get SuSE in sync so that it shares the same init script as RHEL? De

Re: [HACKERS] [PATCH] Largeobject access controls

Alvaro Herrera wrote: > Tom Lane wrote: >> KaiGai Kohei writes: >>> BTW, currently, the default ACL of largeobject allows anything for owner >>> and nothing for world. Do you have any comment for the default behavior? >> Mph. I think the backlash will be too great. You have to leave the >> defau

Re: [HACKERS] remove flatfiles.c

Alvaro Herrera writes: > Tom Lane wrote: >> Hmm, I had been assuming we wouldn't need that anymore. > The comment in user.c and dbcommands.c says [...] > so I think those ones are still necessary. Yeah, after a look through the code I think you can trust the associated comments: if it says it ne

Re: [HACKERS] remove flatfiles.c

Tom Lane wrote: > Alvaro Herrera writes: > > Regarding sync commits that previously happen and now won't, I think the > > only case worth worrying about is the one in vacuum.c. Do we need a > > ForceSyncCommit() in there? I'm not sure if vacuum itself already > > forces sync commit. > > Hmm, I

Re: [HACKERS] remove flatfiles.c

Alvaro Herrera writes: > This patch removes flatfiles.c for good. Aw, you beat me to it. > Regarding sync commits that previously happen and now won't, I think the > only case worth worrying about is the one in vacuum.c. Do we need a > ForceSyncCommit() in there? I'm not sure if vacuum itself

[HACKERS] remove flatfiles.c

This patch removes flatfiles.c for good. It doesn't change the keeping of locks in dbcommands.c and user.c, because at least some of them are still required. Regarding sync commits that previously happen and now won't, I think the only case worth worrying about is the one in vacuum.c. Do we need

Re: [HACKERS] 8.5 release timetable, again

Josh Berkus wrote: > Bruce, > > > I am not sure what other checklist items there would be (or I am > > refusing to divulge). > > Hopefully the last is a joke. ;-) Yes. > So, the only post-CF tasks are issues with specific patches? This seems > resolvable, especially if we take a hard line with

[HACKERS] 8.5 release note editing

I just talked to Josh Berkus via phone. We have decided to put the rough commit messages on a wiki for 8.5 final so they can be easily edited by the community, before markup is added and they are moved to the SGML docs. This should increase community involvement in editing the items, and if it go

Re: [HACKERS] 8.5 release timetable, again

Bruce, > I am not sure what other checklist items there would be (or I am > refusing to divulge). Hopefully the last is a joke. ;-) So, the only post-CF tasks are issues with specific patches? This seems resolvable, especially if we take a hard line with patch readiness. There isn't anything el

Re: [HACKERS] autovacuum launcher using InitPostgres

Hi, Tom Lane writes: >> The user may not care about the difference, but there's a point in >> having the limit be the simpler concept of "this is the maximum amount >> of processes running vacuum at any time". The launcher is very >> uninteresting to users. Adding to this, the launcher will not

Re: [HACKERS] [PATCH] Largeobject access controls

Tom Lane wrote: > KaiGai Kohei writes: > > BTW, currently, the default ACL of largeobject allows anything for owner > > and nothing for world. Do you have any comment for the default behavior? > > Mph. I think the backlash will be too great. You have to leave the > default behavior the same as

Re: [HACKERS] [PATCH] plpythonu datatype conversion improvements

On sön, 2009-08-16 at 02:44 +0300, Peter Eisentraut wrote: > The remaining problem is that the patch loses domain checking on the > return types, because some paths no longer go through the data type's > input function. I have marked these places as FIXME, and the regression > tests also contain a

Re: [HACKERS] 8.5 release notes idea

Greg Sabino Mullane wrote: [ There is text before PGP section. ] > > -BEGIN PGP SIGNED MESSAGE- > Hash: RIPEMD160 > > Just noticed in the release notes for 8.4, there are two items > accredited to just "Greg" (but there are three of us Gregs who > contributed to 8.4 and are in the notes).

Re: [HACKERS] 8.5 release timetable, again

Kevin Grittner wrote: > Bruce Momjian wrote: > > > The issues are different for every commitfest-beta period, so I have > > no idea what to list there, but we do alway have an open issues wiki > > that is maintained, at least for the most recent releases. > > After a quick search of the wiki,

Re: [HACKERS] 8.5 release timetable, again

Kevin Grittner wrote: > Bruce Momjian wrote: > > > it gets no easier to make the decisions later rather than now. The > > delay forces us to make a final decision. We often had months to > > make the decision earlier, but didn't. > > So you're advocating that we find a way to force more tim

Re: [HACKERS] 8.5 release notes idea

On Mon, Aug 31, 2009 at 8:47 PM, Greg Smith wrote: > That's correct--you and I are spelled out completely everwhere we show up > there, so all the "Greg" references without a last name are to Greg Stark. Well they're intended to be. I'm not sure I actually contributed much to those though. -- g

Re: [HACKERS] 8.5 release timetable, again

On sön, 2009-08-30 at 21:09 -0400, Robert Haas wrote: > I really can't understand why it isn't possible for us to find a way > to make an annual release happen, and with more than 8-12 weeks of > development time (ie non-CommitFest non-beta) available during that > year. I understand that there is

Re: [HACKERS] \d+ for long view definitions?

Peter Eisentraut writes: > On sön, 2009-08-30 at 18:43 -0400, Tom Lane wrote: >> Seems like a more general answer would be >> for \d output to go through the pager ... > That should also be fixed, but I'm not sure if it really does it for me. Why not? Just quit out of the pager when you've see

Re: [HACKERS] Linux LSB init script

Peter Eisentraut wrote: > While the major distributions support LSB, the major distributions > also have PostgreSQL packages available and so will likely not need > the init script shipped in the source. My counter-argument to that would be that the SuSE distribution's version of PostgreSQL is

Re: [HACKERS] \d+ for long view definitions?

On sön, 2009-08-30 at 18:43 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > Using \d on, say, information schema views is completely hilarious > > because the column name/data type information is usually scrolled off > > the screen by the immense view definition. > > > Could we change this

Re: [HACKERS] Add YAML option to explain

On Mon, Aug 31, 2009 at 02:15:08PM -, Greg Sabino Mullane wrote: > > Greg, can we see a few examples of the YAML output > > compared to both json and text? ... > greg=# explain (format json, analyze on) select * from pg_class where relname > ~ 'x' order by 1,2,3; > QUER

Re: [HACKERS] Linux LSB init script

On mån, 2009-08-31 at 12:07 -0500, Kevin Grittner wrote: > Is the LSB standard sufficiently widely adopted to omit the older > format? I was concerned that there might be Linux versions we wanted > to support which wouldn't have a /lib/lsb/init-functions file to > source. If that's not an issue,

Re: [HACKERS] set_client_encoding is broken

Zdenek Kotala writes: > Tom Lane píše v po 31. 08. 2009 v 11:00 -0400: >> I'm leaning to the third choice, but I wonder if anyone has any >> comments or better ideas. > It seems to me that 3 is OK. > Another possibility is that InitPostgres can only fill up rel cache and > GUC processing can s

Re: [HACKERS] Linux LSB init script

Greg Smith wrote: > I'm similarly not sure just what the benefits of a LSB compatible > script are here given that several major distributions like > RHEL/Debian have their own thing they're doing and are unlikely to > change. I don't know about other platforms, but on SuSE Linux, you're not

Re: [HACKERS] autovacuum launcher using InitPostgres

Alvaro Herrera writes: > Tom Lane wrote: >> Well, I'm not sure the average user knows or cares about the difference >> between the launcher and the workers. The thing that was in the back of >> my mind was that we would now have the option to have the launcher show >> up in pg_stat_activity. If

Re: [HACKERS] 8.5 release notes idea

On Mon, 31 Aug 2009, Greg Sabino Mullane wrote: Just noticed in the release notes for 8.4, there are two items accredited to just "Greg" (but there are three of us Gregs who contributed to 8.4 and are in the notes). While this is very likely Greg Stark, due to the context... That's correct--yo

Re: [HACKERS] autovacuum launcher using InitPostgres

Alvaro Herrera writes: > The only thing I'm aware is missing from this patch is fixing up > avlauncher's signal handling, and adding a bit more commentary; also I > haven't tested it under EXEC_BACKEND yet. I did the signal handling work and fixed a couple of small oversights, and applied it. I'

[HACKERS] 8.5 release notes idea

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Just noticed in the release notes for 8.4, there are two items accredited to just "Greg" (but there are three of us Gregs who contributed to 8.4 and are in the notes). While this is very likely Greg Stark, due to the context, I think at this poin

Re: [HACKERS] Linux LSB init script

On Mon, 31 Aug 2009, Kevin Grittner wrote: Is the LSB standard sufficiently widely adopted to omit the older format? I'm not sure, and I'm similarly not sure just what the benefits of a LSB compatible script are here given that several major distributions like RHEL/Debian have their own thin

Re: [HACKERS] Linux LSB init script

Andrew Dunstan wrote: > cvsutils That allowed me to use 'cvsdo add' and 'cvs diff -cN' to generate the attached. This contains a couple minor fixes to what I posted in "new file" form. I was holding off on the CommitFest entry until I sorted out the format; I'll link here as version 1 of the

Re: [HACKERS] Hot Standby, conflict cache

On Mon, 2009-08-31 at 15:50 +0300, Heikki Linnakangas wrote: > The conflict cache code is broken I've already removed that code from the version I'm working on as mentioned on another thread, for the same reasons you just mentioned. I think that the conflict options require more discussion and a

Re: [HACKERS] autovacuum launcher using InitPostgres

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> I wonder if it would be cleaner to include the launcher in > >> the autovacuum_max_workers parameter, and increase the min/default > >> values of that by one. > > > Huh, yeah, sorry about that -- fixed here. I think the name of th

Re: [HACKERS] autovacuum launcher using InitPostgres

Tom Lane wrote: > Actually, there is a better way to do this: if we move up the > RelationCacheInitializePhase2 call, then we can have the AV launcher > case just fall out *before* the transaction start. It can do > GetTransactionSnapshot inside its own transaction that reads > pg_database. This

Re: [HACKERS] 8.5 release timetable, again

Bruce Momjian wrote: > it gets no easier to make the decisions later rather than now. The > delay forces us to make a final decision. We often had months to > make the decision earlier, but didn't. So you're advocating that we find a way to force more timely decisions? -Kevin -- Sent vi

Re: [HACKERS] 8.5 release timetable, again

Bruce Momjian wrote: > The issues are different for every commitfest-beta period, so I have > no idea what to list there, but we do alway have an open issues wiki > that is maintained, at least for the most recent releases. After a quick search of the wiki, it appears that the list for 8.4 wa

Re: [HACKERS] 8.5 release timetable, again

On Mon, Aug 31, 2009 at 2:20 PM, Bruce Momjian wrote: > Knowing about the problem usually isn't hard , e.g. \df, but getting > agreement on them is.  One nifty idea would be to do a commit-fest for > open items so we can get to beta. I like that idea very much. > The last commit-fest usually is l

Re: [HACKERS] 8.5 release timetable, again

Josh Berkus wrote: > Bruce, > > > Huh, who has asked for a list from me? This entire post is mostly > > over-the-top and not worth responding to. > > To quote myself: > > > Post-CF: > > Make a list (now, not in January) of the tasks which need to be done > > between CFend and Beta. We'll f

Re: [HACKERS] 8.5 release timetable, again

Joshua D. Drake wrote: > On Mon, 2009-08-31 at 13:59 -0400, Bruce Momjian wrote: > > Robert Haas wrote: > > > On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote: > > > > Josh Berkus wrote: > > > >> Per the above, it would not. ?It would make things worse. ?This has > > > >> been > > > >> true at

Re: [HACKERS] 8.5 release timetable, again

Robert Haas wrote: > That having been said, I think there is a legitimate concern about > organizing and documenting the steps that are required to get a > release out the door. A number of people have said (on this thread > and previous ones) that we didn't know what we were supposed to be > doin

Re: [HACKERS] set_client_encoding is broken

Tom Lane píše v po 31. 08. 2009 v 11:00 -0400: > 3. Push the startup-packet GUC processing (approx. lines 3340..3395 of > postgres.c, as of CVS HEAD) into InitPostgres, so it can be run during > the startup transaction. This is not too unclean, though it would > mean exporting process_postgres_sw

Re: [HACKERS] 8.5 release timetable, again

Bruce, > Huh, who has asked for a list from me? This entire post is mostly > over-the-top and not worth responding to. To quote myself: > Post-CF: > Make a list (now, not in January) of the tasks which need to be done > between CFend and Beta. We'll find that some of them could be done b

Re: [HACKERS] 8.5 release timetable, again

On Mon, 2009-08-31 at 13:59 -0400, Bruce Momjian wrote: > Robert Haas wrote: > > On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote: > > > Josh Berkus wrote: > > >> Per the above, it would not. ?It would make things worse. ?This has been > > >> true at every other OSS project I've seen documented

Re: [HACKERS] 8.5 release timetable, again

On Mon, Aug 31, 2009 at 1:59 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote: >> > Josh Berkus wrote: >> >> Per the above, it would not. ?It would make things worse. ?This has been >> >> true at every other OSS project I've seen documented (disa

Re: [HACKERS] autovacuum launcher using InitPostgres

Alvaro Herrera writes: > Tom Lane wrote: >> While I was looking at this I wondered whether >> RelationCacheInitializePhase2 really needs to be inside the startup >> transaction at all. I think it could probably be moved up before >> that. However, if the AV launcher has to do GetTransactionSnaps

Re: [HACKERS] 8.5 release timetable, again

Robert Haas wrote: > On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote: > > Josh Berkus wrote: > >> Per the above, it would not. ?It would make things worse. ?This has been > >> true at every other OSS project I've seen documented (disastrously so > >> with MySQL); there is no reason to believe

Re: [HACKERS] 8.5 release timetable, again

Kevin Grittner wrote: > Bruce Momjian wrote: > > > Yep, the bottom line here is that patches get into CVS, but issues > > come up related to the patch, and we keep looking for good fixes, > > but once the final commit-fest is over, we _have_ to fix these > > issues. > > If, hypothetically, it

Re: [HACKERS] 8.5 release timetable, again

On Mon, Aug 31, 2009 at 1:57 PM, Bruce Momjian wrote: > Josh Berkus wrote: >> Per the above, it would not.  It would make things worse.  This has been >> true at every other OSS project I've seen documented (disastrously so >> with MySQL); there is no reason to believe that Postgres would be any >>

Re: [HACKERS] 8.5 release timetable, again

Josh Berkus wrote: > Per the above, it would not. It would make things worse. This has been > true at every other OSS project I've seen documented (disastrously so > with MySQL); there is no reason to believe that Postgres would be any > different. > > I also do not see why you are so resistant

Re: [HACKERS] 8.5 release timetable, again

Bruce Momjian wrote: > Yep, the bottom line here is that patches get into CVS, but issues > come up related to the patch, and we keep looking for good fixes, > but once the final commit-fest is over, we _have_ to fix these > issues. If, hypothetically, it might hold up the release for two wee

Re: [HACKERS] 8.5 release timetable, again

On Mon, 2009-08-31 at 10:30 -0700, Josh Berkus wrote: > >>> Another solution would be to make major releases less frequent. > >> That's not a solution and you know it. > > > > I do? > > Ok, here's the reasons it's not a solution: > Per the above, it would not. It would make things worse. This

Re: [HACKERS] 8.5 release timetable, again

>>> Another solution would be to make major releases less frequent. >> That's not a solution and you know it. > > I do? Ok, here's the reasons it's not a solution: 1) having a longer development cycle would frustrate many users who want new features sooner, not later. The current 1 year is a g

Re: [HACKERS] Linux LSB init script

Peter Eisentraut wrote: > If it's a new file, it's pointless to send a patch anyway. If people are OK with just sending the new file, that's cool with me. >From the other posts, it appears that I need to have my own copy of the repository to do it as a patch, or download a tool. (Thanks to t

Re: [HACKERS] Add YAML option to explain

"Greg Sabino Mullane" wrote: > - >Plan: > Node Type: Index Scan > Scan Direction: Forward > Index Name: pg_class_relname_nsp_index > Relation Name: pg_class > Alias: pg_class > Startup Cost: 0.00 > Total Cost: 8.27 > Plan Rows: 1 > Plan Width: 0

Re: [HACKERS] autovacuum launcher using InitPostgres

Alvaro Herrera writes: > Tom Lane wrote: >> I wonder if it would be cleaner to include the launcher in >> the autovacuum_max_workers parameter, and increase the min/default >> values of that by one. > Huh, yeah, sorry about that -- fixed here. I think the name of the > param, which includes "wor

Re: [HACKERS] autovacuum launcher using InitPostgres

Tom Lane wrote: > Alvaro Herrera writes: > > How about this? > > I think the accounting for the AV launcher in shmem allocation is a bit > confused yet --- for instance, isn't MaxBackends already including the > launcher? I wonder if it would be cleaner to include the launcher in > the autovacuu

Re: [HACKERS] autovacuum launcher using InitPostgres

Alvaro Herrera writes: > Heikki Linnakangas wrote: >> I quite like the idea of splitting initialization into two phases, one >> that let's you access shared catalogs, and one to bind to a database. I >> didn't look into the details, though. > The problem is that it only gives you access to pg_dat

Re: [HACKERS] autovacuum launcher using InitPostgres

Alvaro Herrera writes: > How about this? I think the accounting for the AV launcher in shmem allocation is a bit confused yet --- for instance, isn't MaxBackends already including the launcher? I wonder if it would be cleaner to include the launcher in the autovacuum_max_workers parameter, and i

Re: [HACKERS] autovacuum launcher using InitPostgres

Heikki Linnakangas wrote: > Tom Lane wrote: > > Alvaro Herrera writes: > >> Tom Lane wrote: > >>> This just seems truly messy :-(. Let me see if I can find something > >>> cleaner. > > I quite like the idea of splitting initialization into two phases, one > that let's you access shared catalogs,

Re: [HACKERS] autovacuum launcher using InitPostgres

Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> This just seems truly messy :-(. Let me see if I can find something >>> cleaner. I quite like the idea of splitting initialization into two phases, one that let's you access shared catalogs, and one to bind to a database. I didn't l

Re: [HACKERS] autovacuum launcher using InitPostgres

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> This just seems truly messy :-(. Let me see if I can find something > >> cleaner. > > > I was considering having InitPostgres be an umbrella function, so that > > extant callers stay as today, but the various underlying pieces are

Re: [HACKERS] XLogFlush

On Fri, Aug 21, 2009 at 1:18 AM, Jeff Janes wrote: > Maybe this is one of those things that is obvious when someone points > it out to you, but right now I am not seeing it. If you look at the > last eight lines of this snippet from XLogFlush, you see that if we > obtain WriteRqstPtr under the W

Re: [HACKERS] autovacuum launcher using InitPostgres

Alvaro Herrera writes: > Tom Lane wrote: >> This just seems truly messy :-(. Let me see if I can find something >> cleaner. > I was considering having InitPostgres be an umbrella function, so that > extant callers stay as today, but the various underlying pieces are > skipped depending on who's

Re: [HACKERS] autovacuum launcher using InitPostgres

Tom Lane wrote: > Alvaro Herrera writes: > > To this end, InitPostgres has been split in two. The launcher only > > calls the first half, the rest of the callers have been patched to > > invoke the second half. > > This just seems truly messy :-(. Let me see if I can find something > cleaner.

Re: [HACKERS] combined indexes with Gist - planner issues?

hello ... we did some experiments with doing such a table. the problem is if you want to allow arbitrary combinations of words which can be modeled perfectly with FTI. you would instantly end up with a self join with 5 relations or so - which is again bad. there are too many common words to c

Re: [HACKERS] combined indexes with Gist - planner issues?

Hans-Juergen Schoenig -- PostgreSQL wrote: > my knowledge of how gist works internally is not too extensive. any > "kickstart" idea would be appreciated. If there's not too many of those common words, you can create a simple partial b-tree index for each, and handle the less common words with the

Re: [HACKERS] autovacuum launcher using InitPostgres

Alvaro Herrera writes: > To this end, InitPostgres has been split in two. The launcher only > calls the first half, the rest of the callers have been patched to > invoke the second half. This just seems truly messy :-(. Let me see if I can find something cleaner. BTW, is it *really* the case t

Re: [HACKERS] Feature request : add REMAP_SCHEMA-like option to pg_restore

On Mon, Aug 31, 2009 at 10:42 AM, Andrew Dunstan wrote: >>> Hope you find the idea interesting. I'm willing to test anything or add >>> more specification to the feature. I must admit too this is a patch I'd >>> like to write too (it would be my very first) but I don't know if my C >>> skills are g

[HACKERS] autovacuum launcher using InitPostgres

Hi, This seems to be the last holdup for flatfiles.c. This patch removes usage of that code in autovacuum launcher, instead making it go through the most basic relcache initialization so that it is able to read pg_database. To this end, InitPostgres has been split in two. The launcher only call

Re: [HACKERS] set_client_encoding is broken

Zdenek Kotala writes: > [4a9ae815.696e:1] LOG: connection received: host=[local] > [4a9ae815.696e:2] LOG: connection authorized: user=postgres database=postgres > [4a9ae815.696e:3] LOG: conversion between UTF8 and LATIN2 is not supported > [4a9ae815.696e:4] FATAL: invalid value for parameter "

Re: [HACKERS] Feature request : add REMAP_SCHEMA-like option to pg_restore

Robert Haas wrote: On Mon, Aug 31, 2009 at 9:59 AM, Jean-Paul Argudo wrote: Hope you find the idea interesting. I'm willing to test anything or add more specification to the feature. I must admit too this is a patch I'd like to write too (it would be my very first) but I don't know if my C

Re: [HACKERS] combined indexes with Gist - planner issues?

Martijn van Oosterhout wrote: On Mon, Aug 31, 2009 at 04:06:22PM +0200, Hans-Juergen Schoenig -- PostgreSQL wrote: ok, i thought it would be something gist specific i was not aware of. the golden question now is: i am looking for the cheapest products given a certain text in an insane amou

Re: [HACKERS] combined indexes with Gist - planner issues?

On Mon, Aug 31, 2009 at 04:06:22PM +0200, Hans-Juergen Schoenig -- PostgreSQL wrote: > ok, i thought it would be something gist specific i was not aware of. > the golden question now is: i am looking for the cheapest products given > a certain text in an insane amount of data. > how to do it? ot

Re: [HACKERS] Feature request : add REMAP_SCHEMA-like option to pg_restore

On Mon, Aug 31, 2009 at 9:59 AM, Jean-Paul Argudo wrote: > Hope you find the idea interesting. I'm willing to test anything or add > more specification to the feature. I must admit too this is a patch I'd > like to write too (it would be my very first) but I don't know if my C > skills are good eno

Re: [HACKERS] Add YAML option to explain

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Greg, can we see a few examples of the YAML output > compared to both json and text? Sure. Be warned it will make this email long. Because email may

Re: [HACKERS] Bison crashes postgresql

Andrew Dunstan wrote: Werner Echezuria wrote: Hi, I have a code in which I translate some code from sqlf to sql, but when it comes to yy_parse the server crashes, I have no idea why, because it works fine in other situations. I don't understand why you're doing what you're doing this way.

Re: [HACKERS] combined indexes with Gist - planner issues?

Tom Lane wrote: Hans-Juergen Schoenig -- PostgreSQL writes: what we basically expected here is that Postgres will scan the table using the index to give us the cheapest products containing the words we are looking for. i am totally surprised to see that we have to fetch all products given

Re: [HACKERS] Bison crashes postgresql

Werner Echezuria wrote: Hi, I have a code in which I translate some code from sqlf to sql, but when it comes to yy_parse the server crashes, I have no idea why, because it works fine in other situations. I don't understand why you're doing what you're doing this way. Wouldn't it be better

[HACKERS] Feature request : add REMAP_SCHEMA-like option to pg_restore

Hi there, I searched the wiki and the lists about the REMAP_SCHEMA option's idea of a well known RDBMS, since its 10g version. Here's the short description: REMAP_SCHEMA : Objects from one schema are loaded into another schema. The idea is when we have a given schema (let's say this schema is

Re: [HACKERS] combined indexes with Gist - planner issues?

Hans-Juergen Schoenig -- PostgreSQL writes: > what we basically expected here is that Postgres will scan the table > using the index to give us the cheapest products containing the words we > are looking for. > i am totally surprised to see that we have to fetch all products given > the words,

[HACKERS] Bison crashes postgresql

Hi, I have a code in which I translate some code from sqlf to sql, but when it comes to yy_parse the server crashes, I have no idea why, because it works fine in other situations. This is the code (the problem is in parse_sqlf, when I call sqlf_yyparse): #include "postgres.h" #include "gram.h" #

Re: [HACKERS] Add YAML option to explain

On 08/28/2009 02:16 PM, Greg Sabino Mullane wrote: > Attached patch adds YAML output option to explain: > > explain (format YAML) select * from information_schema.columns; Updated version of the patch attached, fixes two small errors. -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8

[HACKERS] combined indexes with Gist - planner issues?

hello everybody, we are seriously fighting with some planner issue which seems to be slightly obscure to us. we have a table which is nicely indexed (several GB in size). i am using btree_gist operator classes to use a combined index including an FTI expression along with a number: db=# \d p

[HACKERS] Hot Standby, conflict cache

I'm looking at the most recent version of the Hot Standby patch at Robert Haas' GIT repository. The conflict cache code is broken: > +void > +SetDeferredRecoveryConflicts(TransactionId latestRemovedXid, RelFileNode > node, > +XLogRecPtr conflict_lsn) > +{ > + ProcArr

Re: [HACKERS] Tightening binary receive functions

On Mon, Aug 31, 2009 at 12:01 PM, Heikki Linnakangas wrote: > Hmm, perhaps we should follow what we did to chr() and ascii(): map the > integer to unicode code points if the database encoding is UTF-8, and > restrict the range to 0..127 for other multi-byte encodings. I don't think we even have to

Re: [HACKERS] Tightening binary receive functions

Greg Stark wrote: > On Mon, Aug 31, 2009 at 9:12 AM, Heikki > Linnakangas wrote: >> The most notable of these is the change to "char" datatype. The patch >> tightens it so that it no longer accepts values >127 with a multi-byte >> database encoding. > > That doesn't sound right to me. We accept ca

Re: [HACKERS] Tightening binary receive functions

On Mon, Aug 31, 2009 at 9:12 AM, Heikki Linnakangas wrote: > The most notable of these is the change to "char" datatype. The patch > tightens it so that it no longer accepts values >127 with a multi-byte > database encoding. That doesn't sound right to me. We accept casts from integer to "char" fo

Re: [HACKERS] hot standby - further cleanup of recovery procs stuff

Robert Haas wrote: > I've made a few further cleanups to the hot standby patch: Thanks! > I am not sure why we have a single GUC to size both the number of > PGPROC structures we allow and the size of UnobservedXids. A > read-only slave might only need to allow a few connections for > reporting

Re: [HACKERS] [PATCH] Largeobject access controls

The attached patch is the revised version of largeobject access controls. It reverts pg_largeobject system catalog, and adds new pg_largeobject_meta system catalog to store the owner identifier and its ACLs. The definition of pg_largeobject_meta: #define LargeObjectMetaRelationId 2336 CATA

Re: [HACKERS] LWLock Queue Jumping

Jeff Janes wrote: On Sun, Aug 30, 2009 at 11:01 AM, Stefan Kaltenbrunner wrote: Jeff Janes wrote: -- Forwarded message -- From: Stefan Kaltenbrunner To: Heikki Linnakangas mailto:heikki.linnakan...@enterprisedb.com>

[HACKERS] set_client_encoding is broken

If you look on gothic_moth and comet_moth http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_moth&dt=2009-08-30%2020:06:00 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_moth&dt=2009-08-29%2021:06:00 you can see following error: ../../src/test/regress/pg_regress --inputdir=. --psq

[HACKERS] Tightening binary receive functions

After the thread started by Andrew McNamara a while ago: http://archives.postgresql.org/message-id/e419f08d-b908-446d-9b1e-f3520163c...@object-craft.com.au the question was left hanging if other binary recv functions are missing sanity checks that the corresponding text input functions have, and