Re: [HACKERS] sepgsql: label regression test failed

On 05/14/2014 07:33 AM, Sergey Muraviov wrote: I've got this compiler warning: relation.c: In function ‘sepgsql_relation_drop’: relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this function [-Wmaybe-uninitialized] sepgsql_avc_check_perms(&object, ^

[HACKERS] Buffer manager scalability and correlated reference period

I have performed a new benchmark related to my ongoing experimentation around caching and buffer manager scalability. The benchmark tests a minor refinement of the prototype patch previously posted [1]. The patch itself is still very much a prototype, and does not significantly differ from what I o

Re: [HACKERS] 9.0 PDF build broken

On 2014-05-15 22:27:42 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > Mysteriously, commit 6b2a1445ec8a631060c4cbff3f172bf31d3379b9 has broken > > the PDF build (openjade + pdfjadetex) in the 9.0 branch only. The error > > is > > > [256.0.28 > > ! pdfTeX error (ext4): \pdfendlink ended up

Re: [HACKERS] Logical replication woes

On 05/15/2014 11:58 PM, Andres Freund wrote: On 2014-05-15 22:30:53 +0300, Heikki Linnakangas wrote: Attached patch fixes things, but I want to add some regression tests before commit. Looks good to me. Attached are two patches. One for the unitialized dbId/tsId issue; one for the decoding b

Re: [HACKERS] SKIP LOCKED DATA (work in progress)

I'm rebasing another implementation of this against current HEAD at the moment. It was well tested but has bitrotted a bit, in particular it needs merging with the multixact changes (eep). That should provide a useful basis for comparison and a chance to share ideas. I'll follow up with the patch

Re: [HACKERS] Trigger concurrent execution

Hi, Thanks all for being patient, apparently I didn't quite understand the norms of trigger execution. On 16 May 2014 07:55, Craig Ringer wrote: > On 05/16/2014 08:06 AM, Blagoj Petrushev wrote: >> Hi, >> >> I'm thinking of an extension to trigger functionality like this: >> >> CREATE TRIGGER tr

[HACKERS] btree_gist macaddr valgrind woes

Hi, After Heikki has fixed the bit btree_gist bugs my valgrind run shows a bug in macaddr. Presumably it's because the type is a fixed width type with a length of 6. I guess it's allocating stuff sizeof(macaddr) but then passes the result around as a Datum which doesn't work well. ==14219== Inva

Re: [HACKERS] Priority table or Cache table

Hello, I applied the patch to current HEAD. There was one failure (attached), freelist.rej Compiled the provided pgbench.c and added following in .conf shared_buffers = 128MB # min 128kB Shared_buffers=64MB

Re: [HACKERS] sepgsql: label regression test failed

2014-05-16 16:26 GMT+09:00 Heikki Linnakangas : > On 05/14/2014 07:33 AM, Sergey Muraviov wrote: >> >> I've got this compiler warning: >> relation.c: In function ‘sepgsql_relation_drop’: >> relation.c:472:25: warning: ‘tclass’ may be used uninitialized in this >> function [-Wmaybe-uninitialized]

Re: [HACKERS] Priority table or Cache table

On 20 Feb 2014, at 01:38, Tom Lane wrote: > Haribabu Kommi writes: >> I want to propose a new feature called "priority table" or "cache table". >> This is same as regular table except the pages of these tables are having >> high priority than normal tables. These tables are very useful, where a

Re: [HACKERS] SKIP LOCKED DATA (work in progress)

On 05/16/2014 04:46 PM, Craig Ringer wrote: > > I'll follow up with the patch and a git tree when it's ready, hopefully > tonight. Here's a rebased version of Simon's original patch that runs on current master. I still need to merge the isolation tests for it merged and sorted out, and after re-

Re: [HACKERS] btree_gist macaddr valgrind woes

On 05/16/2014 01:28 PM, Andres Freund wrote: Hi, After Heikki has fixed the bit btree_gist bugs my valgrind run shows a bug in macaddr. Presumably it's because the type is a fixed width type with a length of 6. I guess it's allocating stuff sizeof(macaddr) but then passes the result around as a

Re: [HACKERS] btree_gist macaddr valgrind woes

On 2014-05-16 17:08:40 +0300, Heikki Linnakangas wrote: > On 05/16/2014 01:28 PM, Andres Freund wrote: > >Hi, > > > >After Heikki has fixed the bit btree_gist bugs my valgrind run shows a > >bug in macaddr. > > > >Presumably it's because the type is a fixed width type with a length of > >6. I guess

[HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

Hello, Can we get that fixed please? It seems rather bad behavior for pg_basebackup to fatal out because of the permissions on a backup file of all things. Instead, we should do WARNING and say skipped. JD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

Hi, On 2014-05-16 07:28:42 -0700, Joshua D. Drake wrote: > Can we get that fixed please? It seems rather bad behavior for pg_basebackup > to fatal out because of the permissions on a backup file of all things. > Instead, we should do WARNING and say skipped. Doesn't sound like a good idea to me.

Re: [HACKERS] Scaling shared buffer eviction

On Thu, May 15, 2014 at 11:11 AM, Amit Kapila wrote: > > Data with LWLOCK_STATS > -- > BufMappingLocks > > PID 7245 lwlock main 38: shacq 41117 exacq 34561 blk 36274 spindelay 101 > PID 7310 lwlock main 39: shacq 40257 exacq 34219 blk 25886 spindelay 72

[HACKERS] chr() is still too loose about UTF8 code points

Quite some time ago, we made the chr() function accept Unicode code points up to U+1F, which is the largest value that will fit in a 4-byte UTF8 string. It was pointed out to me though that RFC3629 restricted the original definition of UTF8 to only allow code points up to U+10 (for compati

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On 05/16/2014 07:30 AM, Andres Freund wrote: Hi, On 2014-05-16 07:28:42 -0700, Joshua D. Drake wrote: Can we get that fixed please? It seems rather bad behavior for pg_basebackup to fatal out because of the permissions on a backup file of all things. Instead, we should do WARNING and say skipp

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

"Joshua D. Drake" writes: > On 05/16/2014 07:30 AM, Andres Freund wrote: >> On 2014-05-16 07:28:42 -0700, Joshua D. Drake wrote: >>> Can we get that fixed please? It seems rather bad behavior for pg_basebackup >>> to fatal out because of the permissions on a backup file of all things. >>> Instead,

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On 2014-05-16 08:13:04 -0700, Joshua D. Drake wrote: > On 05/16/2014 07:30 AM, Andres Freund wrote: > > > >Hi, > > > >On 2014-05-16 07:28:42 -0700, Joshua D. Drake wrote: > >>Can we get that fixed please? It seems rather bad behavior for pg_basebackup > >>to fatal out because of the permissions on

Re: [HACKERS] btree_gist macaddr valgrind woes

Heikki Linnakangas writes: > On 05/16/2014 01:28 PM, Andres Freund wrote: >> Presumably it's because the type is a fixed width type with a length of >> 6. I guess it's allocating stuff sizeof(macaddr) but then passes the >> result around as a Datum which doesn't work well. I've not tried valgrind

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On 05/16/2014 08:19 AM, Tom Lane wrote: pg_hba.conf~ is not an important file. Rather than blaming the messenger, you should be asking why there are files in $PGDATA that the server can't read. That's a recipe for trouble no matter what. Or in words of one syllable: this is a bug in your edi

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

At a minimum: Check to see if there is going to be a permission error BEFORE the base backup begins: starting basebackup: checking perms: ERROR no access to pg_hba.conf~ base backup will fail JD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

Hi, On 2014-05-16 08:45:12 -0700, Joshua D. Drake wrote: > Software is supposed to make our lives easier, not harder. I should be able > to evaluate the errors for the conditions they create. This is why rsync is > and for the forseeable future will be king for creating base backups. It's dangero

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On 05/16/2014 08:48 AM, Andres Freund wrote: Hi, On 2014-05-16 08:45:12 -0700, Joshua D. Drake wrote: Software is supposed to make our lives easier, not harder. I should be able to evaluate the errors for the conditions they create. This is why rsync is and for the forseeable future will be ki

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake wrote: > At a minimum: > > Check to see if there is going to be a permission error BEFORE the base > backup begins: > > starting basebackup: > checking perms: ERROR no access to pg_hba.conf~ base backup will fail That's pretty much what it does

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On 2014-05-16 18:20:35 +0200, Magnus Hagander wrote: > On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake > wrote: > > > At a minimum: > > > > Check to see if there is going to be a permission error BEFORE the base > > backup begins: > > > > starting basebackup: > > checking perms: ERROR no acces

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On Fri, May 16, 2014 at 6:25 PM, Andres Freund wrote: > On 2014-05-16 18:20:35 +0200, Magnus Hagander wrote: > > On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake >wrote: > > > > > At a minimum: > > > > > > Check to see if there is going to be a permission error BEFORE the base > > > backup begins

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On 2014-05-16 18:29:25 +0200, Magnus Hagander wrote: > On Fri, May 16, 2014 at 6:25 PM, Andres Freund wrote: > > > On 2014-05-16 18:20:35 +0200, Magnus Hagander wrote: > > > On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake > >wrote: > > > > > > > At a minimum: > > > > > > > > Check to see if ther

Re: [HACKERS] chr() is still too loose about UTF8 code points

On 05/16/2014 06:05 PM, Tom Lane wrote: Quite some time ago, we made the chr() function accept Unicode code points up to U+1F, which is the largest value that will fit in a 4-byte UTF8 string. It was pointed out to me though that RFC3629 restricted the original definition of UTF8 to only all

Re: [HACKERS] pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On 05/16/2014 09:20 AM, Magnus Hagander wrote: On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake mailto:j...@commandprompt.com>> wrote: At a minimum: Check to see if there is going to be a permission error BEFORE the base backup begins: starting basebackup: checking perm

Re: [HACKERS] chr() is still too loose about UTF8 code points

On 05/16/2014 12:43 PM, Heikki Linnakangas wrote: On 05/16/2014 06:05 PM, Tom Lane wrote: Quite some time ago, we made the chr() function accept Unicode code points up to U+1F, which is the largest value that will fit in a 4-byte UTF8 string. It was pointed out to me though that RFC3629

[HACKERS] Re: pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

Andres Freund-3 wrote > On 2014-05-16 18:29:25 +0200, Magnus Hagander wrote: >> On Fri, May 16, 2014 at 6:25 PM, Andres Freund < > andres@ > >wrote: >> >> > On 2014-05-16 18:20:35 +0200, Magnus Hagander wrote: >> > > On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake < > jd@ > > > >wrote: >> > >

Re: [HACKERS] chr() is still too loose about UTF8 code points

Heikki Linnakangas writes: > On 05/16/2014 06:05 PM, Tom Lane wrote: >> I think this probably means we need to change chr() to reject code points >> above 10. Should we back-patch that, or just do it in HEAD? > +1 for back-patching. A value that cannot be restored is bad, and I > can't imag

Re: [HACKERS] chr() is still too loose about UTF8 code points

On Fri, May 16, 2014 at 11:05:08AM -0400, Tom Lane wrote: > I think this probably means we need to change chr() to reject code points > above 10. Should we back-patch that, or just do it in HEAD? The compatibility risks resemble those associated with the fixes for bug #9210, so I recommend HE

Re: [HACKERS] chr() is still too loose about UTF8 code points

Noah Misch writes: > On Fri, May 16, 2014 at 11:05:08AM -0400, Tom Lane wrote: >> I think this probably means we need to change chr() to reject code points >> above 10. Should we back-patch that, or just do it in HEAD? > The compatibility risks resemble those associated with the fixes for bu

[HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

Hi, elog.c's log_line_prefix() processes %d with: case 'd': if (MyProcPort) { const char *dbname = MyProcPort->database_name; if (dbname == NULL || *dbname == '\0') dbname = _("[unknown]");

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

Andres Freund writes: > elog.c's log_line_prefix() processes %d with: > case 'd': > if (MyProcPort) > { > const char *dbname = MyProcPort->database_name; > if (dbname == NULL || *dbname == '\0') >

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

On 2014-05-16 14:02:44 -0400, Tom Lane wrote: > Andres Freund writes: > > elog.c's log_line_prefix() processes %d with: > > case 'd': > > if (MyProcPort) > > { > > const char *dbname = MyProcPort->database_name; > > >

Re: [HACKERS] chr() is still too loose about UTF8 code points

Tom Lane-2 wrote > Noah Misch < > noah@ > > writes: >> On Fri, May 16, 2014 at 11:05:08AM -0400, Tom Lane wrote: >>> I think this probably means we need to change chr() to reject code >>> points >>> above 10. Should we back-patch that, or just do it in HEAD? > >> The compatibility risks res

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

Andres Freund writes: > On 2014-05-16 14:02:44 -0400, Tom Lane wrote: >> Not directly related to your gripe, but: where did this "padding" logic >> come from, and what prevents it from creating invalidly-encoded output by >> means of truncating multibyte characters in the middle? > Isn't that syn

Re: [HACKERS] chr() is still too loose about UTF8 code points

David G Johnston writes: > Tom Lane-2 wrote >> While I'd be willing to ignore that risk so far as code points above >> 10 go, if we want pg_utf8_islegal to be happy then we will also >> have to reject surrogate-pair code points. It's not beyond the realm >> of possibility that somebody is int

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

On 2014-05-16 14:51:01 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-05-16 14:02:44 -0400, Tom Lane wrote: > >> Not directly related to your gripe, but: where did this "padding" logic > >> come from, and what prevents it from creating invalidly-encoded output by > >> means of truncati

Re: [HACKERS] btree_gist macaddr valgrind woes

Andres Freund writes: > After Heikki has fixed the bit btree_gist bugs my valgrind run shows a > bug in macaddr. AFAICT none of these traces represent live bugs, but I've pushed fixes for them into HEAD. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] btree_gist macaddr valgrind woes

On 05/16/2014 06:43 PM, Tom Lane wrote: Heikki Linnakangas writes: On 05/16/2014 01:28 PM, Andres Freund wrote: Presumably it's because the type is a fixed width type with a length of 6. I guess it's allocating stuff sizeof(macaddr) but then passes the result around as a Datum which doesn't wo

Re: [HACKERS] btree_gist macaddr valgrind woes

Heikki Linnakangas writes: > On 05/16/2014 06:43 PM, Tom Lane wrote: >> Dunno what's the problem for the varlena types, but that's a completely >> separate code path. > It seems to be a similar issue to what I fixed in the bit type earlier. > When the lower+upper keys are stored as one varlen Da

Re: [HACKERS] btree_gist macaddr valgrind woes

Heikki Linnakangas writes: > ISTM the "correct" fix would be to define a gbtreekey12 data type and > use that. That's not back-patchable though, and introducing a whole new > type to save a few bytes is hardly worth it. What you did makes sense. BTW, the *real* problem with all this stuff is th

Re: [HACKERS] Re: pg_basebackup: could not get transaction log end position from server: FATAL: could not open file "./pg_hba.conf~": Permission denied

On 05/16/2014 08:11 PM, David G Johnston wrote: Can we simply backup the non-data parts of $PGDATA first then move onto the data-parts? For the files that we'd be dealing with it would be sufficiently quick to just try and fail, immediately, then check for all possible preconditions first. The

Re: [HACKERS] btree_gist macaddr valgrind woes

Hi, On 2014-05-16 15:31:52 -0400, Tom Lane wrote: > Heikki Linnakangas writes: > > On 05/16/2014 06:43 PM, Tom Lane wrote: > >> Dunno what's the problem for the varlena types, but that's a completely > >> separate code path. > > > It seems to be a similar issue to what I fixed in the bit type ea

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

Andres Freund writes: > On 2014-05-16 14:51:01 -0400, Tom Lane wrote: >> Ah, you're right, so sprintf shouldn't attempt to truncate the data >> anywhere. Nonetheless, this has created a hazard that wasn't there >> before: with any padding spec, sprintf has to determine the >> width-in-characters

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

On 2014-05-16 15:44:53 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-05-16 14:51:01 -0400, Tom Lane wrote: > >> Ah, you're right, so sprintf shouldn't attempt to truncate the data > >> anywhere. Nonetheless, this has created a hazard that wasn't there > >> before: with any padding sp

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

Andres Freund writes: > On 2014-05-16 15:44:53 -0400, Tom Lane wrote: >> But according to previous research, we don't >> really guarantee that glibc thinks the encoding is what we think, anyway. >> The commit messages for 54cd4f04576833abc394e131288bf3dd7dcf4806 and >> ed437e2b27c48219a78f3504b0d0

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

On 2014-05-16 16:19:28 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2014-05-16 15:44:53 -0400, Tom Lane wrote: > >> But according to previous research, we don't > >> really guarantee that glibc thinks the encoding is what we think, anyway. > >> The commit messages for 54cd4f04576833abc394

[HACKERS] CREATE REPLICATION SLOT fails on a timeout

I am finding that my logical walsender connections are being terminated due to a timeout on the CREATE REPLICATION SLOT command. with "terminating walsender process due to replication timeout" Below is the stack trace when this happens #3 0x0067df28 in WalSndCheckTimeOut (now=now@ent

Re: [HACKERS] CREATE REPLICATION SLOT fails on a timeout

Hi, On 2014-05-16 16:37:16 -0400, Steve Singer wrote: > I am finding that my logical walsender connections are being terminated due > to a timeout on the CREATE REPLICATION SLOT command. with "terminating > walsender process due to replication timeout" > > Below is the stack trace when this happe

Re: [HACKERS] CREATE REPLICATION SLOT fails on a timeout

On 05/16/2014 04:43 PM, Andres Freund wrote: Hi, I don't think that's going to cut it though. The creation can take longer than whatever wal_sender_timeout is set to (when there's lots of longrunning transactions). I think checking whether last_reply_timestamp = 0 during timeout checking is more

Re: [HACKERS] SKIP LOCKED DATA (work in progress)

On 16 May 2014 13:21, Craig Ringer wrote: > On 05/16/2014 04:46 PM, Craig Ringer wrote: > > > > I'll follow up with the patch and a git tree when it's ready, hopefully > > tonight. > > Here's a rebased version of Simon's original patch that runs on current > master. > > I still need to merge the

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

Hi, On 2014-05-16 19:54:56 +0200, Andres Freund wrote: > Hi, > > elog.c's log_line_prefix() processes %d with: > case 'd': > if (MyProcPort) > { > const char *dbname = MyProcPort->database_name; > > if (dbname ==

[HACKERS] 9.4 checksum error in recovery with btree index

More fun with my torn page injection test program on 9.4. 24171 2014-05-16 14:00:44.934 PDT:WARNING: 01000: page verification failed, calculated checksum 21100 but expected 3356 24171 2014-05-16 14:00:44.934 PDT:CONTEXT: xlog redo split_l: rel 1663/16384/16405 left 35191, right 35652, next 346

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

Andres Freund writes: >> It's imo pretty annoying that neither bgworkers nor autovacuum workers >> show the proper database in the log. Why don't we just populate a global >> variable in InitPostgres() once we're sure which database the backend is >> connected to? We could fill fake MyProcPorts, b

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

On 2014-05-16 17:48:28 -0400, Tom Lane wrote: > Andres Freund writes: > >> It's imo pretty annoying that neither bgworkers nor autovacuum workers > >> show the proper database in the log. Why don't we just populate a global > >> variable in InitPostgres() once we're sure which database the backend

Re: [HACKERS] %d in log_line_prefix doesn't work for bg/autovacuum workers

On 2014-05-17 00:17:46 +0200, Andres Freund wrote: > On 2014-05-16 17:48:28 -0400, Tom Lane wrote: > > This is basically reintroducing a variable that used to exist and was > > intentionally gotten rid of, on the grounds that it'd fail to track > > any renaming of the session's current database (cf

Re: [HACKERS] CREATE REPLICATION SLOT fails on a timeout

On 2014-05-16 17:02:33 -0400, Steve Singer wrote: > >I don't think that's going to cut it though. The creation can take > >longer than whatever wal_sender_timeout is set to (when there's lots of > >longrunning transactions). I think checking whether last_reply_timestamp > >= 0 during timeout checki

Re: [HACKERS] Scaling shared buffer eviction

On Fri, May 16, 2014 at 10:51 AM, Amit Kapila wrote: > > > Thrds (64) Thrds (128) HEAD 45562 17128 HEAD + 64 57904 32810 V1 + 64 > 105557 81011 HEAD + 128 58383 32997 V1 + 128 110705 114544 > I haven't actually reviewed the code, but this sort of thing seems like good evidence that we need y

Re: [HACKERS] Scaling shared buffer eviction

On Fri, May 16, 2014 at 7:51 AM, Amit Kapila wrote: > shared_buffers= 8GB > scale factor = 3000 > RAM - 64GB > > > Thrds (64) Thrds (128) HEAD 45562 17128 HEAD + 64 57904 32810 V1 + 64 > 105557 81011 HEAD + 128 58383 32997 V1 + 128 110705 114544 > > shared_buffers= 8GB > scale factor = 10

Re: [HACKERS] Scaling shared buffer eviction

On Sat, May 17, 2014 at 6:29 AM, Peter Geoghegan wrote: > > > On Fri, May 16, 2014 at 7:51 AM, Amit Kapila wrote: >> >> shared_buffers= 8GB >> scale factor = 3000 >> RAM - 64GB > > I'm having a little trouble following this. These figure are transactions per second for a 300 second pgbench tpc-

Re: [HACKERS] Scaling shared buffer eviction

On Sat, May 17, 2014 at 6:02 AM, Robert Haas wrote: > > I haven't actually reviewed the code, but this sort of thing seems like good evidence that we need your patch, or something like it. The fact that the patch produces little performance improvement on it's own (though it does produce some) sh

Re: [HACKERS] SKIP LOCKED DATA (work in progress)

On 05/17/2014 05:24 AM, Thomas Munro wrote: > I noticed that in applyLockingClause, Simon has "rc->waitMode |= > waitMode". Is that right? The values are 0, 1, and 2, but if you had > both NOWAIT and SKIP LOCKED somewhere in your query you could up with > rc->waitMode == 3 unless I'm mistaken. I