Re: [HACKERS] inherit support for foreign tables

> (2014/08/28 18:00), Etsuro Fujita wrote: > > (2014/08/22 11:51), Noah Misch wrote: > >> Today's ANALYZE VERBOSE messaging for former inheritance parents > >> (tables with relhassubclass = true but no pg_inherits.inhparent > >> links) is deceptive, and I welcome a fix to omit the spurious > >> mes

Re: [HACKERS] What exactly is our CRC algorithm?

On 11/07/2014 07:08 AM, Amit Kapila wrote: On Tue, Nov 4, 2014 at 3:17 PM, Heikki Linnakangas wrote: On 10/27/2014 06:02 PM, Heikki Linnakangas wrote: I came up with the attached patches. They do three things: 1. Get rid of the 64-bit CRC code. It's not used for anything, and haven't been f

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 2014-11-06 19:03:20 -0600, Jim Nasby wrote: > On 11/6/14, 5:40 PM, Greg Stark wrote: > >On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund wrote: > >>I think the retry logical is a largely pointless complication of already > >>complex enough code. You're fixing a problem for which there is > >>absol

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 2014-11-06 23:40:18 +, Greg Stark wrote: > On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund wrote: > > I think the retry logical is a largely pointless complication of already > > complex enough code. You're fixing a problem for which there is > > absolutely no evidence of its existance. Yes,

Re: [HACKERS] Tweaking Foreign Keys for larger tables

On 6 November 2014 20:47, Alvaro Herrera wrote: > Simon Riggs wrote: ... >> In that case the need for correctness thru locking is minimal. If we >> do lock it will cause very high multixact traffic, so that is worth >> avoiding alone. > > This seems like a can of worms to me. How about the abilit

Re: [HACKERS] Add generate_series(numeric, numeric)

On Tue, Oct 14, 2014 at 3:22 PM, Michael Paquier wrote: > > > On Tue, Oct 7, 2014 at 8:38 AM, Ali Akbar wrote: >> >> 2014-10-06 22:51 GMT+07:00 Marti Raudsepp : >> >> >>> >>> > the one that tests values just before numeric overflow >>> >>> Actually I don't know if that's too useful. I think you s

Re: [HACKERS] inherit support for foreign tables

Hello, I don't fully catch up this topic but tried this one. > >> Here are separated patches. > >> > >> fdw-chk.patch - CHECK constraints on foreign tables > >> fdw-inh.patch - table inheritance with foreign tables > >> > >> The latter has been created on top of [1]. > > > >> [1] > >> http://www

Re: [HACKERS] What exactly is our CRC algorithm?

On Tue, Nov 4, 2014 at 3:17 PM, Heikki Linnakangas wrote: > On 10/27/2014 06:02 PM, Heikki Linnakangas wrote: > >> I came up with the attached patches. They do three things: >> >> 1. Get rid of the 64-bit CRC code. It's not used for anything, and >> haven't been for years, so it doesn't seem wort

Re: [HACKERS] On partitioning

Hi, > ow...@postgresql.org] On Behalf Of Robert Haas > Sent: Tuesday, October 28, 2014 9:20 PM > > On Tue, Oct 28, 2014 at 6:06 AM, Andres Freund > wrote: > > In my opinion we can reuse (some of) the existing logic for INHERITS to > > implement "proper" partitioning, but that should be an imple

Re: [HACKERS] tracking commit timestamps

On 11/01/2014 09:00 PM, Michael Paquier wrote: > 1) It is untested and actually there is no direct use for it in core. > 2) Pushing code that we know as dead is no good, that's a feature more > or less defined as maybe-useful-but-we-are-not-sure-yet-what-to-do-with-it. > 3) If you're going to re-us

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 11/6/14, 5:40 PM, Greg Stark wrote: On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund wrote: I think the retry logical is a largely pointless complication of already complex enough code. You're fixing a problem for which there is absolutely no evidence of its existance. Yes, this happens occasio

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On Thu, Nov 6, 2014 at 9:30 PM, Andres Freund wrote: > I think the retry logical is a largely pointless complication of already > complex enough code. You're fixing a problem for which there is > absolutely no evidence of its existance. Yes, this happens > occasionally. But it's going to be so abs

