[HACKERS] Is this non-volatile pointer access OK?

http://doxygen.postgresql.org/xlog_8c_source.html#l08197 On line 8197 of xlog.c: 08194 /* Get a local copy of the last safe checkpoint record. */ 08195 SpinLockAcquire(&xlogctl->info_lck); 08196 lastCheckPointRecPtr = xlogctl->lastCheckPointRecPtr; 08197 memcpy(&lastCheckPoint, &X

Re: [HACKERS] _USE_32BIT_TIME_T Patch

On Sat, Sep 1, 2012 at 1:35 AM, Andrew Dunstan wrote: > > On 08/31/2012 06:39 PM, Tom Lane wrote: >> >> Andrew Dunstan writes: >>> >>> I'm not sure what we need to do to progress on this, especially re the >>> back branches. >> >> The calendar might help us here. 9.2 is due to wrap next week, b

Re: [HACKERS] [GENERAL] Multiple Slave Failover with PITR

On Sun, Sep 2, 2012 at 4:12 PM, Bruce Momjian wrote: > Do we ever want to document a way to connect slaves to a new master, > rather than recreating the slave? I have written an instruction for myself and I am planning to publish it on http://code.google.com/p/pgcookbook/. See the attachment. Ho

[HACKERS] 9.2: Describing a security barrier view in psql

Hi, Unless I'm missing something, it is not possible in psql to tell whether a view has the security_barrier option. I think that this is something that ought to be possible from psql, otherwise the new feature is not visible. This patch displays any reloptions for a view at the end, if \d+ is us

Re: [HACKERS] Is this non-volatile pointer access OK?

On 3 September 2012 08:10, Daniel Farina wrote: > http://doxygen.postgresql.org/xlog_8c_source.html#l08197 > > On line 8197 of xlog.c: > > 08194 /* Get a local copy of the last safe checkpoint record. */ > 08195 SpinLockAcquire(&xlogctl->info_lck); > 08196 lastCheckPointRecPtr = xlogct

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

On Mon, Sep 3, 2012 at 6:42 AM, Tom Lane wrote: > Noah Misch writes: >> Windows does not have socketpair(), nor a strict pipe() equivalent. I expect >> switching to socketpair() makes the Windows side trickier in some ways and >> simpler in others. +1 for exploring that direction first. > > A b

Re: [HACKERS] pg_upgrade bugs

On 09/03/2012 12:00 AM, Tom Lane wrote: Alvaro Herrera writes: Maybe, to reduce future backpatching pain, we could backpatch the change to exec_prog() API now that you have fixed the implementation? I'm inclined to think this is a good idea, but keep in mind we're less than four days from wra

Re: [HACKERS] pg_upgrade test mods for Windows/Mingw

On 09/02/2012 11:53 PM, Gurjeet Singh wrote: On Sun, Sep 2, 2012 at 11:29 PM, Andrew Dunstan > wrote: The attached patch is what I had to do to get pg_upgrade's "make check" to run on Windows under Mingw. Mostly the changes have to do with getting paths r

Re: [HACKERS] [bugfix] sepgsql didn't follow the latest core API changes

Excerpts from Kohei KaiGai's message of dom sep 02 15:53:22 -0300 2012: > This patch fixes a few portions on which sepgsql didn't follow the latest > core API changes. I think you should get a buildfarm animal installed that builds and tests sepgsql, to avoid this kind of problem in the future. -

Re: [HACKERS] 9.2: Describing a security barrier view in psql

Dean Rasheed writes: > Unless I'm missing something, it is not possible in psql to tell > whether a view has the security_barrier option. I think that this is > something that ought to be possible from psql, otherwise the new > feature is not visible. > This patch displays any reloptions for a vi

Re: [HACKERS] 9.2: Describing a security barrier view in psql

On Mon, Sep 3, 2012 at 3:48 PM, Tom Lane wrote: > Dean Rasheed writes: >> Unless I'm missing something, it is not possible in psql to tell >> whether a view has the security_barrier option. I think that this is >> something that ought to be possible from psql, otherwise the new >> feature is not

Re: [HACKERS] Yet another failure mode in pg_upgrade

On Sun, Sep 2, 2012 at 11:47:06PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Updated patch attached. > > [ looks at that for a bit... ] Now I see why you were on about that: > the method you used here requires both clusters to have the same socket > directory. Which is silly and unnece

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

