Re: [HACKERS] pg_isready features

2016-06-15 Thread Jimmy
(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] Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

2016-06-15 Thread Teodor Sigaev
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

[HACKERS] pg_isready features

2016-06-15 Thread Jimmy
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] Rename max_parallel_degree?

2016-06-15 Thread Julien Rouhaud
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

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

2016-06-15 Thread Robert Haas
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] pg_isready features

2016-06-15 Thread David G. Johnston
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

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

2016-06-15 Thread Noah Misch
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] Should pg_export_snapshot() and currtid() be tagged parallel-unsafe?

2016-06-15 Thread Robert Haas
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 > >

Re: [HACKERS] 10.0

2016-06-15 Thread Jim Nasby
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] parallel.c is not marked as test covered

2016-06-15 Thread Amit Kapila
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

[HACKERS] pg_dump vs. idle_in_transaction_session_timeout

2016-06-15 Thread Bernd Helmle
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] Bug in to_timestamp().

2016-06-15 Thread amul sul
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] Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ?

2016-06-15 Thread Noah Misch
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(),

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

2016-06-15 Thread Ashutosh Bapat
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] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

2016-06-15 Thread Andreas Seltenreich
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

2016-06-15 Thread Noah Misch
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

2016-06-15 Thread Amit Kapila
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] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

2016-06-15 Thread Michael Paquier
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

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

2016-06-15 Thread Kyotaro HORIGUCHI
Hello, At Tue, 14 Jun 2016 21:24:58 +0900, Michael Paquier wrote in

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

2016-06-15 Thread Amit Kapila
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

Re: [HACKERS] Reviewing freeze map code

2016-06-15 Thread Thomas Munro
On Wed, Jun 15, 2016 at 11:43 AM, Thomas Munro wrote: > On Wed, Jun 15, 2016 at 12:44 AM, Robert Haas wrote: >> On Tue, Jun 14, 2016 at 8:11 AM, Robert Haas wrote: > I noticed that the tuples that it reported were

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

2016-06-15 Thread Teodor Sigaev
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] Reviewing freeze map code

2016-06-15 Thread Robert Haas
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 >

Re: [HACKERS] Rename max_parallel_degree?

2016-06-15 Thread Robert Haas
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

2016-06-15 Thread Robert Haas
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] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

2016-06-15 Thread Tom Lane
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] pg_dump vs. idle_in_transaction_session_timeout

2016-06-15 Thread Tom Lane
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

2016-06-15 Thread Merlin Moncure
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] Reviewing freeze map code

2016-06-15 Thread Masahiko Sawada
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] Parallel safety tagging of extension functions

2016-06-15 Thread Andreas Karlsson
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] pg_isready features

2016-06-15 Thread Imre Samu
>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

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

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

2016-06-15 Thread Teodor Sigaev
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

2016-06-15 Thread Jimmy
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] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-06-15 Thread Kevin Grittner
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] Reviewing freeze map code

2016-06-15 Thread Robert Haas
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] 10.0

2016-06-15 Thread David G. Johnston
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

2016-06-15 Thread Amit Kapila
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] ERROR: ORDER/GROUP BY expression not found in targetlist

2016-06-15 Thread Amit Kapila
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] 10.0

2016-06-15 Thread Merlin Moncure
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] Reviewing freeze map code

2016-06-15 Thread Amit Kapila
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] Reviewing freeze map code

2016-06-15 Thread Robert Haas
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] Reviewing freeze map code

2016-06-15 Thread Robert Haas
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] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-06-15 Thread Robert Haas
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] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-06-15 Thread Kevin Grittner
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

2016-06-15 Thread Robert Haas
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

2016-06-15 Thread Kevin Grittner
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

2016-06-15 Thread Alvaro Herrera
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

2016-06-15 Thread Kevin Grittner
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

2016-06-15 Thread Alvaro Herrera
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

2016-06-15 Thread Kevin Grittner
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

2016-06-15 Thread Kevin Grittner
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

2016-06-15 Thread David G. Johnston
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] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-06-15 Thread Alvaro Herrera
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] parallel.c is not marked as test covered

2016-06-15 Thread Robert Haas
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] Rename max_parallel_degree?

2016-06-15 Thread Julien Rouhaud
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

2016-06-15 Thread Kevin Grittner
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

2016-06-15 Thread Alvaro Herrera
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

2016-06-15 Thread Robert Haas
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.

Re: [HACKERS] WIP: Data at rest encryption

2016-06-15 Thread PostgreSQL - Hans-Jürgen Schönig
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

2016-06-15 Thread Andres Freund
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

[HACKERS] Choosing the cheapest optimizer cost

2016-06-15 Thread Bruce Momjian
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

2016-06-15 Thread Andres Freund
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] parallel.c is not marked as test covered

2016-06-15 Thread Robert Haas
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] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-06-15 Thread Kevin Grittner
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] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

2016-06-15 Thread Michael Paquier
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] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

2016-06-15 Thread Alvaro Herrera
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] Typo in parallel comment of heap_delete()

2016-06-15 Thread Thomas Munro
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

2016-06-15 Thread Michael Paquier
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] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

2016-06-15 Thread Vitaly Burovoy
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] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-06-15 Thread Kevin Grittner
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

2016-06-15 Thread Ioseph Kim
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] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-06-15 Thread Andres Freund
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] increase message string buffer size of watch command of psql

2016-06-15 Thread Alvaro Herrera
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] parallel.c is not marked as test covered

2016-06-15 Thread Peter Eisentraut
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] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-06-15 Thread Kevin Grittner
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

2016-06-15 Thread Andres Freund
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] [PATCH v12] GSSAPI encryption support

2016-06-15 Thread Robbie Harwood
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] increase message string buffer size of watch command of psql

2016-06-15 Thread 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 format string to > something other than %c, but I don't think there's enough demand to > justify it. Agreed, that seems

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

2016-06-15 Thread Tom Lane
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] MultiXactId error after upgrade to 9.3.4

2016-06-15 Thread Alvaro Herrera
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] parallel.c is not marked as test covered

2016-06-15 Thread Robert Haas
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] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-06-15 Thread Alvaro Herrera
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] parallel.c is not marked as test covered

2016-06-15 Thread Amit Kapila
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

[HACKERS] forcing a rebuild of the visibility map

2016-06-15 Thread Robert Haas
[ 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] Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it

2016-06-15 Thread Michael Paquier
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.

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

2016-06-15 Thread Vitaly Burovoy
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] ERROR: ORDER/GROUP BY expression not found in targetlist

2016-06-15 Thread Robert Haas
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