On 10/12/2018 10:03 AM, Tom Lane wrote:
Andres Freund writes:
On 2018-10-11 17:11:47 -0400, Tom Lane wrote:
A compromise that occurred to me after a bit of reflection is to place
the necessary table-drop commands in a new regression test script that's
meant to be executed last, but isn't
On Wed, Oct 10, 2018 at 8:27 AM Haribabu Kommi wrote:
> Here is the patch as per the above discussion.
One potential problem with this is that we could add more control-file
attributes in the future, and it will be annoying if the view ends up
with a million columns, or if we ever have to rename
Hi,
On 2018-10-12 11:23:30 -0400, Andrew Dunstan wrote:
> Anything that runs at the time we do the regression tests has problems, from
> my POV. If we run the drop commands then upgrading these types to a target
> <= 11 isn't tested.
I'm asking again, what exactly do we test by having these
Hi,
Christoph Berg, on IRC, raised the issue that at least one extension
failed compiling in v11. The extension currently does:
https://github.com/pgq/pgq/blob/master/triggers/common.c#L225
tbl_cache_ctx = AllocSetContextCreate(TopMemoryContext,
On 10/12/2018 01:10 PM, Christoph Berg wrote:
> Re: Andres Freund 2018-10-12
> Andres' idea would enable the old code to continue to work, but
> couldn't we additionally to backpatch the ALLOCSET_*_SIZES macros, so
> the new code works also on old versions that didn't get the new
>
Pushed, after some further refinement of the test case so that it'd
verify a few more corner case situations.
Thanks Michael.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Andres Freund 2018-10-12 <20181012170355.bhxi273skjt6s...@alap3.anarazel.de>
> Hi,
>
> Christoph Berg, on IRC, raised the issue that at least one extension
> failed compiling in v11. The extension currently does:
> https://github.com/pgq/pgq/blob/master/triggers/common.c#L225
Others have
On 2018-Oct-12, Robert Haas wrote:
> I think we should be striving to use types like regclass more often in
> system catalogs and views, not less often.
+1
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan writes:
> On 10/12/2018 10:03 AM, Tom Lane wrote:
>> Well, in any case I'd say we should put the dropping commands into
>> a separate late-stage test script. Whether that's run by default is a
>> secondary issue: if it is, somebody who wanted to test this stuff could
>> remove the
Hello
I complete new version of this patch. I've attached it.
In this version i remove proposed recovery_target_type/recovery_target_value
and implement set of current settings: recovery_target (immediate),
recovery_target_name, recovery_target_time, recovery_target_xid,
recovery_target_lsn
Hello
I just realized that the current code to assign constraint names to
partitions is going against the SQL standard's idea that constraint
names must be unique within a schema. When a partition is created, the
foreign key gets exactly the same name as the constraint in the parent
table.
Now
On Wed, Oct 10, 2018 at 4:26 AM Amit Langote
wrote:
> On the other hand, the syntax of CHECK constraints allows a fairly wide
> range of expressions to be specified, with expressions/values of arbitrary
> types and operators with arbitrary semantics (not limited to
> btree/ordering semantics, for
On Wed, Oct 10, 2018 at 1:50 PM Tom Lane wrote:
> It fails in cases where the data type
> considers distinguishable values to be "equal", as for example zero vs.
> minus zero in IEEE floats, or numeric values with varying numbers of
> trailing zeroes, or citext, etc. So for example if the sno
Robert Haas writes:
> Now, I think there is a reasonable argument that it would still be
> nice to give an ERROR diagnostic in the cases we can detect, but I do
> not agree with that argument, for all of the reasons stated here: the
> development resources are better spent elsewhere, somebody
Andres Freund writes:
> Christoph Berg, on IRC, raised the issue that at least one extension
> failed compiling in v11. The extension currently does:
> https://github.com/pgq/pgq/blob/master/triggers/common.c#L225
> tbl_cache_ctx = AllocSetContextCreate(TopMemoryContext,
>
Andres Freund writes:
> I'm asking again, what exactly do we test by having these types in the
> dump? They're bog standard types, there's nothing new for pg_dump to
> test with them. No weird typmod rules, no weird parse-time type mapping,
> nothing?
That's a pretty fair point. The types' I/O
On Tue, Oct 2, 2018 at 11:37 PM Michael Paquier wrote:
> Putting the new function pg_partition_children() in partition.c is a
> bad idea I think. So instead I think that we should put that in a
> different location, say utils/adt/partitionfuncs.c.
>
> + TupleDescInitEntry(tupdesc,
On 10/12/2018 12:20 PM, Tom Lane wrote:
Andres Freund writes:
I'm asking again, what exactly do we test by having these types in the
dump? They're bog standard types, there's nothing new for pg_dump to
test with them. No weird typmod rules, no weird parse-time type mapping,
nothing?
That's
Hi All,
The copy command on partitioned table causes server crash when before
insert row trigger is created on one of its partition. Please find the
following test-case to reproduce the crash.
-- create a partitioned table
create table part_copy_test (a int, b int, c text) partition by list
Andres Freund writes:
> But can't we just do something like:
> #if defined(HAVE__BUILTIN_CONSTANT_P) && defined(HAVE__VA_ARGS)
> #define AllocSetContextCreate(parent, name, ...) \
> (StaticAssertExpr(__builtin_constant_p(name), \
> "memory context
On 2018-10-12 13:20:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Christoph Berg, on IRC, raised the issue that at least one extension
> > failed compiling in v11. The extension currently does:
> > https://github.com/pgq/pgq/blob/master/triggers/common.c#L225
> > tbl_cache_ctx =
Hi,
I've had to whack CopyFrom() around a couple times due to the pluggable
storage patch, and I found that after
commit 0d5f05cde011512e605bb2688d9b1fbb5b3ae152
Author: Peter Eisentraut
Date: 2018-08-01 10:23:09 +0200
Allow multi-inserts during COPY into a partitioned table
and also the
Andres Freund writes:
> On 2018-10-12 13:51:53 -0400, Tom Lane wrote:
>> Shall we also backpatch the ALLOCSET_*_SIZES macros as Christoph
>> suggested? I'm not convinced of the usefulness of that, since
>> extensions would still have to cope with them not being present
>> when building against
On Thu, Sep 13, 2018 at 11:40 AM Jesper Pedersen
wrote:
> > I noticed that current implementation doesn't
> > perform well when we have lots of small groups of equal values. Here is
> > the execution time of index skip scan vs unique over index scan, in ms,
> > depending on the size of group. The
On 2018-10-12 13:51:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > But can't we just do something like:
>
> > #if defined(HAVE__BUILTIN_CONSTANT_P) && defined(HAVE__VA_ARGS)
> > #define AllocSetContextCreate(parent, name, ...) \
> > (StaticAssertExpr(__builtin_constant_p(name), \
> >
Hi,
On 2018-10-12 21:16:25 +0530, Ashutosh Sharma wrote:
> The copy command on partitioned table causes server crash when before
> insert row trigger is created on one of its partition. Please find the
> following test-case to reproduce the crash.
>
> -- create a partitioned table
> create
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> I've attached 2 patches in an effort to clarify the upper bounds on
> password lengths:
> - 0001 refactors the hard-coded 100 character buffer size used for
> password prompts for client utilities into a
>
On Fri, 12 Oct 2018 at 16:52, Stephen Frost wrote:
> I'm also trying to figure out why it makes sense to support an 8k
> password and if we've really tried seeing what happens if pg_authid gets
> a toast table that's actually used for passwords...
>
pg_authid.rolpassword stores a hash, so the
Hello Peter,
The abort is by a client, but the code seems to only check the first
client of a thread. ISTM that if the second or later client abort it may
not be detected? Probably an intermediate aggregation at the thread level
is needed, or maybe a global variable, or as errors are counted
Consider this simple query:
regression=# explain select * from
int8_tbl as a1 full join (select 1 as id) as a2 on (a1.q1 = a2.id);
QUERY PLAN
--
Hash Full Join
Hi Stephen,
On 10/12/18, 3:52 PM, "Stephen Frost" wrote:
> If we're going to do work in this area, why wouldn't we have the client
> tools and the server agree on the max length and then have them all be
> consistent..?
>
> Seems odd to decide that 100 character buffer size in the clients makes
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 10/12/18, 3:52 PM, "Stephen Frost" wrote:
> > If we're going to do work in this area, why wouldn't we have the client
> > tools and the server agree on the max length and then have them all be
> > consistent..?
> >
> > Seems odd to
"Bossart, Nathan" writes:
> On 10/12/18, 4:24 PM, "Stephen Frost" wrote:
>> Specific use-cases here would be better than hand-waving at "these other
>> things." Last I checked, all of those work with what we've got today
>> and I don't recall hearing complaints about them not working due to
On 10/12/18, 7:02 PM, "Tom Lane" wrote:
> "Bossart, Nathan" writes:
>> The main one I am thinking of is generated security tokens. It seems
>> reasonable to me to limit md5 and scram-sha-256 passwords to a much
>> shorter length, but I think the actual server message limit should be
>> somewhat
On 2018-10-09 20:46:04 +0530, Amit Khandekar wrote:
> On Wed, 26 Sep 2018 at 05:35, Andres Freund wrote:
> > > +
> > > +/*
> > > + * This is a function used by all getattr() callbacks which deal with a
> > > heap
> > > + * tuple or some tuple format which can be represented as a heap tuple
> >
Isaac Morland writes:
> On Fri, 12 Oct 2018 at 16:52, Stephen Frost wrote:
>> I'm also trying to figure out why it makes sense to support an 8k
>> password and if we've really tried seeing what happens if pg_authid gets
>> a toast table that's actually used for passwords...
> ...
> It's also
Hi Isaac,
On 10/12/18, 4:04 PM, "Isaac Morland" wrote:
> I agree there should be a specific limit that is the same in libpq,
> on the server, and in the protocol. Maybe 128 characters, to get a
> nice round number? This is still way longer than the 32-byte SHA 256
> hash. Or 64, which is still
On Sat, Oct 13, 2018 at 7:36 David Rowley
wrote:
> On 12 October 2018 at 23:35, Amit Langote
> wrote:
> > On 2018/10/11 13:45, Amit Langote wrote:
> >> On 2018/10/07 17:43, David Rowley wrote:
> >>> Amit Langote has since posted a patch to delay the RangeTblEntry
> >>> creation until after
Hi,
On 2018-10-12 19:47:40 -0400, Tom Lane wrote:
> BTW, I was annoyed while looking things over that this patch had broken
> a couple of comments in opr_sanity.sql:
>
> @@ -823,7 +823,6 @@ WHERE a.aggfnoid = p.oid AND
>
> -- Cross-check transfn against its entry in pg_proc.
> -- NOTE: use
Greetings,
* Isaac Morland (isaac.morl...@gmail.com) wrote:
> On Fri, 12 Oct 2018 at 16:52, Stephen Frost wrote:
> > I'm also trying to figure out why it makes sense to support an 8k
> > password and if we've really tried seeing what happens if pg_authid gets
> > a toast table that's actually
Greetings,
* Bossart, Nathan (bossa...@amazon.com) wrote:
> On 10/12/18, 4:04 PM, "Isaac Morland" wrote:
> > I agree there should be a specific limit that is the same in libpq,
> > on the server, and in the protocol. Maybe 128 characters, to get a
> > nice round number? This is still way longer
Andrew Dunstan writes:
> On 10/12/2018 12:20 PM, Tom Lane wrote:
>> That's a pretty fair point. The types' I/O functions will be exercised
>> well enough by the regression tests themselves, and it's hard to see what
>> more test coverage is gained by including them in pg_dump/pg_upgrade
>>
BTW, I was annoyed while looking things over that this patch had broken
a couple of comments in opr_sanity.sql:
@@ -823,7 +823,6 @@ WHERE a.aggfnoid = p.oid AND
-- Cross-check transfn against its entry in pg_proc.
-- NOTE: use physically_coercible here, not binary_coercible, because
--- max
Hi,
On 2018-10-05 12:03:54 +0200, Peter Eisentraut wrote:
> From 37591a06901e2d694e3928b7e1cddfcfd84f6267 Mon Sep 17 00:00:00 2001
> From: Peter Eisentraut
> Date: Mon, 13 Aug 2018 22:38:36 +0200
> Subject: [PATCH v2] Lower lock level for renaming indexes
>
> Change lock level for renaming
Andres Freund writes:
> On 2018-10-09 18:00:54 -0400, Tom Lane wrote:
>>> Also, we have quite a few variant expected-files that exist only to cater
>>> for Windows' habit of printing three exponent digits where everybody else
>>> prints just two. It struck me that it would not be hard, or
On 12 October 2018 at 23:35, Amit Langote wrote:
> On 2018/10/11 13:45, Amit Langote wrote:
>> On 2018/10/07 17:43, David Rowley wrote:
>>> Amit Langote has since posted a patch to delay the RangeTblEntry
>>> creation until after pruning. His patch happens to also move the
>>> total_table_pages
On Fri, Oct 12, 2018 at 12:11:58PM +0900, Michael Paquier wrote:
> Agreed. I am just working on a patch for v11- which uses a
> whitelist-based method instead of what is present now. Reverting the
> tests to put the buildfarm to green could be done, but that's not the
> root of the problem.
So,
Re: Michael Paquier 2018-10-12 <20181012002520.gb26...@paquier.xyz>
> Do you still have the logs of the previous run for the standby?
Sorry, all I have is the (link to) the build log in the original
posting. I can run some tests on the mips porter box if you have any
ideas for things to try.
On 12/10/2018 11:54, Andrey Klychkov wrote:
Studying another question I noticed a small point for optimization.
In the src/backend/access/heap/heapam.c we have the function:
- * simple_heap_insert - insert a tuple
- *
- * Currently, this routine differs from heap_insert only in supplying
- * a
Hi, Hackers
Studying another question I noticed a small point for optimization.
In the src/backend/access/heap/heapam.c we have the function:
- * simple_heap_insert - insert a tuple
- *
- * Currently, this routine differs from heap_insert only in supplying
- * a default command ID and not
Hi, let me clarify my understanding about the $title.
It seems that the number of hash partitions is fixed at 128 in dshash and
right now we cannot change it unless dshash.c code itself is changed, right?
According to the comment of dshash.c, DSHASH_NUM_PARTITIONS could be runtime
parameter in
Hi Michael,
Thanks for your input.
On Thu, Oct 11, 2018 at 11:38 AM, Michael Paquier
wrote:
> On Wed, Oct 10, 2018 at 03:37:50PM +0800, Richard Guo wrote:
> > This is a follow-up to the issue described in thread
> > https://www.postgresql.org/message-id/CAMbWs4-Mys%3DhBQSevTA8Zpd-TYFnb%
>
Hi,
On Fri, Oct 12, 2018 at 03:05:43PM +0900, Michael Paquier wrote:
> On Fri, Oct 12, 2018 at 12:11:58PM +0900, Michael Paquier wrote:
> > Agreed. I am just working on a patch for v11- which uses a
> > whitelist-based method instead of what is present now. Reverting the
> > tests to put the
On 2018/10/11 13:45, Amit Langote wrote:
> On 2018/10/07 17:43, David Rowley wrote:
>> Amit Langote has since posted a patch to delay the RangeTblEntry
>> creation until after pruning. His patch happens to also move the
>> total_table_pages calculation, but I believe this change should be
>> made
> simple_heap_insert() is used in catalog updates and such. Does that have
> any measurable performance impact?
I guess this change doesn't give us an incredible performance increase except
there will no redundant function call.
I don't see any reasons against to use the proposed macro instead
Andres Freund writes:
> On 2018-10-11 17:11:47 -0400, Tom Lane wrote:
>> A compromise that occurred to me after a bit of reflection is to place
>> the necessary table-drop commands in a new regression test script that's
>> meant to be executed last, but isn't actually run by default. Then
>>
On 08.10.2018 00:16, David Rowley wrote:
On 5 October 2018 at 04:45, Konstantin Knizhnik
wrote:
Will the following test be enough:
-- check that columns for parent table are correctly mapped to child
partition of their order doesn't match
create table paren (a int, b text) partition by
On Sat, Oct 6, 2018 at 12:17 AM John Naylor wrote:
>
> -There'll need to be some performance testing to make sure there's no
> regression, and to choose a good value for the threshold. I'll look
> into that, but if anyone has any ideas for tests, that'll help this
> effort along.
>
Can you try
58 matches
Mail list logo