Re: [HACKERS] split builtins.h to quote.h

On Fri, Nov 7, 2014 at 2:31 AM, Alvaro Herrera wrote: > Julien Rouhaud wrote: > >> I just reviewed this patch : >> >> * applies cleanly to master(d2b8a2c7) >> * all regression tests pass >> >> As it's only moving functions from builtins.h to quote.h and update >> impacted files, nothing special to

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

On 10/16/14 11:34 PM, Craig Ringer wrote: > psql: FATAL: Peer authentication failed for user "fred" > HINT: See the server error log for additional information. I think this is wrong for many reasons. I have never seen an authentication system that responds with, hey, what you just did didn't g

Re: [HACKERS] json, jsonb, and casts

On 11/06/2014 03:58 PM, Tom Lane wrote: Andrew Dunstan writes: In 9.3 we changed the way json generating functions worked by taking account of cast functions to json from non-builtin types, such as hstore. In 9.5 I am proposing to provide similar functionality for jsonb. The patch actually take

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

On Fri, Oct 31, 2014 at 9:07 AM, Andres Freund wrote: > Maybe we can, as a first step, make those edges in the lock graph > visible to the deadlock detector? It's pretty clear that undetected > deadlocks aren't ok, but detectable deadlocks in a couple corner cases > might be acceptable. An intere

Re: [HACKERS] [BUGS] ltree::text not immutable?

Jim Nasby writes: > On 11/5/14, 7:38 PM, Robert Haas wrote: >> I don't understand why you went to all the trouble of building a >> versioning system for extensions if you're not going to use it. > I was about to dismiss this comment since I don't see any real need for a > version bump here, exc

Re: [HACKERS] Tweaking Foreign Keys for larger tables

On 11/6/14, 11:49 AM, David G Johnston wrote: > Constraint would add a statement-level after trigger for insert, > update, delete and trigger, which issues a relcache invalidation if > the state was marked valid. Marked as deferrable initially deferred. I don't think you'd need to

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

On 11/5/14, 8:26 PM, Robert Haas wrote: rhaas=# create table foo (a int); CREATE TABLE rhaas=# select test_group_locking('1.0:start,2.0:start,1.0:lock:AccessExclusiveLock:foo,2.0:lock:AccessExclusiveLock:foo'); NOTICE: starting worker 1.0 NOTICE: starting worker 2.0 NOTICE: instructing worker

Re: [HACKERS] BRIN indexes - TRAP: BadArgument

Jeff Janes wrote: > On Wed, Nov 5, 2014 at 12:54 PM, Alvaro Herrera > wrote: > > Thanks for the updated patch. > > Now when I run the test program (version with better error reporting > attached), it runs fine until I open a psql session and issue: > > reindex table foo; Interesting. This was

Re: [HACKERS] [BUGS] ltree::text not immutable?

