Re: [HACKERS] pg_archivecleanup should remove WAL files also in pg_xlog?

On 13.12.2010 09:50, Fujii Masao wrote: On Mon, Dec 13, 2010 at 4:28 PM, Heikki Linnakangas wrote: On 13.12.2010 08:44, Fujii Masao wrote: pg_archivecleanup removes unnecessary WAL files from the archive, but not from pg_xlog directory. So, after failover, those WAL files might exist in pg_x

Re: [HACKERS] hstores in pl/python

Hello this is little bit offtopic, sorry. I am thinking, so we need a standard associative array support in core - like Perl, Python or Javascript. So, I don't think, so migration of hstore to core is good idea. Regards Pavel Stehule 2010/12/13 Jan Urbański : > It would be cool to be able to t

Re: [HACKERS] Instrument checkpoint sync calls

Robert Haas wrote: I'm wondering why md.c is converting the results from an exact value to a floating point, only to have xlog.c turn around and convert back to an integer. I think it could just return milliseconds directly, or if you're worried about a checkpoint that takes more than 24 days t

Re: [HACKERS] pg_archivecleanup should remove WAL files also in pg_xlog?

On Mon, Dec 13, 2010 at 5:01 PM, Heikki Linnakangas wrote: > If the only consequence is that you get some extra WAL files in the archive, > until pg_archivecleanup runs again, I think we can just live with it. We might get some extra WAL files also in pg_xlog. Because the WAL files which don't ha

Re: [HACKERS] hstores in pl/python

Hey Pavel, 2010/12/13 Pavel Stehule > Hello > > this is little bit offtopic, sorry. > > I am thinking, so we need a standard associative array support in core > - like Perl, Python or Javascript. So, I don't think, so migration of > hstore to core is good idea. > Could you tell why in-core assoc

Re: [HACKERS] proposal : cross-column stats

On 2010-12-13 03:28, Robert Haas wrote: Well, I'm not real familiar with contingency tables, but it seems like you could end up needing to store a huge amount of data to get any benefit out of it, in some cases. For example, in the United States, there are over 40,000 postal codes, and some even

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

Tom Lane writes: > The incremental FK checks are designed on the assumption that the > constraint condition held before; they aren't likely to behave very > sanely if the data is bad. I'd want to see a whole lot more analysis of > the resulting behavior before even considering an idea like this

Re: [HACKERS] proposal : cross-column stats

> On 2010-12-13 03:28, Robert Haas wrote: >> Well, I'm not real familiar with contingency tables, but it seems like >> you could end up needing to store a huge amount of data to get any >> benefit out of it, in some cases. For example, in the United States, >> there are over 40,000 postal codes, a

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

2010/12/13 Tom Lane : > But allow me to harbor doubts that they really > intend to allow someone to force a constraint to be considered valid > without any verification. "Table constraints are either enforced or not enforced. Domain constraints and assertions are always enforced.", 4.17.2 I don'

[HACKERS] WaitLatch

Hi All, drainSelfPipe() function will read the data and remove it from the descriptor? Coz the signal (SIGUSR1) is writing sata to selfPipe descriptor but unable to wake up latch on select system call. Data is not avaialable at select in WaitLatch fun. Coz it is read by drailSelfPipe(). So How w

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On 13 December 2010 10:30, Dimitri Fontaine wrote: > Seriously, real-world use cases such as Kevin's one seems to warrant > that we are able to create a table withouth enforcing the FK. That's > horrid, yes, that's needed, too. Maybe some operations would have to be > instructed that the constrain

Re: [HACKERS] rest of works for security providers in v9.1

2010/12/12 KaiGai Kohei : > I'd like to see opinions what facilities should be developed > to the current v9.1 development cycle. It seems to me that the next commit after the label-switcher-function patch ought to be a contrib module that implements a basic form of SE-Linux driven permissions che

Re: [HACKERS] Instrument checkpoint sync calls

On Mon, Dec 13, 2010 at 3:19 AM, Greg Smith wrote: > Robert Haas wrote: >> >> I'm wondering why md.c is converting the results from an exact value to a >> floating >> point, only to have xlog.c turn around and convert back to an integer. >>  I think it could just return milliseconds directly, or i

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Mon, Dec 13, 2010 at 12:59 AM, Rob Wultsch wrote: > On Sun, Dec 12, 2010 at 7:24 PM, Andrew Dunstan wrote: >> In fact it's possible now to disable FK enforcement, by disabling the >> triggers. It's definitely a footgun though. Just the other day I was asked >> how data violating the constraint

