On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > PFA patch, where added elog() to add the error message same as all other
> > places.
>
> Some looking around says that this *isn't* the only place that just
> blithely assumes that it will find an opfamily entry. But
I wrote:
> Andrew Dunstan writes:
>> The problem is command_like's use of redirection to strings. Why this
>> should be a problem for this particular use is a matter of speculation.
> I looked at jacana's two recent pg_ctlCheck failures, and they both
> seem to have failed on this:
> command_like
On Mon, Jul 24, 2017 at 9:21 PM, Jeff Janes wrote:
> On Sat, Jul 22, 2017 at 8:53 PM, Amit Kapila
> wrote:
>>
>> On Thu, Jul 13, 2017 at 7:38 AM, Amit Kapila
>> wrote:
>> > On Wed, Jul 12, 2017 at 11:20 PM, Jeff Janes
>> > wrote:
>> >>
>> >>
>> >>
>> >> Setting parallel_workers to 8 changes the
Alvaro Herrera wrote:
> I'm back at looking into this again, after a rather exhausting week. I
> think I have a better grasp of what is going on in this code now,
Here's an updated patch, which I intend to push tomorrow.
> and it
> appears to me that we should change the locking so that active_p
Tomas Vondra writes:
> It seems to me that VACUUM and ANALYZE somewhat disagree on what exactly
> reltuples means. VACUUM seems to be thinking that
> reltuples = live + dead
> while ANALYZE apparently believes that
> reltuples = live
> The question is - which of the reltuples definitio
Hi,
It seems to me that VACUUM and ANALYZE somewhat disagree on what exactly
reltuples means. VACUUM seems to be thinking that
reltuples = live + dead
while ANALYZE apparently believes that
reltuples = live
This causes somewhat bizarre changes in the value, depending on which of
th
Mat Arye writes:
> On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane wrote:
>> I'm not really sure why planner hooks would have anything to do with your
>> exposed SQL API?
> Sorry what I meant was i'd like to package different versions of my
> extension -- both .sql and .c --
> and have the extension a
On Mon, Jul 24, 2017 at 6:21 AM, Amit Langote
wrote:
> Yes, we need that there too.
>
> Done that in the attached v3 (including the test where
> ExecPartitionCheck() would have crashed without the patch).
Committed. Thanks to all of you.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
(adding -hackers back into thread, got dropped by my email client, sorry)
On Mon, Jul 24, 2017 at 1:38 PM, Tom Lane wrote:
> Mat Arye writes:
> > I tried looking in the contrib modules and didn't find many with lots of
> > planner hook usage.
>
> I'm not really sure why planner hooks would have
On 2017-07-24 23:31, Mark Rofail wrote:
On Mon, Jul 24, 2017 at 11:25 PM, Erik Rijkers wrote:
This patch doesn't apply to HEAD at the moment ( e2c8100e6072936 ).
My bad, I should have mentioned that the patch is dependant on the
original
patch.
Here is a *unified* patch that I just tested
On 2017-07-24 23:08, Mark Rofail wrote:
Here is the new Patch with the bug fixes and the New Patch with the
Index
in place performance results.
I just want to point this out because I still can't believe the
numbers. In
reference to the old patch:
The new patch without the index suffers a 41.
It certainly is, thank you for the heads up. I included a note to encourage
the user to index the referencing column instead.
On Sun, Jul 23, 2017 at 4:41 AM, Robert Haas wrote:
>
> This is a jumbo king-sized can of worms, and even a very experienced
> contributor would likely find it extremely d
>
> However, there is a bug that prevented me from testing the third scenario,
> I assume there's an issue of incompatible types problem since the right
> operand type is anyelement and the supporting procedures expect anyarray.
> I am working on debugging it right now.
>
I have also solved the bu
On Fri, Jul 21, 2017 at 8:05 AM, Alexey Chernyshov
wrote:
> the following patch transfers functionality from gevel module
> (http://www.sai.msu.su/~megera/wiki/Gevel) which provides functions for
> analyzing GIN and GiST indexes to pageinspect. Gevel was originally
> designed by Oleg Bartunov, and
On Fri, Jul 21, 2017 at 6:21 AM, Etsuro Fujita
wrote:
> I mean constraints derived from WITH CHECK OPTIONs specified for parent
> views. We use the words "WITH CHECK OPTION constraints" in comments in
> nodeModifyTable.c, so the expression "CHECK OPTION constrains" doesn't sound
> not that bad to
On 7/24/17 3:28 PM, David Steele wrote:
Yes, and this is another behavioral change to consider -- one that is
more likely to impact users than the change to pg_stop_backup(). If
pg_basebackup is not currently waiting for WAL on a standby (but does on
a primary) then that's pretty serious.
Le 24/07/2017 à 21:18, Tom Lane a écrit :
> Gilles Darold writes:
>> Le 24/07/2017 à 19:19, Tom Lane a écrit :
>>> ... I'm inclined to think in terms of fixing it at that level
>>> rather than in pg_dump. It doesn't look like it would be hard to fix:
>>> both functions ultimately call get_query_d
On Mon, Jul 24, 2017 at 6:45 PM, Stephen Frost wrote:
> What the change would do is make the pg_stop_backup() caller block until
> the last WAL is archvied, and perhaps that ends up taking hours, and
> then the connection is dropped for whatever reason and the backup fails
> where it otherwise
Thomas Munro writes:
> Ahh, I think I see it. This is an EXEC_BACKEND build farm animal.
> Theory: After the backend we see had removed the scratch entry and
> before it had restored it, another backend started up and ran
> InitPredicateLocks(), which inserted a new scratch entry without
> interl
On 7/24/17 12:28 PM, Stephen Frost wrote:
* David Steele (da...@pgmasters.net) wrote:
While this patch brings pg_stop_backup() in line with the
documentation, it also introduces a behavioral change compared to
9.6. Currently, the default 9.6 behavior on a standby is to return
immediately from
On Tue, Jul 25, 2017 at 7:24 AM, Tom Lane wrote:
> Thomas Munro writes:
>> Ahh, I think I see it. This is an EXEC_BACKEND build farm animal.
>> Theory: After the backend we see had removed the scratch entry and
>> before it had restored it, another backend started up and ran
>> InitPredicateLock
Gilles Darold writes:
> Le 24/07/2017 à 19:19, Tom Lane a écrit :
>> ... I'm inclined to think in terms of fixing it at that level
>> rather than in pg_dump. It doesn't look like it would be hard to fix:
>> both functions ultimately call get_query_def(), it's just that one passes
>> down a tuple
On Mon, Jul 24, 2017 at 11:51 AM, Thomas Munro
wrote:
> On Sun, Jul 23, 2017 at 8:32 AM, Tom Lane wrote:
>> Meanwhile, it's still pretty unclear what happened yesterday on
>> culicidae.
>
> That failure is indeed baffling. The only code that inserts
> (HASH_ENTER[_NULL]) into PredicateLockTarget
Le 24/07/2017 à 19:19, Tom Lane a écrit :
> Gilles Darold writes:
>> There is an issue with version prior to 10 when dumping views with circular
>> references. I know that these views are now exported as views in 10 but they
>> are still exported as TABLE + RULE in prior versions. This conduct to
On 7/20/17 16:36, Tom Lane wrote:
> What exactly is the point of the new pg_sequences view?
It is analogous to pg_tables, pg_matviews, pg_indexes, and other such
system views that are sort of half-way between system catalogs and
information schema.
--
Peter Eisentraut http://www.2nd
On Mon, Jul 24, 2017 at 10:50 AM, Joshua D. Drake
wrote:
> Does this suggest that we don't have a cleanup problem but a fragmentation
> problem (or both at least for the index)? Having an index that is almost
> twice the uncleaned up size isn't that uncommon.
As Tom pointed out up-thread, it's i
On 2017-07-24 13:27:58 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> I seriously, seriously, seriously dislike that. You practically might as
> >> well put miscadmin.h into postgres.h. Instead, what do you think of
> >> requiring the individual ExecProcNode functions to perform
> >> CHECK_
On Mon, Jul 24, 2017 at 2:43 PM, Peter Geoghegan wrote:
> On Mon, Jul 24, 2017 at 10:13 AM, Claudio Freire
> wrote:
>> Vacuum *might* be able to redistribute tuples too, while holding locks
>> to all 3 pages (the two children and the parent page), since it can
>> move the TID to the middle point
On 07/23/2017 12:03 PM, Joshua D. Drake wrote:
As you can see even with aggressive vacuuming, over a period of 36 hours
life gets increasingly miserable.
The largest table is:
postgres=# select
pg_size_pretty(pg_total_relation_size('bmsql_order_line'));
pg_size_pretty
1
On Mon, Jul 24, 2017 at 10:13 AM, Claudio Freire wrote:
> In most cases, the TID itself can be omitted when the key itself
> differs already.
>
> When a split happens, a TID will be added referring to a real tid from
> a child page iff necessary.
>
> This gives a lot of leeway in choosing the cuto
Andres Freund writes:
> On 2017-07-21 20:17:54 -0400, Tom Lane wrote:
>>> I dislike having the miscadmin.h include in executor.h - but I don't
>>> quite see a better alternative.
>> I seriously, seriously, seriously dislike that. You practically might as
>> well put miscadmin.h into postgres.h.
On Mon, Jul 24, 2017 at 2:20 PM, Claudio Freire wrote:
> On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura
> wrote:
>> On 2017-07-24 19:11, Claudio Freire wrote:
>>> I was mostly thinking about something like the attached patch.
>>>
>>> Simple, unintrusive, and shouldn't cause any noticeable slowdown
On Mon, Jul 24, 2017 at 2:10 PM, Sokolov Yura
wrote:
> On 2017-07-24 19:11, Claudio Freire wrote:
>>
>> On Mon, Jul 24, 2017 at 6:37 AM, Sokolov Yura
>> wrote:
>>>
>>> Good day, Claudio
>>>
>>>
>>> On 2017-07-22 00:27, Claudio Freire wrote:
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov
Gilles Darold writes:
> There is an issue with version prior to 10 when dumping views with circular
> references. I know that these views are now exported as views in 10 but they
> are still exported as TABLE + RULE in prior versions. This conduct to the
> following error when columns of sub-queri
On Thu, Jul 20, 2017 at 12:51 PM, Tom Lane wrote:
> Robert Haas writes:
> > I think that's a valid point. There are also other concerns here -
> > e.g. whether instead of adopting the patch as proposed we ought to (a)
> > use some smaller size, or (b) keep the size as-is but reduce the
> > maxi
On Mon, Jul 24, 2017 at 2:02 PM, Peter Geoghegan wrote:
> On Mon, Jul 24, 2017 at 9:51 AM, Claudio Freire
> wrote:
>> My point was that the TID doesn't have to point to an actual tuple.
>>
>> It's more of a keyspace thing, so it doesn't need to match real
>> tuples, it can just divide the keyspa
On 2017-07-24 19:11, Claudio Freire wrote:
On Mon, Jul 24, 2017 at 6:37 AM, Sokolov Yura
wrote:
Good day, Claudio
On 2017-07-22 00:27, Claudio Freire wrote:
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
wrote:
My friend noticed, that I didn't said why I bother with autovacuum.
Our custo
On Mon, Jul 24, 2017 at 9:51 AM, Claudio Freire wrote:
> My point was that the TID doesn't have to point to an actual tuple.
>
> It's more of a keyspace thing, so it doesn't need to match real
> tuples, it can just divide the keyspace with an arbitrary cutoff, and
> should be cheapter to maintain
On Wed, Nov 23, 2016 at 12:27 AM, Peter Geoghegan wrote:
> On Mon, Nov 21, 2016 at 5:15 PM, Claudio Freire
> wrote:
>>> There are a couple
>>> of tricky issues with that that you'd have to look out for, like
>>> making sure that the high key continues to hold a real TID, which at a
>>> glance lo
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jul 24, 2017 at 12:31 PM, Stephen Frost wrote:
> > Those backup scripts might very well be, today, producing invalid
> > backups though, which would be much less good..
>
> True. However, I suspect that depends on what procedure is
On Mon, Jul 24, 2017 at 12:31 PM, Stephen Frost wrote:
> Those backup scripts might very well be, today, producing invalid
> backups though, which would be much less good..
True. However, I suspect that depends on what procedure is actually
being followed. If *everyone* who is using this is get
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jul 24, 2017 at 11:40 AM, David Steele wrote:
> > Before reviewing the patch, I would note that it looks like this issue was
> > introduced in b6a323a8c before the 9.6 release. The documentation states
> > that the pg_stop_backup() f
David,
* David Steele (da...@pgmasters.net) wrote:
> On 7/23/17 11:48 PM, Masahiko Sawada wrote:
> >On Sat, Jul 22, 2017 at 8:04 AM, Stephen Frost wrote:
> >>
> >>I started discussing this with David off-list and he'd like a chance to
> >>review it in a bit more detail (he's just returning from b
On Mon, Jul 24, 2017 at 11:40 AM, David Steele wrote:
> Before reviewing the patch, I would note that it looks like this issue was
> introduced in b6a323a8c before the 9.6 release. The documentation states
> that the pg_stop_backup() function will wait for all required WAL to be
> archived, which
Hi,
On 2017-07-21 20:17:54 -0400, Tom Lane wrote:
> > I dislike having the miscadmin.h include in executor.h - but I don't
> > quite see a better alternative.
>
> I seriously, seriously, seriously dislike that. You practically might as
> well put miscadmin.h into postgres.h. Instead, what do yo
On Mon, Jul 24, 2017 at 6:37 AM, Sokolov Yura
wrote:
> Good day, Claudio
>
>
> On 2017-07-22 00:27, Claudio Freire wrote:
>>
>> On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
>> wrote:
>>>
>>>
>>> My friend noticed, that I didn't said why I bother with autovacuum.
>>> Our customers suffers from ta
Stephen Frost writes:
> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
>> On 3/6/17 03:33, Michael Banck wrote:
>>> Would this be a candidate for backpatching, or is the behaviour change
>>> in pg_dump trumping the issues it solves?
>> Unless someone literally has a materialized vie
On Sat, Jul 22, 2017 at 8:53 PM, Amit Kapila
wrote:
> On Thu, Jul 13, 2017 at 7:38 AM, Amit Kapila
> wrote:
> > On Wed, Jul 12, 2017 at 11:20 PM, Jeff Janes
> wrote:
> >>
> >>
> >>
> >> Setting parallel_workers to 8 changes the threshold for the parallel to
> even
> >> be considered from parell
On 7/23/17 11:48 PM, Masahiko Sawada wrote:
On Sat, Jul 22, 2017 at 8:04 AM, Stephen Frost wrote:
I started discussing this with David off-list and he'd like a chance to
review it in a bit more detail (he's just returning from being gone for
a few weeks). That review will be posted to this th
On Sat, Jul 22, 2017 at 10:50 AM, Robert Haas wrote:
> On Fri, Jul 21, 2017 at 4:17 PM, Mat Arye wrote:
> > (I
> > want to avoid having to keep backwards-compatibility for all functions in
> > future shared-libraries).
>
> Are you sure that's a good idea?
No :). But we have a lot of (most of)
Hi,
There is an issue with version prior to 10 when dumping views with circular
references. I know that these views are now exported as views in 10 but they
are still exported as TABLE + RULE in prior versions. This conduct to the
following error when columns of sub-queries doesn't have the same a
Rushabh Lathia writes:
> PFA patch, where added elog() to add the error message same as all other
> places.
Some looking around says that this *isn't* the only place that just
blithely assumes that it will find an opfamily entry. But I agree
that not checking for that isn't up to project standar
Hi,
Consider the following test:
CREATE OR REPLACE FUNCTION dummy_binaryint4(a int4, b int4) RETURNS int4 AS
$$ BEGIN RETURN a; END; $$ LANGUAGE 'plpgsql' IMMUTABLE;
CREATE OPERATOR CLASS custom_opclass2 FOR TYPE int2 USING BTREE AS OPERATOR
1 = , FUNCTION 1 dummy_binaryint4(int4, int4);
t=# CR
On 2017/07/24 17:30, Etsuro Fujita wrote:
> On 2017/07/24 16:16, Amit Khandekar wrote:
>> On 24 July 2017 at 12:11, Amit Langote
>> wrote:
>>> Attached is the updated version of your patch.
>
> Good catch, Amit K. and Amit L.!
>
>> Now that this is done, any particular reason it is not done in
>
On 2017-07-21 20:41, Sokolov Yura wrote:
On 2017-07-21 19:32, Robert Haas wrote:
On Fri, Jul 21, 2017 at 4:19 AM, Sokolov Yura
wrote:
Probably with increased ring buffer there is no need in raising
vacuum_cost_limit. Will you admit it?
No, I definitely won't admit that. With default settin
Good day, Claudio
On 2017-07-22 00:27, Claudio Freire wrote:
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
wrote:
My friend noticed, that I didn't said why I bother with autovacuum.
Our customers suffers from table bloating. I've made synthetic
bloating test, and started experiments with modi
On 2017/07/24 16:16, Amit Khandekar wrote:
On 24 July 2017 at 12:11, Amit Langote wrote:
Attached is the updated version of your patch.
Good catch, Amit K. and Amit L.!
Now that this is done, any particular reason it is not done in
ExecPartitionCheck() ? I see that there is a do_convert_tup
On 24 July 2017 at 12:11, Amit Langote wrote:
> Hi Amit,
>
> On 2017/07/24 14:09, Amit Khandekar wrote:
On 2017/07/10 14:15, Etsuro Fujita wrote:
Another thing I noticed is the error handling in ExecWithCheckOptions; it
doesn't take any care for partition tables, so the column descr
On July 24, 2017 7:10:19 AM GMT+01:00, Noah Misch wrote:
>On Tue, Jul 18, 2017 at 01:04:10PM -0700, Andres Freund wrote:
>> Ok, I'll flesh out the patch till Thursday. But I do think we're
>going
>> to have to do something about the back branches, too.
>
>This PostgreSQL 10 open item is past du
59 matches
Mail list logo
