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
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
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, 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
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.
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.
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
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
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 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 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 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-
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 ?
>
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
> "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
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
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
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
"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
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
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
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
> 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 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
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 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
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
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
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
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 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
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: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
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
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
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
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
> 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
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 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
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 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 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 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
(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 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
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: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 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 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 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
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 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
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/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
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 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
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 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 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
чт, 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 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
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
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 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
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 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
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 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
70 matches
Mail list logo
