Re: [HACKERS] Some whitespaces in utility.c

On Tue, Sep 4, 2012 at 6:57 AM, Michael Paquier wrote: > Hi all, > > I found some whitespace characters in utility.c introduced by commit > 3a0e4d3. > Please find attached a patch fixing that which can be applied on postgres > master (commit 2f0c7d5). That probably exists in many other places in

[HACKERS] txid failed epoch increment, again, aka 6291

It seems like this has reproduced once more. And once again, there doesn't appear to be any funny business in pg_control (but the structs are pasted here for your re-check), and there are successful sensical updates to it. The primary is running 9.0.6. However, we do have a new piece of data: th

[HACKERS] Minor document updates

I noticed the syntax of the \copy command in the psql reference page is an old style. ISTM it's better to update the document. Please find attached a patch. Thanks, Best regards, Etsuro Fujita psql-copy-ref.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

Heikki Linnakangas writes: > Hmm, I was thinking that when walsender gets the position it can send the > WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the current > recovery timeline. If it has changed, refuse to send the new WAL and > terminate. That would be a fairly small cha

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Tuesday, September 04, 2012 11:00 AM Andres Freund wrote: On Tuesday, September 04, 2012 06:20:59 AM Tom Lane wrote: > Andres Freund writes: >> > I can see why that would be nice, but is it really realistic? Don't we >> > expect some more diligence in applications using this against letting >>

Re: [HACKERS] Multiple setup steps for isolation tests

> Tom Lane wrote: > "Kevin Grittner" writes: >>> Tom Lane wrote: >>> The grammar changes look wrong: I think you eliminated the >>> ability to have zero setup steps, no? Instead, setup_list should >>> expand to either empty or "setup_list setup". > >> I tried that first, but had shift/reduce con

Re: [HACKERS] index-only scans versus serializable transactions

Tom Lane wrote: > "Kevin Grittner" writes: >> By not visiting the heap page for tuples, index-only scans fail to >> acquire all of the necessary predicate locks for correct behavior >> at the serializable transaction isolation level. The tag for the >> tuple-level predicate locks includes the xmi

[HACKERS] 9.2rc1 produces incorrect results

Hello. It took me a while to get a version of this that was independent of my data, but here it is. I don't understand what's going wrong but if you change any part of this query (or at least any part I tried), the correct result is returned. This script will reproduce it: = create table t

Re: [HACKERS] [COMMITTERS] pgsql: Make a cut at a major-features list for 9.2.

On Mon, Sep 3, 2012 at 6:11 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Aug 22, 2012 at 11:58 PM, Tom Lane wrote: >>> Make a cut at a major-features list for 9.2. >>> >>> This is open to debate of course, but it's past time we had *something* >>> here. > >> We have cascading replica

Re: [HACKERS] pg_dump incorrect output in plaintext mode

On Fri, Aug 31, 2012 at 2:05 PM, Magnus Hagander wrote: > > On Aug 28, 2012 9:59 PM, "Tom Lane" wrote: >> >> Magnus Hagander writes: >> > On Tue, Aug 28, 2012 at 6:42 PM, Tom Lane wrote: >> >> I don't see anything particularly incorrect about that. The point of >> >> the --verbose switch is to

[HACKERS] pg_upgrade docs

This doc sentence about pg_upgrade is now inaccurate: If doing --check with a running old server of a pre-9.1 version, and the old server is using a Unix-domain socket directory that is different from the default built into the new PostgreSQL installation, set PGHOST to point to the so

Re: [HACKERS] [WIP PATCH] for Performance Improvement in Buffer Management

On Tuesday, September 04, 2012 12:42 AM Jeff Janes wrote: On Mon, Sep 3, 2012 at 7:15 AM, Amit kapila wrote: >> This patch is based on below Todo Item: > >> Consider adding buffers the background writer finds reusable to the free >> list > > > >> I have tried implementing it and taken the readings

Re: [HACKERS] Statistics and selectivity estimation for ranges

On Mon, Aug 27, 2012 at 5:00 PM, Heikki Linnakangas < heikki.linnakan...@enterprisedb.com> wrote: > On 24.08.2012 18:51, Heikki Linnakangas wrote: > >> On 20.08.2012 00:31, Alexander Korotkov wrote: >> >>> New version of patch. >>> * Collect new stakind STATISTIC_KIND_BOUNDS_**HISTOGRAM, which is

