Re: [HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On 6/15/16, Michael Paquier wrote: > On Thu, Jun 16, 2016 at 12:10 PM, Vitaly Burovoy > wrote: >> In the initial letter[1] I posted a digest from the SQL-2011 standard >> and a conclusion as a design of a new patch. >> Now I have more free

Re: [HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On Thu, Jun 16, 2016 at 1:27 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane wrote: > >> > IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the >> > current state is. >> >> Are you

Re: [HACKERS] Typo in parallel comment of heap_delete()

On Tue, Jun 7, 2016 at 12:00 AM, Robert Haas wrote: > On Sun, Jun 5, 2016 at 4:39 PM, Jim Nasby wrote: >> I'm pretty sure this is a typo... > > Sure is. Thanks. The same typo appears in heap_update. PS Far be it from me, but postgres_fdw.c

Re: [HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

Michael Paquier wrote: > On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane wrote: > > IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the > > current state is. > > Are you talking about that? >

Re: [HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On Thu, Jun 16, 2016 at 12:10 PM, Vitaly Burovoy wrote: > In the initial letter[1] I posted a digest from the SQL-2011 standard > and a conclusion as a design of a new patch. > Now I have more free time and I'm hacking it that way. The new patch > is at the very early

Re: [HACKERS] ERROR: ORDER/GROUP BY expression not found in targetlist

On Tue, Jun 14, 2016 at 12:18 PM, Tom Lane wrote: > Amit Kapila writes: >> On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane wrote: >>> ... I got a core dump in the window.sql test: >>> which I think may be another manifestation of the

Re: [HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On 6/15/16, Tom Lane wrote: > Michael Paquier writes: >> To put it short, it should not be possible to drop a NOT NULL >> constraint on a child relation when its parent table is using it, this >> should only be possible from the parent. Attached is

Re: [HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane wrote: > Michael Paquier writes: > This doesn't sound like the right approach; in particular, it won't really > help for deciding whether to propagate a DROP NOT NULL on a parent rel to > its children.

[HACKERS] forcing a rebuild of the visibility map

[ Changing subject line in the hopes of keeping separate issues in separate threads. ] On Mon, Jun 6, 2016 at 11:00 AM, Tom Lane wrote: > Robert Haas writes: >> I'm intuitively sympathetic to the idea that we should have an option >> for this, but I

Re: [HACKERS] parallel.c is not marked as test covered

On Wed, Jun 15, 2016 at 10:48 PM, Amit Kapila wrote: > exec_stmt_execsql() is used to execute SQL statements insider plpgsql which > includes dml statements as well, so probably you wanted to play safe by not > allowing parallel option from that place. However, I think

Re: [HACKERS] parallel.c is not marked as test covered

On Thu, Jun 16, 2016 at 12:46 AM, Robert Haas wrote: > > On Wed, Jun 15, 2016 at 5:23 AM, Amit Kapila wrote: > >> > Considering above analysis is correct, we have below options: > >> > a. Modify the test such that it actually generates an error and

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

Kevin Grittner wrote: > test=# -- connection 1 > analyze verbose t1; -- when run after threshold, STO error occurs > INFO: analyzing "public.t1" > INFO: "t1": scanned 45 of 45 pages, containing 8999 live rows and > 1001 dead rows; 8999 rows in sample, 8999 estimated total rows > ERROR:

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-06-15 20:22:24 -0500, Kevin Grittner wrote: > I'm not clear where you see this as being in any way different with > STO. Above it seemed that you saw this as an issue related to > ANALYZE. If there is not early pruning for the table being > analyzed, nothing is at all different. If

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 5:34 PM, Andres Freund wrote: > On 2016-06-15 16:58:25 -0500, Kevin Grittner wrote: >> On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund wrote: >>> On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote: On Wed, Jun 15, 2016 at 2:20

Re: [HACKERS] increase message string buffer size of watch command of psql

Thanks, I agree that strftime() is better then asctime(). regards, Ioseph 2016년 06월 16일 08:37에 Tom Lane 이(가) 쓴 글: > Alvaro Herrera writes: >> +1 to strftime("%c"). If we wanted to provide additional flexibility we >> could have a \pset option to change the strftime

Re: [HACKERS] increase message string buffer size of watch command of psql

Alvaro Herrera writes: > +1 to strftime("%c"). If we wanted to provide additional flexibility we > could have a \pset option to change the strftime format string to > something other than %c, but I don't think there's enough demand to > justify it. Agreed, that seems

Re: [HACKERS] MultiXactId error after upgrade to 9.3.4

Stephen Frost wrote: > Greetings, > > Looks like we might not be entirely out of the woods yet regarding > MultiXactId's. After doing an upgrade from 9.2.6 to 9.3.4, we saw the > following: > > ERROR: MultiXactId 6849409 has not been created yet -- apparent wraparound > > The table

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

Michael Paquier writes: > On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote: >> Robbie Harwood writes: >>> Tom Lane writes: >>> Wait a second. So the initial connection-request packet is

Re: [HACKERS] New design for FK-based join selectivity estimation

Tomas Vondra writes: > Attached is a reworked patch, mostly following the new design proposal > from this thread. I've whacked this around quite a bit and am now reasonably happy with it. The issue of planning speed hit should be pretty much gone, although I've not

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-06-15 16:58:25 -0500, Kevin Grittner wrote: > On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund wrote: > > On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote: > >> On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote: > >> > >> > We might fetch a

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 2:40 PM, Alvaro Herrera wrote: > Kevin Grittner wrote: >> On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera >> wrote: > >> > We actually go quite some lengths to support this case, even when it's >> > the opinion of many

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 3:25 PM, Andres Freund wrote: > On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote: >> On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote: >> >> > We might fetch a toast tuple which >> > since have been re-purposed for a datum of

Re: [HACKERS] parallel.c is not marked as test covered

On Wed, Jun 15, 2016 at 4:59 PM, Peter Eisentraut wrote: > On 6/14/16 12:37 PM, Robert Haas wrote: >> ERROR: can't generate random numbers because you haven't specified a seed >> >> ...to which the user will reply, "oh yes I did; in fact I ran SELECT >>

Re: [HACKERS] parallel.c is not marked as test covered

On 6/14/16 12:37 PM, Robert Haas wrote: ERROR: can't generate random numbers because you haven't specified a seed ...to which the user will reply, "oh yes I did; in fact I ran SELECT magic_setseed(42) just before I ran the offending query!". They'll then contact an expert (hopefully) who will

Re: [HACKERS] increase message string buffer size of watch command of psql

Tom Lane wrote: > I wrote: > > Well, we did part of that, but it's still using asctime(). Should we > > change that to strftime(..."%c"...) to be less English-centric? > > (The result seems to be the same in C locale. pg_controldata has done > > it that way for a long time, with few

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-06-15 14:24:58 -0500, Kevin Grittner wrote: > On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote: > > > We might fetch a toast tuple which > > since have been re-purposed for a datum of a different type. > > How would that happen? Autovac vacuums toast and heap

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 3:40 PM, Alvaro Herrera wrote: > Kevin Grittner wrote: > > On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera > > wrote: > > > > We actually go quite some lengths to support this case, even when it's > > > the opinion of

Re: [HACKERS] WIP: Data at rest encryption

On 06/14/2016 09:59 PM, Jim Nasby wrote: On 6/12/16 2:13 AM, Ants Aasma wrote: On Fri, Jun 10, 2016 at 5:23 AM, Haribabu Kommi wrote: > 1. Instead of doing the entire database files encryption, how about > providing user an option to protect only some particular

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 2:59 PM, Alvaro Herrera wrote: > Kevin Grittner wrote: >> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote: >> >> > The expression index case is the one to worry about; if there is a >> > problem, that's where it is.

[HACKERS] Choosing the cheapest optimizer cost

Right now, the optimizer chooses the path with the cheapest cost. However, do we take into account the behavior of the plan in handling mis-estimated row counts? For example, if a path has a log(n) behavior for changes in the row count, and another plan that is slightly cheaper has a log(n^2)

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

Kevin Grittner wrote: > On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera > wrote: > > We actually go quite some lengths to support this case, even when it's > > the opinion of many that we shouldn't. For example VACUUM doesn't try > > to find index entries using the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 2:20 PM, Andres Freund wrote: > We might fetch a toast tuple which > since have been re-purposed for a datum of a different type. How would that happen? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-06-15 14:50:46 -0400, Robert Haas wrote: > On Wed, Jun 15, 2016 at 2:45 PM, Alvaro Herrera > wrote: > > Robert Haas wrote: > >> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner > >> wrote: > >> > The test I showed creates a situation which (to

Re: [HACKERS] parallel.c is not marked as test covered

On Wed, Jun 15, 2016 at 5:23 AM, Amit Kapila wrote: >> > Considering above analysis is correct, we have below options: >> > a. Modify the test such that it actually generates an error and to hide >> > the >> > context, we can exception block and raise some generic error.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 1:59 PM, Alvaro Herrera wrote: > Kevin Grittner wrote: >> On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote: >> >>> The expression index case is the one to worry about; if there is a >>> problem, that's where it is. What

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 1:54 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> The expression index case is the one to worry about; if there is a >> problem, that's where it is. What bothers me is that a function used >> in an expression index could do anything at all

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

Kevin Grittner wrote: > On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote: > > > The expression index case is the one to worry about; if there is a > > problem, that's where it is. What bothers me is that a function used > > in an expression index could do anything at

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 1:50 PM, Robert Haas wrote: > The expression index case is the one to worry about; if there is a > problem, that's where it is. What bothers me is that a function used > in an expression index could do anything at all - it can read any > table in

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

Robert Haas wrote: > On Wed, Jun 15, 2016 at 2:45 PM, Alvaro Herrera > wrote: > > Maybe it is possible to get into trouble if you're taking a sample for > > an expression index. > > The expression index case is the one to worry about; if there is a > problem, that's

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 2:45 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner >> wrote: >> > The test I showed creates a situation which (to ANALYZE) is >> > identical to what you describe -- ANALYZE

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 1:45 PM, Alvaro Herrera wrote: > Maybe it is possible to get into trouble if you're taking a sample for > an expression index. Maybe -- if you are using a function for an index expression which does an explicit SELECT against some database table

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

Robert Haas wrote: > On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner > wrote: > > The test I showed creates a situation which (to ANALYZE) is > > identical to what you describe -- ANALYZE sees a page with an LSN > > recent enough that it could have been (and actually has been)

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 1:29 PM, Robert Haas wrote: > On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner > wrote:>> So what happens in this scenario: >>> 1. ANALYZE runs really slowly - maybe the user-defined function it's >>> running for the expression

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 1:44 PM, Kevin Grittner wrote:>> So what happens in this scenario: >> 1. ANALYZE runs really slowly - maybe the user-defined function it's >> running for the expression index is extremely long-running. >> 2. Eventually, the snapshot for ANALYZE is older

Re: [HACKERS] Rename max_parallel_degree?

On 15/06/2016 18:14, Julien Rouhaud wrote: > On 15/06/2016 17:49, Robert Haas wrote: >> On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud >> wrote: I don't entirely like the new logic in RegisterDynamicBackgroundWorker. >>> I wonder if we can't drive this

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jun 15, 2016 at 10:46 AM, Robert Haas wrote: > On Sat, Jun 11, 2016 at 11:29 AM, Kevin Grittner wrote: >> I have reviewed the code and run tests to try to find something >> here which could be considered a bug, without finding any problem. >>

Re: [HACKERS] pg_isready features

yup, it does for (1) :-) On Wed, Jun 15, 2016 at 9:53 AM Imre Samu wrote: > >Why I need it? There is tiny window between postgres being ready to > accept connections > >and final scripts which create initial user/database. > >Ideally having option to say "postgres is

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

We need to reach a consensus here, since there is no way to say "I don't know". I inclined to agree with you, that returning false is better in such a case.That will indicate user to the source of problem. Here is a patch, now phrase operation returns false if there is not postion information.

Re: [HACKERS] pg_isready features

>Why I need it? There is tiny window between postgres being ready to accept connections >and final scripts which create initial user/database. >Ideally having option to say "postgres is ready after specific user can login to specific database" would be ideal. temporary - the official

Re: [HACKERS] pg_isready features

On 06/15/2016 09:30 AM, David G. Johnston wrote: On Wed, Jun 15, 2016 at 12:09 PM, Jimmy

Re: [HACKERS] pg_isready features

(1) I can (and do) use psql, pg_isready seems lighter and since it already supports credentials and DB name, I see very little harm for pg_isready to say back whether user logged IN or not using these credentials. (2) timeout is not the same - timeout does not retry, its a simple timeout in case

Re: [HACKERS] pg_isready features

On Wed, Jun 15, 2016 at 12:09 PM, Jimmy wrote: > Not sure if this was discussed in the past and decided it does not belong > to pg_isready utility > > I am using pg_isready in dockerized development environment as part of > docker-compose. Simply say I have POSTGRES

Re: [HACKERS] An extra error for client disconnection on Windows

On Thu, Jun 2, 2016 at 4:51 AM, Kyotaro HORIGUCHI wrote: > After a process termination without PQfinish() of a client, > server emits the following log message not seen on Linux boxes. > >> LOG: could not receive data from client: An existing connection was >>

Re: [HACKERS] Rename max_parallel_degree?

On 15/06/2016 17:49, Robert Haas wrote: > On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud > wrote: >>> I don't entirely like the new logic in >>> RegisterDynamicBackgroundWorker. >> >>> I wonder if we can't drive this off >>> of a couple of counters, instead of having

[HACKERS] pg_isready features

Not sure if this was discussed in the past and decided it does not belong to pg_isready utility I am using pg_isready in dockerized development environment as part of docker-compose. Simply say I have POSTGRES container and APP container. I use pg_isready inside app container and wait till

Re: [HACKERS] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

what's about word with several infinitives select to_tsvector('en', 'leavings'); to_tsvector 'leave':1 'leavings':1 (1 row) select to_tsvector('en', 'leavings') @@ 'leave <0> leavings'::tsquery; ?column? -- t (1 row) Second example is not

Re: [HACKERS] 10.0

On 6/15/16 9:04 AM, Merlin Moncure wrote: We could stand to be more explicit here. The docs for version() >> > indicated >> > the server_version_num should be used for "machine processing". On a somewhat related note, any objection to adding server_version_num to pg_config? It's common to

Re: [HACKERS] Rename max_parallel_degree?

On Tue, Jun 14, 2016 at 7:10 AM, Julien Rouhaud wrote: >> I don't entirely like the new logic in >> RegisterDynamicBackgroundWorker. > > I'm not that happy with it too. We can avoid iterating over every slots > if the feature isn't activated though (max_parallel_workers

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Sat, Jun 11, 2016 at 11:29 AM, Kevin Grittner wrote: > I have reviewed the code and run tests to try to find something > here which could be considered a bug, without finding any problem. > When reading pages for the random sample for ANALYZE (or > auto-analyze) there is not

Re: [HACKERS] Should pg_export_snapshot() and currtid() be tagged parallel-unsafe?

On Tue, Jun 14, 2016 at 5:01 PM, Andreas Seltenreich wrote: > Digging through the sqlsmith logging db, I noticed the following errors: > > ERROR: cannot update SecondarySnapshot during a parallel operation > ERROR: cannot assign XIDs during a parallel operation > >

[HACKERS] Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

On Wed, Jun 15, 2016 at 03:02:15PM +0300, Teodor Sigaev wrote: > On Wed, Jun 15, 2016 at 02:54:33AM -0400, Noah Misch wrote: > > On Mon, Jun 13, 2016 at 10:44:06PM -0400, Noah Misch wrote: > > > On Fri, Jun 10, 2016 at 03:10:40AM -0400, Noah Misch wrote: > > > > [Action required within 72 hours.

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 15, 2016 at 9:59 AM, Amit Kapila wrote: >> That just kicks the can down the road. Then you have PD_ALL_VISIBLE >> clear but the VM bit is still set. > > I mean to say clear both as we are doing currently in code: > if (PageIsAllVisible(BufferGetPage(buffer)))

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 15, 2016 at 10:03 AM, Masahiko Sawada wrote: >> I'm not sure what to do about this: this part of the heap_update() >> logic has been like this forever, and I assume that if it were easy to >> refactor this away, somebody would have done it by now. > > How about

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/14/2016 07:51 PM, Robert Haas wrote: On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson wrote: I have rebased all my patches on the current master now (and skipped the extensions I previously listed). Thanks, this is really helpful. It was starting to get hard to

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 15, 2016 at 9:56 PM, Robert Haas wrote: > On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro > wrote: >> I spent some time chasing down the exact circumstances. I suspect >> that there may be an interlocking problem in heap_update.

Re: [HACKERS] 10.0

On Wed, Jun 15, 2016 at 8:59 AM, David G. Johnston wrote: > On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure wrote: >> >> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston >> wrote: >> > On Tue, Jun 14, 2016 at 5:58 PM,

Re: [HACKERS] 10.0

On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure wrote: > On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston > wrote: > > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure > wrote: > >> > >> On Tue, Jun 14, 2016 at 4:13 PM, Jim

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 15, 2016 at 7:13 PM, Robert Haas wrote: > > On Wed, Jun 15, 2016 at 9:43 AM, Amit Kapila wrote: > > On Wed, Jun 15, 2016 at 6:26 PM, Robert Haas wrote: > >> On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro > >>

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 15, 2016 at 9:43 AM, Amit Kapila wrote: > On Wed, Jun 15, 2016 at 6:26 PM, Robert Haas wrote: >> On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro >> wrote: >> > I spent some time chasing down the exact

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 15, 2016 at 6:26 PM, Robert Haas wrote: > > On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro > wrote: > > I spent some time chasing down the exact circumstances. I suspect > > that there may be an interlocking problem in

Re: [HACKERS] pg_dump vs. idle_in_transaction_session_timeout

Bernd Helmle writes: > Currently pg_dump doesn't turn off idle_in_transaction_session_timeout. Definitely an oversight, since it turns off other timeout settings. > Okay, the window of failure here is very narrow (on my machine it breaks > with an insane setting of 1ms

Re: [HACKERS] 10.0

On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston wrote: > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure wrote: >> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby >> wrote: >> > On 6/14/16 3:56 PM, Tom Lane wrote: >> >>

Re: [HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

Michael Paquier writes: > To put it short, it should not be possible to drop a NOT NULL > constraint on a child relation when its parent table is using it, this > should only be possible from the parent. Attached is a patch handling > this problem by adding a new

Re: [HACKERS] ERROR: ORDER/GROUP BY expression not found in targetlist

On Tue, Jun 14, 2016 at 4:48 PM, Amit Kapila wrote: > On Mon, Jun 13, 2016 at 8:11 PM, Tom Lane wrote: > > > I do > > not share your confidence that using apply_projection_to_path within > > create_grouping_paths is free of such a hazard. > > > >

Re: [HACKERS] Reviewing freeze map code

On Wed, Jun 15, 2016 at 2:41 AM, Thomas Munro wrote: > I spent some time chasing down the exact circumstances. I suspect > that there may be an interlocking problem in heap_update. Using the > line numbers from cae1c788 [1], I see the following interaction >

[HACKERS] Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 9.6 open item is long past due for your status update. Please reacquaint yourself with the policy on open item ownership[1] and then reply immediately. If I do not hear from you by 2016-06-16 07:00 UTC, I will transfer this item to release

Re: [HACKERS] Bug in to_timestamp().

On Monday, 13 June 2016 9:57 PM, Robert Haas wrote: >I think a space in the format string should skip a whitespace >character in the input string, but not a non-whitespace character. +1, enough the benefit is we are giving correct output. PFA patch proposing this fix.

[HACKERS] pg_dump vs. idle_in_transaction_session_timeout

Currently pg_dump doesn't turn off idle_in_transaction_session_timeout. Okay, the window of failure here is very narrow (on my machine it breaks with an insane setting of 1ms only), but for the sake of reliable backups and protection against over motivated DBA it looks better to me to turn that

Re: [HACKERS] parallel.c is not marked as test covered

On Wed, Jun 15, 2016 at 12:07 PM, Noah Misch wrote: > > On Wed, Jun 15, 2016 at 11:50:33AM +0530, Amit Kapila wrote: > > In short, this test doesn't serve it's purpose which is to generate an > > error from worker. > > That's bad. Thanks for figuring out the problem. > > > do

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

Hello, At Tue, 14 Jun 2016 21:24:58 +0900, Michael Paquier wrote in

[HACKERS] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

Hi all, A couple of months back the $subject has been mentioned, though nobody actually wrote a patch to prevent that: http://www.postgresql.org/message-id/21633.1448383...@sss.pgh.pa.us So here is one.. To put it short, it should not be possible to drop a NOT NULL constraint on a child relation

[HACKERS] Partition-wise join for join between (declaratively) partitioned tables

Amit Langote is working on supporting declarative partitioning in PostgreSQL [1]. I have started working on supporting partition-wise join. This mail describes very high level design and some insight into the performance improvements. An equi-join between two partitioned tables can be broken down

Re: [HACKERS] parallel.c is not marked as test covered

On Wed, Jun 15, 2016 at 12:07 PM, Noah Misch wrote: > > On Wed, Jun 15, 2016 at 11:50:33AM +0530, Amit Kapila wrote: > > do $$begin > > Perform stringu1::int2 from tenk1 where unique1 = 1; > > end$$; > > > > ERROR: invalid input syntax for integer: "BA" > > CONTEXT:

[HACKERS] Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

On Mon, Jun 13, 2016 at 10:44:06PM -0400, Noah Misch wrote: > On Fri, Jun 10, 2016 at 03:10:40AM -0400, Noah Misch wrote: > > On Tue, Jun 07, 2016 at 06:05:10PM -0400, Tom Lane wrote: > > > Jean-Pierre Pelletier writes: > > > > I wanted to test if phraseto_tsquery(),

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

Amit Kapila writes: > Right, so I have moved "Failed assertion in parallel worker > (ExecInitSubPlan)" item to CLOSE_WAIT state as I don't think there is any > known pending issue in that item. I have moved it to CLOSE_WAIT state > because we have derived our queries to reproduce the problem

Re: [HACKERS] parallel.c is not marked as test covered

On Wed, Jun 15, 2016 at 11:50:33AM +0530, Amit Kapila wrote: > In short, this test doesn't serve it's purpose which is to generate an > error from worker. That's bad. Thanks for figuring out the problem. > do $$begin > Perform stringu1::int2 from tenk1 where unique1 = 1; > end$$; > > ERROR:

Re: [HACKERS] parallel.c is not marked as test covered

On Wed, Jun 15, 2016 at 1:42 AM, Robert Haas wrote: > > On Tue, Jun 14, 2016 at 1:14 PM, Tom Lane wrote: > > > > I have not dug into the code enough to find out exactly what's happening > > in Peter's complaint, but it seems like it would be a good idea