On 11/5/14, 7:38 PM, Robert Haas wrote: Attached is a complete patch along these lines. As I suggested earlier, >this just makes the relevant changes in ltree--1.0.sql and >pg_trgm--1.1.sql without bumping their extension version numbers, >since it doesn't seem important enough to justify a vers

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 2014-11-06 14:55:37 -0600, Jim Nasby wrote: > On 10/29/14, 11:49 AM, Jim Nasby wrote: > >On 10/21/14, 6:05 PM, Tom Lane wrote: > >>Jim Nasby writes: > >>>- What happens if we run out of space to remember skipped blocks? > >> > >>You forget some, and are no worse off than today. (This might be

Re: [HACKERS] [BUGS] BUG #11867: Strange behaviour with composite types after resetting database tablespace

On 11/4/14, 10:45 AM, Tom Lane wrote: So it's safe as things stand; but this seems a bit, um, rickety. Should we insert a DropRelFileNodesAllBuffers call into ATExecSetTableSpace to make it safer? It's kind of annoying to have to scan the buffer pool twice, but I'm afraid that sometime in the f

Re: [HACKERS] Tweaking Foreign Keys for larger tables

Alvaro Herrera wrote: > Simon Riggs wrote: >> On 5 November 2014 21:15, Peter Eisentraut wrote: >> ON DELETE IGNORE ON UPDATE IGNORE If we allow this specification then the FK is "one way" - we check the existence of a row in the referenced table, but there is no need for a >>

Re: [HACKERS] Proposal: Log inability to lock pages during vacuum

On 10/29/14, 11:49 AM, Jim Nasby wrote: On 10/21/14, 6:05 PM, Tom Lane wrote: Jim Nasby writes: - What happens if we run out of space to remember skipped blocks? You forget some, and are no worse off than today. (This might be an event worthy of logging, if the array is large enough that we

Re: [HACKERS] json, jsonb, and casts

Andrew Dunstan writes: > In 9.3 we changed the way json generating functions worked by taking > account of cast functions to json from non-builtin types, such as hstore. > In 9.5 I am proposing to provide similar functionality for jsonb. The > patch actually takes account of cast functions to b

Re: [HACKERS] Tweaking Foreign Keys for larger tables

Simon Riggs wrote: > On 5 November 2014 21:15, Peter Eisentraut wrote: > > >> ON DELETE IGNORE > >> ON UPDATE IGNORE > >> If we allow this specification then the FK is "one way" - we check the > >> existence of a row in the referenced table, but there is no need for a > >> trigger on the referenc

[HACKERS] json, jsonb, and casts

In 9.3 we changed the way json generating functions worked by taking account of cast functions to json from non-builtin types, such as hstore. In 9.5 I am proposing to provide similar functionality for jsonb. The patch actually takes account of cast functions to both jsonb and json (with jso

Re: [HACKERS] What exactly is our CRC algorithm?

On 11/04/2014 03:21 PM, Robert Haas wrote: On Tue, Nov 4, 2014 at 4:47 AM, Heikki Linnakangas wrote: I hear none, so committed with some small fixes. Are you going to get the slice-by-N stuff working next, to speed this up? I don't have any concrete plans, but yeah, that would be great. So

Re: [HACKERS] Tweaking Foreign Keys for larger tables

On Thu, Nov 6, 2014 at 10:29 AM, Jim Nasby-5 [via PostgreSQL] < ml-node+s1045698n582596...@n5.nabble.com> wrote: > On 11/6/14, 2:58 AM, Simon Riggs wrote: > > > On 5 November 2014 21:15, Peter Eisentraut <[hidden email] > > wrote: > >> On 10/31

Re: [HACKERS] split builtins.h to quote.h

Julien Rouhaud wrote: > I just reviewed this patch : > > * applies cleanly to master(d2b8a2c7) > * all regression tests pass > > As it's only moving functions from builtins.h to quote.h and update > impacted files, nothing special to add. > > It will probably break some user extensions using qu

Re: [HACKERS] Tweaking Foreign Keys for larger tables

On 11/6/14, 2:58 AM, Simon Riggs wrote: On 5 November 2014 21:15, Peter Eisentraut wrote: On 10/31/14 6:19 AM, Simon Riggs wrote: Various ways of tweaking Foreign Keys are suggested that are helpful for larger databases. *INITIALLY NOT ENFORCED FK created, but is not enforced during DML

Re: [HACKERS] split builtins.h to quote.h

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 14/10/2014 10:00, Michael Paquier a écrit : > On Mon, Oct 13, 2014 at 11:14 PM, Robert Haas > wrote: >> >> IMHO, putting some prototypes for a .c file in one header and >> others in another header is going to make it significantly harder >> to fig

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

On Wed, Nov 5, 2014 at 9:26 PM, Robert Haas wrote: > Yes, I think that's probably a net improvement in robustness quite > apart from what we decide to do about any of the rest of this. I've > attached it here as revise-procglobal-tracking.patch and will commit > that bit if nobody objects. The r

Re: [HACKERS] WAL format and API changes (9.5)

Replying to some of your comments below. The rest were trivial issues that I'll just fix. On 10/30/2014 09:19 PM, Andres Freund wrote: * Is it really a good idea to separate XLogRegisterBufData() from XLogRegisterBuffer() the way you've done it ? If we ever actually get a record with a la

Re: [HACKERS] Amazon Redshift

--On 5. November 2014 23:36:03 +0100 philip taylor wrote: Date Functions http://docs.aws.amazon.com/redshift/latest/dg/r_ADD_MONTHS.html http://docs.aws.amazon.com/redshift/latest/dg/r_DATEADD_function.html http://docs.aws.amazon.com/redshift/latest/dg/r_DATEDIFF_function.html http://docs.

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

Kevin Grittner writes: > Why? This "fix" might not deal with the bigger issues that I > discussed, like that the later-to-start and > later-to-acquire-a-snapshot transaction might logically be first in > the apparent order of execution. You can't "fix" that without a > lot of blocking -- that mo

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On 10/1/14 3:00 AM, Michael Paquier wrote: > - Use of AccessExclusiveLock when swapping relfilenodes of an index and > its concurrent entry instead of ShareUpdateExclusiveLock for safety. At > the limit of my understanding, that's the consensus reached until now. I'm very curious about this point.

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

Greg Sabino Mullane wrote: > Kevin Grittner wrote: > (wording change suggestion) >>> | sees a snapshot as of the start of the first query within the >>> | transaction, not as of the start of the current query within the >>> | transaction. >> >> Would that have prevented the confusion here? > > I

Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: [HACKERS] HEAD seems to generate larger WAL regarding GIN index

On Tue, Nov 4, 2014 at 12:04 PM, Etsuro Fujita wrote: > IIUC, I think that min = 0 disables fast update, so ISTM that it'd be > appropriate to set min to some positive value. And ISTM that the idea of > using the min value of work_mem is not so bad. OK. I changed the min value to 64kB. > *** 35

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Kevin Grittner wrote: (wording change suggestion) >> | sees a snapshot as of the start of the first query within the >> | transaction, not as of the start of the current query within the >> | transaction. > > Would that have prevented the confus

Re: [HACKERS] Order of views in stats docs

On 11/6/14 6:16 AM, Magnus Hagander wrote: > Another thought I had in that case is maybe we need to break out the > pg_stat_activity and pg_stat_replication views into their own table. > They are really the only two views that are different in a lot of > ways. Maybe call the splits "session statist

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

Álvaro Hernández Tortosa wrote: > There has been two comments which seem to state that changing this > may introduce some performance problems and some limitations when you > need to take out some locks. I still believe, however, that current > behavior is confusing for the user. Sure, one op

Re: [HACKERS] initdb -S and tablespaces

At 2014-10-30 14:30:27 +0530, a...@2ndquadrant.com wrote: > > Here's a proposed patch to initdb to make initdb -S fsync everything > under pg_tblspc. Oops, I meant to include the corresponding patch to xlog.c to do the same at startup. It's based on the initdb patch, but modified to not use fprint

Re: [HACKERS] WAL format and API changes (9.5)

On 11/05/2014 11:30 AM, Andres Freund wrote: On 2014-11-04 18:33:34 +0200, Heikki Linnakangas wrote: On 10/30/2014 06:02 PM, Andres Freund wrote: On 2014-10-29 10:24:20 +0200, Heikki Linnakangas wrote: On 10/06/2014 02:29 PM, Andres Freund wrote: I've not yet really looked, but on a quick rea

Re: [HACKERS] Repeatable read and serializable transactions see data committed after tx start

On 06/11/14 02:06, Jim Nasby wrote: On 11/5/14, 6:04 PM, Álvaro Hernández Tortosa wrote: On 05/11/14 17:46, Jim Nasby wrote: On 11/4/14, 6:11 PM, Álvaro Hernández Tortosa wrote: Should we improve then the docs stating this more clearly? Any objection to do this? If we go that route we

Re: [HACKERS] Typo in comment

(2014/11/06 20:04), Fujii Masao wrote: On Thu, Nov 6, 2014 at 7:44 PM, Etsuro Fujita wrote: I ran into a typo in a comment in src/backend/commands/matview.c. Please find attached a patch. Thanks! Applied. Thanks! Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] WAL format and API changes (9.5)

On 11/06/2014 07:57 AM, Amit Kapila wrote: On Wed, Nov 5, 2014 at 2:56 PM, Heikki Linnakangas wrote: On 11/05/2014 09:06 AM, Amit Kapila wrote: 2. XLogRecPtr XLogInsertRecord(XLogRecData *rdata, XLogRecPtr fpw_lsn) So the scenario is that: * XLogRecordAssemble decides that a page doesn't n

Re: [HACKERS] two dimensional statistics in Postgres

Dne 6 Listopad 2014, 12:05, Gavin Flower napsal(a): > On 06/11/14 23:57, Tomas Vondra wrote: >> Dne 6 Listopad 2014, 11:50, Gavin Flower napsal(a): >>> Could you store a 2 dimensional histogram in a one dimensional array: >>> A[z] = value, where z = col * rowSize + row (zero starting index)? >> How

Re: [HACKERS] Order of views in stats docs

On Wed, Nov 5, 2014 at 4:57 PM, Tom Lane wrote: > Magnus Hagander writes: >> http://www.postgresql.org/docs/9.3/static/monitoring-stats.html, table 27-1. >> Can somebody find or explain the order of the views in there? It's not >> actually alphabetical, but it's also not logical. In particular, w

Re: [HACKERS] two dimensional statistics in Postgres

On 06/11/14 23:57, Tomas Vondra wrote: Dne 6 Listopad 2014, 11:50, Gavin Flower napsal(a): Could you store a 2 dimensional histogram in a one dimensional array: A[z] = value, where z = col * rowSize + row (zero starting index)? How would that work for columns with different data types? Tomas

Re: [HACKERS] Typo in comment

On Thu, Nov 6, 2014 at 7:44 PM, Etsuro Fujita wrote: > I ran into a typo in a comment in src/backend/commands/matview.c. > Please find attached a patch. Thanks! Applied. > > Best regards, > Etsuro Fujita > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make chan

Re: [HACKERS] Proposal : REINDEX SCHEMA

On Fri, Oct 24, 2014 at 3:41 AM, Fabrízio de Royes Mello wrote: > On Wed, Oct 22, 2014 at 9:21 PM, Alvaro Herrera > wrote: >> >> Sawada Masahiko wrote: >> >> > Thank you for reviewing. >> > I agree 2) - 5). >> > Attached patch is latest version patch I modified above. >> > Also, I noticed I had f

