On Wed, Jun 27, 2018 at 12:10 PM, Andrey V. Lepikhov
wrote:
> I prepare third version of the patches. Summary:
> 1. Mask DEAD tuples at a page during consistency checking (See comments for
> the mask_dead_tuples() function).
- ItemIdSetDead(lp);
+ if (target_index_deletion_factor > 0)
+
On Tue, Jun 26, 2018 at 10:38 AM, Amit Langote
wrote:
> Hi.
>
> As discussed a little while back [1] and also recently mentioned [2], here
> is a patch that adds a set of functions to inspect the details of a
> partition tree. There are three functions:
>
> pg_partition_parent(regclass) returns
On 29.06.2018 10:00, Kuntal Ghosh wrote:
On Wed, Jun 27, 2018 at 12:10 PM, Andrey V. Lepikhov
wrote:
I prepare third version of the patches. Summary:
1. Mask DEAD tuples at a page during consistency checking (See comments for
the mask_dead_tuples() function).
- ItemIdSetDead(lp);
+ if
On 27 June 2018 at 18:33, Ashutosh Bapat
wrote:
> On Wed, Jun 27, 2018 at 10:39 AM, Andres Freund wrote:
>> Hi,
>>
>> (sorry if I CCed the wrong folks, the code has changed a fair bit)
>>
>> I noticed that several places in the partitioning code look like:
>>
>> /*
>> * If the tuple has
On Sat, Jun 23, 2018 at 2:52 PM Ashutosh Sharma
wrote:
> On Sat, Jun 23, 2018 at 7:36 AM, Haribabu Kommi
> wrote:
> > On Sat, Jun 23, 2018 at 5:45 AM Euler Taveira
> wrote:
> >>
> >> 2018-06-22 12:06 GMT-03:00 Robert Haas :
> >> > On Wed, Jun 20, 2018 at 10:19 AM, Euler Taveira >
> >> >
On Thu, Jun 28, 2018 at 11:12 PM Bruce Momjian wrote:
> On Wed, Jun 27, 2018 at 11:16:07PM +1000, Haribabu Kommi wrote:
> > On Sun, Jun 24, 2018 at 6:36 AM Bruce Momjian wrote:
> >
> > On Wed, Jun 13, 2018 at 11:42:14AM +1000, Haribabu Kommi wrote:
> > >
> > > Thanks for the
On 2018/06/29 6:23, Peter Eisentraut wrote:
> On 6/28/18 22:52, Alvaro Herrera wrote:
>>> Couldn't psql chase the pg_depend links to find inherited triggers?
>>
>> Yeah, I thought this would be exceedingly ugly, but apparently it's not
>> *that* bad -- see the attached patch, which relies on the
On Mon, Jun 4, 2018 at 10:00 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 6/4/18 20:55, Jeff Janes wrote:
> > The user docs say about column defaults: "The value is any variable-free
> > expression (subqueries and cross-references to other columns in the
> > current table
On Thu, 28 Jun 2018 16:22:15 -0700
"David G. Johnston" wrote:
> On Thu, Jun 28, 2018 at 3:57 PM, Daniel Gustafsson wrote:
Thank you for your reviewing!
I attached the updated patch.
>
> > > On 27 Jun 2018, at 18:02, Yugo Nagata wrote:
> >
> > > I found that there isn't explanation about
Hi!
Current estimation of sort cost has following issues:
- it doesn't differ one and many columns sort
- it doesn't pay attention to comparison function cost and column width
- it doesn't try to count number of calls of comparison function on per column
basis
At least [1] and [2] hit
Hi,
On 2018-06-28 16:08:31 +0530, Rajkumar Raghuwanshi wrote:
> I am getting server crash with below test case, logfile message and core
> dump details in the mail.
Which versions are affected here? Is this reproducible in postgres 10 or
just the current beta?
> postgres=# CREATE TABLE
Hi,
On 2018-06-28 22:35:11 +0530, Rajkumar Raghuwanshi wrote:
> On Thu, Jun 28, 2018 at 9:45 PM, Andres Freund wrote:
> > On 2018-06-28 16:08:31 +0530, Rajkumar Raghuwanshi wrote:
> > > I am getting server crash with below test case, logfile message and core
> > > dump details in the mail.
> >
>
On 2018-Jun-28, Peter Geoghegan wrote:
> On Thu, Jun 28, 2018 at 8:21 AM, Bruce Momjian wrote:
> > Good point. I have never used it but I can see its value. I have added
> > it to my template.
>
> FWIW, I developed a document on committing for my own reference, with
> some help from Andres.
I'm afraid that's a misunderstanding - my objections did not really go
away. I'm just saying my claim that we're not messing with order of
grouping keys is not entirely accurate, because we do that in one
particular case.
I still think we need to be careful when introducing new optimizations
in
On Thu, Jun 28, 2018 at 9:45 PM, Andres Freund wrote:
> Hi,
>
> On 2018-06-28 16:08:31 +0530, Rajkumar Raghuwanshi wrote:
> > I am getting server crash with below test case, logfile message and core
> > dump details in the mail.
>
> Which versions are affected here? Is this reproducible in
Andres Freund writes:
> On June 28, 2018 4:28:39 PM PDT, Tom Lane wrote:
>> (In principle, CREATE STATISTICS might someday obsolete this use-case
>> for expression indexes, but it hasn't done so yet AFAIK.)
> You mean stats on them, or the feature entirely? If the latter, how?
No, just the
On 2018/06/28 22:01, Ashutosh Bapat wrote:
> On Thu, Jun 28, 2018 at 11:19 AM, Amit Langote
> wrote:
>>>
>>> It would have imagined that just creating a new file, say
>>> partition_desc.sql or similar is nicer.
>>
>> How about partition_info.sql because they're testing partitioning
>> information
On 29 June 2018 at 11:10, David Rowley wrote:
> On further inspection, the slowdown is coming from the planner in
> make_inh_translation_list(). The INSERT path does not hit that since
> the planner's job is pretty simple for simple INSERTs.
I've attached a patch that uses SearchSysCacheAttName
On Thu, Jun 28, 2018 at 09:54:35AM +0200, Daniel Gustafsson wrote:
> On 28 Jun 2018, at 04:54, Michael Paquier wrote:
>> I see more that 860 references to openssl as lower case with lots of
>> noise around file names and translations. And I can see that you missed
>> two of them:
>
> Nice
On Fri, Jun 29, 2018 at 10:37:55AM +0900, Michael Paquier wrote:
> The set of APIs that we use to the SSL abstraction layer is very
> internal, so it would not be an issue if we add some in stable branches,
> no? My point is that from OpenSSL point of view, TLS 1.3 stuff has been
> added in 1.1.1
On June 28, 2018 4:28:39 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> On June 28, 2018 4:18:36 PM PDT, Tom Lane wrote:
>>> Also, is it really true that we don't support included expression
>>> columns now? In what way would that not be a bug?
>
>> I don't think IOS supports expression
On Thu, Jun 28, 2018 at 10:05:23AM +0200, Peter Eisentraut wrote:
> But before we drop the SCRAM business completely off the open items, I
> think we need to consider how TLS 1.3 affects this.
The set of APIs that we use to the SSL abstraction layer is very
internal, so it would not be an issue
On Wed, Jun 27, 2018 at 11:16:07PM +1000, Haribabu Kommi wrote:
> On Sun, Jun 24, 2018 at 6:36 AM Bruce Momjian wrote:
>
> On Wed, Jun 13, 2018 at 11:42:14AM +1000, Haribabu Kommi wrote:
> >
> > Thanks for the confirmation.
> > This is a good use case that must be explicitly
On Thu, Jun 28, 2018 at 9:47 AM, Teodor Sigaev wrote:
> Current estimation of sort cost has following issues:
> - it doesn't differ one and many columns sort
> - it doesn't pay attention to comparison function cost and column width
> - it doesn't try to count number of calls of comparison
On Wed, Jun 27, 2018 at 9:22 AM, Yugo Nagata wrote:
> According to the syntax in ALTER INDEX doc, a column should be specified by
> column number as discussed in [1]. However, the current code still allows to
> use an internal column name like "expr". Is this intentional?
>
> Although it is
On Thu, Jun 28, 2018 at 11:14:38AM -0400, Alvaro Herrera wrote:
> I'm not sure pgsql-committers was the right audience. Cross-posting to
> pg-hackers.
>
> On 2018-Jun-28, Bruce Momjian wrote:
>
> > 2 Reported-by:
> > 5 Author:
> > 6 Reviewed-by:
> > 7 Tested-by:
>
>
On Thu, Jun 28, 2018 at 9:52 AM, Alvaro Herrera
wrote:
>> FWIW, I developed a document on committing for my own reference, with
>> some help from Andres.
>
> Sounds very useful.
>
> How about turning it into a wiki page, for everybody's benefit?
I'll try to do that, but I'd still recommend
On 6/28/18 22:52, Alvaro Herrera wrote:
>> Couldn't psql chase the pg_depend links to find inherited triggers?
>
> Yeah, I thought this would be exceedingly ugly, but apparently it's not
> *that* bad -- see the attached patch, which relies on the fact that
> triggers don't otherwise depend on
On 6/28/18 13:30, Michael Paquier wrote:
> On Thu, Jun 28, 2018 at 12:37:14PM +0200, Peter Eisentraut wrote:
>> I'm thinking, an SQL query might be more efficient if you want to
>> qualify the query further. For example, give me all tables in this tree
>> that match '2018'. If you wrote your
On 28.06.2018 05:23, Chapman Flack wrote:
On 06/27/2018 07:36 PM, Nikita Glukhov wrote:
Also it can be found in our sqljson repository on sqljson_doc branch:
https://github.com/postgrespro/sqljson/tree/sqljson_doc
Perhaps it is my unfamiliarity, but it seems that on lines 1067–1071,
the
> On 27 Jun 2018, at 18:02, Yugo Nagata wrote:
> I found that there isn't explanation about EXCLUDING in CREATE TABLE doc.
> Attached is a patch to add this. I would appreciate it if a native English
> speaker comments on this.
+ If EXCLUDING option is specified
The empty seems wrong.
On 2018-Jun-28, Andres Freund wrote:
> On 2018-06-28 22:35:11 +0530, Rajkumar Raghuwanshi wrote:
> > On Thu, Jun 28, 2018 at 9:45 PM, Andres Freund wrote:
> > > On 2018-06-28 16:08:31 +0530, Rajkumar Raghuwanshi wrote:
> > > > I am getting server crash with below test case, logfile message and
On 29 June 2018 at 02:23, Alexander Kuzmenkov
wrote:
> I think I found one possible reason for this slowness. Your patch behaves as
> expected when there is a dropped output column, but does one extra
> comparison when there is a dropped input column. This backwards conversion
> is called from
On 06/28/2018 06:45 PM, Nikita Glukhov wrote:
> Standard says only about returning of string (both binary and character),
> numeric, boolean and datetime types in JSON_VALUE and only about string
> types in JSON_QUERY.
What I think I noticed was that right now, in func-sqljson.sgml,
the same
Yugo Nagata writes:
> I found that both key columns and included columns are checked when analyze
> is run on indexes. This is almost harmless because non-expression columns
> are not processed. However, this check is obviously unnecessary and we
> can fix this to not check included columns. If
On June 28, 2018 4:18:36 PM PDT, Tom Lane wrote:
>Yugo Nagata writes:
>> I found that both key columns and included columns are checked when
>analyze
>> is run on indexes. This is almost harmless because non-expression
>columns
>> are not processed. However, this check is obviously
On Thu, Jun 28, 2018 at 3:57 PM, Daniel Gustafsson wrote:
> > On 27 Jun 2018, at 18:02, Yugo Nagata wrote:
>
> > I found that there isn't explanation about EXCLUDING in CREATE TABLE doc.
> > Attached is a patch to add this. I would appreciate it if a native
> English
> > speaker comments on
On Thu, Jun 28, 2018 at 11:51:23AM +0530, Rajkumar Raghuwanshi wrote:
> postgres=# select pgstatindex('part_pk');
> ERROR: relation "part_pk" is not a btree index
This error message is intentional. Please see bef5fcc and its related
thread:
On Fri, Mar 30, 2018 at 2:56 PM, Thomas Munro
wrote:
> On Thu, Mar 8, 2018 at 10:28 AM, Robert Haas wrote:
>> +SerializableXactHandle
>> +ShareSerializableXact(void)
>> +{
>> +Assert(!IsParallelWorker());
>> +
>> +return MySerializableXact;
>> +}
>>
>> Uh, how's that OK? There's no rule
On Thu, Jun 28, 2018 at 09:44:13AM +0200, Magnus Hagander wrote:
> Normally I'm the biggest promoter for back-patching documentation changes
> :) But in the case when it's really just about the capitalization, I think
> it's fine to just bother with HEAD for it.
Yeah, after second-thoughts I
Thank you for the new version.
On Wed, Jun 27, 2018 at 03:10:51PM -0500, Justin Pryzby wrote:
> Thanks - I've done this in the attached. It works well for having minimal
> logic.
I think everthing is OK. But I didn't notice in previous version of the
patch that there is no braces in EXPLAIN and
Hi,
I am getting server crash with below test case, logfile message and core
dump details in the mail.
postgres=# CREATE TABLE part_tbl (a INT, b TEXT, c INT) PARTITION BY
RANGE(a);
CREATE TABLE
postgres=# CREATE TABLE part_tbl_p PARTITION OF part_tbl FOR VALUES FROM
(minvalue) TO (maxvalue);
On 6/28/18 10:59, Amit Langote wrote:
> On 2018/06/28 17:40, Peter Eisentraut wrote:
>> On 6/26/18 07:08, Amit Langote wrote:
>>> As discussed a little while back [1] and also recently mentioned [2], here
>>> is a patch that adds a set of functions to inspect the details of a
>>> partition tree.
On 28 June 2018 at 05:37, Peter Moser wrote:
[]
> In general my use-case is, that I want to delete an X in a certain
> namespace, where the type is not known in advance. I could query the
> catalog to get that information and then build a procedure to "execute" the
> right DROP command (as
On Thu, Jun 28, 2018 at 12:37:14PM +0200, Peter Eisentraut wrote:
> I'm thinking, an SQL query might be more efficient if you want to
> qualify the query further. For example, give me all tables in this tree
> that match '2018'. If you wrote your functions as SQL-language
> functions, the
On Thu, Jun 28, 2018 at 10:04:05AM +0200, Peter Eisentraut wrote:
> On 6/28/18 09:35, Magnus Hagander wrote:
> > No, we absolutely still have SCRAM channel binding.
> >
> > *libpq* has no way to *enforce* it, meaning it always acts like our
> > default SSL config which is "use it if available but
On Thu, Jun 28, 2018 at 11:19 AM, Amit Langote
wrote:
>>
>> It would have imagined that just creating a new file, say
>> partition_desc.sql or similar is nicer.
>
> How about partition_info.sql because they're testing partitioning
> information functions? partition_desc reminded me of
another case where I got error like partition table index is not a index is
given below.
postgres=# create table part(a int, constraint part_pk primary key(a))
PARTITION BY RANGE(a);
CREATE TABLE
postgres=# create table part_p1 partition of part for values from
(minvalue) to (0);
CREATE TABLE
On Thu, Jun 28, 2018 at 12:07 PM, Michael Paquier
wrote:
> On Thu, Jun 28, 2018 at 11:51:23AM +0530, Rajkumar Raghuwanshi wrote:
> > postgres=# select pgstatindex('part_pk');
> > ERROR: relation "part_pk" is not a btree index
>
> This error message is intentional. Please see bef5fcc and its
Hi,
I found that both key columns and included columns are checked when analyze
is run on indexes. This is almost harmless because non-expression columns
are not processed. However, this check is obviously unnecessary and we
can fix this to not check included columns. If we decide to support
On Thu, Jun 28, 2018 at 09:35:57AM +0200, Magnus Hagander wrote:
> No, we absolutely still have SCRAM channel binding.
>
> *libpq* has no way to *enforce* it, meaning it always acts like our default
> SSL
> config which is "use it if available but if it's not then silently accept the
>
On 6/27/18 23:01, Alvaro Herrera wrote:
> Another angle is that we're already in beta3 and there may be concerns
> about altering catalog definition this late in the cycle. Anybody?
> Maybe psql can just match tgisinternal triggers by name, and if one
> match occurs then we assume it's a clone
On Thu, Jun 28, 2018 at 10:04 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 6/28/18 09:35, Magnus Hagander wrote:
> > No, we absolutely still have SCRAM channel binding.
> >
> > *libpq* has no way to *enforce* it, meaning it always acts like our
> > default SSL config which
On 6/28/18 08:47, Michael Paquier wrote:
>>> There could be some cases where
>>> copying a physical slot also makes sense.
>> I've thought that but I didn't find concrete use case. That's why I
>> started with only logical slot.
> Let's imagine the case of a single base backup which is associated
Hi,
According to the error message, it is not allowed to alter statistics on
included column because this is "non-expression column".
postgres=# create table test (i int, d int);
CREATE TABLE
postgres=# create index idx on test(i) include (d);
CREATE INDEX
postgres=# alter index idx alter
On 06/26/2018 07:06 PM, Tom Lane wrote:
Also worth noting is that similar issues arise elsewhere, eg we now
have "procedures" vs "functions" in a single namespace. Let's not have
DROP TABLE acting in a way that's inconsistent with other parts of the
system.
I think, that
DROP ...
could
On Thu, Jun 28, 2018 at 4:54 AM, Michael Paquier
wrote:
> On Thu, Jun 28, 2018 at 12:16:52AM +0200, Daniel Gustafsson wrote:
> > Skimming over SSL code and docs I noticed that we almost always properly
> > capitalize “OpenSSL" when referring to the name of the library, using
> "openssl”
> > for
On Thu, Jun 28, 2018 at 03:34:00PM +0900, Masahiko Sawada wrote:
> On Thu, Jun 28, 2018 at 12:29 PM, Michael Paquier wrote:
>> Hm. Shouldn't the original slot copied be owned by the process doing
>> the copy with ReplicationSlotAcquire?
>
> Right, it should do and release it before creating new
On 6/28/18 09:35, Magnus Hagander wrote:
> No, we absolutely still have SCRAM channel binding.
>
> *libpq* has no way to *enforce* it, meaning it always acts like our
> default SSL config which is "use it if available but if it's not then
> silently accept the downgrade". From a security
On 6/28/18 09:33, Magnus Hagander wrote:
> Should there be one or more parameters? How should they interact? At
> which level should they be controlled? Limited to SCRAM or other channel
> bindings? Are the different levels of SCRAM to be considered different
> protocols or the same protocol with
On Thu, Jun 28, 2018 at 5:37 PM, Peter Eisentraut
wrote:
> On 6/28/18 08:47, Michael Paquier wrote:
There could be some cases where
copying a physical slot also makes sense.
>>> I've thought that but I didn't find concrete use case. That's why I
>>> started with only logical slot.
>>
> On 28 Jun 2018, at 04:54, Michael Paquier wrote:
> I see more that 860 references to openssl as lower case with lots of
> noise around file names and translations. And I can see that you missed
> two of them:
Nice catch, fixed in the attached.
> I don't think that the comments are worth
On Thu, Jun 28, 2018 at 12:29 PM, Michael Paquier wrote:
> On Thu, Jun 28, 2018 at 11:51:20AM +0900, Masahiko Sawada wrote:
>> A use case I imagined is for investigations for example. I mean that
>> when replication collision occurs on subscriber there is no way to see
>> what replicated data is
On 6/28/18 01:10, Michael Paquier wrote:
> On Wed, Jun 27, 2018 at 01:37:33PM -0700, Andres Freund wrote:
>> On 2018-06-27 22:31:30 +0200, Peter Eisentraut wrote:
>>> I propose that we instead silently ignore attempts to add TOAST tables
>>> to shared and system catalogs after bootstrapping.
>>
>>
On Wed, Mar 14, 2018 at 11:29 AM, Masahiko Sawada wrote:
> On Tue, Mar 6, 2018 at 11:27 PM, Alvaro Herrera
> wrote:
>> Hello
>>
>> I haven't read your respective patches yet, but both these threads
>> brought to memory a patch I proposed a few years ago that I never
>> completed:
>>
>>
On Wed, Jun 27, 2018 at 7:24 PM, Alvaro Herrera
wrote:
> Going over this thread a little bit I'm confused about what is being
> proposed. I think I understand that we no longer think we have have
> SCRAM channel binding. I hope that doesn't mean we don't have SCRAM
> itself. However, in terms
On 6/28/18 09:35, Magnus Hagander wrote:
> No, we absolutely still have SCRAM channel binding.
>
> *libpq* has no way to *enforce* it, meaning it always acts like our
> default SSL config which is "use it if available but if it's not then
> silently accept the downgrade". From a security
On 06/25/2018 08:00 AM, David Rowley wrote:
I'd have expected Test 6 to do about 480-500tps. Adding debug to check
why it's not revealed that the search is doing what's expected. I'm
unsure why it has not improved more.
I think I found one possible reason for this slowness. Your patch
behaves
On Thu, Jun 28, 2018 at 11:20 AM, Andres Freund wrote:
>> Apparently, there's a recent trend to credit patch authors using
>> "Co-authored-by". Should we use that too?
>> https://stackoverflow.com/a/41847267/
>
> I just put multiple people into Authors, with order roughly implying the
> amount
I'm not sure pgsql-committers was the right audience. Cross-posting to
pg-hackers.
On 2018-Jun-28, Bruce Momjian wrote:
> 2 Reported-by:
> 5 Author:
> 6 Reviewed-by:
> 7 Tested-by:
Should these include email addresses?
I've also used "Diagnosed-by" to credit a person
On 2018-06-28 11:14:38 -0400, Alvaro Herrera wrote:
> I'm not sure pgsql-committers was the right audience. Cross-posting to
> pg-hackers.
>
> On 2018-Jun-28, Bruce Momjian wrote:
>
> > 2 Reported-by:
> > 5 Author:
> > 6 Reviewed-by:
> > 7 Tested-by:
>
> Should these
71 matches
Mail list logo
