Re: [HACKERS] TAP test breakage on MacOS X

2014-10-31 Thread Tom Lane
Noah Misch n...@leadboat.com writes: On Thu, Oct 30, 2014 at 10:49:33PM -0400, Tom Lane wrote: I think the installs as such aren't the only reason for the sucky performance. We need to also reduce the number of initdb cycles incurred by the TAP tests. It's useless for example that the

Re: [HACKERS] tracking commit timestamps

2014-10-31 Thread Andres Freund
On 2014-10-31 14:55:11 +0900, Michael Paquier wrote: On Tue, Oct 28, 2014 at 9:25 PM, Simon Riggs si...@2ndquadrant.com wrote: On 13 October 2014 10:05, Petr Jelinek p...@2ndquadrant.com wrote: I worked bit on this patch to make it closer to committable state. Here is updated

Re: [HACKERS] pg_receivexlog --status-interval add fsync feedback

2014-10-31 Thread furuyao
We seem to be going in circles. You suggested having two options, --feedback, and --fsync, which is almost exactly what Furuya posted originally. I objected to that, because I think that user interface is too complicated. Instead, I suggested having just a single option called

Re: [HACKERS] Lockless StrategyGetBuffer() clock sweep

2014-10-31 Thread Amit Kapila
On Thu, Oct 30, 2014 at 5:01 PM, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-30 10:23:56 +0530, Amit Kapila wrote: I have a feeling that this might also have some regression at higher loads (like scale_factor = 5000, shared_buffers = 8GB, client_count = 128, 256) for the similar

[HACKERS] Tweaking Foreign Keys for larger tables

2014-10-31 Thread Simon Riggs
Various ways of tweaking Foreign Keys are suggested that are helpful for larger databases. * Deferrable Enforcement Timing Clause * NOT DEFERRABLE - immediate execution * DEFERRABLE *INITIALLY IMMEDIATE - existing *INITIALLY DEFERRED - existing *INITIALLY NOT ENFORCED FK created, but

[HACKERS] Reducing Catalog Locking

2014-10-31 Thread Simon Riggs
Recent work on parallel query has opened my eyes to exactly how frequently we request locks on various catalog tables. (Attached file is a lock analysis on a representative Pg server). Given these are catalog tables, we aren't doing much to them that requires a strong lock. Specifically, only

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Simon Riggs
On 31 October 2014 04:42, Amit Kapila amit.kapil...@gmail.com wrote: In fact it would be more sensible to lock the toast table earlier. It might make some sense to lock the toast table earlier for this particular case, but I don't think in general it will be feasible to lock all the tables

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Robert Haas
On Fri, Oct 31, 2014 at 6:41 AM, Simon Riggs si...@2ndquadrant.com wrote: Is it genuinely required for most parallel operations? I think it's clear that none of us knows the answer. Sure, the general case needs it, but is the general case the same thing as the reasonably common case? Well, I

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Robert Haas
On Fri, Oct 31, 2014 at 6:35 AM, Simon Riggs si...@2ndquadrant.com wrote: Recent work on parallel query has opened my eyes to exactly how frequently we request locks on various catalog tables. (Attached file is a lock analysis on a representative Pg server). That analysis is interesting.

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Andres Freund
On 2014-10-31 08:54:54 -0400, Robert Haas wrote: On Fri, Oct 31, 2014 at 6:41 AM, Simon Riggs si...@2ndquadrant.com wrote: Is it genuinely required for most parallel operations? I think it's clear that none of us knows the answer. Sure, the general case needs it, but is the general case the

Re: [HACKERS] TAP test breakage on MacOS X

2014-10-31 Thread Andrew Dunstan
On 10/30/2014 09:17 PM, Andres Freund wrote: On 2014-10-30 21:03:43 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-10-30 20:13:53 -0400, Tom Lane wrote: As I said upthread, that approach seems to me to be contrary to the project policy about how configure should

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: Recent work on parallel query has opened my eyes to exactly how frequently we request locks on various catalog tables. (Attached file is a lock analysis on a representative Pg server). Given these are catalog tables, we aren't doing much to them that

Re: [HACKERS] Missing FIN_CRC32 calls in logical replication code

