Re: [HACKERS] extend pgbench expressions with functions

Hello Michael, Thanks for your remarks. + double constants such as 3.14156, You meant perhaps 3.14159 :) Indeed! + max(i, ...) + integer Such function declarations are better with optional arguments listed within brackets. Why not. I did it that way because this is the

[HACKERS] A question regarding LWLock in ProcSleep

Hi there, In function ProcSleep, after the process has been waken up, either with lock granted or deadlock detected, it would re-acquire the lock table's partition LWLock. The code episode is here: /* * Re-acquire the lock table's partition lock. We have to do this to hold * off

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Dec 17, 2015 at 7:24 PM, Michael Paquier wrote: > On Thu, Dec 17, 2015 at 3:06 PM, Kyotaro HORIGUCHI > wrote: >> At Mon, 14 Dec 2015 14:13:02 +0900, Michael Paquier >> wrote in >>

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Wed, Dec 9, 2015 at 12:14 AM, Robert Haas wrote: > On Wed, Dec 2, 2015 at 6:45 AM, Rushabh Lathia > wrote: > > Thanks Ashutosh. > > > > Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch > > looks good to me. > > This patch needs a

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Wed, Dec 16, 2015 at 8:39 PM, Tomas Vondra wrote: > Hi, > > On 12/01/2015 10:34 AM, Shulgin, Oleksandr wrote: > >> >> I have the plans to make something from this on top of >> pg_stat_statements and auto_explain, as I've mentioned last time. The >> next

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On Tue, Dec 15, 2015 at 11:30 PM, Tomas Vondra wrote: > > Attached is a spreadsheet with results for various work_mem values, and > also with a smaller data set (just 30M rows in the fact table), which > easily fits into memory. Yet it shows similar gains, shaving

Re: [HACKERS] extend pgbench expressions with functions

(2a) remove double stuff, just keep integer functions. I would rather keep min/max, though. (2a) sounds like a fine plan to get something committable. We could keep min/max/abs, and remove sqrt/pi. What's actually the use case for debug? I cannot wrap my mind on one? It was

Re: [HACKERS] parallel joins, and better parallel explain

On Wed, Dec 17, 2015 at 11:03 AM Amit Kapila wrote: > While looking at plans of Q5 and Q7, I have observed that Gather is > pushed below another Gather node for which we don't have appropriate > way of dealing. I think that could be the reason why you are seeing > the

Re: [HACKERS] pg_tables bug?

Gaetano Mendola writes: > I'm playing around with tablespace (postgresq 9.4) and I found out what I > believe is a bug in pg_tables. > Basically if you create a database in a table space X and then you create a > table on the database the table is created correctly on the

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 17 December 2015 at 19:11, Simon Riggs wrote: > On 17 December 2015 at 00:17, Tomas Vondra > wrote: > >> I'd go with match_first_tuple_only. > > > +1 > > unique_inner is a state that has been detected, match_first_tuple_only is > the

Re: [HACKERS] Clarify vacuum verbose message

On Tue, Dec 15, 2015 at 9:19 PM, Jim Nasby wrote: > VACUUM VERBOSE spits out two different messages for the heap, one of which > is rather confusing: > > INFO: "trades": removed 625664 row versions in 20967 pages > ... > INFO: "trades": found 3282 removable, 56891627

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Tue, Dec 15, 2015 at 7:25 AM, Andres Freund wrote: > On 2015-12-11 17:00:01 +0300, Aleksander Alekseev wrote: >> The problem is that code between LWLockAcquire (lock.c:881) and >> LWLockRelease (lock.c:1020) can _sometimes_ run up to 3-5 ms. Using >> old-good gettimeofday

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On 12/17/2015 11:44 AM, Simon Riggs wrote: My understanding is that the bloom filter would be ineffective in any of these cases * Hash table is too small Yes, although it depends what you mean by "too small". Essentially if we can do with a single batch, then it's cheaper to do a single

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

> It'd really like to see it being replaced by a queuing lock > (i.e. lwlock) before we go there. And then maybe partition the > freelist, and make nentries an atomic. I believe I just implemented something like this (see attachment). The idea is to partition PROCLOCK hash table manually into

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

