[HACKERS] New replication mode: write

Hi, http://archives.postgresql.org/message-id/AANLkTilgyL3Y1jkDVHX02433COq7JLmqicsqmOsbuyA1%40mail.gmail.com Previously I proposed the replication mode "recv" on the above thread, but it's not committed yet. Now I'd like to propose that mode again because it's useful to reduce the overhead of syn

[HACKERS] review of: collation for (expr)

Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from 2012-01-12 checkout. Bison upgraded to v2.5, and downgraded to v2.4.1 Make process for both versions resulted in the following errors: make[3]: Leaving directory `/usr/local/src/pgbuild/src/backend/catalog' make -C parser gram.

[HACKERS] Patch: DROP INDEX CONCURRENTLY partially reviewed

https://commitfest.postgresql.org/action/patch_view?id=742 Compiled on Ubuntu 10.04.2 LTS from 2012-01-12 git checkout - patch successfully applied - docs built and viewable and reviewed - source/patch built - make check ran successfully - additional testing with pgbench passed Completed steps 1

[HACKERS] gistVacuumUpdate

hi, gistVacuumUpdate was removed when old-style VACUUM FULL was removed. i wonder why. it was not practical and REINDEX is preferred? anyway, the removal seems incomplete and there are some leftovers: F_TUPLES_DELETED F_DELETED XLOG_GIST_PAGE_DELETE YAMAMOTO Takashi --

[HACKERS] Postgres ReviewFest Patch: URI connection string support for libpq

Just reviewed the patch for adding URI connection string support for libpg. There seem to be many tabs in the patch. Perhaps the indentation is not correct. Also, the patch did not run correctly: patching file src/interfaces/libpq/fe-connect.c Hunk #1 succeeded at 282 with fuzz 1. Hunk #2 FAILE

[HACKERS] 9.2 Reviewfest - logging hooks patch

Patch In reviewing the referenced patch, we found that it has no developer documentation and no regression tests. While it compiles and installs, there is nothing to tell us how to use (or test) it. --Christopher __

Re: [HACKERS] Standalone synchronous master

On Wed, Jan 4, 2012 at 11:28 PM, Aidan Van Dyk wrote: > So, I'm a big fan of syncrep guaranteeing it's guarantees.  To me, > that's the whole point.  Having it "fall out of sync rep" at any point > *automatically* seems to be exactly counter to the point of sync rep. Yes, what Alexander proposed

[HACKERS] Text comparison suddenly can't find collation?

Hi all, Why would a string comparison work in one case and not another? In the following example, it works to compare a and b, but not a and d. This is in a C module which calls DirectFunctionCall2( text_le, d1, d2 ); DEBUG: Comparing a == b DEBUG: Comparing a == d ERROR: could not determi

Re: [HACKERS] reprise: pretty print viewdefs

On Tue, Dec 27, 2011 at 8:02 AM, Andrew Dunstan wrote: > > > Updated, with docs and tests. Since the docs mark the versions of > pg_get_viewdef() that take text as the first param as deprecated, I removed > that variant of the new flavor. I left adding extra psql support to another > day - I think

[HACKERS] Review of patch renaming constraints

Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from 2012-01-12 git checkout. Patch applied fine. Docs are present, build, look good and are clear. Changes to gram.y required Bison 2.5 to compile. Are we requiring Bison 2.5 now? There's no configure check for it, so it took

Re: [HACKERS] Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.

On Fri, Jan 13, 2012 at 4:19 AM, Simon Riggs wrote: > On Thu, Jan 12, 2012 at 10:37 AM, Fujii Masao wrote: >> On Thu, Jan 12, 2012 at 5:53 PM, Simon Riggs wrote: >>> PrimaryKeepaliveMessage is a message type that uses WalSndrMessage. >>> That message type is only sent when the WalSndr is quiet,

Re: [HACKERS] log messages for archive recovery progress

On Fri, Jan 13, 2012 at 12:58 AM, Satoshi Nagayasu wrote: > Anyway, how about this one? > > If we have 47 in archive, and 48 in pg_xlog, > > (1) LOG: restored log file "00080047" from archive > (2) LOG: replaying log file "00080047" > (3) LOG: could not restore file

Re: [HACKERS] checkpoint writeback via sync_file_range

On 1/11/12 9:25 AM, Andres Freund wrote: The heavy pressure putting it directly in the writeback queue leads to less efficient io because quite often it won't reorder sensibly with other io anymore and thelike. At least that was my experience in using it with in another application. Sure, this

Re: [HACKERS] [COMMITTERS] pgsql: Fix breakage from earlier plperl fix.

On Fri, Jan 6, 2012 at 14:05, Tom Lane wrote: > Alex Hunsaker writes: >> Oh my... I dunno exactly what I was smoking last night, but its a good >> thing I didn't share :-). Uh so my test program was also completely >> wrong, Ill have to redo it all. I've narrowed it down to: >>         if ((type

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > Hmm, I would think you'd get assertion failures from calling > HeapTupleHeaderGetCmax when xmax isn't the current transaction. > (But I'm not sure that the regression tests really exercise such > cases ... did you try the isolation tests with this?) I was > thinking we should

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" wrote: >> I was thinking we should probably define the cmax as being >> returned only in SelfUpdated cases. > > I thought about that, but didn't see how it could be other than > self-updated. If you do, I guess I missed something. Oh, I see it now. Oops. I can fix that an

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > "Kevin Grittner" writes: >> Am I getting closer? > > Hmm, I would think you'd get assertion failures from calling > HeapTupleHeaderGetCmax when xmax isn't the current transaction. > (But I'm not sure that the regression tests really exercise such > cases ... did you try the i

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > OK, I got rid of the parrots and candles and added a structure to > hold the data returned only on failure. > Am I getting closer? Hmm, I would think you'd get assertion failures from calling HeapTupleHeaderGetCmax when xmax isn't the current transaction. (But I'm not

Re: [HACKERS] ERRCODE_READ_ONLY_SQL_TRANSACTION

Simon Riggs writes: > Hot Standby returns ERRCODE_READ_ONLY_SQL_TRANSACTION in most cases > for illegal actions on a standby. > There are two possible but not normally seen cases that give errors, > but don't set the correct sqlstate, which makes it difficult to > diagnose misdirected SQL from mo

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > You forgot to attach the patch, but the approach seems totally > Rube Goldberg to me anyway. Why not just fix heap_update/ > heap_delete to return the additional information? It's not like > we don't whack their parameter lists around regularly. > > Rather than having three

[HACKERS] ERRCODE_READ_ONLY_SQL_TRANSACTION

Hot Standby returns ERRCODE_READ_ONLY_SQL_TRANSACTION in most cases for illegal actions on a standby. There are two possible but not normally seen cases that give errors, but don't set the correct sqlstate, which makes it difficult to diagnose misdirected SQL from more normal SQL problems. *Patch

[HACKERS] rewriteheap.c bug: toast rows don't get XIDs matching their parents

While working on bug #6393 I was reminded of the truth of $SUBJECT: any rows inserted into the new toast table will have the xmin of the CLUSTER or VACUUM FULL operation, and invalid xmax, whereas their parent heap rows will have xmin/xmax copied from the previous instance of the table. This does n

Re: [HACKERS] WIP -- renaming implicit sequences

On 12 January 2012 00:58, Tom Lane wrote: > Thomas Munro writes: >> Here is an unfinished patch to implement something which appears on >> the TODO list under ALTER: automatic renaming of sequences created >> with serial when the table and column names change.  I've often wanted >> this feature a

Re: [HACKERS] measuring spinning

On Thu, Jan 12, 2012 at 4:00 AM, Simon Riggs wrote: > Please can you repeat the test, focusing on minutes 10-30 of a 30 > minute test run. That removes much of the noise induced during cache > priming. > > My suggested size of database is one that is 80% size of RAM, with > shared_buffers set to 4

Re: [HACKERS] pgbench post-connection command

On 12.01.2012 22:04, Tom Lane wrote: Simon Riggs writes: On Thu, Jan 12, 2012 at 5:32 PM, Tom Lane wrote: More like "\once ... any SQL command or meta command here ..." if we want to extend the scripting language. But I'd be perfectly happy with a command-line switch that specifies a script

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > You forgot to attach the patch, but the approach seems totally > Rube Goldberg to me anyway. Why not just fix heap_update/ > heap_delete to return the additional information? It's not like > we don't whack their parameter lists around regularly. OK. > Rather than having t

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > Tom Lane wrote: >> it needs to check the tuple's cmax [...] And that means the patch >> will be a bit more invasive than this, because heap_update and >> heap_delete don't return that information at present. > I'm thinking that I could keep the test for: > GetCur

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" wrote: > Attached is a patch based on these thoughts. OK, really attached this time. -Kevin *** a/src/backend/executor/execMain.c --- b/src/backend/executor/execMain.c *** *** 1921,1928 EvalPlanQualFetch(EState *estate, Relation relation, int lockmode,

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > it needs to check the tuple's cmax [...] And that means the patch > will be a bit more invasive than this, because heap_update and > heap_delete don't return that information at present. I'm thinking that I could keep the test for: GetCurrentCommandId(false) != estate->e

Re: [HACKERS] pgbench post-connection command

Simon Riggs writes: > On Thu, Jan 12, 2012 at 5:32 PM, Tom Lane wrote: >> More like "\once ... any SQL command or meta command here ..." >> if we want to extend the scripting language.  But I'd be perfectly happy >> with a command-line switch that specifies a script file to be run once. > Once p

Re: [HACKERS] create index regression fail

Excerpts from Jaime Casanova's message of jue ene 12 16:22:17 -0300 2012: > On Thu, Jan 12, 2012 at 1:59 PM, Tom Lane wrote: > > Jaime Casanova writes: > >> the query where the regression fails is: > > > >> SELECT count(*) FROM dupindexcols > >>   WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX'; >

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > Florian Pflug writes: >> On Jan12, 2012, at 17:30 , Tom Lane wrote: >>> Actually, on reflection there might be a reason for checking >>> update_ctid, with a view to allowing "harmless" cases. > >> I've argued against that in the past, and I still think it's a >> bad idea. > >

Re: [HACKERS] create index regression fail

On Thu, Jan 12, 2012 at 1:59 PM, Tom Lane wrote: > Jaime Casanova writes: >> the query where the regression fails is: > >> SELECT count(*) FROM dupindexcols >>   WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX'; > >> my first theory was that it was because some locale because mine is >> es_EC.UTF-8

Re: [HACKERS] pgbench post-connection command

On Thu, Jan 12, 2012 at 5:32 PM, Tom Lane wrote: > More like "\once ... any SQL command or meta command here ..." > if we want to extend the scripting language.  But I'd be perfectly happy > with a command-line switch that specifies a script file to be run once. Once per connection, yes? --  S

Re: [HACKERS] Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.

On Thu, Jan 12, 2012 at 10:37 AM, Fujii Masao wrote: > On Thu, Jan 12, 2012 at 5:53 PM, Simon Riggs wrote: >> PrimaryKeepaliveMessage is a message type that uses WalSndrMessage. >> That message type is only sent when the WalSndr is quiet, so what is >> the difference, in that case? > > Oh, you ar

Re: [HACKERS] create index regression fail

Jaime Casanova writes: > the query where the regression fails is: > SELECT count(*) FROM dupindexcols > WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX'; > my first theory was that it was because some locale because mine is > es_EC.UTF-8 but the content of the table doesn't justify that, [ exper

Re: [HACKERS] Remembering bug #6123

Florian Pflug writes: > On Jan12, 2012, at 17:30 , Tom Lane wrote: >> Actually, on reflection there might be a reason for checking >> update_ctid, with a view to allowing "harmless" cases. > I've argued against that in the past, and I still think it's a bad idea. Well, the main argument for it i

[HACKERS] create index regression fail

Hi, In current HEAD, create index regression is failing (at least here). Is anyone else seeing this? Attached regression.diffs the query where the regression fails is: SELECT count(*) FROM dupindexcols WHERE f1 > 'LX' and id < 1000 and f1 ~<~ 'YX'; my first theory was that it was because some

Re: [HACKERS] Sending notifications from the master to the standby

> Many people clearly do think this is useful. It also comes under the heading of "avoiding surprising behavior". That is, users instinctively expect to be able to LISTEN on standbys, and are surprised when they can't. > I personally don't think it will be that complex. I'm willing to > review

Re: [HACKERS] pgbench post-connection command

Simon Riggs writes: > On Thu, Jan 12, 2012 at 4:24 PM, Tom Lane wrote: >> I don't believe that works for multiple \set commands, which is the >> more likely use-case for this; as noted upthread, executing SET here >> is quite unnecessary since you can get that behavior with >> "export PGOPTIONS".

Re: [HACKERS] Remembering bug #6123

On Jan12, 2012, at 17:30 , Tom Lane wrote: > Actually, on reflection there might be a reason for checking > update_ctid, with a view to allowing "harmless" cases. I see > these cases: > > * UPDATE finds a trigger already updated the row: must throw error > since we can't apply the update. > > *

Re: [HACKERS] pgbench post-connection command

On Thu, Jan 12, 2012 at 4:24 PM, Tom Lane wrote: > Simon Riggs writes: >> On Thu, Jan 12, 2012 at 3:26 PM, Tom Lane wrote: >>> This seems rather poorly designed, mainly because there's no reason to >>> think that a single command would be sufficient. > >> It supports multiple commands via multi-

Re: [HACKERS] Remembering bug #6123

I wrote: >> ... It ought to be comparing the tuple's xmax to >> es_output_cid. Sigh, need to go find some caffeine. Obviously, it needs to check the tuple's cmax, not xmax. And that means the patch will be a bit more invasive than this, because heap_update and heap_delete don't return that infor

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > Tom Lane wrote: >> Also, what's the point of testing update_ctid? I don't see that >> it matters whether the outdate was a delete or an update. > The update_ctid code was a carry-over from my old, slightly > different approach, which I failed to change as I should ha

Re: [HACKERS] JSON for PG 9.2

On 01/12/2012 11:21 AM, Merlin Moncure wrote: On Thu, Jan 12, 2012 at 9:51 AM, Andrew Dunstan wrote: On 01/12/2012 10:44 AM, Pavel Stehule wrote: this should be little bit more enhanced to support a row arrays - it can be merged with some routines from pst tool http://okbob.blogspot.com/2010

Re: [HACKERS] JSON for PG 9.2

2012/1/12 Merlin Moncure : > On Thu, Jan 12, 2012 at 9:51 AM, Andrew Dunstan wrote: >> On 01/12/2012 10:44 AM, Pavel Stehule wrote: >>> this should be little bit more enhanced to support a row arrays - it >>> can be merged with some routines from pst tool >>> http://okbob.blogspot.com/2010/11/new-

Re: [HACKERS] pgbench post-connection command

Simon Riggs writes: > On Thu, Jan 12, 2012 at 3:26 PM, Tom Lane wrote: >> This seems rather poorly designed, mainly because there's no reason to >> think that a single command would be sufficient. > It supports multiple commands via multi-statement requests > e.g. > -x "SET this = on; SET that =

Re: [HACKERS] JSON for PG 9.2

On Thu, Jan 12, 2012 at 9:51 AM, Andrew Dunstan wrote: > On 01/12/2012 10:44 AM, Pavel Stehule wrote: >> this should be little bit more enhanced to support a row arrays - it >> can be merged with some routines from pst tool >> http://okbob.blogspot.com/2010/11/new-version-of-pst-collection-is.html

Re: [HACKERS] Remembering bug #6123

Florian Pflug writes: > So, I guess my question is, if we add safeguards against these sorts of > bugs for triggers, should we also add them to FOR UPDATE? Historically, > we seem to have taken the stand that modifications of self-updated tuples > should be ignored. If we're going to reverse that

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > So what we need to do is check whether the outdate was done by a > later CommandId than current. I see that your patch is attempting > to deal with these issues by testing GetCurrentCommandId(false) != > estate->es_output_cid, but that seems completely wrong to me, as > what i

Re: [HACKERS] pgbench post-connection command

On Thu, Jan 12, 2012 at 3:26 PM, Tom Lane wrote: > Simon Riggs writes: >> New -x option for pgbench executes the given command once after >> connection of each session. > > This seems rather poorly designed, mainly because there's no reason to > think that a single command would be sufficient. I

Re: [HACKERS] pgbench post-connection command

Heikki Linnakangas writes: > On 12.01.2012 17:26, Tom Lane wrote: >> Simon Riggs writes: >>> New -x option for pgbench executes the given command once after >>> connection of each session. > If it's just for SET, you could just put the GUCs in postgresql.conf. Or use PGOPTIONS. I think there m

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > Tom Lane wrote: >> ... All we have to do is start treating >> HeapTupleSelfUpdated result from heap_update or heap_delete as an >> error case instead of an okay-do-nothing case. There doesn't even >> need to be an explicit check that this was caused by a trigger, >> b

Re: [HACKERS] log messages for archive recovery progress

2012/01/13 0:13, Robert Haas wrote: On Thu, Jan 12, 2012 at 10:04 AM, Simon Riggs wrote: On Thu, Jan 12, 2012 at 2:13 PM, Robert Haas wrote: On Wed, Jan 11, 2012 at 9:01 AM, Simon Riggs wrote: On Wed, Jan 11, 2012 at 1:54 PM, Satoshi Nagayasu wrote: However, I'm a bit afraid that it will

Re: [HACKERS] pgbench post-connection command

On 12.01.2012 17:26, Tom Lane wrote: Simon Riggs writes: New -x option for pgbench executes the given command once after connection of each session. If it's just for SET, you could just put the GUCs in postgresql.conf. This seems rather poorly designed, mainly because there's no reason to t

Re: [HACKERS] JSON for PG 9.2

On 01/12/2012 10:44 AM, Pavel Stehule wrote: 2012/1/12 Andrew Dunstan: On 01/12/2012 09:00 AM, Joey Adams wrote: I wrote an array_to_json function during GSoC 2010: http://git.postgresql.org/gitweb/?p=json-datatype.git;a=blob;f=json_io.c#l289 It's not exposed as a procedure called array_t

Re: [HACKERS] pgbench post-connection command

Excerpts from Tom Lane's message of jue ene 12 12:26:49 -0300 2012: > Simon Riggs writes: > > New -x option for pgbench executes the given command once after > > connection of each session. > > This seems rather poorly designed, mainly because there's no reason to > think that a single command w

Re: [HACKERS] Remembering bug #6123

On Jan12, 2012, at 00:32 , Kevin Grittner wrote: > Going back through the patches we had to make to 9.0 to move to > PostgreSQL triggers, I noticed that I let the issues raised as bug > #6123 lie untouched during the 9.2 development cycle. In my view, > the best suggestion for a solution was propo

Re: [HACKERS] JSON for PG 9.2

2012/1/12 Andrew Dunstan : > > > On 01/12/2012 09:00 AM, Joey Adams wrote: >> >> I wrote an array_to_json function during GSoC 2010: >> >> >> http://git.postgresql.org/gitweb/?p=json-datatype.git;a=blob;f=json_io.c#l289 >> >> It's not exposed as a procedure called array_to_json: it's part of the >>

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > I suggest that the current behavior was designed for the case of > independent concurrent updates, and you have not made a good > argument for changing that. What does make sense to me, in light > of these examples, is to complain if a BEFORE trigger modifies the > row "itself

Re: [HACKERS] Remembering bug #6123

"Kevin Grittner" writes: > Tom Lane wrote: >> While that sounds relatively safe, if possibly performance- >> impacting, it's not apparent to me how it fixes the problem you >> complained of. The triggers you were using were modifying rows >> other than the one being targeted by the triggering ac

Re: [HACKERS] pgbench post-connection command

Simon Riggs writes: > New -x option for pgbench executes the given command once after > connection of each session. This seems rather poorly designed, mainly because there's no reason to think that a single command would be sufficient. What would make more sense to me is to add an option for a o

Re: [HACKERS] JSON for PG 9.2

On 01/12/2012 09:00 AM, Joey Adams wrote: I wrote an array_to_json function during GSoC 2010: http://git.postgresql.org/gitweb/?p=json-datatype.git;a=blob;f=json_io.c#l289 It's not exposed as a procedure called array_to_json: it's part of the to_json function, which decides what to do b

Re: [HACKERS] Sending notifications from the master to the standby

On Wed, Jan 11, 2012 at 11:38 PM, Tom Lane wrote: >> The obvious first use case for this is for cache invalidation. > > Yeah, upthread Simon pointed out that propagating notifies would be > useful for flushing caches in applications that watch the database in a > read-only fashion.  I grant that

Re: [HACKERS] log messages for archive recovery progress

On Thu, Jan 12, 2012 at 10:04 AM, Simon Riggs wrote: > On Thu, Jan 12, 2012 at 2:13 PM, Robert Haas wrote: >> On Wed, Jan 11, 2012 at 9:01 AM, Simon Riggs wrote: >>> On Wed, Jan 11, 2012 at 1:54 PM, Satoshi Nagayasu wrote: >>> However, I'm a bit afraid that it will confuse DBA if we use >>

Re: [HACKERS] log messages for archive recovery progress

On Thu, Jan 12, 2012 at 2:13 PM, Robert Haas wrote: > On Wed, Jan 11, 2012 at 9:01 AM, Simon Riggs wrote: >> On Wed, Jan 11, 2012 at 1:54 PM, Satoshi Nagayasu wrote: >> >>> However, I'm a bit afraid that it will confuse DBA if we use >>> "restored" under the pg_xlog replay context, because we ha

[HACKERS] pgbench post-connection command

New -x option for pgbench executes the given command once after connection of each session. e.g. pgbench -x "SET synchronous_commit = off" pgbench -x "SET foo_extension.enabled = on" Allows easier testing of user parameters. Command listed in final report $ pgbench -c 2 -t 4 -x "set synchronous_

Re: [HACKERS] log messages for archive recovery progress

On Wed, Jan 11, 2012 at 9:01 AM, Simon Riggs wrote: > On Wed, Jan 11, 2012 at 1:54 PM, Satoshi Nagayasu wrote: > >> However, I'm a bit afraid that it will confuse DBA if we use >> "restored" under the pg_xlog replay context, because we have >> already used "restored" that means a WAL file as succ

Re: [HACKERS] JSON for PG 9.2

I wrote an array_to_json function during GSoC 2010: http://git.postgresql.org/gitweb/?p=json-datatype.git;a=blob;f=json_io.c#l289 It's not exposed as a procedure called array_to_json: it's part of the to_json function, which decides what to do based on the argument type. - Joey -- Sent vi

Re: [HACKERS] Remembering bug #6123

Tom Lane wrote: > "Kevin Grittner" writes: >> Going back through the patches we had to make to 9.0 to move to >> PostgreSQL triggers, I noticed that I let the issues raised as bug >> #6123 lie untouched during the 9.2 development cycle. In my view, >> the best suggestion for a solution was prop

Re: [HACKERS] CLOG contention

On Thu, Jan 5, 2012 at 6:26 PM, Simon Riggs wrote: > Patch to remove clog contention caused by dirty clog LRU. v2, minor changes, updated for recent commits --  Simon Riggs   http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Training & Services diff --git a/src

[HACKERS] Simulating Clog Contention

In order to simulate real-world clog contention, we need to use benchmarks that deal with real world situations. Currently, pgbench pre-loads data using COPY and executes a VACUUM so that all hint bits are set on every row of every page of every table. Thus, as pgbench runs it sees zero clog acces

Re: [HACKERS] CLOG contention, part 2

On Sun, Jan 8, 2012 at 2:25 PM, Simon Riggs wrote: > I've taken that idea and used it to build a second Clog cache, known > as ClogHistory which allows access to the read-only tail of pages in > the clog. Once a page has been written to for the last time, it will > be accessed via the ClogHistory

Re: [HACKERS] Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.

On Thu, Jan 12, 2012 at 5:53 PM, Simon Riggs wrote: > PrimaryKeepaliveMessage is a message type that uses WalSndrMessage. > That message type is only sent when the WalSndr is quiet, so what is > the difference, in that case? Oh, you are right. There is no difference. Regards, -- Fujii Masao NI

Re: [HACKERS] [WIP] Double-write with Fast Checksums

On Thu, Jan 12, 2012 at 12:09 AM, Tom Lane wrote: > Simon Riggs writes: >> On Wed, Jan 11, 2012 at 11:07 PM, Josh Berkus wrote: >>> On 1/11/12 1:25 PM, Dan Scales wrote: And just wanted to reiterate one other benefit of double writes -- it greatly reduces the size of the WAL logs. > >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.

On Thu, Jan 12, 2012 at 3:09 AM, Fujii Masao wrote: > On Thu, Jan 12, 2012 at 12:20 AM, Simon Riggs wrote: >>> +static void >>> +ProcessWalSndrMessage(XLogRecPtr walEnd, TimestampTz sendTime) >>> >>> walEnd is not used in ProcessWalSndrMessage() at all. Can't we remove it? >>> If yes, walEnd fiel

Re: [HACKERS] measuring spinning

On Thu, Jan 12, 2012 at 1:48 AM, Robert Haas wrote: > Just to whet your appetite, here are the top spinners on a 32-client > SELECT-only test on a 32-core Itanium server.  All the locks not shown > below have two orders of magnitude less of a problem than these do. Please can you repeat the test