Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On 02/02/2011 08:22 PM, Dimitri Fontaine wrote: Either one line in the Makefile or a new file with the \i equivalent lines, that would maybe look like: SELECT pg_execute_sql_file('upgrade.v14.sql'); SELECT pg_execute_sql_file('upgrade.v15.sql'); So well… I don't see how you've made it les

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On 02/03/2011 12:23 AM, Robert Haas wrote: [..] -- unconditional stuff [..6] -- stuff to do if coming from pre-7 [..] -- some more unconditional stuff [6..12] -- stuff to do if coming from between 6 and 12 [..] -- a few more unconditional things This might be a stupid idea, but how about intr

Re: [HACKERS] compiler warning

On Thu, Feb 3, 2011 at 04:40, Bruce Momjian wrote: > I am seeing the following compiler warning for the past few days: > >        basebackup.c:213: warning: variable `ptr' might be clobbered by >        `longjmp' or `vfork' > > and I see this comment in the file: > >        /* >         * Actually

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: > Stepping back from the implementation details and file naming > conventions a bit, it seems to me that when you do schema upgrades, > there are basically three possible things you might want to put in the > upgrade script: [...] > I've managed schema upgrades that went throug

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Anssi Kääriäinen writes: > upgrade_from_2.0.sql contents: > alter table foobar add column id3 integer; > pg_execute_extension_file('upgrade_from_3.0.sql'); > > ... > > So, when creating a new version you would need to update the main .sql file, > create a new upgrade file, and alter the upgrade_fr

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

This might be a silly idea, but I'm not sure if it was really discussed with respect to extensions here before... Why not use PL/pgSQL as install/upgrade script language, specially now when it's included in the core by default? This would allow for relatively straightforward inclusion of condit

[HACKERS] Typo in create user mapping docs page

Someone submitted a comment to the docs (which I'll shortly delete) which points out a typo on the CREATE USER MAPPING page in the docs. A very brief patch is attached. They also added: "Also concerning this paragraph: a little more detail on how exactly the two sources of encapsuled information a

Re: [HACKERS] Move WAL warning

On Wed, Feb 2, 2011 at 18:00, Magnus Hagander wrote: > On Wed, Feb 2, 2011 at 17:43, Heikki Linnakangas > wrote: >> On 02.02.2011 16:36, Magnus Hagander wrote: >>> >>> When running pg_basebackup with -x to include all transaction log, the >>> server will still throw a warning about xlog archiving

Re: [HACKERS] [DOCS] Typo in create user mapping docs page

On Thu, Feb 3, 2011 at 11:07, Thom Brown wrote: > Someone submitted a comment to the docs (which I'll shortly delete) > which points out a typo on the CREATE USER MAPPING page in the docs. > A very brief patch is attached. Thanks, applied. --  Magnus Hagander  Me: http://www.hagander.net/  Work

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

Hi, On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote: > I'm sorry I'm late to this party. I haven't been keeping up with > pgsql-hackers. Better late than never :) > > I'd kind'a hoped that this functionality could be tied into extending > PL/Perl to handle named arguments. That way the perl varia

Re: [HACKERS] LIKE, CHAR(), and trailing spaces

On Wed, Feb 02, 2011 at 07:48:38PM -0500, Bruce Momjian wrote: > Brendan Jurd wrote: > > On 3 February 2011 10:54, Bruce Momjian wrote: > > > It seems LIKE is considering the trailing CHAR(10) field spaces as > > > significant, even though our documentations says: > > > > > -- snip -- > > > > > >

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 03, 2011 at 10:21:28AM +0200, Anssi Kääriäinen wrote: > On 02/02/2011 08:22 PM, Dimitri Fontaine wrote: >> Either one line in the Makefile or a new file with the \i equivalent >> lines, that would maybe look like: >> >>SELECT pg_execute_sql_file('upgrade.v14.sql'); >>SELECT pg_e

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 3, 2011 at 9:53 AM, Ross J. Reedstrom wrote: >> Example: >> >> upgrade_from_1_0 = '1.0 => upgrade_from_1.0.sql' >> upgrade_from_2_0 = '2.0 => upgrade_from_2.0.sql' >> upgrade_from_3_0 = '3.0 => upgrade_from_3.0.sql' > > Hmm, how about allowing a list of files to execute? That allows th

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

"Ross J. Reedstrom" writes: > Hmm, how about allowing a list of files to execute? That allows the Sure. I still don't see why doing it in the control file is better than in the Makefile, even if it's already better than in the SQL script, at least in terms of code to write to support the idea.

Re: [HACKERS] out of memory during COPY .. FROM

On Tue, Feb 1, 2011 at 5:32 AM, Tom Lanyon wrote: > List, > > Can anyone suggest where the below error comes from, given I'm attempting to > load HTTP access log data with reasonably small row and column value lengths? > >        logs=# COPY raw FROM '/path/to/big/log/file' DELIMITER E'\t' CSV; >

Re: [HACKERS] Problem with postgresql database connection in combination with HUAWEI data modem

2011/1/31 Jürgen Wolfsgruber : > Trying to start a telnet-connection, the result was: > > telnet 127.0.0.1 5432 > Trying 127.0.0.1... > telnet: connect to address 127.0.0.1: Operation timed out > telnet: Unable to connect to remote host That's just bizarre. How can you get a network timeout over

[HACKERS] is_absolute_path cleanup

I have applied the attached patch to cleanup coding of the is_absolute_path macro, and added documentation of how 'E:abc' is handled on Win32. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be

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

On Wed, Feb 02, 2011 at 12:10:59PM -0500, Andrew Dunstan wrote: > > On 02/02/2011 11:45 AM, Tim Bunce wrote: > >>But why are we bothering to keep $prolog at > >>all any more, if all we're going to pass it is&PL_sv_no all the > >>time? Maybe we'll have a use for it in the future, but right now we >

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 03, 2011 at 04:31:08PM +0100, Dimitri Fontaine wrote: > "Ross J. Reedstrom" writes: > > Hmm, how about allowing a list of files to execute? That allows the > > Sure. I still don't see why doing it in the control file is better than > in the Makefile, even if it's already better than

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 3, 2011 at 11:25 AM, Ross J. Reedstrom wrote: >> Speaking about which, using Make rules to prepare your upgrade files >> from other pieces means no development at all on the backend side.  You >> can hardly beat that. > > Yes, from the backend-developer's perspective. But not from the

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

=?iso-8859-2?Q?=AEiga_Kranjec?= writes: > This might be a silly idea, but I'm not sure if it was really > discussed with respect to extensions here before... yes, it was ... > Why not use PL/pgSQL as install/upgrade script language, > specially now when it's included in the core by default? "I

Re: [HACKERS] is_absolute_path incorrect on Windows

Bruce Momjian wrote: > > However, it misses the case with for example E:foo, which is a perfectly > > valid path on windows. Which isn't absolute *or* relative - it's relative > > to the current directory on the E: drive. Which will be the same as the > > current directory for the process *if* the

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On Feb 3, 2011, at 4:23 AM, Alexey Klyukin wrote: >> - Making the conversion lazy would be a big help. > > Converting it to string is already lazy, and, per the argumens above, I don't > see a real benefit of lazy conversion to the perl reference (as comparing to > the hurdles of implementing tha

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: >> Yes, from the backend-developer's perspective. But not from the >> extension-developer's perspective :-) And seriously, make is one of >> those things that is supremely capable of doing lots of stuff, but is so >> difficult to use correctly that everyone keeps reinventing ne

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb3, 2011, at 16:31 , Dimitri Fontaine wrote: > "Ross J. Reedstrom" writes: >> Hmm, how about allowing a list of files to execute? That allows the > > Sure. I still don't see why doing it in the control file is better than > in the Makefile, even if it's already better than in the SQL script

Re: [HACKERS] LIKE, CHAR(), and trailing spaces

Kenneth Marshall writes: > On Wed, Feb 02, 2011 at 07:48:38PM -0500, Bruce Momjian wrote: >>> It seems LIKE is considering the trailing CHAR(10) field spaces as >>> significant, even though our documentations says: > +10 for leaving the behavior as is. Yeah, we've been around on this before if m

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 3, 2011 at 11:53 AM, Dimitri Fontaine wrote: > Robert Haas writes: >>> Yes, from the backend-developer's perspective. But not from the >>> extension-developer's perspective :-) And seriously, make is one of >>> those things that is supremely capable of doing lots of stuff, but is so >

Re: [HACKERS] is_absolute_path incorrect on Windows

Bruce Momjian writes: > I have reviewed is_absolute_path() and have implemented > path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on > Win32; patch attached. This patch appears to remove some security-critical restrictions. Why did you delete the path_contains_parent_refere

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Florian Pflug writes: > I fully agree. The extension infrastructure should provide basic support > for upgrades, not every kind of bell and whistle one could possible think of. Maybe somewhere around here we should stop and ask why we are bothering with any of this. The original idea for an exte

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 3, 2011, at 9:38 AM, Tom Lane wrote: > Given that pg_upgrade is now considered a supported piece of the system, > ISTM that most real-world upgrade scenarios will be accomplished with > pg_upgrade relying on provision (3). It looks to me like we're talking > about adding a large amount of

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 3, 2011 at 12:38 PM, Tom Lane wrote: > Florian Pflug writes: >> I fully agree. The extension infrastructure should provide basic support >> for upgrades, not every kind of bell and whistle one could possible think of. > > Maybe somewhere around here we should stop and ask why we are b

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On Thu, Feb 03, 2011 at 02:23:32PM +0200, Alexey Klyukin wrote: > Hi, > > On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote: > > > I'm sorry I'm late to this party. I haven't been keeping up with > > pgsql-hackers. > > Better late than never :) > > > I'd kind'a hoped that this functionality could be

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 3, 2011, at 9:54 AM, Robert Haas wrote: > I think you can pretty much take it to the bank that there will be > demand. This is an important, real-world problem. > > That having been said, I'm not 100% convinced that the main extensions > patch is ready for prime-time, and I'm even less co

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

"David E. Wheeler" writes: > I think we will need to come back to it before, long, however, because many > extensions are released far more often than major versions of PostgreSQL. So > while one might run pg_upgrade, at most, about once every 12-18 months, they > will often want to take advant

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 3, 2011, at 10:07 AM, Tom Lane wrote: > Well, pg_upgrade is designed to work within a major-version series, eg > you could do a 9.1-to-9.1 upgrade if you needed to install a newer > version of an extension. Admittedly, this is swinging a rather larger > hammer than "apply an upgrade script

Re: [HACKERS] is_absolute_path incorrect on Windows

Tom Lane wrote: > Bruce Momjian writes: > > I have reviewed is_absolute_path() and have implemented > > path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on > > Win32; patch attached. > > This patch appears to remove some security-critical restrictions. > Why did you delete t

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On 02/03/2011 01:01 PM, Tim Bunce wrote: Imagine that PL/Perl could handle named arguments: CREATE FUNCTION join_list( separator text, list array ) AS $$ return join( $separator, @$list ); $$ LANGUAGE plperl; The $list variable, magically created by PL/Perl, could be the a

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Tom Lane writes: > Maybe somewhere around here we should stop and ask why we are bothering > with any of this. The original idea for an extension concept was that > (1) some collection of objects could be designated as a module > (2) pg_dump would be taught to dump "LOAD MODULE foo" instead of th

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On tor, 2011-02-03 at 18:01 +, Tim Bunce wrote: > Imagine that PL/Perl could handle named arguments: > > CREATE FUNCTION join_list( separator text, list array ) AS $$ > return join( $separator, @$list ); > $$ LANGUAGE plperl; > > The $list variable, magically created by PL/Per

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Tom Lane writes: > Now having said that, it does occur to me that there is an upgrade-ish > scenario that every user is going to hit immediately, which is how to > get from an existing installation with a pile of "loose" objects created > by one or more contrib modules to a state where those objec

Re: [HACKERS] is_absolute_path incorrect on Windows

Bruce Momjian writes: > Tom Lane wrote: >> Bruce Momjian writes: >>> I have reviewed is_absolute_path() and have implemented >>> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on >>> Win32; patch attached. >> >> This patch appears to remove some security-critical restrict

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 3, 2011 at 1:10 PM, David E. Wheeler wrote: > On Feb 3, 2011, at 10:07 AM, Tom Lane wrote: > >> Well, pg_upgrade is designed to work within a major-version series, eg >> you could do a 9.1-to-9.1 upgrade if you needed to install a newer >> version of an extension.  Admittedly, this is

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Robert Haas writes: > On Thu, Feb 3, 2011 at 1:10 PM, David E. Wheeler wrote: >> On Feb 3, 2011, at 10:07 AM, Tom Lane wrote: >>> Well, pg_upgrade is designed to work within a major-version series, eg >>> you could do a 9.1-to-9.1 upgrade if you needed to install a newer >>> version of an extensi

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 3, 2011, at 11:02 AM, Tom Lane wrote: >> That's putting it mildly. It's more like sending a rocket into outer >> space to tweak the orbit of a comet so that it crashes into your >> barbecue grill to light a fire so you can roast marshmallows. LOL. > No, it's more like using a sledgehamme

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Thu, Feb 3, 2011 at 2:02 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 3, 2011 at 1:10 PM, David E. Wheeler >> wrote: >>> On Feb 3, 2011, at 10:07 AM, Tom Lane wrote: Well, pg_upgrade is designed to work within a major-version series, eg you could do a 9.1-to-9.1 upgrade

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

All, Let me summarize the prospective solutions based on some chatting with some potential extension authors (that is, folks who maintain in-house stuff they're thinking of offering as extensions). Especially since I think at this point the majority of -hackers has lost track of the argument: (A

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Josh Berkus writes: > Let me summarize the prospective solutions based on some chatting with > some potential extension authors (that is, folks who maintain in-house > stuff they're thinking of offering as extensions). Especially since I > think at this point the majority of -hackers has lost tra

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On Thu, Feb 3, 2011 at 05:23, Alexey Klyukin wrote: > Hi, > > On Feb 2, 2011, at 7:16 PM, Tim Bunce wrote: > [...] >> Some observations on the current code (based on a quick skim): >> >> - I'd like to see the conversion function exposed as a builtin >>    $ref = decode_array_literal("{...}"); > >

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

> Well if you want to support upgrades between each two versions, that > means you have users and you don't know what they currently have > installed. Then you have this problem to solve, and it's complex the > same no matter what tools are offered. How *are* we detecting which version is instal

Re: [HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

Dne 30.1.2011 23:22, Robert Haas napsal(a): > On Thu, Dec 23, 2010 at 2:41 PM, Tomas Vondra wrote: OK, so here goes the simplified patch - it tracks one reset timestamp for a background writer and for each database. >>> >>> I think you forgot the attachment. >> >> Yes, I did. Thanks! >

Re: [HACKERS] Spread checkpoint sync

On Sat, Jan 15, 2011 at 05:47:24AM -0500, Greg Smith wrote: > For example, the pre-release Squeeze numbers we're seeing are awful so > far, but it's not really done yet either. Unfortunately, it does not look like Debian squeeze will change any more (or has changed much since your post) at this p

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

Josh Berkus writes: > (D) Requires a series of ordered upgrade scripts in sortable version > numbering, each of which gets applied in order between the two versions. > This initially seems like the most attractive option -- and is the one > used by dozens of popular open source web applications -

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

On Feb 3, 2011, at 11:35 AM, Josh Berkus wrote: > (D) Requires a series of ordered upgrade scripts in sortable version > numbering, each of which gets applied in order between the two versions. > This initially seems like the most attractive option -- and is the one > used by dozens of popular ope

Re: [HACKERS] ALTER EXTENSION UPGRADE, v3

> FWIW, I think that last objection is bogus. There's no reason that an > extension author can't leave dummy C functions in his code to support > obsolete CREATE FUNCTION calls. (As an example, I added one to > Alexander Korotkov's recent pg_trgm patch. It consists of 10 lines of > boilerplate

Re: [HACKERS] Per-column collation, the finale

On Thu, Feb 03, 2011 at 05:53:28PM +0200, Peter Eisentraut wrote: > On tor, 2011-02-03 at 00:10 -0500, Noah Misch wrote: > > > This is good stuff. I'll send you a new patch in a day or three for > > > perhaps another round of performance tests. Some of the other > > issues > > > above can perhaps

[HACKERS] exposing COPY API

Revisiting this, it occurred to me that I could achieve what I need of we extend the proposed API a bit. Currently, it has: extern CopyState BeginCopyFrom(Relation rel, const char *filename, List *attnamelist, List *options); I'd like to be able to add a

Re: [HACKERS] arrays as pl/perl input arguments [PATCH]

On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin wrote: > I've looked at the patch and added a test for arrays exceeding or equal > maximum dimensions to check, whether the recursive function won't bring > surprises there. I've also added check_stack_depth calls to both split_array > and plperl_ha

Re: [HACKERS] exposing COPY API

On Fri, Feb 4, 2011 at 09:48, Andrew Dunstan wrote: > I'd like to be able to add a callback function to construct the values for > the tuple. So it would become something like: >   typedef void (*copy_make_values) (CopyState cstate, NumFieldsRead int); You can do nothing interesting in the callba

Re: [HACKERS] exposing COPY API

Of course, I want this so I could construct a text array from the read in data, but I could also imagine a foreign data wrapper wanting to mangle the data before handing it to postgres, say by filling in a field or hashing it. Could you explain the actual use-cases and examples? I think we ne

Re: [HACKERS] keeping a timestamp of the last stats reset (for a db, table and function)

Thinking I should start with why I think this patch is neat...most of the servers I deal with are up 24x7 minus small amounts of downtime, presuming everyone does their job right that is. In that environment, having a starting timestamp for when the last stats reset happened lets you quickly c

Re: [HACKERS] exposing COPY API

On Fri, Feb 4, 2011 at 11:32, Andrew Dunstan wrote: > Umm, where? I can't find this in the documentation > Here: http://pgbulkload.projects.postgresql.org/pg_bulkload.html#filter > The object, as I have explained previously, is to have

Re: [HACKERS] exposing COPY API

On 02/03/2011 09:43 PM, Itagaki Takahiro wrote: On Fri, Feb 4, 2011 at 11:32, Andrew Dunstan wrote: Umm, where? I can't find this in the documentation Here: http://pgbulkload.projects.postgresql.org/pg_bulkload.html#filter The ob

Re: [HACKERS] [PERFORM] pgbench to the MAXINT

Robert Haas wrote: At least in my book, we need to get this committed in the next two weeks, or wait for 9.2. Yes, I was just suggesting that I was not going to get started in the first week or two given the other pgbench related tests I had queued up already. Those are closing up nicely,

Re: [HACKERS] autogenerating error code lists (was Re: [COMMITTERS] pgsql: Add foreign data wrapper error code values for SQL/MED.)

On Sun, Jan 30, 2011 at 6:27 PM, Tom Lane wrote: > I wrote: >> Just in a quick read-through of the patches, the only things I noticed > > Oh, a third thing: the patch places errcodes.txt under src/include, > which does not seem even approximately right.  src/backend/utils > seems like a saner plac

Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support

On Sun, Jan 30, 2011 at 3:26 PM, Magnus Hagander wrote: >> Magnus, are you planning to get this committed for 9.1? > > I'd like to, but I'm not sure I'll have the time. Per the comment from > Brar it was intended as an initial attempt not quite ready yet, so > it's not something we should hold up

Re: [HACKERS] exposing COPY API

On Fri, Feb 4, 2011 at 12:17, Andrew Dunstan wrote: >> http://pgbulkload.projects.postgresql.org/pg_bulkload.html#filter > AFAICT, this doesn't support ragged tables with too many columns, which is > my prime use case. If it supported variadic arguments in filter functions it > might come closer.

Re: [HACKERS] We need to log aborted autovacuums

On Sun, Jan 30, 2011 at 10:26 PM, Robert Haas wrote: > On Sun, Jan 30, 2011 at 10:03 PM, Alvaro Herrera > wrote: >> Excerpts from Robert Haas's message of dom ene 30 23:37:51 -0300 2011: >> >>> Unless I'm missing something, making autovacuum.c call >>> ConditionalLockRelationOid() is not going to

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

On Fri, Jan 14, 2011 at 6:15 AM, Simon Riggs wrote: > Patch to implement the proposed feature attached, for CFJan2011. > > 2 sub-command changes: > > ALTER TABLE foo ADD FOREIGN KEY fkoo ... NOT VALID; > > ALTER TABLE foo VALIDATE CONSTRAINT fkoo; This patch, which seems to be the latest version,

[HACKERS] Compilation failed

Hi, When I run "git pull" from the git master and "make", I encountered the following compilation error. gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -g -I../../src/port -I../../src/include -D_GNU_SOUR

Re: [HACKERS] Compilation failed

On Thu, Feb 3, 2011 at 11:02 PM, Fujii Masao wrote: > Hi, > > When I run "git pull" from the git master and "make", I encountered > the following compilation error. > > gcc -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -Wformat-security > -fno-strict-ali

Re: [HACKERS] pg_dump directory archive format / parallel pg_dump

On Wed, Feb 2, 2011 at 13:32, Joachim Wieland wrote: > Here is a rebased version with some minor changes as well. I read the patch works as below. Am I understanding correctly? 1. Open all connections in a parent process. 2. Start transactions for each connection in the parent. 3. Spawn chi

Re: [HACKERS] Compilation failed

On Thu, Feb 3, 2011 at 11:42 PM, Robert Haas wrote: > On Thu, Feb 3, 2011 at 11:02 PM, Fujii Masao wrote: >> Hi, >> >> When I run "git pull" from the git master and "make", I encountered >> the following compilation error. >> >> gcc -Wall -Wmissing-prototypes -Wpointer-arith >> -Wdeclaration-afte

Re: [HACKERS] Compilation failed

On Fri, Feb 4, 2011 at 12:11 AM, Robert Haas wrote: > On Thu, Feb 3, 2011 at 11:42 PM, Robert Haas wrote: >> On Thu, Feb 3, 2011 at 11:02 PM, Fujii Masao wrote: >>> Hi, >>> >>> When I run "git pull" from the git master and "make", I encountered >>> the following compilation error. >>> >>> gcc -W

Re: [HACKERS] Add ENCODING option to COPY

On Tue, Feb 1, 2011 at 13:08, Hitoshi Harada wrote: >> The third patch is attached, modifying mb routines so that they can >> receive conversion procedures as FmgrInof * and save the function >> pointer in CopyState. >> I tested it with encoding option and could not see performance slowdown. > Hmm

Re: [HACKERS] exposing COPY API

On 02/03/2011 10:43 PM, Itagaki Takahiro wrote: Also, a FDW allows the COPY to be used as a FROM target, giving it great flexibility. AFAICT this does not. BTW, which do you want to improve, FDW or COPY FROM? If FDW, the better API would be "raw" version of NextCopyFrom(). For example: b