Re: [HACKERS] SP-GiST for ranges based on 2d-mapping and quad-tree

On Mon, Aug 20, 2012 at 12:25 AM, Jeff Davis wrote: > I am taking a look at this patch now. A few quick comments: > > * It looks like bounds_adjacent modifies it's by-reference arguments, > which is a little worrying to me. The lower/upper labels are flipped > back, but the inclusivities are not.

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On Mon, Sep 3, 2012 at 12:44:09PM -0400, Andrew Dunstan wrote: > The attached very small patch allows pg_upgrade's "make check" to > succeed on REL9_2_STABLE on my Mingw system. > > However, I consider the issue I mentioned earlier regarding use of > forward slashes in the argument to rmdir to be

Re: [HACKERS] pg_dump incorrect output in plaintext mode

On Tue, Sep 4, 2012 at 3:51 PM, Tom Lane wrote: > Magnus Hagander writes: >>> On Aug 28, 2012 9:59 PM, "Tom Lane" wrote: Well, why don't we just s/restoring/processing/ in the debug message, and call it good? > >> Are we "allowed" to backpatch things to 9.2 at this point that changes >

Re: [HACKERS] pg_dump incorrect output in plaintext mode

Magnus Hagander writes: >> On Aug 28, 2012 9:59 PM, "Tom Lane" wrote: >>> Well, why don't we just s/restoring/processing/ in the debug message, >>> and call it good? > Are we "allowed" to backpatch things to 9.2 at this point that changes > strings for translators? Well, not being a translator

Re: [HACKERS] Some whitespaces in utility.c

Magnus Hagander writes: > On Tue, Sep 4, 2012 at 6:57 AM, Michael Paquier > wrote: >> I found some whitespace characters in utility.c introduced by commit >> 3a0e4d3. >> Please find attached a patch fixing that which can be applied on postgres >> master (commit 2f0c7d5). > That probably exists i

Re: [HACKERS] pg_upgrade del/rmdir path fix

Excerpts from Andrew Dunstan's message of mar sep 04 01:16:39 -0300 2012: > And here's the first Windows buildfarm check of pg_upgrade. > Great, thanks. Who's going to work now on p

Re: [HACKERS] pg_upgrade del/rmdir path fix

On Tue, Sep 4, 2012 at 11:42:58AM -0300, Alvaro Herrera wrote: > Excerpts from Andrew Dunstan's message of mar sep 04 01:16:39 -0300 2012: > > > And here's the first Windows buildfarm check of pg_upgrade. > >

Re: [HACKERS] 9.2rc1 produces incorrect results

Vik Reykja writes: > Hello. It took me a while to get a version of this that was independent of > my data, but here it is. I don't understand what's going wrong but if you > change any part of this query (or at least any part I tried), the correct > result is returned. Huh. 9.1 gets the wrong

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/04/2012 10:42 AM, Alvaro Herrera wrote: Excerpts from Andrew Dunstan's message of mar sep 04 01:16:39 -0300 2012: And here's the first Windows buildfarm check of pg_upgrade.

Re: [HACKERS] txid failed epoch increment, again, aka 6291

On Tue, Sep 04, 2012 at 02:07:30AM -0700, Daniel Farina wrote: > It seems like this has reproduced once more. And once again, there > doesn't appear to be any funny business in pg_control (but the structs > are pasted here for your re-check), and there are successful sensical > updates to it. The

Re: [HACKERS] Wiki link for max_connections? (Fwd: Re: [ADMIN] PostgreSQL oom_adj postmaster process to -17)

Robert Haas wrote: > Kevin Grittner wrote: >>> Also, I am a bit doubtful about the advice on sizing the >>> connection pool as applied to small servers: >>> surely it's not sane to recommend that a single-processor system >>> with one disk should have max_connections = 3. At least, *I* >>> don

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On 09/04/2012 09:47 AM, Bruce Momjian wrote: On Mon, Sep 3, 2012 at 12:44:09PM -0400, Andrew Dunstan wrote: The attached very small patch allows pg_upgrade's "make check" to succeed on REL9_2_STABLE on my Mingw system. However, I consider the issue I mentioned earlier regarding use of forward

Re: [HACKERS] pg_upgrade del/rmdir path fix