> 5. The fork/exec code is pretty primitive with respect to error handling. > I didn't put much time into it since I'm afraid we may need to refactor it entirely before a Windows equivalent can be > written. (And I need somebody to write/test the Windows equivalent - any volunteers?) I think pa

Re: [HACKERS] pg_upgrade test mods for Windows/Mingw

On 09/03/2012 09:16 AM, Andrew Dunstan wrote: On 09/02/2012 11:53 PM, Gurjeet Singh wrote: On Sun, Sep 2, 2012 at 11:29 PM, Andrew Dunstan > wrote: The attached patch is what I had to do to get pg_upgrade's "make check" to run on Windows under Mingw. Mostly

Re: [HACKERS] 9.2: Describing a security barrier view in psql

On 3 September 2012 14:48, Tom Lane wrote: > Dean Rasheed writes: >> Unless I'm missing something, it is not possible in psql to tell >> whether a view has the security_barrier option. I think that this is >> something that ought to be possible from psql, otherwise the new >> feature is not visib

Re: [HACKERS] Yet another failure mode in pg_upgrade

Bruce Momjian writes: > Also, I don't see my doc addition on your patch; was that intentional? It's not necessary, no? The code now gets socket directory right without help. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To ma

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

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 for Select when all the data is in either OS buffers or Shared Buffers. The Patch has simple implementation for "bgwrit

[HACKERS] Caught up

I spent the month of August going through 1.7k emails I had saved from the previous year that required my attention. I want to thank everyone for helping me close many open items, and for tolerating my questions. Ideally I would have dealt with many of these emails earlier, but time constraints c

Re: [HACKERS] Yet another failure mode in pg_upgrade

On Mon, Sep 3, 2012 at 10:07:43AM -0400, Tom Lane wrote: > Bruce Momjian writes: > > Also, I don't see my doc addition on your patch; was that intentional? > > It's not necessary, no? The code now gets socket directory right > without help. Well, the doc comment is: +If running check on

Re: [HACKERS] Yet another failure mode in pg_upgrade

Bruce Momjian writes: > On Mon, Sep 3, 2012 at 10:07:43AM -0400, Tom Lane wrote: >> It's not necessary, no? The code now gets socket directory right >> without help. > Well, the doc comment is: > +If running check on an old pre-9.1 Unix-like running server, and the > +old and new serve

Re: [HACKERS] Yet another failure mode in pg_upgrade

On Mon, Sep 3, 2012 at 10:42:38AM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Mon, Sep 3, 2012 at 10:07:43AM -0400, Tom Lane wrote: > >> It's not necessary, no? The code now gets socket directory right > >> without help. > > > Well, the doc comment is: > > > +If running check on

Re: [HACKERS] Is this non-volatile pointer access OK?