2014-10-31 Thread Andres Freund
On 2014-10-27 09:30:33 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-10-27 12:51:44 +0200, Heikki Linnakangas wrote: replication/slot.c and replication/logical/snapbuild.c use a CRC on the physical slot and snapshot files. It uses the same algorithm as used

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On a related note, I've previously had the thought that it would be nice to have a big DDL lock - that is, a lock that prevents concurrent DDL without preventing anything else - so that pg_dump could get just that one lock and then not worry about the

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Andres Freund
On 2014-10-31 09:48:52 -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On a related note, I've previously had the thought that it would be nice to have a big DDL lock - that is, a lock that prevents concurrent DDL without preventing anything else - so that pg_dump could

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Robert Haas
On Fri, Oct 31, 2014 at 9:54 AM, Andres Freund and...@2ndquadrant.com wrote: But more to the point, this seems like optimizing pg_dump startup by adding overhead everywhere else, which doesn't really sound like a great tradeoff to me. Well, it'd finally make pg_dump correct under concurrent

Re: [HACKERS] tracking commit timestamps

2014-10-31 Thread Merlin Moncure
On Tue, Dec 10, 2013 at 2:48 PM, Robert Haas robertmh...@gmail.com wrote: Speaking of the functionality this does offer, it seems pretty limited. A commit timestamp is nice, but it isn't very interesting on its own. You really also want to know what the transaction did, who ran it, etc. ISTM

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: On 2014-10-31 09:48:52 -0400, Tom Lane wrote: But more to the point, this seems like optimizing pg_dump startup by adding overhead everywhere else, which doesn't really sound like a great tradeoff to me. Well, it'd finally make pg_dump correct

Re: [HACKERS] tracking commit timestamps

2014-10-31 Thread Tom Lane
Merlin Moncure mmonc...@gmail.com writes: It's also requested now and then in the context of auditing and forensic analysis of application problems. But I also agree that the tolerance for performance overhead is got to be quite low. If a GUC is introduced to manage the tradeoff, it should

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Robert Haas
On Fri, Oct 31, 2014 at 9:07 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-31 08:54:54 -0400, Robert Haas wrote: On Fri, Oct 31, 2014 at 6:41 AM, Simon Riggs si...@2ndquadrant.com wrote: Is it genuinely required for most parallel operations? I think it's clear that none of us

[HACKERS] CREATE INDEX CONCURRENTLY?

2014-10-31 Thread Mark Woodward
I have not kept up with PostgreSQL changes and have just been using it. A co-worker recently told me that you need to word CONCURRENTLY in CREATE INDEX to avoid table locking. I called BS on this because to my knowledge PostgreSQL does not lock tables. I referenced this page in the documentation:

Re: [HACKERS] infinite loop in _bt_getstackbuf

2014-10-31 Thread Robert Haas
On Thu, Oct 30, 2014 at 11:45 PM, Noah Misch n...@leadboat.com wrote: Given the lack of prior complaints about this loop, I'm not sure I see the need to work harder than that; corruption of this sort must be quite rare. Looks like _bt_getstackbuf() is always called with some buffer lock held,

Re: [HACKERS] tracking commit timestamps

2014-10-31 Thread Petr Jelinek
On 31/10/14 15:07, Tom Lane wrote: Merlin Moncure mmonc...@gmail.com writes: It's also requested now and then in the context of auditing and forensic analysis of application problems. But I also agree that the tolerance for performance overhead is got to be quite low. If a GUC is introduced

Re: [HACKERS] Column Redaction

2014-10-31 Thread Simon Riggs
On 16 October 2014 01:29, Claudio Freire klaussfre...@gmail.com wrote: But in any case, if the deterrence isn't enough, and you get attacked, anything involving redaction as fleshed out in the OP is good for nothing. The damage has been done already. The feature doesn't meaningfully slow down

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Andres Freund
On 2014-10-31 10:08:59 -0400, Robert Haas wrote: On Fri, Oct 31, 2014 at 9:07 AM, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-31 08:54:54 -0400, Robert Haas wrote: On Fri, Oct 31, 2014 at 6:41 AM, Simon Riggs si...@2ndquadrant.com wrote: Is it genuinely required for most

Re: [HACKERS] CREATE INDEX CONCURRENTLY?

2014-10-31 Thread Andrew Dunstan
On 10/31/2014 10:28 AM, Mark Woodward wrote: I have not kept up with PostgreSQL changes and have just been using it. A co-worker recently told me that you need to word CONCURRENTLY in CREATE INDEX to avoid table locking. I called BS on this because to my knowledge PostgreSQL does not lock

Re: [HACKERS] CREATE INDEX CONCURRENTLY?