Re: [HACKERS] two dimensional statistics in Postgres

Dne 6 Listopad 2014, 11:50, Gavin Flower napsal(a): > > Could you store a 2 dimensional histogram in a one dimensional array: > A[z] = value, where z = col * rowSize + row (zero starting index)? How would that work for columns with different data types? Tomas -- Sent via pgsql-hackers mailing

Re: [HACKERS] two dimensional statistics in Postgres

Hi, Dne 6 Listopad 2014, 11:15, Katharina Büchse napsal(a): > Hi, > > I'm a phd-student at the university of Jena, Thüringen, Germany, in the > field of data bases, more accurate query optimization. > I want to implement a system in PostgreSQL that detects column > correlations and creates statist

Re: [HACKERS] B-Tree index builds, CLUSTER, and sortsupport

On 11/06/2014 02:30 AM, Peter Geoghegan wrote: Thanks for the review. On Wed, Nov 5, 2014 at 4:33 PM, Andreas Karlsson wrote: I looked at the changes to the code. The new code is clean and there is more code re-use and improved readability. On possible further improvement would be to move the

Re: [HACKERS] two dimensional statistics in Postgres

On 06/11/14 23:15, Katharina Büchse wrote: Hi, I'm a phd-student at the university of Jena, Thüringen, Germany, in the field of data bases, more accurate query optimization. I want to implement a system in PostgreSQL that detects column correlations and creates statistical data about correlate