Hi, On 12/17/2015 10:50 AM, Shulgin, Oleksandr wrote: On Tue, Dec 15, 2015 at 11:30 PM, Tomas Vondra > wrote: Attached is a spreadsheet with results for various work_mem values, and also with a smaller data set (just 30M rows

Re: Using a single standalone-backend run in initdb (was Re: [HACKERS] Bootstrap DATA is a pita)

Mark Dilger writes: > I use CREATE RULE within startup files in the fork that I maintain. I have > lots of them, totaling perhaps 50k lines of rule code. I don't think any of > that > code would have a problem with the double-newline separation you propose, > which

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On 2015-12-17 09:47:57 -0500, Robert Haas wrote: > On Tue, Dec 15, 2015 at 7:25 AM, Andres Freund wrote: > > I'd consider using a LWLock instead of a spinlock here. I've seen this > > contended in a bunch of situations, and the queued behaviour, combined > > with directed

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On 10 December 2015 at 20:02, Tom Lane wrote: > Robert Haas writes: >> It seems to be a loss of 4 digits in every case I've seen. > > I wouldn't have a problem with, say, throwing in an extra DEC_DIGITS worth > of rscale in each of these functions so

Re: Fwd: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

On Thu, Dec 17, 2015 at 12:14 PM, Andres Freund wrote: > On 2015-12-17 09:04:25 -0800, Jeff Janes wrote: >> > But I'm somewhat confused what this has to do with Andres's report. >> >> Doesn't it explain the exact situation he is in, where the oldest >> database is 200 million,

Re: Fwd: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

On 2015-12-17 13:08:15 -0500, Robert Haas wrote: > On Thu, Dec 17, 2015 at 12:14 PM, Andres Freund wrote: > > On 2015-12-17 09:04:25 -0800, Jeff Janes wrote: > >> > But I'm somewhat confused what this has to do with Andres's report. > >> > >> Doesn't it explain the exact

Re: [HACKERS] PATCH: postpone building buckets to the end of Hash (in HashJoin)

On Mon, Dec 14, 2015 at 3:04 PM, Tomas Vondra wrote: > attached is v1 of one of the hashjoin improvements mentioned in September in > the lengthy thread [1]. > > The main objection against simply removing the MaxAllocSize check (and > switching to

[HACKERS] psql - -dry-run option

Hi when I read a blog http://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ where is emulated dry-run mode, I though so we can implement it very simply. Notices, comments? Regards Pavel

Re: Fwd: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

On 2015-12-17 09:04:25 -0800, Jeff Janes wrote: > > But I'm somewhat confused what this has to do with Andres's report. > > Doesn't it explain the exact situation he is in, where the oldest > database is 200 million, but the cluster as a whole is 2 billion? There were no crashes, so no, I don't

Re: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

On Thu, Dec 10, 2015 at 1:55 PM, Andres Freund wrote: > > Looking at datfrozenxid: > postgres=# select datname, datfrozenxid, age(datfrozenxid) FROM pg_database ; > datname | datfrozenxid |age > ---+--+--- > template1 | 3357685367 |

Re: [HACKERS] Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?

On Mon, Dec 14, 2015 at 6:08 PM, Tomas Vondra wrote: > So we know that we should expect about > > (prev_wal_bytes - wal_bytes) + (prev_wal_fpw_bytes - wal_fpw_bytes) > > ( regular WAL) + ( FPW WAL ) > > to be produced until

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Wed, Dec 16, 2015 at 4:24 PM, Peter Geoghegan wrote: > On Wed, Dec 16, 2015 at 12:28 PM, Robert Haas > wrote: > >> I seem to be able to produce these sorting patches at a much greater > >> rate than they can be committed, in part because Robert is the

Re: [HACKERS] Inaccurate results from numeric ln(), log(), exp() and pow()

On Thu, Dec 17, 2015 at 10:38 AM, Dean Rasheed wrote: > On 10 December 2015 at 20:02, Tom Lane wrote: >> Robert Haas writes: >>> It seems to be a loss of 4 digits in every case I've seen. >> >> I wouldn't have a problem with,

Fwd: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

Sorry, accidentally failed to include the list originally, here it is for the list: On Dec 16, 2015 9:52 AM, "Robert Haas" wrote: > > On Fri, Dec 11, 2015 at 1:08 PM, Jeff Janes wrote: > > Since changes to datfrozenxid are WAL logged at the time they

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Thu, Dec 17, 2015 at 11:03 AM, Aleksander Alekseev wrote: >> It'd really like to see it being replaced by a queuing lock >> (i.e. lwlock) before we go there. And then maybe partition the >> freelist, and make nentries an atomic. > > I believe I just implemented

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Dec 17, 2015 at 11:47 AM, Michael Paquier wrote: > On Thu, Dec 10, 2015 at 3:31 AM, Robert Haas wrote: >> On Mon, Nov 30, 2015 at 12:58 PM, Bruce Momjian wrote: >>> On Mon, Nov 30, 2015 at 10:48:04PM +0530, Masahiko

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Dec 14, 2015 at 2:57 PM, Kyotaro HORIGUCHI wrote: > Thank you for the new patch. > > At Wed, 9 Dec 2015 20:59:20 +0530, Masahiko Sawada > wrote in >> On Wed, Nov

Re: [HACKERS] psql - -dry-run option

2015-12-17 20:14 GMT+01:00 Pavel Stehule : > > > 2015-12-17 20:03 GMT+01:00 Tom Lane : > >> Pavel Stehule writes: >> > when I read a blog >> > >>

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Thu, Dec 17, 2015 at 9:29 AM, Corey Huinker wrote: > My apologies to Peter and all the Roberts, I wasn't able to set up a test > fast enough. Glad it got committed. I don't use the term "slam-dunk" casually. :-) This was the first time I ever referred to a patch of

Re: [HACKERS] psql - -dry-run option

Joe Conway wrote: > On 12/17/2015 11:58 AM, Christopher Browne wrote: > > On 17 December 2015 at 14:16, Pavel Stehule > > wrote: > >> or different idea - just enforce syntax check without execution. > > > > That seems pretty cool... I'd

Re: [HACKERS] Declarative partitioning

On Mon, Dec 14, 2015 at 2:14 AM, Amit Langote wrote: > Syntax to create a partitioned table (up to 2 levels of partitioning): > > CREATE TABLE foo ( > ... > ) > PARTITION BY R/L ON (key0) > SUBPARTITION BY R/L ON (key1) > [(PARTITION foo_1 FOR VALUES [] [] >

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-12-14 23:09 GMT+01:00 Daniel Verite : > Pavel Stehule wrote: > > > postgres=# \crosstabview 4 +month label > > > > Maybe using optional int order column instead label is better - then you > can > > do sort on client side > > > > so the syntax can be

Re: Fwd: [HACKERS] Cluster "stuck" in "not accepting commands to avoid wraparound data loss"

On Thu, Dec 17, 2015 at 1:20 PM, Andres Freund wrote: > On 2015-12-17 13:08:15 -0500, Robert Haas wrote: >> On Thu, Dec 17, 2015 at 12:14 PM, Andres Freund wrote: >> > On 2015-12-17 09:04:25 -0800, Jeff Janes wrote: >> >> > But I'm somewhat confused what

Re: [HACKERS] psql - -dry-run option

2015-12-17 20:03 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > when I read a blog > > > http://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ > > where is emulated dry-run mode, I though so we

Re: [HACKERS] psql - -dry-run option

On 12/17/2015 11:58 AM, Christopher Browne wrote: > On 17 December 2015 at 14:16, Pavel Stehule > wrote: >> or different idea - just enforce syntax check without execution. > > That seems pretty cool... I'd find "syntax check without

Re: [HACKERS] psql - -dry-run option

Pavel Stehule writes: > when I read a blog > http://www.depesz.com/2015/12/14/waiting-for-9-6-psql-support-multiple-c-and-f-options-and-allow-mixing-them/ > where is emulated dry-run mode, I though so we can implement it very > simply. Not one that is actually reliable.

[HACKERS] broken autocomplete in head

Hi it looks like backslash is ignored, and then autocomplete for backslash commands is off. Regards Pavel

Re: [HACKERS] broken autocomplete in head

Pavel Stehule writes: > it looks like backslash is ignored, and then autocomplete for backslash > commands is off. Turns out adding rl_initialize() did that :-(. Fixed now. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Remove array_nulls?

On Wed, Dec 16, 2015 at 10:48 PM, Jim Nasby wrote: > IIUC, that means supporting backwards compat. GUCs for 10 years, which seems > a bit excessive. Granted, that's about the worse-case scenario for what I > proposed (ie, we'd still be supporting 8.0 stuff right now).

Re: [HACKERS] [PoC] Asynchronous execution again (which is not parallel)

Hi Robert and others, First, I currently don't know the postgresql code well enough yet. I still hope my toughts are usefull. Robert Haas wrote: > It is unclear to me how useful this is beyond ForeignScan, Gather, and > Append. MergeAppend's ordering constraint makes it less useful; we > can

Re: [HACKERS] PATCH: postpone building buckets to the end of Hash (in HashJoin)

Hi, On 12/17/2015 07:20 PM, Robert Haas wrote: ... If this doesn't regress performance in the case where the number of buckets is estimated accurately to begin with, then I think this is a great idea. Can you supply some performance tests results for that case, and maybe some of the other

Re: [HACKERS] broken autocomplete in head

2015-12-17 22:56 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > it looks like backslash is ignored, and then autocomplete for backslash > > commands is off. > > Turns out adding rl_initialize() did that :-(. Fixed now. > Thank you Regards Pavel

Re: [HACKERS] Comment typo in pg_upgrade.c

On 2015/12/18 14:53, Amit Langote wrote: > In prepare_new_cluster(), following looks like a typo: > > - * would cause us to lose the frozenids restored by the load. We use > + * would cause us to lose the frozenxids restored by the load. We use Or maybe not, because "frozenids" is

Re: [HACKERS] Freeze avoidance of very large table.

On Fri, Dec 18, 2015 at 3:17 AM, Masahiko Sawada wrote: > On Thu, Dec 17, 2015 at 11:47 AM, Michael Paquier > wrote: >> make check with pg_upgrade is failing for me: >> Visibility map rewriting test failed >> make: *** [check] Error 1 > > make

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Fri, Dec 18, 2015 at 4:31 PM, Peter Geoghegan wrote: > On Thu, Dec 17, 2015 at 11:06 PM, Michael Paquier > wrote: >> Now per the two points listed in >> the first sentence in this paragraph, perhaps this opinion is fine as >> moot :) I didn't get

[HACKERS] Comment typo in pg_upgrade.c

In prepare_new_cluster(), following looks like a typo: - * would cause us to lose the frozenids restored by the load. We use + * would cause us to lose the frozenxids restored by the load. We use Attached find the patch. Thanks, Amit diff --git a/src/bin/pg_upgrade/pg_upgrade.c

[HACKERS] Typo in the comment above heap_prepare_freeze_tuple()

I think the following may be a typo: * Caller is responsible for ensuring that no other backend can access the * storage underlying this tuple, either by holding an exclusive lock on the - * buffer containing it (which is what lazy VACUUM does), or by having it by + * buffer containing it

Re: [HACKERS] pg_stat_replication log positions vs base backups

On Wed, Dec 16, 2015 at 9:35 PM, Michael Paquier wrote: > On Wed, Dec 16, 2015 at 7:14 PM, Magnus Hagander wrote: >> On Wed, Dec 16, 2015 at 8:34 AM, Michael Paquier >> wrote: >>> Interesting. I got just today a bug

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Thu, Dec 17, 2015 at 4:55 PM, Peter Geoghegan wrote: > On Wed, Dec 16, 2015 at 11:44 PM, Peter Geoghegan wrote: >>> In any case, at this point 9.5 is really aimed to be stabilized, so >>> targeting only master is a far saner approach IMO for this patch. >>>

Re: [HACKERS] Making tab-complete.c easier to maintain

On Thu, Dec 17, 2015 at 6:04 PM, Thomas Munro wrote: > On Thu, Dec 17, 2015 at 7:24 PM, Michael Paquier > wrote: > Kyotaro's suggestion of using a macro NEG x to avoid complicating the > string constants seems good to me. But perhaps

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Thu, Dec 17, 2015 at 11:06 PM, Michael Paquier wrote: >> I should add: I think that the chances of this patch destabilizing the >> code are very slim, once it receives the proper review. Certainly, I >> foresee no possible downside to not inserting the doomed

Re: [HACKERS] Function and view to retrieve WAL receiver status

On Mon, Dec 14, 2015 at 7:23 PM, Michael Paquier wrote: > On Tue, Dec 15, 2015 at 5:27 AM, Gurjeet Singh wrote: >> The function, maybe. But emitting an all-nulls row from a view seems >> counter-intuitive, at least when looking at it in context of relational >>

Re: [HACKERS] extend pgbench expressions with functions

On Thu, Dec 17, 2015 at 10:33 PM, Fabien COELHO wrote: > >>> (2a) remove double stuff, just keep integer functions. >>> I would rather keep min/max, though. >> >> >> (2a) sounds like a fine plan to get something committable. We could keep >> min/max/abs, and remove

Re: [HACKERS] extend pgbench expressions with functions

On Fri, Dec 18, 2015 at 9:08 AM, Michael Paquier wrote: > On Thu, Dec 17, 2015 at 10:33 PM, Fabien COELHO wrote: >> (2a) remove double stuff, just keep integer functions. I would rather keep min/max, though. >>> >>> >>> (2a) sounds

[HACKERS] Small fix in pg_rewind (redundant declaration)

Hello hackers. I've stumbled upon a strange code. In src/bin/pg_rewind/datapagemap.h we decalre: extern void datapagemap_destroy(datapagemap_t *map); But nowhere is implemented. I think the declaration of this function must be removed. I'm not sure that this trivial things needed patch. Thanks.

Re: [HACKERS] extend pgbench expressions with functions

On Thu, Dec 17, 2015 at 6:02 PM, Fabien COELHO wrote: >> Really, I like this patch, and I think that it is great to be able to >> use a set of functions and methods within a pgbench script because >> this clearly can bring more clarity for a developer, still it seems >> that

Re: [HACKERS] pg_tables bug?

On Thu, Dec 17, 2015 at 4:54 PM, Gaetano Mendola wrote: > I'm playing around with tablespace (postgresq 9.4) and I found out what I > believe is a bug in pg_tables. > Basically if you create a database in a table space X and then you create a > table on the database the table

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On 15 December 2015 at 22:30, Tomas Vondra wrote: 3) Currently the bloom filter is used whenever we do batching, but it > should really be driven by selectivity too - it'd be good to (a) > estimate the fraction of 'fact' tuples having a match in the hash

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-12-14 23:09 GMT+01:00 Daniel Verite : > Pavel Stehule wrote: > > > postgres=# \crosstabview 4 +month label > > > > Maybe using optional int order column instead label is better - then you > can > > do sort on client side > > > > so the syntax can be

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-12-14 23:15 GMT+01:00 Daniel Verite : > Pavel Stehule wrote: > > > > here is patch - supported syntax: \crosstabview VCol [+/-]HCol > [HOrderCol] > > > > Order column should to contains any numeric value. Values are sorted on > > client side > > If I

Re: [HACKERS] psql - -dry-run option

On 17 December 2015 at 14:16, Pavel Stehule wrote: > or different idea - just enforce syntax check without execution. That seems pretty cool... I'd find "syntax check without execution" to be pretty useful to test SQL (and especially DDL). -- When confronted by a

Re: [HACKERS] psql - -dry-run option

Christopher Browne writes: > On 17 December 2015 at 14:16, Pavel Stehule wrote: >> or different idea - just enforce syntax check without execution. > That seems pretty cool... I'd find "syntax check without execution" to be > pretty useful to test

Re: [HACKERS] parallel joins, and better parallel explain

On Thu, Dec 17, 2015 at 12:33 AM, Amit Kapila wrote: > While looking at plans of Q5 and Q7, I have observed that Gather is > pushed below another Gather node for which we don't have appropriate > way of dealing. I think that could be the reason why you are seeing > the

Re: [HACKERS] Small fix in pg_rewind (redundant declaration)

On Fri, Dec 18, 2015 at 10:22 AM, Tom Lane wrote: > Done. Thanks. -- Michael -- 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] Small fix in pg_rewind (redundant declaration)

On Thu, Dec 17, 2015 at 9:23 PM, YUriy Zhuravlev wrote: > Hello hackers. > I've stumbled upon a strange code. > In src/bin/pg_rewind/datapagemap.h we decalre: > extern void datapagemap_destroy(datapagemap_t *map); > But nowhere is implemented. I think the declaration

Re: [HACKERS] Small fix in pg_rewind (redundant declaration)

Michael Paquier writes: > On Thu, Dec 17, 2015 at 9:23 PM, YUriy Zhuravlev > wrote: >> Hello hackers. >> I've stumbled upon a strange code. >> In src/bin/pg_rewind/datapagemap.h we decalre: >> extern void datapagemap_destroy(datapagemap_t

Re: [HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

On Wed, Dec 16, 2015 at 12:04 PM, Peter Geoghegan wrote: >> What kind of state is that? Can't we define this in terms of what it >> is rather than how it gets that way? > > It's zeroed. > > I guess we can update everything, including existing comments, to reflect > that.

[HACKERS] [PATCH] Copy-pasteo in logical decoding

Trivial fix for a copy-and-paste error in a logical decoding error callback. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services diff --git a/src/backend/replication/logical/logical.c

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

> Oh, that's an interesting idea. I guess the problem is that if the > freelist is unshared, then users might get an error that the lock > table is full when some other partition still has elements remaining. True, but I don't believe it should be a real problem assuming we have a strong hash

Re: [HACKERS] Relation extension scalability

On Sun, Jul 19 2015 9:37 PM Andres Wrote, > The situation the read() protect us against is that two backends try to > extend to the same block, but after one of them succeeded the buffer is > written out and reused for an independent page. So there is no in-memory > state telling the slower