2014-10-31 Thread Greg Stark
On Fri, Oct 31, 2014 at 2:28 PM, Mark Woodward mark.woodw...@actifio.com wrote: I have not kept up with PostgreSQL changes and have just been using it. A co-worker recently told me that you need to word CONCURRENTLY in CREATE INDEX to avoid table locking. I called BS on this because to my

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Simon Riggs
On 31 October 2014 13:39, Tom Lane t...@sss.pgh.pa.us wrote: I doubt that this can ever be safe, because it will effectively assume that all operations on catalog tables are done by code that knows that it is accessing a catalog. What about manual DML, or even DDL, on a catalog? I've never

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Andres Freund
On 2014-10-31 10:02:28 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-10-31 09:48:52 -0400, Tom Lane wrote: But more to the point, this seems like optimizing pg_dump startup by adding overhead everywhere else, which doesn't really sound like a great tradeoff

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Simon Riggs
On 31 October 2014 13:03, Robert Haas robertmh...@gmail.com wrote: Given these are catalog tables, we aren't doing much to them that requires a strong lock. Specifically, only CLUSTER and VACUUM FULL touch those tables like that. When we do that, pretty much everything else hangs, cos you

[HACKERS] Temp tables, pg_class_temp and AccessExclusiveLocks

2014-10-31 Thread Simon Riggs
While investigating how to reduce logging of AccessExclusiveLocks for temp tables, I came up with the attached patch. My feeling was that's an ugly patch, but it set me thinking that a more specialised code path around temp tables could be useful in other ways, and therefore worth pursuing

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Simon Riggs
On 31 October 2014 12:54, Robert Haas robertmh...@gmail.com wrote: 1. Turing's theorem being what it is, predicting what catalog tables the child might lock is not necessarily simple. The Pareto principle offers ways to cope with the world's lack of simplicity. You mentioned earlier that

Re: [HACKERS] Temp tables, pg_class_temp and AccessExclusiveLocks

2014-10-31 Thread Simon Riggs
On 31 October 2014 14:53, Simon Riggs si...@2ndquadrant.com wrote: While investigating how to reduce logging of AccessExclusiveLocks for temp tables, I came up with the attached patch. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: [HACKERS] Reducing Catalog Locking

2014-10-31 Thread Simon Riggs
On 31 October 2014 14:49, Andres Freund and...@2ndquadrant.com wrote: On 2014-10-31 10:02:28 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2014-10-31 09:48:52 -0400, Tom Lane wrote: But more to the point, this seems like optimizing pg_dump startup by adding

Re: [HACKERS] Add shutdown_at_recovery_target option to recovery.conf

2014-10-31 Thread Petr Jelinek
Hi, Attached is the v2 of the patch with the review comments addressed (see below). On 29/10/14 21:08, Petr Jelinek wrote: On 29/10/14 20:27, Asif Naeem wrote: 1. It seems that following log message need to be more descriptive about reason for shutdown i.e. + if

Re: [HACKERS] tracking commit timestamps

2014-10-31 Thread Petr Jelinek
Hi, On 28/10/14 13:25, Simon Riggs wrote: On 13 October 2014 10:05, Petr Jelinek p...@2ndquadrant.com wrote: I worked bit on this patch to make it closer to committable state. Here is updated version that works with current HEAD for the October committfest. I've reviewed this and it

[HACKERS] why does LIMIT 2 take orders of magnitude longer than LIMIT 1 in this query?