Bruce Momjian writes: > On Tue, Sep 4, 2012 at 11:42:58AM -0300, Alvaro Herrera wrote: >> Who's going to work now on porting the shell script to Perl? ;-) > Well, we require Perl for development, but not for usage, at least not > yet. This is a regression-test script, so that complaint doesn't

Re: [HACKERS] pg_upgrade del/rmdir path fix

On Tue, Sep 4, 2012 at 11:12:52AM -0400, Andrew Dunstan wrote: > > On 09/04/2012 10:49 AM, Bruce Momjian wrote: > >On Tue, Sep 4, 2012 at 11:42:58AM -0300, Alvaro Herrera wrote: > >>Excerpts from Andrew Dunstan's message of mar sep 04 01:16:39 -0300 2012: > >> > >>>And here's the first Windows b

Re: [HACKERS] pg_upgrade del/rmdir path fix

Andrew Dunstan writes: > This is a test script, not what you should use in production. I don't > see any reason why we shouldn't require Perl for running the standard test. But on the third hand ... we've taken pains to ensure that you don't *have* to have Perl to build from a tarball, and I thi

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/04/2012 10:49 AM, Bruce Momjian wrote: On Tue, Sep 4, 2012 at 11:42:58AM -0300, Alvaro Herrera wrote: Excerpts from Andrew Dunstan's message of mar sep 04 01:16:39 -0300 2012: And here's the first Windows buildfarm check of pg_upgrade.

Re: [HACKERS] gistchoose vs. bloat

On Mon, Aug 20, 2012 at 9:13 PM, Alexander Korotkov wrote: > Current gistchoose code has a bug. I've started separate thread about it. > http://archives.postgresql.org/pgsql-hackers/2012-08/msg00544.php > Also, it obviously needs more comments. > > Current state of patch is more proof of concept t

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/04/2012 11:21 AM, Tom Lane wrote: Andrew Dunstan writes: This is a test script, not what you should use in production. I don't see any reason why we shouldn't require Perl for running the standard test. But on the third hand ... we've taken pains to ensure that you don't *have* to have

Re: [HACKERS] txid failed epoch increment, again, aka 6291

On Tue, Sep 4, 2012 at 8:04 AM, Noah Misch wrote: > On Tue, Sep 04, 2012 at 02:07:30AM -0700, Daniel Farina wrote: >> It seems like this has reproduced once more. And once again, there >> doesn't appear to be any funny business in pg_control (but the structs >> are pasted here for your re-check),

Re: [HACKERS] Yet another issue with pg_upgrade vs unix_socket_directories

On 9/3/12 5:00 PM, Tom Lane wrote: > I went back for another try at building the Fedora packages with 9.2 > branch tip ... and it still failed at pg_upgrade's "make check". > The reason for this is that test.sh starts a couple of random > postmasters, and those postmasters expect to put their socke

Re: [HACKERS] Yet another issue with pg_upgrade vs unix_socket_directories

On Tue, Sep 4, 2012 at 01:44:59PM -0400, Peter Eisentraut wrote: > On 9/3/12 5:00 PM, Tom Lane wrote: > > I went back for another try at building the Fedora packages with 9.2 > > branch tip ... and it still failed at pg_upgrade's "make check". > > The reason for this is that test.sh starts a coupl

Re: [HACKERS] Yet another issue with pg_upgrade vs unix_socket_directories

Peter Eisentraut writes: > Yeah, I have resorted to putting something like > export PGHOST=/tmp > in all my test scripts, because the above-mentioned issues have affected > Debian for a long time. Welcome to the party. ;-) Yeah, my current patch for Fedora does exactly that in pg_regress, and ha

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/04/2012 10:42 AM, Alvaro Herrera wrote: Somehow the verbose reporting of user relation files being copied does not seem exceedingly useful; and I don't remember seeing that on Linux. Yeah, and it does something odd anyway when it's not writing to a terminal. Can we get rid of it, or

Re: [HACKERS] 9.2rc1 produces incorrect results

I wrote: > Vik Reykja writes: >> Hello. It took me a while to get a version of this that was independent of >> my data, but here it is. I don't understand what's going wrong but if you >> change any part of this query (or at least any part I tried), the correct >> result is returned. > Huh. 9.

Re: [HACKERS] [PATCH] XLogReader v2

