Re: [HACKERS] [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after

Hi Tom, On Tuesday 23 February 2010 06:37:26 Tom Lane wrote: > I wrote: > > Any theories about what is happening? > Now, this doesn't mean that all is fine and dandy. I believe that a > majority of Unixen will reject attempts to open directories for writing, > so this solution puts us even furth

Re: [HACKERS] Streaming replication and pg_xlogfile_name()

Fujii Masao wrote: > On Mon, Feb 22, 2010 at 9:30 PM, Heikki Linnakangas > wrote: >> Thinking about this again, I'm not sure this is a good idea. Using >> curFileTLI makes sense if you're going to call pg_xlogfile_name() and >> would expect it to return the filename of the file containing the WAL

[HACKERS] to_char("HH12") with intervals

bruce wrote: > bruce wrote: > > Dave Page wrote: > > > This was posted as a documentation comment: > > > > > > to_char(interval '0d 0h 12m 44s', 'DD HH MI SS'); > > > with HH and HH12 will return 12 instead of 0. > > > > > > Testing on 8.4.1, it does seem to be the case that you get "00 12 12 > >

Re: [HACKERS] A thought on Index Organized Tables

Tom Lane wrote: > > Also, we're using the same technique for TOASTed values. The cost can be > > compared with "select * from mytable where toasted_value = something", no? > > No, because toast pointers point in the direction you need to traverse. > AFAICS, this proposal involves scanning the w

Re: [HACKERS] A thought on Index Organized Tables

Takahiro Itagaki writes: > Tom Lane wrote: >> Takahiro Itagaki writes: >>> Instead, how about excluding columns in primary keys from table data? >> >> How will you implement "select * from mytable" ? Or even >> "select * from mytable where non_primary_key = something" ? > Also, we're using th

Re: [HACKERS] A thought on Index Organized Tables

Tom Lane wrote: > Takahiro Itagaki writes: > > Instead, how about excluding columns in primary keys from table data? > > How will you implement "select * from mytable" ? Or even > "select * from mytable where non_primary_key = something" ? Use index full scans. We can do it even for now with

Re: [HACKERS] pretty print viewdefs

What happened to this? I didn't see it applied. --- Tom Lane wrote: > Andrew Dunstan writes: > > OK, and how are we going to set that flag? Like I did, with a separate > > function? > > I would be inclined to invent a va

Re: [HACKERS] tie user processes to postmaster

Jaime Casanova wrote: > integrated_user_processes = 'x, y, z' > API would be user_process_startup(), user_process_shutdown(). FYI, pg_statsinfo version 2 emulates the same behavior with shared_preload_libraries and spawn an user process in _PG_init(). But it's still ugly and not so reliable. Of

Re: [HACKERS] phypot - Pygmy Hippotause ?

I assume this is not something we are supposed to apply. --- Paul Matthews wrote: > Kevin Grittner wrote: > > > > The first test seems unnecessary if you have the second. > > x >= 0, so x can't be zero unless y is, too. >

Re: [HACKERS] Adding \ev view editor?

Is this a TODO? --- Josh Berkus wrote: > All, > > I've grown to adore the new \ef function editor. > > It doesn't seem like it would be that difficult to add a view editor as > \ev. While editors would also be good for ot

Re: [HACKERS] More robust pg_hba.conf parsing/error logging

Tom Lane wrote: > Alvaro Herrera writes: > > Andrew Dunstan wrote: > >> It will affect any dbname or username in mixed or upper case, not just > >> ALL, won't it? > > > No, I am suggesting to change only the comparisons to the literals > > "all", "sameuser", "samegroup" and "samerole". What happ

Re: [HACKERS] A thought on Index Organized Tables

Takahiro Itagaki writes: > Instead, how about excluding columns in primary keys from table data? How will you implement "select * from mytable" ? Or even "select * from mytable where non_primary_key = something" ? If you can't do either of those without great expense, I think a savings on primar

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

Alvaro Herrera writes: > Regarding hooks or events, I think postmaster should be kept simple: > launch at start, reset at crash recovery, kill at stop. Salt and pepper > allowed but that's about it -- more complex ingredients are out of the > question due to added code to postmaster, which we wan

Re: [HACKERS] A thought on Index Organized Tables

Gokulakannan Somasundaram wrote: > a) IOT has both table and index in one structure. So no duplication of data > b) With visibility maps, we have three structures a) Table b) Index c) > Visibility map. So the disk footprint of the same data will be higher in > postgres ( 2x + size of the visibil

[HACKERS] recovery.conf.sample

Hi, recovery.conf.sample has the following section for Hot Standby. Is this still required? > #--- > # HOT STANDBY PARAMETERS > #--- > # > # If you want

Re: [HACKERS] function side effects

Tatsuo Ishii writes: > I'm wondering if we could detect a funcion has a side effect, > i.e. does a write to database. > Currently we have three properties of functions: IMMUTABLE, STABLE and > VOLATILE. According to docs IMMUTABLE or STABLE functions do not write > to database. Those classificat

Re: [SPAM][HACKERS] function side effects

"Tatsuo Ishii" wrote: > VOLATILE functions such as random() and timeofday() apparently do not > write and sending those queries that include such functions is > overkill. > Can we VOLATILE property divide into two categories, say, VOLATILE > without write, and VOLATILE with write? I think it's

[HACKERS] synchronous commit in dump

Hi, it's safe to set synchrounous_commit to off in a pg_dump generated script? if yes, would this help to the performance of restore a database? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent v

[HACKERS] function side effects

Hi, I'm wondering if we could detect a funcion has a side effect, i.e. does a write to database. This is neccessary for pgpool to decide if a qeury should to be sent to all of databases or not. If a query includes functions which do writes to database, it should send the query to all of databases,

Re: [HACKERS] Elementary dependency look-up

Added to TODO: |Add function to dump pg_depend information cleanly --- Greg Smith wrote: > On Wed, 9 Sep 2009, decibel wrote: > > > What might be more useful is a view that takes the guesswork out of using > > pg_

Re: [HACKERS] Streaming replication and pg_xlogfile_name()

On Mon, Feb 22, 2010 at 9:30 PM, Heikki Linnakangas wrote: > Thinking about this again, I'm not sure this is a good idea. Using > curFileTLI makes sense if you're going to call pg_xlogfile_name() and > would expect it to return the filename of the file containing the WAL > record being replayed. B

Re: [HACKERS] [PATCH] backend: compare word-at-a-time in bcTruelen

Tom Lane wrote: > Jeremy Kerr writes: > > Stephen, > >> If the updated function is always faster when the overall string is at > >> least, say, 16 characters long, > > > But that's not the case - the cost of the function (and the speedup from > > the previous version) depends on the number of sp

Re: [HACKERS] updated hstore patch

Tom Lane wrote: > "David E. Wheeler" writes: > > On Sep 20, 2009, at 8:43 AM, Tom Lane wrote: > >> Yeah, this is a long-standing generic issue, and not really hstore's > >> problem to fix. > > > So then does there need to be some documentation for how to deal with > > this, for those doing an i

Re: [HACKERS] numeric_to_number() function skipping some digits

Added to TODO: |Fix to_number() handling for values not matching the format string --- Jeevan Chalke wrote: > Hi, > > On Mon, Sep 21, 2009 at 12:36 PM, Brendan Jurd wrote: > > > 2009/9/21 Jeevan Chalke : > > >

Re: [HACKERS] Issues for named/mixed function notation patch

Can someone work on a patch to implement the document changes suggested below? --- Jeff Davis wrote: > On Tue, 2009-09-15 at 10:51 +0200, Pavel Stehule wrote: > > My renonc, please, try new patch. I forgot mark regproc.c fil

Re: [HACKERS] [PATCH] 8.5 TODO: Add comments to output indicating version of pg_dump and of the database server

What happened to this patch? I don't see any objections, but it was not applied. --- Jim Cox wrote: > On Tue, Sep 29, 2009 at 12:00 AM, Alvaro Herrera > wrote: > > Jim Cox escribi?: > > > >> Attached s/b a patch for the 8.5

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

David Christensen wrote: > What are the semantics? If you launch a process and it crashes, is > the postmaster responsible for relaunching it? Is there any > additional monitoring of that process it would be expected to do? > What defined hooks/events would you want to launch these processes > f

Re: [HACKERS] remove useless set of active snap

Bruce Momjian wrote: > Alvaro Herrera wrote: > > This patch removes a useless pushing of an active snapshot on > > PortalStart. Instead of push/get/pop of the active snapshot, without > > any intervening use of the active snapshot, we just pass a local > > snapshot down to CreateQueryDesc. > > Al

Re: [HACKERS] commented out para in docs

Andrew Dunstan wrote: > > > We have this para in the CREATE TABLE docs, commented out, as shown. It > seems to have been like that for a long time (see > ). > > Surely we should either include it o

Re: [HACKERS] remove useless set of active snap

Alvaro Herrera wrote: > This patch removes a useless pushing of an active snapshot on > PortalStart. Instead of push/get/pop of the active snapshot, without > any intervening use of the active snapshot, we just pass a local > snapshot down to CreateQueryDesc. Alvaro, what happened to this patch?

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

On Feb 22, 2010, at 5:22 PM, Jaime Casanova wrote: On Mon, Feb 22, 2010 at 4:37 PM, Tom Lane wrote: Dimitri Fontaine writes: Tom Lane writes: This seems like a solution in search of a problem to me. The most salient aspect of such processes is that they would necessarily run as the postg

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

On Mon, Feb 22, 2010 at 4:37 PM, Tom Lane wrote: > Dimitri Fontaine writes: >> Tom Lane writes: >>> This seems like a solution in search of a problem to me.  The most >>> salient aspect of such processes is that they would necessarily run >>> as the postgres user > >> The precedent are archive a

Re: [HACKERS] scheduler in core

Merlin Moncure escribió: > Like I noted above, what people want to schedule is going to be stored > procedures. Having both would virtually eliminate the need for > scripting outside the database, which is a pretty big deal since > external scripts are a real pain to keep cross platform. Since >

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

Tom Lane writes: > Well, yeah, but you *must* trust those commands because every last bit > of your database content passes through their hands. That is not an > argument why you need to trust a scheduling facility --- much less the > tasks it schedules. It seems to me that CREATE FUNCTION maint

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

Dimitri Fontaine writes: > Tom Lane writes: >> This seems like a solution in search of a problem to me. The most >> salient aspect of such processes is that they would necessarily run >> as the postgres user > The precedent are archive and restore command. They do run as postgres > user too, do

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

On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane wrote: > I still haven't seen a good reason for not using cron or Task Scheduler > or other standard tools. *) provided and popular feature in higher end databases *) the audience you cater to expects it *) IMO, it should simply not be necessary to inco

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

Tom Lane writes: > This seems like a solution in search of a problem to me. The most > salient aspect of such processes is that they would necessarily run > as the postgres user I happen to run my PGQ tickers and londiste daemons as "londiste" user and make it a superuser (at least while install

Re: [HACKERS] What does this configure warning mean?

Tom Lane wrote: > Bruce Momjian writes: > > Should we just go ahead and say official releases and daily snapshots? > > Please just revert the patch. So much for my trying to improve things. Reverted. -- Bruce Momjian http://momjian.us EnterpriseDB http

Re: [HACKERS] What does this configure warning mean?

Bruce Momjian writes: > Should we just go ahead and say official releases and daily snapshots? Please just revert the patch. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgres

Re: [HACKERS] What does this configure warning mean?

Tom Lane wrote: > Bruce Momjian writes: > > Alvaro Herrera wrote: > >> Bruce Momjian wrote: > >>> With the attached patch, I have updated the message to use the wording > >>> "bundled distribution". I think the point about the snapshot tarballs > >>> and official releases is that they are "bundle

Re: [HACKERS] What does this configure warning mean?

Tom Lane wrote: > Bruce Momjian writes: > > Alvaro Herrera wrote: > >> Bruce Momjian wrote: > >>> With the attached patch, I have updated the message to use the wording > >>> "bundled distribution". I think the point about the snapshot tarballs > >>> and official releases is that they are "bundle

Re: [HACKERS] What does this configure warning mean?

Bruce Momjian writes: > Alvaro Herrera wrote: >> Bruce Momjian wrote: >>> With the attached patch, I have updated the message to use the wording >>> "bundled distribution". I think the point about the snapshot tarballs >>> and official releases is that they are "bundled" rather than pulled via >>

Re: [HACKERS] Reason why set-value functions not allowed in GREATEST(), etc?

Hitoshi Harada writes: > I just wonder why generate_series() is not allowed in GREATEST syntax. > Looking through execQual.c, almost all syntactic evaluations like > COALESCE, ARRAY[], ROW() doesn't allow set-value functions. Could > someone tell the underlying reason? Laziness, or lack of retur

Re: [HACKERS] scheduler in core

On Mon, Feb 22, 2010 at 2:29 PM, Alvaro Herrera wrote: > Merlin Moncure escribió: > >> Like I noted above, what people want to schedule is going to be stored >> procedures.  Having both would virtually eliminate the need for >> scripting outside the database, which is a pretty big deal since >> ex

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

On Mon, Feb 22, 2010 at 3:08 PM, Jaime Casanova wrote: > On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane wrote: >> >> I still haven't seen a good reason for not using cron or Task Scheduler >> or other standard tools. >> > > - marketing? don't you hate when people say: Oracle has it!? just before some

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

On Mon, Feb 22, 2010 at 2:53 PM, Tom Lane wrote: > > I still haven't seen a good reason for not using cron or Task Scheduler > or other standard tools. > - marketing? don't you hate when people say: Oracle has it!? - user dumbness: they forgot to start daemons they need (yes, i have seen that) or

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

Magnus Hagander writes: > 2010/2/22 Tom Lane : >> Magnus Hagander writes: >>> One way to deal with it would be to expose the whole renegotiation >>> setting as a user configuratble option. So they can set *when* we >>> renegotiate, which would also let them turn it off completely. >> >> Well, th

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

Jaime Casanova writes: > wrote: >> API would be user_process_startup(), user_process_shutdown(). > so it should be a GUC, that is settable only at start time. > we need those integrated processes at all when in a standby server? This seems like a solution in search of a problem to me. The most

Re: [HACKERS] What does this configure warning mean?

Alvaro Herrera wrote: > Bruce Momjian wrote: > > Alvaro Herrera wrote: > > > > That's too subtle. I wouldn't figure out what it means if my life > > > depended on it (then again, it doesn't). > > > > Well, "official" made no sense. Bundled seemed similar enough to > > "tarball". What suggestio

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

2010/2/22 Tom Lane : > Magnus Hagander writes: >> 2010/2/22 Tom Lane : >>> Red Hat's already shipping the patch.  Dunno about other vendors. > >> Which patch? The one that breaks it, or the one that changes the protocol? > > The one with the protocol change. Ok. If RedHat has done it, I think we'

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

2010/2/22 Chris Campbell : > On Feb 22, 2010, at 12:25 PM, Tom Lane wrote: > >> I think we already missed the window where it would have been sensible >> to install a hack workaround for this.  If we'd done that in November >> it might have been reasonable, but by now it's too late for any hack >>

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

On 2/22/10, Joshua D. Drake wrote: > On Mon, 2010-02-22 at 18:45 +0100, Magnus Hagander wrote: >> 2010/2/22 Joshua D. Drake : >> > On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander >> > >> > wrote: >> > >> >> We also have to consider our Windows users, where *we* ship the >> >> OpenSSL library.

Re: [HACKERS] What does this configure warning mean?

Bruce Momjian wrote: > Alvaro Herrera wrote: > > That's too subtle. I wouldn't figure out what it means if my life > > depended on it (then again, it doesn't). > > Well, "official" made no sense. Bundled seemed similar enough to > "tarball". What suggestion do you have? "tarball" ? -- Alvar

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

On Mon, Feb 22, 2010 at 1:50 PM, Heikki Linnakangas wrote: > >> we need those integrated processes at all when in a standby server? > > Yes. You might want to run e.g. scheduled reports from a standby > reporting server, launched by a scheduler process. Or backups. > ah! fair enough! -- Atentam

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

Jaime Casanova wrote: > > if we can do this, how should it work? > Simon said: > """ > Yes, I think so. Rough design... > > integrated_user_processes = 'x, y, z' > > would run x(), y() and z() in their own processes. These would execute > after startup, or at consistent point in recovery. The cod

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

On Mon, 2010-02-22 at 18:45 +0100, Magnus Hagander wrote: > 2010/2/22 Joshua D. Drake : > > On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander > > wrote: > > > >> We also have to consider our Windows users, where *we* ship the > >> OpenSSL library. Where there is no library we can ship right now

Re: [HACKERS] scheduler in core

On Sat, Feb 20, 2010 at 8:06 PM, Joshua D. Drake wrote: > > That doesn't mean it isn't a really good idea. It would be nice to have > a comprehensive job scheduling solution that allows me to continue > abstract away from external solutions and operating system dependencies. +1! Aa scheduler is

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

On Mon, Feb 22, 2010 at 1:18 PM, Heikki Linnakangas wrote: > Jaime Casanova wrote: > >> so, is this idea (having some user processes be "tied" to postmaster >> start/stop) going to somewhere? > > I've added this to the TODO list. Now we just need someone to write it. > if we can do this, how shou

Re: [HACKERS] scheduler in core

2010/2/22 Heikki Linnakangas : > Jaime Casanova wrote: >> On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs wrote: >>> There is currently no way to run a separate daemon process that runs >>> user code as part of Postgres, so that the startup code gets run >>> immediately we startup, re-run if we crash

Re: [HACKERS] scheduler in core

Jaime Casanova wrote: > On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs wrote: >> There is currently no way to run a separate daemon process that runs >> user code as part of Postgres, so that the startup code gets run >> immediately we startup, re-run if we crash and shut down cleanly when >> the se

Re: [HACKERS] Reason why set-value functions not allowed in GREATEST(), etc?

2010/2/22 Hitoshi Harada : > I just wonder why generate_series() is not allowed in GREATEST syntax. > Looking through execQual.c,  almost all syntactic evaluations like > COALESCE, ARRAY[], ROW() doesn't allow set-value functions. Could > someone tell the underlying reason? > > Also, using variadic

Re: [HACKERS] What does this configure warning mean?

Alvaro Herrera wrote: > Bruce Momjian wrote: > > Simon Riggs wrote: > > > > If you have downloaded a full copy of the source then > > > If you are building from a repository checkout ... > > > > > > We don't need to use the word tarball, but we do need to say what we > > > mean. Anyway, its a

Re: [HACKERS] What does this configure warning mean?

Bruce Momjian wrote: > Simon Riggs wrote: > > If you have downloaded a full copy of the source then > > If you are building from a repository checkout ... > > > > We don't need to use the word tarball, but we do need to say what we > > mean. Anyway, its a seldom-used error message and I would

Re: [HACKERS] Wire protocol docs

Dave Page wrote: > On Tue, Oct 13, 2009 at 6:24 PM, Tom Lane wrote: > > Dave Page writes: > >> Right. My complaint though, is that the docs imply that the info on > >> how those values get set is in the docs somewhere, which appears to be > >> incorrect. > > > > The libpq documentation does cover

Re: [HACKERS] transaction_isolation vs. default_transaction_isolation

Josh Berkus wrote: > > > Yeah, they basically have semantics specified by the SQL standard that > > are not compatible with anything else in GUC land. They are more like > > SET LOCAL settings, but again not quite. > > Mind you, transaction_isolation and transaction_read_only aren't > documented

Re: [HACKERS] What does this configure warning mean?

Simon Riggs wrote: > On Thu, 2009-10-15 at 00:26 +0300, Peter Eisentraut wrote: > > On Wed, 2009-10-14 at 15:06 -0300, Alvaro Herrera wrote: > > > Simon Riggs wrote: > > > > > > > > When I run ./configure, I get > > > > > > > > (...warning..) > > > > (If you are using the official distribution of

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

On Feb 22, 2010, at 12:25 PM, Tom Lane wrote: > I think we already missed the window where it would have been sensible > to install a hack workaround for this. If we'd done that in November > it might have been reasonable, but by now it's too late for any hack > we install to spread much faster t

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

2010/2/22 Joshua D. Drake : > On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander > wrote: > >> We also have to consider our Windows users, where *we* ship the >> OpenSSL library. Where there is no library we can ship right now that >> fixes it. > > We do? I mean I know that we provide the old 8.2

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

On Mon, 22 Feb 2010 18:00:33 +0100, Magnus Hagander wrote: > We also have to consider our Windows users, where *we* ship the > OpenSSL library. Where there is no library we can ship right now that > fixes it. We do? I mean I know that we provide the old 8.2/8.3 pginstaller, but EDB is the provi

Re: [HACKERS] scheduler in core

On Sun, Feb 21, 2010 at 1:11 PM, Simon Riggs wrote: [...] >> Dimitri Fontaine writes: >> > Dave Page writes: >> >> Why not just use pgAgent? It's far more flexible than the design >> >> you've suggested, and already exists. >> >> > What would it take to have it included in core, >> [...] > > The

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

On Mon, 22 Feb 2010 12:25:08 -0500, Tom Lane wrote: > Magnus Hagander writes: >> 2010/2/22 Tom Lane : >>> Red Hat's already shipping the patch.  Dunno about other vendors. > >> Which patch? The one that breaks it, or the one that changes the >> protocol? > > The one with the protocol change. >

[HACKERS] Reason why set-value functions not allowed in GREATEST(), etc?

I just wonder why generate_series() is not allowed in GREATEST syntax. Looking through execQual.c, almost all syntactic evaluations like COALESCE, ARRAY[], ROW() doesn't allow set-value functions. Could someone tell the underlying reason? Also, using variadic functions introduced since 8.4, I hop

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

Magnus Hagander writes: > 2010/2/22 Tom Lane : >> Red Hat's already shipping the patch.  Dunno about other vendors. > Which patch? The one that breaks it, or the one that changes the protocol? The one with the protocol change. I think we already missed the window where it would have been sensib

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

2010/2/22 Tom Lane : > Magnus Hagander writes: >> If so, shouldn't we try to disable renegotiation for all versions >> *before* it was properly fixed? > > If we could tell that, sure.  But I don't believe there is any way to > identify whether a given installation of openssl has this patched. > Pl

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

Magnus Hagander writes: > If so, shouldn't we try to disable renegotiation for all versions > *before* it was properly fixed? If we could tell that, sure. But I don't believe there is any way to identify whether a given installation of openssl has this patched. Please don't suggest looking at th

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

2010/2/20 Tom Lane : > Bruce Momjian writes: >> Tom Lane wrote: >>> Chris Campbell writes: Is there a way to detect when the SSL library has renegotiation disabled? >>> >>> Probably not.  The current set of emergency security patches would >>> certainly not have exposed any new API that woul

Re: [HACKERS] [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after

BTW, I notice that after allegedly fixing things, we are now seeing fsync failures during CREATE DATABASE in the installcheck phase of buildfarm runs on (apparently) all the Windows critters, plus a couple of other platforms too. This mystifies me. I could believe that there was something still w

Re: [HACKERS] ALTER TABLE SET STATISTICS requires AccessExclusiveLock

Simon Riggs wrote: > On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote: > > Simon Riggs wrote: > > > > > > On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote: > > > > Tom Lane wrote: > > > > > Peter Eisentraut writes: > > > > > > Is there a good reason for $subject, other than that the

Re: [HACKERS] Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries

2010/2/22 Alvaro Herrera : > Pavel Stehule escribió: >> Hello, >> >> * Now I am working on migration of plpgpsm to plpgsql 9.0 base. I hope >> so I understand SQL/PSM well so I am able to write production quality >> implementation. If you like, I can integrate it to core. It can share >> about 40-5

Re: [HACKERS] [COMMITTERS] Re: pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after

Greg Stark writes: > On Mon, Feb 22, 2010 at 2:54 AM, Tom Lane wrote: >> I also think it should scan the todir not the fromdir, just on >> general principles to avoid any possibility of race conditions. > I had concluded that scanning the original directory was odd but > better because it served

[HACKERS] ALTER TABLE documentation

I just noticed that the current ALTER TABLE documentation doesn't do a very good job differentiating between commands that affect the whole table and commands that only affect specific columns. http://developer.postgresql.org/pgdocs/postgres/sql-altertable.html That didn't matter as much before,

Re: [HACKERS] Plans for 9.1, Grouping Sets, disabling multiqueries, contrib module for string, plpgpsm, preload dictionaries

Pavel Stehule escribió: > Hello, > > * Now I am working on migration of plpgpsm to plpgsql 9.0 base. I hope > so I understand SQL/PSM well so I am able to write production quality > implementation. If you like, I can integrate it to core. It can share > about 40-50% code with plpgpsm. The behave o

Re: [HACKERS] A thought on Index Organized Tables

Greg Stark escribió: > On Mon, Feb 22, 2010 at 8:18 AM, Gokulakannan Somasundaram > wrote: > > a) IOT has both table and index in one structure. So no duplication of data > > b) With visibility maps, we have three structures a) Table b) Index c) > > Visibility map. So the disk footprint of the sam

Re: [HACKERS] Time travel on the buildfarm

Tom Lane wrote: It is currently 22:21:59 EST here. At 21:50 I committed a fix to copydir.c that cleaned up a couple of thinkos by Greg, including a misspelling that had been making all the builds fail for several hours. I went to see if any of the buildfarm had gone green yet, and indeed half

Re: [HACKERS] Streaming replication and pg_xlogfile_name()

Fujii Masao wrote: > On Thu, Jan 28, 2010 at 5:28 PM, Heikki Linnakangas > wrote: >> How about extending the format of the string returned by >> pg_last_xlog_receive/replay_location() to include the timeline ID? When >> it currently returns e.g '6/200016C', it could return '1/6/200016C', >> where

Re: [HACKERS] A thought on Index Organized Tables

Forgot to include the group... On Mon, Feb 22, 2010 at 4:31 PM, Gokulakannan Somasundaram < gokul...@gmail.com> wrote: > > >> These sound like the same point to me. I don't think we're concerned >> with footprint -- only with how much of that footprint actually needs >> to be scanned. So if we ha

Re: [HACKERS] A thought on Index Organized Tables

On Mon, Feb 22, 2010 at 8:18 AM, Gokulakannan Somasundaram wrote: > a) IOT has both table and index in one structure. So no duplication of data > b) With visibility maps, we have three structures a) Table b) Index c) > Visibility map. So the disk footprint of the same data will be higher in > post

Re: [HACKERS] scheduler in core

On Sun, 2010-02-21 at 20:46 +0100, Dimitri Fontaine wrote: > Simon Riggs writes: > > There is currently no way to run a separate daemon process that runs > > user code as part of Postgres, so that the startup code gets run > > immediately we startup, re-run if we crash and shut down cleanly when >

Re: [HACKERS] A thought on Index Organized Tables

Heikki, I had a quick look at the discussion on visibility map design. The main differences as i see it are a) IOT has both table and index in one structure. So no duplication of data b) With visibility maps, we have three structures a) Table b) Index c) Visibility map. So the disk footpri

Re: [HACKERS] [COMMITTERS] pgsql: Oops, don't forget to rewind the directory before scanning it to

On Monday 22 February 2010 04:58:29 Tom Lane wrote: > Fujii Masao writes: > > + Free(xldir); > > > > s/Free/FreeDir ? > > Yeah, that too. I think it's all good now, but please test. At least I havent seen any of the problems pointed out in "fsync fun". > One thing I was wondering was whether