Re: [HACKERS] GiST insert algorithm rewrite

On Mon, Dec 13, 2010 at 7:09 AM, Heikki Linnakangas wrote: > Attached is an updated patch, but that issue with limited number of backup > blocks needs to be resolved. The straightforward way would be to change the > WAL format to increase the limit. Eh, is that going to bloat WAL? -- Robert Haa

Re: [HACKERS] GiST insert algorithm rewrite

On 13.12.2010 15:04, Robert Haas wrote: On Mon, Dec 13, 2010 at 7:09 AM, Heikki Linnakangas wrote: Attached is an updated patch, but that issue with limited number of backup blocks needs to be resolved. The straightforward way would be to change the WAL format to increase the limit. Eh, is t

Increasing max # of backup blocks (was Re: [HACKERS] GiST insert algorithm rewrite)

On 13.12.2010 15:20, Heikki Linnakangas wrote: On 13.12.2010 15:04, Robert Haas wrote: On Mon, Dec 13, 2010 at 7:09 AM, Heikki Linnakangas wrote: Attached is an updated patch, but that issue with limited number of backup blocks needs to be resolved. The straightforward way would be to change t

Re: [HACKERS] rest of works for security providers in v9.1

(2010/12/13 21:53), Robert Haas wrote: 2010/12/12 KaiGai Kohei: I'd like to see opinions what facilities should be developed to the current v9.1 development cycle. It seems to me that the next commit after the label-switcher-function patch ought to be a contrib module that implements a basic f

Re: [HACKERS] pg_execute_from_file, patch v10

On Sun, Dec 12, 2010 at 06:08, Dimitri Fontaine wrote: > The other infrastructure patch that has been mark ready for commit then > commented further upon by Tom is $subject, even if the function provided > as been renamed to pg_execute_sql_file(). > > Please find attached the newer version that fi

Re: [HACKERS] hstores in pl/python

2010/12/13 Dmitriy Igrishin : > Hey Pavel, > > 2010/12/13 Pavel Stehule >> >> Hello >> >> this is little bit offtopic, sorry. >> >> I am thinking, so we need a standard associative array support in core >> - like Perl, Python or Javascript. So, I don't think, so migration of >> hstore to core is g

Re: [HACKERS] pg_execute_from_file, patch v10

Itagaki Takahiro writes: > I think the version is almost OK, but I have a couple of comments: > - Why do you need directory_fctx in genfile.h ? I then use it in extension.c, this way: typedef struct extension_fctx { directory_fctx dir; ExtensionList *installed; } extension_fctx;

Re: [HACKERS] ALTER EXTENSION ... UPGRADE;

On Sat, Dec 11, 2010 at 4:35 PM, David E. Wheeler wrote: >> What about having the following keys supported in the control file: >> >>  upgrade_ = 'script.version.sql' >>  upgrade_all = 'script.sql' > > Why not just use an upgrade script naming convention? Think: Convention over > configuration.

Re: [HACKERS] Optimize PL/Perl function argument passing [PATCH]

On Dec 9, 2010, at 7:32 PM, Tim Bunce wrote: > On Wed, Dec 08, 2010 at 09:21:05AM -0800, David E. Wheeler wrote: >> On Dec 8, 2010, at 9:14 AM, Tim Bunce wrote: >> Do you have any more improvements in the pipeline? >>> >>> I'd like to add $arrayref = decode_array_literal('{2,3}') and >>> m

Re: [HACKERS] hstores in pl/python

On Monday 13 December 2010 15:27:48 Pavel Stehule wrote: > 2010/12/13 Dmitriy Igrishin : > > Hey Pavel, > > > > 2010/12/13 Pavel Stehule > > > >> Hello > >> > >> this is little bit offtopic, sorry. > >> > >> I am thinking, so we need a standard associative array support in core > >> - like Per

Re: [HACKERS] ALTER EXTENSION ... UPGRADE;

Aidan Van Dyk writes: > Mainly, because of the situation where I have may versions that can > all be upgraded from the same script. I'ld much rather distribution > just 3 scripts (install + 2 upgrades), and a control file with > something like this (pretend I'm on version 2.6) > upgragde-1.0