2014-10-31 Thread Chris Rogers
I'm on PostgreSQL 9.3. This should reproduce on any table with 100,000+ rows. The EXPLAIN ANALYZE shows many more rows getting scanned with LIMIT 2, but I can't figure out why. Limit 1: EXPLAIN ANALYZE WITH base AS ( SELECT *, ROW_NUMBER() OVER () AS rownum FROM a_big_table ), filter AS (

Re: [HACKERS] tracking commit timestamps

2014-10-31 Thread Simon Riggs
On 31 October 2014 15:46, Petr Jelinek p...@2ndquadrant.com wrote: Attached version with the above comments near the relevant code. Looks cooked and ready to serve. Who's gonna commit this? Alvaro, or do you want me to? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL

[HACKERS] Re: why does LIMIT 2 take orders of magnitude longer than LIMIT 1 in this query?

2014-10-31 Thread David G Johnston
Chris Rogers wrote I'm on PostgreSQL 9.3. This should reproduce on any table with 100,000+ rows. The EXPLAIN ANALYZE shows many more rows getting scanned with LIMIT 2, but I can't figure out why. EXPLAIN ANALYZE WITH base AS ( SELECT *, ROW_NUMBER() OVER () AS rownum FROM a_big_table

Re: [HACKERS] why does LIMIT 2 take orders of magnitude longer than LIMIT 1 in this query?

2014-10-31 Thread Tom Lane
Chris Rogers teuk...@gmail.com writes: I'm on PostgreSQL 9.3. This should reproduce on any table with 100,000+ rows. The EXPLAIN ANALYZE shows many more rows getting scanned with LIMIT 2, but I can't figure out why. This is not -hackers material. The first row pulled from the nestloop LEFT

Re: [HACKERS] CREATE IF NOT EXISTS INDEX

2014-10-31 Thread Adam Brightwell
All, FWIW, I've cleanly applied v8 of this patch to master (252e652) and check-world was successful. I also successfully ran through a few manual test cases. -Adam -- Adam Brightwell - adam.brightw...@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com

Re: [HACKERS] CREATE IF NOT EXISTS INDEX

2014-10-31 Thread Fabrízio de Royes Mello
On Fri, Oct 31, 2014 at 2:46 PM, Adam Brightwell adam.brightw...@crunchydatasolutions.com wrote: All, FWIW, I've cleanly applied v8 of this patch to master (252e652) and check-world was successful. I also successfully ran through a few manual test cases. Thanks for your review! Regards,

Re: [HACKERS] CREATE INDEX CONCURRENTLY?

2014-10-31 Thread Michael Banck
Am Freitag, den 31.10.2014, 14:43 + schrieb Greg Stark: On Fri, Oct 31, 2014 at 2:28 PM, Mark Woodward mark.woodw...@actifio.com wrote: I have not kept up with PostgreSQL changes and have just been using it. A co-worker recently told me that you need to word CONCURRENTLY in CREATE

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Robert Haas
On Fri, Oct 31, 2014 at 10:38 AM, Andres Freund and...@2ndquadrant.com wrote: I have serious doubts about the number of cases where it's correct to access relations in a second backend that are exclusively locked. Not so much when that happens for a user issued LOCK statement of course, but

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Simon Riggs
On 31 October 2014 18:29, Robert Haas robertmh...@gmail.com wrote: Suppose somebody fires off a parallel sort on a text column, or a parallel sequential scan involving a qual of the form textcol = 'zog'. We launch a bunch of workers to do comparisons; they do lookups against pg_collation.

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Robert Haas
On Fri, Oct 31, 2014 at 11:02 AM, Simon Riggs si...@2ndquadrant.com wrote: You mentioned earlier that functions would need to be marked proisparallel etc.. What conditions will that be protecting against? If we aren't going to support the general case where every single thing works, can we

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Andres Freund
On 2014-10-31 14:29:57 -0400, Robert Haas wrote: On Fri, Oct 31, 2014 at 10:38 AM, Andres Freund and...@2ndquadrant.com wrote: I have serious doubts about the number of cases where it's correct to access relations in a second backend that are exclusively locked. Not so much when that

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Robert Haas
On Fri, Oct 31, 2014 at 2:46 PM, Simon Riggs si...@2ndquadrant.com wrote: On 31 October 2014 18:29, Robert Haas robertmh...@gmail.com wrote: Suppose somebody fires off a parallel sort on a text column, or a parallel sequential scan involving a qual of the form textcol = 'zog'. We launch a

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Robert Haas
On Fri, Oct 31, 2014 at 3:32 PM, Andres Freund and...@2ndquadrant.com wrote: So just refusing parallelism as soon as anything has taken an access exclusive lock doesn't sound too bad to me. That restriction seems onerous to me; for example, it would prevent a parallel sort for CLUSTER or a

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Andres Freund
On 2014-10-31 15:56:42 -0400, Robert Haas wrote: On Fri, Oct 31, 2014 at 3:32 PM, Andres Freund and...@2ndquadrant.com wrote: So just refusing parallelism as soon as anything has taken an access exclusive lock doesn't sound too bad to me. That restriction seems onerous to me; for

Re: [HACKERS] DISTINCT with btree skip scan

2014-10-31 Thread Thomas Munro
On 27 October 2014 20:24, David Rowley dgrowle...@gmail.com wrote: I've had a quick look at this and it seems like a great win! I'm quite surprised that we've not got this already. I think this technology could also really help performance of queries such as SELECT * from bigtable bt WHERE

Re: [HACKERS] alter user/role CURRENT_USER

2014-10-31 Thread Adam Brightwell
All, I agree that we should probably seperate the concerns here. Personally, I like the idea of being able to say CURRENT_USER in utility commands to refer to the current user where a role would normally be expected, as I could see it simplifying things for some applications, but that's a

[HACKERS] Let's drop two obsolete features which are bear-traps for novices

2014-10-31 Thread Josh Berkus
PostgreSQL has two bits of obsolete, incomplete functionality which entrap and frustrate new users in large numbers. Both of these features share the following characteristics: * added more than 10 years ago * have the same names as useful features from other databases * were never finished and

Re: [HACKERS] Let's drop two obsolete features which are bear-traps for novices

2014-10-31 Thread Tom Lane
Josh Berkus j...@agliodbs.com writes: Of course, I'm talking about the MONEY type and hash indexes (not the hash ops class, which is useful, just the index type). It's time to put both of these features out to pasture. Certainly neither of theise features would be accepted into PostgreSQL

Re: [HACKERS] _mdfd_getseg can be expensive

2014-10-31 Thread Andres Freund
Hi, On 2014-03-31 12:10:01 +0200, Andres Freund wrote: I recently have seen some perf profiles in which _mdfd_getseg() was in the top #3 when VACUUMing large (~200GB) relations. Called by mdread(), mdwrite(). Looking at it's implementation, I am not surprised. It iterates over all segment

Re: [HACKERS] tracking commit timestamps

2014-10-31 Thread Michael Paquier
On Sat, Nov 1, 2014 at 1:15 AM, Simon Riggs si...@2ndquadrant.com wrote: On 31 October 2014 15:46, Petr Jelinek p...@2ndquadrant.com wrote: Attached version with the above comments near the relevant code. Looks cooked and ready to serve. Who's gonna commit this? Alvaro, or do you want me

Re: [HACKERS] _mdfd_getseg can be expensive

2014-10-31 Thread Tom Lane
Andres Freund and...@2ndquadrant.com writes: I wrote the attached patch that get rids of that essentially quadratic behaviour, by replacing the mdfd chain/singly linked list with an array. Since we seldomly grow files by a whole segment I can't see the slightly bigger memory reallocations

Re: [HACKERS] _mdfd_getseg can be expensive

2014-10-31 Thread Andres Freund
On 2014-10-31 18:48:45 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: I wrote the attached patch that get rids of that essentially quadratic behaviour, by replacing the mdfd chain/singly linked list with an array. Since we seldomly grow files by a whole segment I can't

Re: [HACKERS] pg_background (and more parallelism infrastructure patches)

2014-10-31 Thread Jim Nasby
On 10/24/14, 6:17 PM, Jim Nasby wrote: - Does anyone have a tangible suggestion for how to reduce the code duplication in patch #6? Between execute_sql_string() and tcop/exec_simple_query()? Is there stuff in exec_simple that's not safe for bgwriter? I'm not seeing why we can't use

Re: [HACKERS] infinite loop in _bt_getstackbuf

2014-10-31 Thread Noah Misch
On Fri, Oct 31, 2014 at 10:29:53AM -0400, Robert Haas wrote: On Thu, Oct 30, 2014 at 11:45 PM, Noah Misch n...@leadboat.com wrote: Given the lack of prior complaints about this loop, I'm not sure I see the need to work harder than that; corruption of this sort must be quite rare. Looks

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Robert Haas
On Fri, Oct 31, 2014 at 4:10 PM, Andres Freund and...@2ndquadrant.com wrote: I don't think that's correct. We only need to process local invalidation messages after CommandCounterIncrement(), which I anticipate prohibiting during parallel execution (short thought should convince you that

Re: [HACKERS] Let's drop two obsolete features which are bear-traps for novices

2014-10-31 Thread Eric Ridge
On Fri, Oct 31, 2014 at 6:07 PM, Tom Lane t...@sss.pgh.pa.us wrote: I don't know if/when that will happen as such, but Simon was making noises about writing code to treat hash indexes as unlogged automatically, which would more or less fix the worst risks. That's not just a special case for

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Simon Riggs
On 31 October 2014 19:36, Robert Haas robertmh...@gmail.com wrote: It's an obscure case and its not the only solution either. I don't think that's an obscure situation at all. Do you really think a patch that could cause an attempt to VACUUM FULL a system catalog to suffer an undetected

Re: [HACKERS] group locking: incomplete patch, just for discussion

2014-10-31 Thread Simon Riggs
On 31 October 2014 18:47, Robert Haas robertmh...@gmail.com wrote: On Fri, Oct 31, 2014 at 11:02 AM, Simon Riggs si...@2ndquadrant.com wrote: You mentioned earlier that functions would need to be marked proisparallel etc.. What conditions will that be protecting against? If we aren't going