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
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
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
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:
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
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
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
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
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()
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
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"
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
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
- Цитат от 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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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'
28 matches
Mail list logo