Re: [HACKERS] Optimize PL/Perl function argument passing [PATCH]

On 12/13/2010 09:42 AM, Alexey Klyukin wrote: I used to work on a patch that converts postgres arrays into perl array references: http://archives.postgresql.org/pgsql-hackers/2009-11/msg01552.php I have a newer patch, which is, however, limited to one-dimensional resulting arrays. If there's

Re: [HACKERS] hstores in pl/python

Interesting argument. I can ask, how many people knows what is tsvector or tsquery ? Or how many people knows what is polygon or path ? The answer is: everyone who need or using it. Hstore is a proven and well designed solution. And in fact I am surprising why it does not in core yet?! 2010/12/13

Re: [HACKERS] hstores in pl/python

2010/12/13 Andres Freund : > On Monday 13 December 2010 15:27:48 Pavel Stehule wrote: >> 2010/12/13 Dmitriy Igrishin : >> > Hey Pavel, >> > >> > 2010/12/13 Pavel Stehule >> > >> >> Hello >> >> >> >> this is little bit offtopic, sorry. >> >> >> >> I am thinking, so we need a standard associative ar

Re: [HACKERS] pg_archivecleanup should remove WAL files also in pg_xlog?

On Mon, Dec 13, 2010 at 6:02 PM, Fujii Masao wrote: > Yep, that's recommended in the document, but I don't want to use that. > Because that might make new master fail to archive WAL file because of > existence of half-baked file in the archive, after failover. This can happen > if the master crash

Re: [HACKERS] hstores in pl/python

On Monday 13 December 2010 16:01:35 Pavel Stehule wrote: > 2010/12/13 Andres Freund : > > On Monday 13 December 2010 15:27:48 Pavel Stehule wrote: > >> 2010/12/13 Dmitriy Igrishin : > >> > Hey Pavel, > >> > > >> > 2010/12/13 Pavel Stehule > >> > > >> >> Hello > >> >> > >> >> this is little bit

Re: [HACKERS] hstores in pl/python

2010/12/13 Dmitriy Igrishin : > Interesting argument. > I can ask, how many people knows what is tsvector or tsquery ? > Or how many people knows what is polygon or path ? TSearch isn't good example. There are not a common interface for fulltext. > The answer is: everyone who need or using it.

Re: [HACKERS] GiST insert algorithm rewrite

Heikki Linnakangas writes: > But that creates a new problem: There's a maximum of three backup blocks > per WAL record, but a GiST page can be split into any number of child > pages as one operation. You might run out of backup block slots. > Attached is an updated patch, but that issue with li

Re: [HACKERS] ALTER EXTENSION ... UPGRADE;

On Mon, Dec 13, 2010 at 9:55 AM, Dimitri Fontaine wrote: >> Again, I'ld love for the "version" to support some sort of prefix or >> wildcard matching, so I could do: >>     upgrade-1.* =  $EXT-upgrade-1.sql >>     upgrade-2.* =  $EXT-upgrade-2.sql > > Problem is: what to do if a single upgrade ma

Re: [HACKERS] hstores in pl/python

>> >> name and interface - hstore is designed as external module - a >> internal class can be designed different. > Could you actually name such a difference rather than pointing to some airily > hint of one? That would make it way much easier to see where you want to go. My idea is: somevar['key

Re: [HACKERS] proposal : cross-column stats

Tomas Vondra writes: > Well, until this point we've discussed failure cases involving 'AND' > conditions. What about 'OR' conditions? I think the current optimizer > computes the selectivity as 's1+s2 - s1*s2' (at least that's what I > found in backend/optimizer/path/clausesel.c:630). If you can

Re: [HACKERS] initdb failure with Postgres 8.4.4

On Fri, Dec 10, 2010 at 10:54 AM, Andrew Dunstan wrote: > Here's my understanding. > > It's not initdb that's really complaining. The timezone files are not inputs > to initdb. It's the postgres that initdb invokes that's complaining. >> Postges will look for the share file in two places: the con

Re: [HACKERS] proposal : cross-column stats

Robert Haas writes: > On Sun, Dec 12, 2010 at 9:16 PM, Tomas Vondra wrote: >> The proposed solution is based on contingency tables, built for selected >> groups of columns (not for each possible group). And the contingency >> table gives you the ability to estimate the probabilities needed to >>

Re: [HACKERS] Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE

Florian Pflug writes: > On Dec13, 2010, at 00:16 , Robert Haas wrote: >> And in fact it strikes me that we might not have much choice about how >> to fix this. I think we are not going to retroactively change the >> behavior of ALTER DATABASE .. SET ROLE in a released version, but yet >> we do, I

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Mon, 2010-12-13 at 11:54 +, Peter Geoghegan wrote: > On 13 December 2010 10:30, Dimitri Fontaine wrote: > > Seriously, real-world use cases such as Kevin's one seems to warrant > > that we are able to create a table withouth enforcing the FK. That's > > horrid, yes, that's needed, too. Mayb

Re: [HACKERS] ALTER EXTENSION ... UPGRADE;

Aidan Van Dyk writes: > On Sat, Dec 11, 2010 at 4:35 PM, David E. Wheeler > wrote: >> Why not just use an upgrade script naming convention? > Mainly, because of the situation where I have may versions that can > all be upgraded from the same script. I'ld much rather distribution > just 3 scrip

Re: [HACKERS] initdb failure with Postgres 8.4.4

Excerpts from BRUSSER Michael's message of lun dic 13 12:34:49 -0300 2010: > I'm not sure if our current approach would work with v8.4. This is what we do > in the nutshell: > - build Postgres > - do not run install > - collect all generated libraries, executables and input files and pack them >

Re: [HACKERS] hstores in pl/python