Excerpts from Andres Freund's message of jue jul 19 06:29:03 -0400 2012: > Hi, > > Attached is v2 of the patch. Hello, I gave this code a quick read some days ago. Here's the stuff I would change: * There are way too many #ifdef VERBOSE_DEBUG stuff for my taste. It might look better if you ha

Re: [HACKERS] pg_upgrade diffs on WIndows

On 09/04/2012 03:09 PM, Andrew Dunstan wrote: I realized this morning that I might have been a bit cavalier in using dos2unix to smooth away differences in the dumpfiles produced by pg_upgrade. Attached is a dump of the diff if this isn't done, with Carriage Returns printed as '*' to make the

Re: [HACKERS] build farm machine using mixed results

Excerpts from Robert Creager's message of sáb sep 01 12:12:51 -0400 2012: > > I change the build-farm.conf file to have the following make line: > > make => 'make -j 8', # or gmake if required. can include path if > necessary. > > 2 pass, 4 fail. Is this a build configuration you want to p

Re: [HACKERS] build farm machine using mixed results

On 9/1/12 12:12 PM, Robert Creager wrote: > > I change the build-farm.conf file to have the following make line: > > make => 'make -j 8', # or gmake if required. can include path if > necessary. > > 2 pass, 4 fail. Is this a build configuration you want to pursue? Sure that would be useful

Re: [HACKERS] embedded list v2

Excerpts from Andres Freund's message of jue jun 28 17:06:49 -0400 2012: > On Thursday, June 28, 2012 10:03:26 PM Andres Freund wrote: > > What I wonder is how hard it would be to remove catcache.h's structs into > > the implementation. Thats the reason why the old and new list > > implementation

Re: [HACKERS] build farm machine using mixed results

Excerpts from Peter Eisentraut's message of mar sep 04 18:49:46 -0300 2012: > On 9/1/12 12:12 PM, Robert Creager wrote: > > > > I change the build-farm.conf file to have the following make line: > > > > make => 'make -j 8', # or gmake if required. can include path if > > necessary. > > > > 2

Re: [HACKERS] build farm machine using mixed results

On 09/04/2012 05:49 PM, Peter Eisentraut wrote: On 9/1/12 12:12 PM, Robert Creager wrote: I change the build-farm.conf file to have the following make line: make => 'make -j 8', # or gmake if required. can include path if necessary. 2 pass, 4 fail. Is this a build configuration you want

Re: [HACKERS] too much pgbench init output

On 9/1/12 6:30 AM, Robert Haas wrote: > On Sat, Sep 1, 2012 at 12:00 AM, Peter Eisentraut wrote: >> When initializing a large database, pgbench writes tons of "%d tuples >> done" lines. I propose to change this to a sort of progress counter >> that stays on the same line, as in the attached patch

Re: [HACKERS] Some whitespaces in utility.c

On Tue, Sep 4, 2012 at 11:35 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Tue, Sep 4, 2012 at 6:57 AM, Michael Paquier > > wrote: > >> I found some whitespace characters in utility.c introduced by commit > >> 3a0e4d3. > >> Please find attached a patch fixing that which can be applied on

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

Guys, Is this a patch to 9.3? i.e. do we need to delay the release for this? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hacker

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On 04.09.2012 03:02, Dimitri Fontaine wrote: Heikki Linnakangas writes: Hmm, I was thinking that when walsender gets the position it can send the WAL up to, in GetStandbyFlushRecPtr(), it could atomically check the current recovery timeline. If it has changed, refuse to send the new WAL and ter

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On 04.09.2012 15:41, Josh Berkus wrote: Guys, Is this a patch to 9.3? i.e. do we need to delay the release for this? It is for 9.2. I'll do a little bit more testing, and barring any issues, commit the patch. What exactly is the schedule? Do we need to do a RC2 because of this? - Heikki

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

Heikki, > It is for 9.2. I'll do a little bit more testing, and barring any > issues, commit the patch. What exactly is the schedule? Do we need to do > a RC2 because of this? We're currently scheduled to release next week. If we need to do an RC2, we're going to have to do some fast reschedulin

Re: [HACKERS] build farm machine using mixed results

On Sep 4, 2012 6:06 PM, "Andrew Dunstan" wrote: > > > Frankly, I have had enough failures of parallel make that I think doing this would generate a significant number of non-repeatable failures (I had one just the other day that took three invocations of make to get right). So I'm not sure doing t

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

