On 2018/06/29 15:23, Amit Langote wrote:
> Instead of a single TupleTableSlot attached at partition_tuple_slot, we
> allocate an array of TupleTableSlot pointers of same length as the number
> of partitions, as you mentioned upthread. We then call
> MakeTupleTableSlot() only if a partition needs i
On Fri, 29 Jun 2018 08:39:01 +0200
Daniel Gustafsson wrote:
> > On 29 Jun 2018, at 07:56, Yugo Nagata wrote:
> > On Thu, 28 Jun 2018 16:22:15 -0700
> > "David G. Johnston" wrote:
>
> >> Maybe try something like:
> >>
> >> It is legal to specify the same option multiple times - e.g., "INCLUDI
On Thu, 28 Jun 2018 10:26:13 -0400
Robert Haas wrote:
> 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
Hello
Thank you for update
It may be better to use NULL as the default value at sql level.
> ereport(LOG, (errmsg("userid %u, dbid %u, queryid %ld does not exist",
> userid, dbid, queryid)));
I think LOG level is not useful here. In common case this is server log only.
How about WARNING? Or jus
On Thu, 28 Jun 2018 19:18:36 -0400
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 unnecess
Hello.
This is intended to provide more stats like the following thread.
https://www.postgresql.org/message-id/20171010.192616.108347483.horiguchi.kyot...@lab.ntt.co.jp
Most major obstracle for having more items in statistics
collector views comes from the mechanism to share the values
among bac
On Wed, Jun 27, 2018 at 12:10 PM, Andrey V. Lepikhov
wrote:
>
>
> On 23.06.2018 00:43, Peter Geoghegan wrote:
>>
>> On Fri, Jun 22, 2018 at 4:24 AM, Andrey V. Lepikhov
>> wrote:
>>>
>>> According to your feedback, i develop second version of the patch.
>>> In this version:
I had quick look at yo
On June 26th, our PostGIS debian bot started failing on PostgreSQL 10 with
one of our regression tests for topology.
It started erroring out with
ORDER/GROUP BY expression not found in targetlist
Related ticket here: https://trac.osgeo.org/postgis/ticket/4111
I think the exact query that is tr
чт, 28 июн. 2018 г., 8:37 Andrey V. Lepikhov :
>
>
> On 28.06.2018 05:00, Peter Geoghegan wrote:
> > On Tue, Jun 26, 2018 at 11:40 PM, Andrey V. Lepikhov
> > wrote:
> >> I still believe that the patch for physical TID ordering in btree:
> >> 1) has its own value, not only for target deletion,
> >
On 29 June 2018 at 21:06, Regina Obe wrote:
> I think the exact query that is triggering it is this one though I don't
> have PostgreSQL 10 head installed locally to confirm.
>
> SELECT 't3280', 'L1b' || topology.TopoGeo_AddLinestring('bug3280', geom)
> FROM bug3280.edge where edge_id = 1
> ORDE
> On 29 Jun 2018, at 09:14, Yugo Nagata wrote:
> Thanks a lot.
>
> I updated the patch.
This version looks good to me. You might want to add it to the CF to make sure
it isn’t forgotten.
cheers ./daniel
On Fri, 29 Jun 2018 11:36:19 +0200
Daniel Gustafsson wrote:
> > On 29 Jun 2018, at 09:14, Yugo Nagata wrote:
>
> > Thanks a lot.
> >
> > I updated the patch.
>
> This version looks good to me. You might want to add it to the CF to make
> sure
> it isn’t forgotten.
>
> cheers ./daniel
Sure
On Thu, Jun 28, 2018 at 7:55 PM, Masahiko Sawada wrote:
> I'd like to test and review this patches but they seem to conflict
> with current HEAD. Could you please rebase them?
Hi Sawada-san,
Thanks! Rebased and attached. The only changes are: the LWLock
tranche is now shown as "serializable_xa
Hi,
I am getting assertion failure in StartTransaction() on the latest
master when procedure having SECURITY DEFINER called, here is the
script to reproducible this crash:
--create procedure
CREATE PROCEDURE transaction_test1() LANGUAGE plpgsql SECURITY DEFINER
AS $$ BEGIN
COMMIT;
END
On 6/27/18 18:51, Peter Eisentraut wrote:
> On 6/27/18 17:44, Andres Freund wrote:
>> This hasn't progressed in a while. Peter, since you committed the
>> relevant change, could you update us please?
>
> I've been on vacation for a bit. I will work on this next. I hope to
> have a solution in a
On 6/29/18 13:07, amul sul wrote:
> This happens because of in fmgr_security_definer() function we are
> changing global variable SecurityRestrictionContext and in the
> StartTransaction() insisting it should be zero, which is the problem.
Hmm, what is the reason for this insistation?
We could w
On 6/28/18 17:14, Alvaro Herrera wrote:
>> 2 Reported-by:
>> 5 Author:
>> 6 Reviewed-by:
>> 7 Tested-by:
> Should these include email addresses?
One reason I include emails is that sometimes the names are spelled in
inconsistent ways or don't include ASCII characters at all
hey,
i am reviewing this patch
On Thu, May 31, 2018 at 4:49 AM, Carter Thaxton
wrote:
>
> pg_dump --where '"foo:bar":created_at >= '2018-05-01'" dbname
>
it would be more sqlish if it specified like:
--table=foo --where ="bar created_at >= 2018-05-01"
and i don't like the idea of duplicating t
On Fri, Jun 29, 2018 at 02:04:07PM +0200, Peter Eisentraut wrote:
> On 6/28/18 17:14, Alvaro Herrera wrote:
>>> 2 Reported-by:
>>> 5 Author:
>>> 6 Reviewed-by:
>>> 7 Tested-by:
>> Should these include email addresses?
>
> One reason I include emails is that sometimes the na
On 06/29/2018 03:25 AM, David Rowley wrote:
I've attached a patch that uses SearchSysCacheAttName to speed up
these translations in the planner.
Good idea. On my desktop, this gives 270 tps dropped vs 610 tps plain
(for updates). If you combine it with persistent inner loop index, it's
probab
On Thu, Jun 28, 2018 at 10:52:42AM -0700, Peter Geoghegan wrote:
> On Thu, Jun 28, 2018 at 9:52 AM, Alvaro Herrera
> I'll try to do that, but I'd still recommend personalizing it. A lot
> of the stuff in there is specific to my own workflow and tool
> preferences, and my own personal working style.
On Wed, Jun 27, 2018 at 10:26 PM, Amit Langote
wrote:
> By the way, picking up on the word "inherited" in the error message shown
> above, I wonder if you decided against using similar terminology
> intentionally.
Good question.
> I guess the thinking there is that the terminology being
> used e
On 06/29/2018 02:19 PM, Michael Paquier wrote:
On Fri, Jun 29, 2018 at 02:04:07PM +0200, Peter Eisentraut wrote:
On 6/28/18 17:14, Alvaro Herrera wrote:
2 Reported-by:
5 Author:
6 Reviewed-by:
7 Tested-by:
Should these include email addresses?
One reason I include
On Wed, Jun 27, 2018 at 10:27 PM, Michael Paquier wrote:
> On Wed, Jun 27, 2018 at 07:32:18PM +0300, Konstantin Knizhnik wrote:
>> I wonder why we are monitoring time of writing to WAL, but not time of
>> fsyncing WAL segments?
>> Is there are principle reason for it or just because nobody added i
(2018/06/22 22:54), Ashutosh Bapat wrote:
I have started reviewing the patch.
Thanks for the review!
+ if (enable_partitionwise_join&& rel->top_parent_is_partitioned)
+ {
+ build_childrel_tlist(root, rel, childrel, 1,&appinfo);
+ }
Why do we need rel->top_parent_
On 06/29/2018 02:30 PM, Robert Haas wrote:
On Wed, Jun 27, 2018 at 10:26 PM, Amit Langote
wrote:
By the way, picking up on the word "inherited" in the error message shown
above, I wonder if you decided against using similar terminology
intentionally.
Good question.
I guess the thinking t
On 06/28/2018 06:52 PM, Teodor Sigaev wrote:
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 b
On 29.06.2018 15:48, Robert Haas wrote:
On Wed, Jun 27, 2018 at 10:27 PM, Michael Paquier wrote:
On Wed, Jun 27, 2018 at 07:32:18PM +0300, Konstantin Knizhnik wrote:
I wonder why we are monitoring time of writing to WAL, but not time of
fsyncing WAL segments?
Is there are principle reason f
On 12.06.18 18:47, Andrew Gierth wrote:
> While testing this, I ran into another semi-related issue:
> shmem_exit_inprogress isn't ever being cleared in the postmaster, which
> means that if you ever have a crash-restart, any attempt to do a
> rollback in a procedure will then crash or get some oth
On Fri, Jun 29, 2018 at 08:48:33AM -0400, Robert Haas wrote:
> Are there other instances of fsync() that also need to be covered?
Yeah, I double-checked the calls to pg_fsync back when I looked at this
patch, but now that I look again I see at least two more of them:
- fsync_fname_ext.
- write_aut
While we're here, do people find this useful:
INCLUDING ALL is an abbreviated form of
INCLUDING COMMENTS INCLUDING CONSTRAINTS INCLUDING
DEFAULTS INCLUDING IDENTITY INCLUDING INDEXES INCLUDING STATISTICS
INCLUDING STORAGE.
Maybe something more like "... is an abbreviated f
> On 29 Jun 2018, at 15:42, Peter Eisentraut
> wrote:
>
> While we're here, do people find this useful:
>
>
> INCLUDING ALL is an abbreviated form of
> INCLUDING COMMENTS INCLUDING CONSTRAINTS INCLUDING
> DEFAULTS INCLUDING IDENTITY INCLUDING INDEXES INCLUDING STATISTICS
> INCLUD
Hello,
On a pG10.4 instance, my query ( a simple select from a view) throw this error:
ERROR: cannot start subtransactions during a parallel operation
CONTEXT: PL/pgSQL function check_validity(ltree[]) line 4 during statement
block entry
But prefixing this query by "set max_parallel_workers_ga
AFAICS, we'd just have to revert this patch later, so I don't see
much value in it.
True, I suppose we should apply this patch just for consistency, because we
don't allow expression in included columns.
Also, is it really true that we don't support included expression
columns now? In what w
Peter Geoghegan wrote:
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 c
On 06.03.2018 17:30, David Steele wrote:
I agree with Andres. Pushing this patch to the next CF.
Attached 4th version of the patches rebased onto the current master.
Nothing interesting has changed from the previous version.
--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
On 06/29/2018 04:00 PM, Mai Peng wrote:
Hello,
On a pG10.4 instance, my query ( a simple select from a view) throw this
error:
ERROR: cannot start subtransactions during a parallel operation
CONTEXT: PL/pgSQL function check_validity(ltree[]) line 4 during
statement block entry
So, what
I tried to attack the cost_sort() issues and hope on that basis we can solve
problems with 0002 patch and improve incremental sort patch.
OK, will do. Thanks for working on this!
I hope, now we have a better cost_sort(). The obvious way is a try all
combination of pathkeys in get_cheapes
On 06/29/2018 04:51 PM, Teodor Sigaev wrote:
I tried to attack the cost_sort() issues and hope on that basis we
can solve problems with 0002 patch and improve incremental sort patch.
OK, will do. Thanks for working on this!
I hope, now we have a better cost_sort(). The obvious way is a tr
On 2018-Jun-29, Rajkumar Raghuwanshi wrote:
> On Fri, Jun 29, 2018 at 4:30 AM, Alvaro Herrera
> wrote:
>
> > On 2018-Jun-28, Andres Freund wrote:
> > > Alvaro, sounds like it could be an open item assigned to you?
> >
> > You're right. The attached patch seems to fix it.
> >
> Thanks for patch
On 2018-Jun-29, Amit Langote wrote:
> 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
Hi Ashutosh,
On 06/27/2018 05:01 AM, Ashutosh Sharma wrote:
Currently, get_page_from_raw() is not used in the pageinspect
functions for btree and heap to fetch a page image from raw page.
However, the pageinspect for gin and hash is using it to avoid server
crash on alignment picky machines with
Daniel Gustafsson writes:
>> On 29 Jun 2018, at 15:42, Peter Eisentraut
>> wrote:
>> While we're here, do people find this useful:
>>
>>
>> INCLUDING ALL is an abbreviated form of
>> INCLUDING COMMENTS INCLUDING CONSTRAINTS INCLUDING
>> DEFAULTS INCLUDING IDENTITY INCLUDING INDEXES INCLUDING S
> On 29 Jun 2018, at 18:44, Tom Lane wrote:
> Now it's just confusing, especially since you
> can't tell very easily whether any of the individual options were
> intentionally omitted from the list. It will not get better with
> more options, either.
Agreed, that’s a good point.
cheers ./danie
It looks to me like we're missing a trick in CancelVirtualTransaction --
there's a loop to compare all VXIDs, and we break as soon as find a
perfect match in (backendid, localTransactionId). However, once we've
found the backendId that matches, it's not possible for there to be
another entry with
On 29/06/18 10:14, Sergei Kornilov wrote:
> It may be better to use NULL as the default value at sql level.
Absolutely. +1 from me.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
> On 29 June 2018 at 21:06, Regina Obe wrote:
> > I think the exact query that is triggering it is this one though I
> > don't have PostgreSQL 10 head installed locally to confirm.
> >
> > SELECT 't3280', 'L1b' || topology.TopoGeo_AddLinestring('bug3280',
> > geom) FROM bug3280.edge where edge_id
On 30 June 2018 at 00:22, Alexander Kuzmenkov
wrote:
> On 06/29/2018 03:25 AM, David Rowley wrote:
>> I've attached a patch that uses SearchSysCacheAttName to speed up
>> these translations in the planner.
>
> Good idea. On my desktop, this gives 270 tps dropped vs 610 tps plain (for
> updates). I
Hi,
On 2018-06-29 13:56:12 +0200, Peter Eisentraut wrote:
> On 6/29/18 13:07, amul sul wrote:
> > This happens because of in fmgr_security_definer() function we are
> > changing global variable SecurityRestrictionContext and in the
> > StartTransaction() insisting it should be zero, which is the
On 2018-06-29 16:50:47 +0200, Tomas Vondra wrote:
> On 06/29/2018 04:00 PM, Mai Peng wrote:
> > Hello,
> >
> > On a pG10.4 instance, my query ( a simple select from a view) throw this
> > error:
> > ERROR: cannot start subtransactions during a parallel operation
> > CONTEXT: PL/pgSQL function ch
I was a bit surprised by the new epqslot output argument being added,
and now I think I know why: we already have es_trig_tuple_slot, so
shouldn't we be using that here instead? Seems like it'd all be simpler ...
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Developmen
"Regina Obe" writes:
> Here is a trivial example to exercise that doesn't involve PostGIS.
> CREATE TABLE edge AS SELECT 1 AS edge_id;
> SELECT 't3280', 'L1b' || generate_series(1,10)
> FROM edge
> ORDER BY 1;
That's odd. It works fine in HEAD but not the v10 branch. I suspect
that the fix Da
On 2018-Jun-08, Robert Haas wrote:
> On Wed, Jun 6, 2018 at 12:08 PM, Alvaro Herrera
> wrote:
> > So, apparently this is not a Postgres 11 open item, but rather a bug
> > that goes back to pg10. However, maybe it would be worth fixing soon
> > anyway? In particular, if we want to perturb the ex
On 06/29/2018 07:22 PM, Andres Freund wrote:
On 2018-06-29 16:50:47 +0200, Tomas Vondra wrote:
On 06/29/2018 04:00 PM, Mai Peng wrote:
Hello,
On a pG10.4 instance, my query ( a simple select from a view) throw this
error:
ERROR: cannot start subtransactions during a parallel operation
CONT
Hi,
On 2018-06-29 20:37:23 +0200, Tomas Vondra wrote:
> My guess is that it's a PL/pgSQL function with an EXCEPTION block, and
> there's no easy way to "fix" that.
Obviously not going to immediately help the OP, but I do think we should
be able to relax the subtransaction restriction around paral
> "Regina Obe" writes:
> > Here is a trivial example to exercise that doesn't involve PostGIS.
>
> > CREATE TABLE edge AS SELECT 1 AS edge_id; SELECT 't3280', 'L1b' ||
> > generate_series(1,10) FROM edge ORDER BY 1;
>
> That's odd. It works fine in HEAD but not the v10 branch. I suspect that
t
While trying to figure out this code I found
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/replication/logical/logical.c;h=61588d626f608006196c769ad9807f1d3ac592e9;hb=HEAD#l913
What function should it be referring to ?
Thanks,
Dave Cramer
2018-06-29 15:55 GMT-03:00 Dave Cramer :
> While trying to figure out this code I found
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/replication/logical/logical.c;h=61588d626f608006196c769ad9807f1d3ac592e9;hb=HEAD#l913
>
> What function should it be referring to ?
>
On 29.06.18 04:16, Michael Paquier wrote:
> I am able to find easily drafts of TLS 1.3, but I am not seeing an RFC
> associated to it, which would be the base document to rely on I
> guess... So that's really hard to make any decision in this area
> without the real deal. As far as I can see tls-
On 29.06.18 03:37, 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 which is now in beta 6
On 30/06/18 03:03, Tomas Vondra wrote:
On 06/29/2018 04:51 PM, Teodor Sigaev wrote:
I tried to attack the cost_sort() issues and hope on that basis we
can solve problems with 0002 patch and improve incremental sort patch.
OK, will do. Thanks for working on this!
I hope, now we have a bet
On 2018-Jun-27, David Rowley wrote:
> I've only just completed reading back through all the code and I think
> it's correct. I ended up changing add_paths_to_append_rel() so that
> instead of performing concatenation on partitioned_rels from two UNION
> ALL children, it creates a List of lists.
On Thu, Jun 28, 2018 at 09:46:17AM -0700, Peter Geoghegan wrote:
> * Don't assume that you haven't broken the doc build if you make even
> a trivial doc change. Removing a GUC can break instances in the
> release notes where they're referenced. Even grep can miss this, since
> references to the GUC
Alvaro Herrera writes:
> I'm CCing Tom here, as author of the patch that caused (most of) the
> issue.
Uh ... me? I thought this was a parallel-query issue, which I've
pretty much not been involved in.
regards, tom lane
Alvaro Herrera writes:
> Since Tom has been revamping this code lately, I think it's a good
> idea to wait for his input.
I'm on vacation and won't have time to look at this until week after
next. If you don't mind putting the topic on hold that long, I'll
be happy to take responsibility for it.
On 2018-Jun-28, Tom Lane wrote:
> Alvaro Herrera writes:
> > Fix "base" snapshot handling in logical decoding
>
> According to buildfarm member friarbird, and as confirmed here,
> the contrib/test_decoding/specs/oldest_xmin.spec test added by this
> commit fails under CLOBBER_CACHE_ALWAYS.
Hm.
On 2018-Jun-29, Tom Lane wrote:
> Alvaro Herrera writes:
> > I'm CCing Tom here, as author of the patch that caused (most of) the
> > issue.
>
> Uh ... me? I thought this was a parallel-query issue, which I've
> pretty much not been involved in.
Well, maybe it's a matter of opinion. Amit K sa
I was using copy command to load. Removing the primary key constraint on
the table and then loading it helps a lot. In fact, a 400GB table was
loaded and the primary constraint was added in around 15 hours. Thanks for
the wonderful suggestions.
Regards,
Srinivas Karthik
On 28 Jun 2018 2:07 a.m.,
On 2018-Jun-29, Alvaro Herrera wrote:
> On 2018-Jun-28, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > Fix "base" snapshot handling in logical decoding
> >
> > According to buildfarm member friarbird, and as confirmed here,
> > the contrib/test_decoding/specs/oldest_xmin.spec test added by
Alvaro Herrera writes:
>> On 2018-Jun-28, Tom Lane wrote:
>>> According to buildfarm member friarbird, and as confirmed here,
>>> the contrib/test_decoding/specs/oldest_xmin.spec test added by this
>>> commit fails under CLOBBER_CACHE_ALWAYS.
> I suppose 60 seconds (isolationtester's default time
70 matches
Mail list logo