Pavel Stehule writes: >> Could you actually name such a difference rather than pointing to some airily >> hint of one? That would make it way much easier to see where you want to go. > My idea is: > somevar['key'] = value > value = somevar['key']; > or with constructor > somevar = ARRAY[key1 =

Re: [HACKERS] initdb failure with Postgres 8.4.4

"BRUSSER Michael" writes: > I'm not sure if our current approach would work with v8.4. This is what we do > in the nutshell: > - build Postgres > - do not run install > - collect all generated libraries, executables and input files and pack them > along with other app > - distribute the tar-ball

Re: [HACKERS] SQL/MED - file_fdw

On 12/13/2010 01:31 AM, Itagaki Takahiro wrote: On Sat, Dec 11, 2010 at 05:30, Andrew Dunstan wrote: On 12/04/2010 11:11 PM, Itagaki Takahiro wrote: One exports the copy functions from the core, and another implements file_fdw using the infrastructure. Who is actually going to do this split

Re: [HACKERS] rest of works for security providers in v9.1

On Mon, Dec 13, 2010 at 8:32 AM, KaiGai Kohei wrote: > (2010/12/13 21:53), Robert Haas wrote: >> 2010/12/12 KaiGai Kohei: >>> >>> I'd like to see opinions what facilities should be developed >>> to the current v9.1 development cycle. >> >> It seems to me that the next commit after the label-switch

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 11/01/2010 10:10 PM, Itagaki Takahiro wrote: On Tue, Nov 2, 2010 at 8:43 AM, Hiroshi Inoue wrote: The problem which was fixed by your old patch is at runtime not at compilation time. Is it fixed with gcc 4.5? Now it works as far as simple test, including core functions and dynamic modules

Re: [HACKERS] hstores in pl/python

My most serious pro about hstore in core is a better dump/restore support. Also, since we have so much better hstore and people started to use it in their projects, it'd be great to have built-in feature in PostgreSQL, which mimic key-value or document-oriented database. Oleg On Mon, 13 Dec

Re: [HACKERS] ALTER EXTENSION ... UPGRADE;

Excerpts from Tom Lane's message of lun dic 13 12:50:43 -0300 2010: > I see no advantage of this over a script per version combination, so > long as you allow scripts to \include each other. Hmm, are the upgrade scripts going to be run via SPI? -- Álvaro Herrera The PostgreSQL Company - Comman

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs wrote: > (a) ALTER TABLE ... ADD FOREIGN KEY ... NOT VALIDATED INITIALLY; > will add a FK but NOT run the check - we mark it as "check pending". > Lock held: ShareRowExclusiveLock Seems about right. Not sure whether the lock strength is correct. > (

Re: [HACKERS] hstores in pl/python

There are a lot of operators and functions to work with hstore. Does it worth it to implement similar things only to make it possible using operator [] ? 2010/12/13 Pavel Stehule > >> > >> name and interface - hstore is designed as external module - a > >> internal class can be designed differen

Re: [HACKERS] SQL/MED - file_fdw

Andrew Dunstan writes: > Hmm. I don't think that's going to expose enough for what I want to be > able to do. I actually had in mind exposing lower level routines like > CopyReadAttibutesCSV/CopyReadAttributesText and allowing the Foreign > Data Wrapper to manipulate the raw values read (for ex

Re: [HACKERS] ALTER EXTENSION ... UPGRADE;

Tom Lane writes: > I see no advantage of this over a script per version combination, so > long as you allow scripts to \include each other. I guess the following should do: SELECT pg_execute_sql_file('upgrade-1.sql'); But I rather prefer the 2-liner control file, myself: upgrade-1.* = 'upg

Re: [HACKERS] Problem with pg_upgrade (8.4 -> 9.0) due to ALTER DATABASE SET ROLE

On Dec13, 2010, at 16:40 , Tom Lane wrote: > Florian Pflug writes: >> On Dec13, 2010, at 00:16 , Robert Haas wrote: >>> And in fact it strikes me that we might not have much choice about how >>> to fix this. I think we are not going to retroactively change the >>> behavior of ALTER DATABASE .. SE

Re: [HACKERS] SQL/MED - file_fdw

On 12/13/2010 11:12 AM, Tom Lane wrote: Andrew Dunstan writes: Hmm. I don't think that's going to expose enough for what I want to be able to do. I actually had in mind exposing lower level routines like CopyReadAttibutesCSV/CopyReadAttributesText and allowing the Foreign Data Wrapper to mani

Re: [HACKERS] SQL/MED - core functionality

2010/12/14 Shigeru HANADA : > On Thu, 25 Nov 2010 15:03:29 +0200 > Heikki Linnakangas wrote: >> I propose the attached API instead. This has a clear separation between >> plan and execution. I'm sure we'll have to extend the API in the future >> FDWs want tighter integration, but I think this is a

Re: [HACKERS] SQL/MED - core functionality

2010/12/13 Shigeru HANADA : > On Sun, 12 Dec 2010 23:47:53 +0200 > Peter Eisentraut wrote: >> On ons, 2010-12-01 at 12:30 +0900, Hitoshi Harada wrote: >> > From a user's view, this is very long way to see a simplest foreign >> > table. I know it is based on the standard, but I really want a >> > s

Re: [HACKERS] [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags

On 12/13/2010 12:54 AM, Glen Knowles wrote: On Sun, Dec 12, 2010 at 8:16 AM, Tom Lane > wrote: > What are the values of _S_IREAD and _S_IWRITE, anyway? I'm still > wondering how come the previous coding with hardwired constants > behaved correctly.

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 11/01/2010 10:10 PM, Itagaki Takahiro wrote: >> BTW, with out without the above fix, regression test failed with >> weird error if the server is built with gcc 4.5. However, server >> can run if I started it manually with PGPORT or -o "--port=X". >> We might need anothe

Re: [HACKERS] hstores in pl/python

2010/12/13 Dmitriy Igrishin : > There are a lot of operators and functions to work with hstore. > Does it worth it to implement similar things only to make it > possible using operator [] ? yes > > 2010/12/13 Pavel Stehule >> >> >> >> >> name and interface - hstore is designed as external module

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On 13 December 2010 16:08, Robert Haas wrote: > On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs wrote: >> 2. pg_validate_foreign_key('constraint name'); >> Returns immediately if FK is valid >> Returns SETOF rows that violate the constraint, or if no rows are >> returned it updates constraint to sh

Re: [HACKERS] initdb failure with Postgres 8.4.4

Here is what you should do: 1. Build Postgres with --prefix set to some empty directory. 2. Run install. 3. Bundle up the resulting install tree as part of your tarball. Do not editorialize upon the relative locations of its contents. 4. Drop the install tree wherever you want on the target machi

Re: [HACKERS] GiST insert algorithm rewrite

On Mon, Dec 13, 2010 at 3:14 PM, Tom Lane wrote: > I think you need to refactor the operation so that there's one WAL > record per child page, or something along that line.  I concede this > might be diffcult :-( If it's only the backup blocks that matter couldn't you generate noop WAL records wi

Re: [HACKERS] initdb failure with Postgres 8.4.4

On 12/13/2010 12:16 PM, BRUSSER Michael wrote: Here is what you should do: 1. Build Postgres with --prefix set to some empty directory. 2. Run install. 3. Bundle up the resulting install tree as part of your tarball. Do not editorialize upon the relative locations of its contents. 4. Drop the

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Mon, Dec 13, 2010 at 05:15:29PM +, Peter Geoghegan wrote: > On 13 December 2010 16:08, Robert Haas wrote: > > On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs wrote: > >> 2. pg_validate_foreign_key('constraint name'); > >> Returns immediately if FK is valid > >> Returns SETOF rows that violat

Re: [HACKERS] hstores in pl/python

2010/12/13 Pavel Stehule > 2010/12/13 Dmitriy Igrishin : > > There are a lot of operators and functions to work with hstore. > > Does it worth it to implement similar things only to make it > > possible using operator [] ? > > yes > > > > > 2010/12/13 Pavel Stehule > >> > >> >> > >> >> name and

Re: [HACKERS] unlogged tables

On Fri, Dec 10, 2010 at 11:16 PM, Robert Haas wrote: > I think the first patch (relpersistence-v4.patch) is ready to commit, So I've now committed it. > and the third patch to allow synchronous commits to become > asynchronous when it doesn't matter (relax-sync-commit-v1.patch) Jeff Janes revie

[HACKERS] CommitFest wrap-up

We're now just a day or two from the end of this CommitFest and there are still a LOT of open patches - to be specific, 23.Here's a brief synopsis of where we are with the others, all IMO of course. - fix for seg picksplit function - I don't have confidence this change is for the best and can't ta

Re: [HACKERS] GiST insert algorithm rewrite

On 13.12.2010 19:19, Greg Stark wrote: On Mon, Dec 13, 2010 at 3:14 PM, Tom Lane wrote: I think you need to refactor the operation so that there's one WAL record per child page, or something along that line. I concede this might be diffcult :-( If it's only the backup blocks that matter coul

Re: [HACKERS] GiST insert algorithm rewrite

Heikki Linnakangas writes: > On 13.12.2010 19:19, Greg Stark wrote: >> If it's only the backup blocks that matter couldn't you generate noop >> WAL records with just the full page image in them. Once all those are >> generated then generate the actual split operation and since all the >> pages hav

Re: [HACKERS] CommitFest wrap-up

On 12/13/2010 12:37 PM, Robert Haas wrote: - SQL/MED - core functionality - Seems clear to move this to the next CF and keep working on it. [...] - SQL/MED - file_fdw - Discussion is ongoing, but I see no harm in marking this Returned with Feedback for now in anticipation of a new version bef

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/13/2010 12:01 PM, Tom Lane wrote: Andrew Dunstan writes: On 11/01/2010 10:10 PM, Itagaki Takahiro wrote: BTW, with out without the above fix, regression test failed with weird error if the server is built with gcc 4.5. However, server can run if I started it manually with PGPORT or -o

Re: [HACKERS] proposal : cross-column stats

On Sun, Dec 12, 2010 at 07:10:44PM -0800, Nathan Boley wrote: > Another quick note: I think that storing the full contingency table is > wasteful since the marginals are already stored in the single column > statistics. Look at copulas [2] ( FWIW I think that Josh Tolley was > looking at this a cou

Re: [HACKERS] initdb failure with Postgres 8.4.4

Andrew Dunstan writes: > On 12/13/2010 12:16 PM, BRUSSER Michael wrote: >> Would it be a completely crazy idea if I try to modify Postgres to look at >> some env. var >> (similar to PGDATA) and if exists and path is valid look there for the >> timezone files? > Yes, that's only the first probl

Re: [HACKERS] CommitFest wrap-up

On Mon, Dec 13, 2010 at 12:55 PM, Andrew Dunstan wrote: > > > On 12/13/2010 12:37 PM, Robert Haas wrote: >> >> - SQL/MED - core functionality - Seems clear to move this to the next >> CF and keep working on it. > > [...] >> >> - SQL/MED - file_fdw - Discussion is ongoing, but I see no harm in >> m

Re: [HACKERS] hstores in pl/python

2010/12/13 Dmitriy Igrishin : > > > 2010/12/13 Pavel Stehule >> >> 2010/12/13 Dmitriy Igrishin : >> > There are a lot of operators and functions to work with hstore. >> > Does it worth it to implement similar things only to make it >> > possible using operator [] ? >> >> yes >> >> > >> > 2010/12/1

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > On 12/13/2010 12:01 PM, Tom Lane wrote: >> It smells a little bit like an optimization bug. Does dialing down to >> -O0 make it go away? > Sadly, no. I'm testing downgrading the compiler now. Mph. FWIW, I see that my last build of Postgres for Fedora 14 would have been

Re: [HACKERS] hstores in pl/python

On Dec 13, 2010, at 8:06 AM, Oleg Bartunov wrote: > My most serious pro about hstore in core is a better dump/restore > support. Also, since we have so much better hstore and people started > to use it in their projects, it'd be great to have built-in feature in > PostgreSQL, which mimic key-va

Re: [HACKERS] GiST insert algorithm rewrite

On 13.12.2010 19:48, Tom Lane wrote: Heikki Linnakangas writes: On 13.12.2010 19:19, Greg Stark wrote: If it's only the backup blocks that matter couldn't you generate noop WAL records with just the full page image in them. Once all those are generated then generate the actual split operation

Re: [HACKERS] GiST insert algorithm rewrite

Heikki Linnakangas writes: > On 13.12.2010 19:48, Tom Lane wrote: >> Yeah. Wouldn't the original page-split record have been carrying full >> page images already? > Yes. > BTW, the original split record doesn't run into the limit because it > doesn't use the backup-block mechanism, it contains

Re: [HACKERS] GiST insert algorithm rewrite

On 13.12.2010 20:30, Tom Lane wrote: Can we fix it so that each child page is updated, and its downlink inserted, as a separate atomic action? That'd require each intermediate state to be consistent and crash-safe, but I think you really need the intermediate states to be consistent anyway becau

Re: [HACKERS] ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED

On Mon, 2010-12-13 at 17:15 +, Peter Geoghegan wrote: > On 13 December 2010 16:08, Robert Haas wrote: > > On Mon, Dec 13, 2010 at 10:49 AM, Simon Riggs wrote: > >> 2. pg_validate_foreign_key('constraint name'); > >> Returns immediately if FK is valid > >> Returns SETOF rows that violate the c

Re: [HACKERS] proposal : cross-column stats

Dne 13.12.2010 16:34, Tom Lane napsal(a): > Tomas Vondra writes: >> Well, until this point we've discussed failure cases involving 'AND' >> conditions. What about 'OR' conditions? I think the current optimizer >> computes the selectivity as 's1+s2 - s1*s2' (at least that's what I >> found in backe

Re: [HACKERS] proposal : cross-column stats

Dne 13.12.2010 16:38, Tom Lane napsal(a): > The reason that this wasn't done years ago is precisely that nobody's > figured out how to do it with a tolerable amount of stats data and a > tolerable amount of processing time (both at ANALYZE time and during > query planning). It's not hard to see wh

Re: [HACKERS] CommitFest wrap-up

On Mon, Dec 13, 2010 at 12:37:52PM -0500, Robert Haas wrote: > We're now just a day or two from the end of this CommitFest and there > are still a LOT of open patches - to be specific, 23.Here's a brief > synopsis of where we are with the others, all IMO of course. [snip] > - Writeable CTEs - I th

Re: [HACKERS] proposal : cross-column stats

Dne 13.12.2010 18:59, Joshua Tolley napsal(a): > On Sun, Dec 12, 2010 at 07:10:44PM -0800, Nathan Boley wrote: >> Another quick note: I think that storing the full contingency table is >> wasteful since the marginals are already stored in the single column >> statistics. Look at copulas [2] ( FWIW

Re: [HACKERS] CommitFest wrap-up

On Mon, Dec 13, 2010 at 2:19 PM, David Fetter wrote: > On Mon, Dec 13, 2010 at 12:37:52PM -0500, Robert Haas wrote: >> We're now just a day or two from the end of this CommitFest and there >> are still a LOT of open patches - to be specific, 23.Here's a brief >> synopsis of where we are with the o

Re: [HACKERS] CommitFest wrap-up

Robert Haas writes: > We're now just a day or two from the end of this CommitFest and there > are still a LOT of open patches - to be specific, 23.Here's a brief > synopsis of where we are with the others, all IMO of course. Thanks for doing this! > - Extensions - Still under active discussion,

Re: [HACKERS] WaitLatch

On Mon, Dec 13, 2010 at 5:48 AM, aaliya zarrin wrote: > drainSelfPipe() function will read the data and remove it from the > descriptor? Yes... > Coz the signal (SIGUSR1) is writing sata to selfPipe descriptor but unable > to wake up latch on select system call. The signal won't cause the selec

Re: [HACKERS] pg_is_in_recovery=1

On Mon, Dec 13, 2010 at 12:48 AM, aaliya zarrin wrote: > When pg_is_in_recovery in the table changes to zero(status change)?? > At the time when recovery stops? Ah... yep. > If switch over has to be done then, after receivibg the signal and telling > the postgres to run the startup process (got_

Re: [HACKERS] hstores in pl/python

2010/12/13 Pavel Stehule > 2010/12/13 Dmitriy Igrishin : > > > > > > 2010/12/13 Pavel Stehule > >> > >> 2010/12/13 Dmitriy Igrishin : > >> > There are a lot of operators and functions to work with hstore. > >> > Does it worth it to implement similar things only to make it > >> > possible using o

Re: [HACKERS] CommitFest wrap-up

On Dec 13, 2010, at 12:04 PM, Dimitri Fontaine wrote: > So, who's in to finish up and commit this patch in this round? :) > I certainly am ready to support last minute changes, given some are > required. And if they are too big for the schedule, better shake the > patch out now rather than let it

Re: [HACKERS] hstores in pl/python

2010/12/13 Dmitriy Igrishin : > > > 2010/12/13 Pavel Stehule >> >> 2010/12/13 Dmitriy Igrishin : >> > >> > >> > 2010/12/13 Pavel Stehule >> >> >> >> 2010/12/13 Dmitriy Igrishin : >> >> > There are a lot of operators and functions to work with hstore. >> >> > Does it worth it to implement similar

Re: [HACKERS] Why percent_rank is so slower than rank?

Tom Lane wrote: > argue that there was a regression. It's certainly a performance bug > though: nobody would expect that giving a query *more* work_mem would > cause it to run many times slower. I wouldn't be that surprised - otherwise it'd just be hard-coded to something large. Especially since

Re: [HACKERS] CommitFest wrap-up

"David E. Wheeler" writes: > On Dec 13, 2010, at 12:04 PM, Dimitri Fontaine wrote: >> So, who's in to finish up and commit this patch in this round? :) > > I'll try to do another review this week. Thanks! -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

Re: [HACKERS] BufFreelistLock

On Dec 12, 2010, at 8:48 PM, Jim Nasby wrote: >> There might be some advantage in having it move buffers >> to a freelist that's just protected by a simple spinlock (or at least, >> a lock different from the one that protects the clock sweep). The >> idea would be that most of the time, backends j

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On 12/13/2010 01:12 PM, Tom Lane wrote: Andrew Dunstan writes: On 12/13/2010 12:01 PM, Tom Lane wrote: It smells a little bit like an optimization bug. Does dialing down to -O0 make it go away? Sadly, no. I'm testing downgrading the compiler now. Mph. FWIW, I see that my last build of Po

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

On Mon, Dec 13, 2010 at 22:29, Andrew Dunstan wrote: > > > On 12/13/2010 01:12 PM, Tom Lane wrote: >> >> Andrew Dunstan  writes: >>> >>> On 12/13/2010 12:01 PM, Tom Lane wrote: It smells a little bit like an optimization bug.  Does dialing down to -O0 make it go away? >>> >>> Sadly,

Re: [HACKERS] Complier warnings on mingw gcc 4.5.0

Andrew Dunstan writes: > Further digging shows some weirdness. This doesn't appear to be > compiler-related. I've rolled back all the way to gcc 3.5. It is > triggered by the following line in pg_regress.c, commenting out of which > causes the problem to go away (although of course it causes th

Re: [HACKERS] proposal : cross-column stats

Tomas, > (a) find out what statistics do we need to collect and how to use it > (b) implement a really stupid inefficient solution > (c) optimize in iterations, i.e. making it faster, consuming less > space etc. I'll suggest again how to decide *which* columns to cross: whichever colu

Re: [HACKERS] CommitFest wrap-up

On 12/13/10 9:37 AM, Robert Haas wrote: > - synchronous replication - and... > - synchronous replication, transaction-controlled - If we want to get > this feature into 9.1, we had better get a move on. But I don't > currently have it in my time budget to deal with this. I thought we'd covered mo

  1   2   >