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
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 index
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 ph
"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 this
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 an
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
>> testin
On 10/12/18, 4:24 PM, "Stephen Frost" wrote:
> * Bossart, Nathan (bossa...@amazon.com) wrote:
>> My main motivation for suggesting the increase to 8k is to provide
>> flexibility for alternative authentication methods like LDAP, RADIUS,
>> PAM, and BSD.
>
> Specific use-cases here would be better
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 pruni
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 ca
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
> > >
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 t
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 obv
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 pl
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 d
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 use
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
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 p
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 (cost=0.03..
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
> PROMPT_MAX_PASSW
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 expensi
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 so
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 ex
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
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 table
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), \
> >
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 nam
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 = AllocS
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 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
> AllocSetContext
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,
>
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 alre
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 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 col
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 migh
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
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 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
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
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, (AttrNumb
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 m
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 f
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
>
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 types
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
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 (b)
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
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 ac
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
>> teac
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 wi
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 range
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 a
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 bui
> 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 of
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 allowing
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.
What
56 matches
Mail list logo