Peter Geoghegan writes: > On 3 September 2012 08:10, Daniel Farina wrote: >> On line 8197 of xlog.c: >> >> 08194 /* Get a local copy of the last safe checkpoint record. */ >> 08195 SpinLockAcquire(&xlogctl->info_lck); >> 08196 lastCheckPointRecPtr = xlogctl->lastCheckPointRecPtr; >>

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

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. (yes, i've been backlogged) We have cascading replication as a major feature, which I agree it is. But I think we s

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

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 replication as a major feature, which I agree it is. > But I thi

Re: [HACKERS] Yet another failure mode in pg_upgrade

Bruce Momjian writes: > I am working on an additional enhancement that also pulls the live > cluster's port number from the postmaster.pid file. I am attaching the > part of my patch that was modified to add that feature. This allows > live checks without requiring any port numbers to be specifi

Re: [HACKERS] Yet another failure mode in pg_upgrade

On Mon, Sep 3, 2012 at 12:16:04PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I am working on an additional enhancement that also pulls the live > > cluster's port number from the postmaster.pid file. I am attaching the > > part of my patch that was modified to add that feature. This all

[HACKERS] 9.2 pg_upgrade regression tests on WIndows

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 a significant blocker, so I'm going to go and fix that and then pull

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

On Mon, Sep 3, 2012 at 12:11:45PM -0400, 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

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

Andrew Dunstan writes: > 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 a significant blocker, so > I'm going

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

Amit Kapila writes: > I think part of the code for windows can be written by referring function > internal_forkexec(), > If you are okay, I can take up this. Please confirm. Nobody else volunteered, so have at it. Note that I'm planning to redo that code to use socketpair(), so possibly you wan

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

On Mon, Sep 3, 2012 at 7:07 PM, Tom Lane wrote: > Amit Kapila writes: >>> 8. PQcancel needs some work - it can't do what it does now, but it could >>> do kill(conn->postgres_pid, SIGINT) instead. At least in Unix. I have no >>> idea what we'd do in Windows. This doesn't matter for pg_upgrade o

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

On Sat, Sep 1, 2012 at 2:32 AM, Fujii Masao wrote: > On Fri, Aug 31, 2012 at 5:03 PM, Heikki Linnakangas wrote: >> When a cascading standby launches a new walsender, it fetches the current >> recovery timeline: >> >> /* >> * Use the recovery target timeline ID during recovery >>

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

On 09/03/2012 12:58 PM, Tom Lane wrote: Andrew Dunstan writes: 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 a sign

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

Andrew Dunstan writes: > On 09/03/2012 12:58 PM, Tom Lane wrote: >> My intentions over the next hour or two are to commit the >> unix-socket-directory fix and then sync 9.2 pg_upgrade with HEAD >> (ie, back-patch everything that's in HEAD except the int64-XLogRecPtr >> changes). Will that cause a

[HACKERS] pg_upgrade del/rmdir path fix

Here is a patch against 9.2 sources (it applies with offsets to HEAD too) to fix the problem that pg_upgrade can write paths in arguments for Windows builtin commands (specifically DEL and RMDIR) with the wrong path separator style. This should be applied all the way back to 9.0. cheers andre

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

Magnus Hagander writes: > On Mon, Sep 3, 2012 at 7:07 PM, Tom Lane wrote: >> Hmm, after looking at src/port/kill.c it doesn't seem like there's much >> of a problem with doing that. I had had the idea that our kill >> emulation only worked within the backend environment, but of course >> pg_ctl

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

On Mon, Sep 3, 2012 at 8:51 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Mon, Sep 3, 2012 at 7:07 PM, Tom Lane wrote: >>> Hmm, after looking at src/port/kill.c it doesn't seem like there's much >>> of a problem with doing that. I had had the idea that our kill >>> emulation only worked w

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/03/2012 02:30 PM, Andrew Dunstan wrote: Here is a patch against 9.2 sources (it applies with offsets to HEAD too) to fix the problem that pg_upgrade can write paths in arguments for Windows builtin commands (specifically DEL and RMDIR) with the wrong path separator style. This should be

Re: [HACKERS] 9.2 pg_upgrade regression tests on WIndows

I wrote: > Andrew Dunstan writes: >> No, go for it. I can sync up without difficulty. Does that include >> backpatching the exec_prog changes to 9.2? > Yes, nobody objected, so I'll do that too. And done. Please apply the other open fixes to both HEAD and 9.2. Should be easy at this point.

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

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 who can do a kill() on a postgres process. If there's any >

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

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 for Select when all the > data is in either OS buffers > > or

Re: [HACKERS] pg_upgrade del/rmdir path fix

Andrew Dunstan writes: > This time with a patch. Nitpicky gripe: "fix_path" is a mighty generic name. How about "fix_path_for_windows" or something like that? I don't think I'd mark it inline, either. More generally, the behavior of combining two (maybe) filename segments seems overcomplicated

Re: [HACKERS] Multiple setup steps for isolation tests

"Kevin Grittner" writes: > I just today found that the index-only scan feature has broken SSI. > I don't think it will take much to fix, and I'm looking at that, but > the first thing I wanted was a test to show the breakage. Ugh. That sounds like a release-blocker. What's your ETA for a fix?

[HACKERS] Multiple setup steps for isolation tests

I just today found that the index-only scan feature has broken SSI. I don't think it will take much to fix, and I'm looking at that, but the first thing I wanted was a test to show the breakage. I couldn't find a way to do that without running VACUUM after loading data to the test tables, and bec

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/03/2012 03:22 PM, Tom Lane wrote: Andrew Dunstan writes: This time with a patch. Nitpicky gripe: "fix_path" is a mighty generic name. How about "fix_path_for_windows" or something like that? I don't think I'd mark it inline, either. More generally, the behavior of combining two (mayb

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

Noah Misch writes: > On Mon, Sep 03, 2012 at 12:11:20AM -0400, Tom Lane wrote: >> One easy thing we could do that would at least narrow the risks is to >> only allow the executable's *directory* to be specified, hardwiring the >> executable file name to "postgres" (or "postgres.exe" I guess). > I

Re: [HACKERS] pg_upgrade del/rmdir path fix

Andrew Dunstan writes: > OK, revised patch attached. Looks good to me. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

On 09/03/2012 04:23 PM, Tom Lane wrote: I'm reluctantly coming to the conclusion that we can't pass these parameters through the regular libpq connection string mechanism, and will have to invent something else. That's awfully nasty though; it will pretty much cripple the idea that this would b

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

Hi, On Monday, September 03, 2012 10:23:52 PM Tom Lane wrote: > I'm reluctantly coming to the conclusion that we can't pass these > parameters through the regular libpq connection string mechanism, and > will have to invent something else. That's awfully nasty though; > it will pretty much crippl

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

Andrew Dunstan writes: > On 09/03/2012 04:23 PM, Tom Lane wrote: >> I'm reluctantly coming to the conclusion that we can't pass these >> parameters through the regular libpq connection string mechanism, and >> will have to invent something else. That's awfully nasty though; >> it will pretty much

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

Andres Freund writes: > On Monday, September 03, 2012 10:23:52 PM Tom Lane wrote: >> I'm reluctantly coming to the conclusion that we can't pass these >> parameters through the regular libpq connection string mechanism, and >> will have to invent something else. That's awfully nasty though; >> it

[HACKERS] Yet another issue with pg_upgrade vs unix_socket_directories

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 sockets in the configured default location (whic

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

On Monday, September 03, 2012 10:54:23 PM Tom Lane wrote: > Andres Freund writes: > > On Monday, September 03, 2012 10:23:52 PM Tom Lane wrote: > >> I'm reluctantly coming to the conclusion that we can't pass these > >> parameters through the regular libpq connection string mechanism, and > >> wil

Re: [HACKERS] Multiple setup steps for isolation tests

> Tom Lane wrote: > "Kevin Grittner" writes: >> I just today found that the index-only scan feature has broken >> SSI. I don't think it will take much to fix, and I'm looking at >> that, but the first thing I wanted was a test to show the >> breakage. > > Ugh. That sounds like a release-blocker

[HACKERS] index-only scans versus serializable transactions

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 xmin, to avoid possible problems with tid re-use. (This wa

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

On 03.09.2012 10:43, Fujii Masao wrote: On Sat, Sep 1, 2012 at 2:32 AM, Fujii Masao wrote: On Fri, Aug 31, 2012 at 5:03 PM, Heikki Linnakangas wrote: Aside from the missing locking, I wonder what that does to a cascaded standby. If there is an active walsender running while RecoveryTargetTLI

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/03/2012 04:32 PM, Tom Lane wrote: Andrew Dunstan writes: OK, revised patch attached. Looks good to me. OK. I will try to get the test script wrapped up tonight or tomorrow, that's the only thing left. cheers andrew -- Sent via pgsql-hackers mailing lis

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

On Tue, Sep 4, 2012 at 7:07 AM, Heikki Linnakangas wrote: > On 03.09.2012 10:43, Fujii Masao wrote: >> >> On Sat, Sep 1, 2012 at 2:32 AM, Fujii Masao wrote: >>> >>> On Fri, Aug 31, 2012 at 5:03 PM, Heikki Linnakangas >>> wrote: Aside from the missing locking, I wonder what that does to

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

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 GetStandbyFlushRecPtr(), it could atomically check the current recovery timeline. If it has changed, refuse t

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

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 GetStandbyFlushRecPtr(), it could atomically check the current

Re: [HACKERS] Is this non-volatile pointer access OK?

On Mon, 2012-09-03 at 11:14 +0100, Peter Geoghegan wrote: > Come to think of it, the whole convention of using a lower-case > variant of the original pointer variable name seems like a foot-gun, > given the harmful and indeed very subtle consequences of making this > error. With some inventive mac

Re: [HACKERS] Yet another failure mode in pg_upgrade

On Mon, Sep 3, 2012 at 09:52:22AM -0400, Bruce Momjian wrote: > On Sun, Sep 2, 2012 at 11:47:06PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > Updated patch attached. > > > > [ looks at that for a bit... ] Now I see why you were on about that: > > the method you used here requires bo

Re: [HACKERS] pg_upgrade del/rmdir path fix

On Mon, Sep 3, 2012 at 02:30:18PM -0400, Andrew Dunstan wrote: > Here is a patch against 9.2 sources (it applies with offsets to HEAD > too) to fix the problem that pg_upgrade can write paths in arguments > for Windows builtin commands (specifically DEL and RMDIR) with the > wrong path separator s

Re: [HACKERS] [GENERAL] Date conversion using day of week

Patch applied. --- On Sat, Sep 1, 2012 at 05:14:39PM -0400, Bruce Momjian wrote: > [Properly posted to hackers list] > > On Fri, Apr 1, 2011 at 02:27:02AM +1100, Brendan Jurd wrote: > > On 1 April 2011 02:00, Adrian Klave

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/03/2012 10:41 PM, Bruce Momjian wrote: On Mon, Sep 3, 2012 at 02:30:18PM -0400, Andrew Dunstan wrote: Here is a patch against 9.2 sources (it applies with offsets to HEAD too) to fix the problem that pg_upgrade can write paths in arguments for Windows builtin commands (specifically DEL a

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

On Monday, September 03, 2012 10:37 PM Tom Lane wrote: Amit Kapila writes: >> I think part of the code for windows can be written by referring function >> internal_forkexec(), >> If you are okay, I can take up this. Please confirm. > Nobody else volunteered, so have at it. Note that I'm plannin

Re: [HACKERS] Multiple setup steps for isolation tests

"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 conflicts. [ scratches head

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

"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 xmin, to avoid possible >

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

On Mon, Sep 3, 2012 at 4:38 PM, Andres Freund wrote: > On Monday, September 03, 2012 10:23:52 PM Tom Lane wrote: >> I'm reluctantly coming to the conclusion that we can't pass these >> parameters through the regular libpq connection string mechanism, and >> will have to invent something else. Tha

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

Robert Haas writes: > I tend to agree. Another idea here might be to stick with Tom's > original idea of making it a connection parameter, but have it be > turned off by default. In other words, if an application wants to > allow those parameters to be used, it would need to do > PQenableStartSe

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

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 > such a child continue to run after ctrl-c/SIGTERMing e.g. pg_dump in > comparison to closing a normal database connection? Er, w

Re: [HACKERS] pg_upgrade del/rmdir path fix

On 09/03/2012 11:05 PM, Andrew Dunstan wrote: On 09/03/2012 10:41 PM, Bruce Momjian wrote: On Mon, Sep 3, 2012 at 02:30:18PM -0400, Andrew Dunstan wrote: Here is a patch against 9.2 sources (it applies with offsets to HEAD too) to fix the problem that pg_upgrade can write paths in arguments

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

On Tue, Sep 04, 2012 at 12:01:17AM -0400, Robert Haas wrote: > Another idea here might be to stick with Tom's > original idea of making it a connection parameter, but have it be > turned off by default. In other words, if an application wants to > allow those parameters to be used, it would need t

Re: [HACKERS] [GENERAL] Multiple Slave Failover with PITR

On Mon, Sep 3, 2012 at 2:58 AM, Daniel Farina wrote: > On Sun, Sep 2, 2012 at 5:12 AM, Bruce Momjian wrote: >> >> Do we ever want to document a way to connect slaves to a new master, >> rather than recreating the slave? > > Please, please please do so. And hopefully it'll be less tricky > sooner

[HACKERS] Some whitespaces in utility.c

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). Thanks, -- Michael Paquier http://michael.otacoo.com 20120906_utility_whitespace.patch Description: Binary da

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

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 > > such a child continue to run after ctrl-c/SIGTERMing e.g. pg_d

[HACKERS] build farm machine using mixed results

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? I can either create a new machine, or change one of my existing machines. Makes

[HACKERS] Reduce the time to know trigger_file's existence

Hi, We are trying to introduce a thread that monitors the creation of the trigger_file. As and when the file is created, the process that monitors postgres server needs to be notified through the inotify API. This is to reduce the 3-4 seconds delay that exists with the current implementation in p

[HACKERS] Reduce the time to know trigger_fi​le's existence

Hi, We are trying to introduce a thread that monitors the creation of the trigger_file. As and when the file is created, the process that monitors postgres server needs to be notified through the inotify API. This is to reduce the 3-4 seconds delay that exists with the current implementation in p