Josh Berkus writes: > Heikki, >> It is for 9.2. I'll do a little bit more testing, and barring any >> issues, commit the patch. What exactly is the schedule? Do we need to do >> a RC2 because of this? > We're currently scheduled to release next week. If we need to do an > RC2, we're going to hav

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On 03.09.2012 17:40, Heikki Linnakangas wrote: On 03.09.2012 16:26, Heikki Linnakangas wrote: On 03.09.2012 16:25, Fujii Masao wrote: On Tue, Sep 4, 2012 at 7:07 AM, Heikki Linnakangas wrote: Hmm, I was thinking that when walsender gets the position it can send the WAL up to, in GetStandbyFlus

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On 04.09.2012 16:50, Tom Lane wrote: Josh Berkus writes: Heikki, It is for 9.2. I'll do a little bit more testing, and barring any issues, commit the patch. What exactly is the schedule? Do we need to do a RC2 because of this? We're currently scheduled to release next week. If we need to d

Re: [HACKERS] too much pgbench init output

Peter Eisentraut writes: > On 9/1/12 6:30 AM, Robert Haas wrote: >> On Sat, Sep 1, 2012 at 12:00 AM, Peter Eisentraut wrote: >>> When initializing a large database, pgbench writes tons of "%d tuples >>> done" lines. I propose to change this to a sort of progress counter >>> that stays on the sam

Re: [HACKERS] build farm machine using mixed results

Andrew Dunstan writes: > Frankly, I have had enough failures of parallel make that I think doing > this would generate a significant number of non-repeatable failures (I > had one just the other day that took three invocations of make to get > right). So I'm not sure doing this would advance us

Re: [HACKERS] pg_upgrade diffs on WIndows

On 09/04/2012 03:44 PM, Andrew Dunstan wrote: On 09/04/2012 03:09 PM, Andrew Dunstan wrote: I realized this morning that I might have been a bit cavalier in using dos2unix to smooth away differences in the dumpfiles produced by pg_upgrade. Attached is a dump of the diff if this isn't done,

Re: [HACKERS] build farm machine using mixed results

On 09/04/2012 08:37 PM, Tom Lane wrote: Andrew Dunstan writes: Frankly, I have had enough failures of parallel make that I think doing this would generate a significant number of non-repeatable failures (I had one just the other day that took three invocations of make to get right). So I'm not

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/04/2012 02:25 PM, Andrew Dunstan wrote: On 09/04/2012 10:42 AM, Alvaro Herrera wrote: Somehow the verbose reporting of user relation files being copied does not seem exceedingly useful; and I don't remember seeing that on Linux. Yeah, and it does something odd anyway when it's not

Re: [HACKERS] pg_upgrade diffs on WIndows

On Tue, Sep 4, 2012 at 08:46:53PM -0400, Andrew Dunstan wrote: > > On 09/04/2012 03:44 PM, Andrew Dunstan wrote: > > > >On 09/04/2012 03:09 PM, Andrew Dunstan wrote: > >>I realized this morning that I might have been a bit cavalier in > >>using dos2unix to smooth away differences in the dumpfiles

Re: [HACKERS] Multiple setup steps for isolation tests

"Kevin Grittner" wrote: > Tom Lane wrote: >> the attached version works fine for me. > > Yeah, that should do it. Will apply. Pushed to master and REL9_2_STABLE. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://ww

Re: [HACKERS] index-only scans versus serializable transactions

"Kevin Grittner" wrote: > New version attached. Will apply if no further problems are found. Pushed to master and REL9_2_STABLE. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hack

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On 04.09.2012 17:34, Heikki Linnakangas wrote: On 04.09.2012 16:50, Tom Lane wrote: Josh Berkus writes: Heikki, It is for 9.2. I'll do a little bit more testing, and barring any issues, commit the patch. What exactly is the schedule? Do we need to do a RC2 because of this? We're currently s

Re: [HACKERS] too much pgbench init output

On Tue, Sep 4, 2012 at 8:35 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 9/1/12 6:30 AM, Robert Haas wrote: >>> On Sat, Sep 1, 2012 at 12:00 AM, Peter Eisentraut wrote: When initializing a large database, pgbench writes tons of "%d tuples done" lines. I propose to change this