[HACKERS] Typo in comment

I ran into a typo in a comment in src/backend/commands/matview.c. Please find attached a patch. Best regards, Etsuro Fujita diff --git a/src/backend/commands/matview.c b/src/backend/commands/matview.c index 30bd40d..db05f7c 100644 --- a/src/backend/commands/matview.c +++ b/src/backend/commands/mat

Re: [HACKERS] Sequence Access Method WIP

On 11/05/2014 05:01 AM, Petr Jelinek wrote: > I guess I could port BDR sequences to this if it would help (once we > have bit more solid agreement that the proposed API at least > theoretically seems ok so that I don't have to rewrite it 10 times if at > all possible). Because the BDR sequences re

Re: [HACKERS] CREATE IF NOT EXISTS INDEX

On Thu, Nov 6, 2014 at 7:49 AM, Fujii Masao wrote: > > On Sat, Nov 1, 2014 at 1:56 AM, Fabrízio de Royes Mello > wrote: > > > > On Fri, Oct 31, 2014 at 2:46 PM, Adam Brightwell > > wrote: > >> > >> All, > >> > >> FWIW, I've cleanly applied v8 of this patch to master (252e652) and > >> check-worl

[HACKERS] two dimensional statistics in Postgres

Hi, I'm a phd-student at the university of Jena, Thüringen, Germany, in the field of data bases, more accurate query optimization. I want to implement a system in PostgreSQL that detects column correlations and creates statistical data about correlated columns for the optimizer. Therefore I ne

Re: [HACKERS] Amazon Redshift

On 11/05/2014 11:36 PM, philip taylor wrote: > String Functions > > http://docs.aws.amazon.com/redshift/latest/dg/FUNC_SHA1.html http://www.postgresql.org/docs/9.3/static/pgcrypto.html (not really a string function imho) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] CREATE IF NOT EXISTS INDEX

On Sat, Nov 1, 2014 at 1:56 AM, Fabrízio de Royes Mello wrote: > > On Fri, Oct 31, 2014 at 2:46 PM, Adam Brightwell > 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 ca

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Tue, Nov 4, 2014 at 2:03 PM, Rahila Syed wrote: > Hello , > > Please find updated patch with the review comments given above implemented Hunk #3 FAILED at 692. 1 out of 3 hunks FAILED -- saving rejects to file src/backend/access/transam/xlogreader.c.rej The patch was not applied to the master

Re: [HACKERS] Tweaking Foreign Keys for larger tables

On 5 November 2014 21:15, Peter Eisentraut wrote: > On 10/31/14 6:19 AM, Simon Riggs wrote: >> Various ways of tweaking Foreign Keys are suggested that are helpful >> for larger databases. > >> *INITIALLY NOT ENFORCED >> FK created, but is not enforced during DML. >> Will be/Must be marked NOT

Re: [HACKERS] Tweaking Foreign Keys for larger tables

On 5 November 2014 21:15, Peter Eisentraut wrote: >> ON DELETE IGNORE >> ON UPDATE IGNORE >> If we allow this specification then the FK is "one way" - we check the >> existence of a row in the referenced table, but there is no need for a >> trigger on the referenced table to enforce an action on

Re: [HACKERS] Tweaking Foreign Keys for larger tables

Peter Eisentraut-2 wrote > On 10/31/14 6:19 AM, Simon Riggs wrote: >> Various ways of tweaking Foreign Keys are suggested that are helpful >> for larger databases. > >> *INITIALLY NOT ENFORCED >> FK created, but is not enforced during DML. >> Will be/Must be marked NOT VALID when first created