Re: [HACKERS] Bugs in our Windows socket code

2012-05-14 Thread Tom Lane
I wrote: > I've been trying to figure out why my recent attempt to latch-ify the > stats collector didn't work well on the Windows buildfarm machines. > ... > What I intend to try doing about this is making > pgwin32_waitforsinglesocket detach its event object from the socket before > returning, ie

Re: [HACKERS] Patch pg_is_in_backup()

2012-05-14 Thread Gilles Darold
Sorry for the the double post but it seems that my previous reply doesn't reach the pgsql-hacker list. So here is the new patches that limit lines to 80 characters. Regards, Le 02/05/2012 19:53, Gabriele Bartolini a écrit : > Hi Gilles, > >Sorry for the delay. > > Il 03/04/12 14:21, Gilles Da

Re: [HACKERS] Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value

2012-05-14 Thread Simon Riggs
On 14 May 2012 20:05, Peter Eisentraut wrote: > On lör, 2012-05-12 at 12:59 -0400, Tom Lane wrote: >> Now it's entirely likely that there is nobody out there relying on >> such a thing, but nonetheless this is a compatibility break, and an >> unnecessary one IMO.  You haven't shown any convincing

Re: [HACKERS] Draft release notes complete

2012-05-14 Thread Merlin Moncure
On Wed, May 9, 2012 at 10:11 PM, Bruce Momjian wrote: > I have completed my draft of the 9.2 release notes, and committed it to > git. The beta release announcement is on postgresql.org with a direct link to the release notes. The notes lead off with: NARRATIVE HERE. Major enhancements include:

Re: [HACKERS] Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value

2012-05-14 Thread Peter Eisentraut
On mån, 2012-05-14 at 15:11 -0400, Tom Lane wrote: > Hm. Interesting argument, but why exactly would you expect that age() > would work differently from, say, wall clock time? And how likely is > it that a database that requires monitoring is going to have exactly > zero transactions over a signi

Re: [HACKERS] Draft release notes complete

2012-05-14 Thread Jeff Janes
On Mon, May 14, 2012 at 9:56 AM, Jeff Janes wrote: > On Mon, May 14, 2012 at 9:06 AM, Bruce Momjian wrote: > >> This is the git commit message: >> >>    Make group commit more effective. >> >>    When a backend needs to flush the WAL, and someone else is already >> flushing >>    the WAL, wait u

Re: [HACKERS] Draft release notes complete

2012-05-14 Thread Peter Geoghegan
On 14 May 2012 17:06, Bruce Momjian wrote: > So this group commit happens > even if users don't change these? > >        #commit_delay = 0           # range 0-10, in microseconds >        #commit_siblings = 5            # range 1-1000 Yes, that's right - the new group commit is not configurab

Re: [HACKERS] Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value

2012-05-14 Thread Tom Lane
Peter Eisentraut writes: > On lör, 2012-05-12 at 12:59 -0400, Tom Lane wrote: >> Now it's entirely likely that there is nobody out there relying on >> such a thing, but nonetheless this is a compatibility break, and an >> unnecessary one IMO. You haven't shown any convincing reason why we >> nee

Re: [HACKERS] Re: [COMMITTERS] pgsql: Ensure age() returns a stable value rather than the latest value

2012-05-14 Thread Peter Eisentraut
On lör, 2012-05-12 at 12:59 -0400, Tom Lane wrote: > Now it's entirely likely that there is nobody out there relying on > such a thing, but nonetheless this is a compatibility break, and an > unnecessary one IMO. You haven't shown any convincing reason why we > need to change the behavior of age()

Re: [HACKERS] Strange issues with 9.2 pg_basebackup & replication

2012-05-14 Thread Jim Nasby
On May 13, 2012, at 3:08 PM, Josh Berkus wrote: > More issues: promoting intermediate standby breaks replication. > > To be a bit blunt here, has anyone tested cascading replication *at all* > before this? Josh, do you have scripts that you're using to do this testing? If so can you post them so

Re: [HACKERS] incorrect handling of the timeout in pg_receivexlog

2012-05-14 Thread Fujii Masao
On Fri, May 11, 2012 at 11:43 PM, Magnus Hagander wrote: > Should we go down the easy way and just reject connections when the flag is > mismatching between the client and the server (trivial to do - see the > attached patch)? + char *tmpparam; You forgot to add "const" before "char"

Re: [HACKERS] libpq URL syntax vs SQLAlchemy

2012-05-14 Thread Alex
karave...@mail.bg writes: > - Цитат от Alex Shulgin (a...@commandprompt.com), на 14.05.2012 в 18:16 > - > >> Alex writes: >> >> >> The host part in this case is empty (it is "hidden" between the "//" and >> the following "/",) thus local socket connection is employed for this >> type

Re: [HACKERS] WalSndWakeup() and synchronous_commit=off

2012-05-14 Thread Fujii Masao
On Mon, May 14, 2012 at 6:32 PM, Andres Freund wrote: > On Friday, May 11, 2012 08:45:23 PM Tom Lane wrote: >> Andres Freund writes: >> > Its the only place though which knows whether its actually sensible to >> > wakeup the walsender. We could make it return whether it wrote anything >> > and do

Re: [HACKERS] libpq URL syntax vs SQLAlchemy

2012-05-14 Thread karavelov
- Цитат от Alex Shulgin (a...@commandprompt.com), на 14.05.2012 в 18:16 - > Alex writes: > > > The host part in this case is empty (it is "hidden" between the "//" and > the following "/",) thus local socket connection is employed for this > type of URIs. To specify non-standard path

Re: [HACKERS] Draft release notes complete