Re: [HACKERS] Wiki link for max_connections? (Fwd: Re: [ADMIN] PostgreSQL oom_adj postmaster process to -17)

On Tue, Sep 4, 2012 at 11:15 AM, Kevin Grittner wrote: > It is something which has to be considered, and I don't think it's > theoretical at all. Here's how we deal with it. We don't use a > plain FIFO queue for our transaction requests, but a prioritized > FIFO with 10 levels of priority (0 to

Re: [HACKERS] too much pgbench init output

On Tue, 2012-09-04 at 23:14 -0400, Robert Haas wrote: > Actually, this whole things seems like a solution in search of a > problem to me. We just reduced the verbosity of pgbench -i tenfold in > the very recent past - I would have thought that enough to address > this problem. But maybe not. The

Re: [HACKERS] pg_upgrade diffs on WIndows

On Tue, 2012-09-04 at 20:46 -0400, Andrew Dunstan wrote: > OK, nobody else has reacted. I've spoken to Bruce and he seems happy > with it, although, TBH, whe I talked to him I thought I understood it > and now I'm not so sure. So we have 3 possibilities: leave it as is with > an error-hiding hac

Re: [HACKERS] too much pgbench init output

Peter Eisentraut writes: > On Tue, 2012-09-04 at 23:14 -0400, Robert Haas wrote: >> Actually, this whole things seems like a solution in search of a >> problem to me. We just reduced the verbosity of pgbench -i tenfold in >> the very recent past - I would have thought that enough to address >> th

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On Mon, Sep 3, 2012 at 12:44:09PM -0400, Andrew Dunstan wrote: > The attached very small patch allows pg_upgrade's "make check" to > succeed on REL9_2_STABLE on my Mingw system. > > However, I consider the issue I mentioned earlier regarding use of > forward slashes in the argument to rmdir to be

Re: [HACKERS] 9.2rc1 produces incorrect results

I wrote: > I think probably the best fix is to rejigger things so that Params > assigned by different executions of SS_replace_correlation_vars and > createplan.c can't share PARAM_EXEC numbers. This will result in > rather larger ecxt_param_exec_vals arrays at runtime, but the array > entries are

Re: [HACKERS] too much pgbench init output

On Tue, Sep 4, 2012 at 11:31 PM, Peter Eisentraut wrote: > On Tue, 2012-09-04 at 23:14 -0400, Robert Haas wrote: >> Actually, this whole things seems like a solution in search of a >> problem to me. We just reduced the verbosity of pgbench -i tenfold in >> the very recent past - I would have thou

Re: [HACKERS] too much pgbench init output

On Wed, Sep 5, 2012 at 9:47 AM, Robert Haas wrote: > > Actually it'd be nice to even get a bit more output: say, a timestamp > on each line, and a completion percentage... but now I'm getting > greedy. > > May be we need a verbosity level and print a lot less or a lot more information than what w

Re: [HACKERS] pg_upgrade diffs on WIndows

Peter Eisentraut writes: > On Tue, 2012-09-04 at 20:46 -0400, Andrew Dunstan wrote: >> OK, nobody else has reacted. I've spoken to Bruce and he seems happy >> with it, although, TBH, whe I talked to him I thought I understood it >> and now I'm not so sure. So we have 3 possibilities: leave it as

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On Tue, 2012-09-04 at 19:34 -0700, Heikki Linnakangas wrote: > > The attached patch fixes it for me. It fixes the original problem, by > > adding the missing locking and terminating walsenders on a target > > timeline change, and also changes the behavior wrt. WAL segments > > restored from the arc

Re: [HACKERS] Cascading replication and recovery_target_timeline='latest'

On 04.09.2012 21:56, Peter Eisentraut wrote: On Tue, 2012-09-04 at 19:34 -0700, Heikki Linnakangas wrote: The attached patch fixes it for me. It fixes the original problem, by adding the missing locking and terminating walsenders on a target timeline change, and also changes the behavior wrt. WA

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

On Tuesday, September 04, 2012 12:40 AM Tom Lane wrote: Magnus Hagander writes: > On Mon, Sep 3, 2012 at 8:51 PM, Tom Lane wrote: >>> I have another question after thinking about that for awhile: is there >>> any security concern there? On Unix-oid systems, we expect the kernel >>> to restrict w