2012-05-14 Thread Jeff Janes
On Mon, May 14, 2012 at 9:06 AM, Bruce Momjian wrote: > On Sun, May 13, 2012 at 09:01:03PM +0100, Peter Geoghegan wrote: >> On 12 May 2012 01:37, Robert Haas wrote: >> > Right.  It's not a new feature; it's a performance improvement.  We've >> > had group commit for a long time; it just didn't wo

Re: [HACKERS] Draft release notes complete

2012-05-14 Thread Robert Haas
On May 14, 2012, at 9:06 AM, Bruce Momjian wrote: > So the new release item wording will be: > >Add group commit capability for sessions that commit at the same >time > > This is the git commit message: > >Make group commit more effective. > >When a backend needs to flush t

Re: [HACKERS] Draft release notes complete

2012-05-14 Thread Bruce Momjian
On Sun, May 13, 2012 at 09:01:03PM +0100, Peter Geoghegan wrote: > On 12 May 2012 01:37, Robert Haas wrote: > > Right.  It's not a new feature; it's a performance improvement.  We've > > had group commit for a long time; it just didn't work very well > > before.  And it's not batching the commits

Re: [HACKERS] libpq URL syntax vs SQLAlchemy

2012-05-14 Thread Alex Shulgin
Alex writes: > Peter Eisentraut writes: > >> I have been reviewing how our new libpq URL syntax compares against >> existing implementations of URL syntaxes in other drivers or >> higher-level access libraries. In the case of SQLAlchemy, there is an >> incompatibility regarding how Unix-domain

Re: [HACKERS] Why do we still have commit_delay and commit_siblings?

2012-05-14 Thread Peter Geoghegan
On 14 May 2012 15:09, Robert Haas wrote: > I don't have a strong opinion > about that, and welcome discussion.  But I'm always going to be > opposed to adding or removing things on the basis of what we didn't > test. The subject of the thread is "Why do we still have commit_delay and commit_sibli

Re: [HACKERS] Why do we still have commit_delay and commit_siblings?

2012-05-14 Thread Robert Haas
On Mon, May 14, 2012 at 3:15 AM, Magnus Hagander wrote: > On Mon, May 14, 2012 at 8:17 AM, Robert Haas wrote: >> On Mon, May 14, 2012 at 2:07 AM, Simon Riggs wrote: >>> Keeping a parameter without any clue as to whether it has benefit is >>> just wasting people's time. >> >> No, arguing that we

Re: [HACKERS] Why do we still have commit_delay and commit_siblings?

2012-05-14 Thread Jeff Janes
On Sun, May 13, 2012 at 11:07 PM, Simon Riggs wrote: > > Keeping a parameter without any clue as to whether it has benefit is > just wasting people's time. > > We don't ADD parameters based on supposition, why should we avoid > removing parameters that have no measured benefit? Using pgbench -T30

Re: [HACKERS] Why do we still have commit_delay and commit_siblings?

2012-05-14 Thread Jeff Janes
On Sun, May 13, 2012 at 4:17 PM, Peter Geoghegan wrote: > This code is our pre-9.2 group commit implementation, pretty much in > its entirety: > > if (CommitDelay > 0 && enableFsync && >        MinimumActiveBackends(CommitSiblings)) >        pg_usleep(CommitDelay); A semantic issue, I guess, but

[HACKERS] hot standby PSQL 9.1 Windows 2008 Servers

2012-05-14 Thread chinnaobi
Hi All, I have implemented hot standby for PostgreSQL with a group of two Primary and Standby in windows 2008 servers. Currently below are the settings: 1. Archiving is enabled on primary, stored on network storage. 2. Asynchronous Streaming replication from primary to standby. wal-senders=5, wa

Re: [HACKERS] Gsoc2012 idea, tablesample

2012-05-14 Thread Stephen Frost
* Qi Huang (huangq...@hotmail.com) wrote: > Thanks, guys, for your hot discussion. I'll explore the ANALYZE command first > and try make SYSTEM sampling work. Other parts, I'll look at them later. That sounds like the right first steps to me. Reviewing this discussion, it was my thought to crea

Re: [HACKERS] WalSndWakeup() and synchronous_commit=off

2012-05-14 Thread Andres Freund
On Friday, May 11, 2012 08:45:23 PM Tom Lane wrote: > Andres Freund writes: > > Its the only place though which knows whether its actually sensible to > > wakeup the walsender. We could make it return whether it wrote anything > > and do the wakeup at the callers. I count 4 different callsites whi

Re: [HACKERS] Update comments for PGPROC/PGXACT split

2012-05-14 Thread Heikki Linnakangas
On 13.05.2012 23:52, Noah Misch wrote: Many comment references to PGPROC and MyProc should now refer to PGXACT and MyPgXact. This patch attempts to cover all such cases. In some places, a comment refers collectively to all the xid-related fields, which span both structures. I variously changed

Re: [HACKERS] Analyzing foreign tables & memory problems

2012-05-14 Thread Albe Laurenz
Noah Misch wrote: > 1) Expose WIDTH_THRESHOLD in commands/vacuum.h and add documentation >so that the authors of foreign data wrappers are aware of the >problem and can avoid it on their side. >This would be quite simple. >> Seems reasonable. How would the FDW retu

Re: [HACKERS] Why do we still have commit_delay and commit_siblings?

2012-05-14 Thread Magnus Hagander
On Mon, May 14, 2012 at 8:17 AM, Robert Haas wrote: > On Mon, May 14, 2012 at 2:07 AM, Simon Riggs wrote: >> Keeping a parameter without any clue as to whether it has benefit is >> just wasting people's time. > > No, arguing that we should remove a parameter because it's useless > when you haven'