Hi,
First, thank you for your insightful discussion.
I remade patches and attached in this mail.
> From: Tsunakawa, Takayuki
> OTOH, it may be better to commit the tcp_user_timeout patch when
> Nagaura-san has refined the documentation, and then continue
> socket_timeout.
Yes, I want to commit
On Sat, 23 Mar 2019 at 04:13, David Rowley wrote:
>
> On Sat, 23 Mar 2019 at 03:39, Alexander Kuzmenkov
> > This is a bug indeed. Unique index search is not exhaustive, so if many
> > indexes match the join quals, we might not find the same index for both
> > sides. I think this can be overcome
On Mon, Feb 4, 2019 at 8:41 PM Andres Freund wrote:
> On 2018-09-19 13:58:36 +1200, Thomas Munro wrote:
>
> > +/*
> > + * Advance nextFullXid to the value after a given xid. The epoch is
> > inferred.
> > + * If lock_free_check is true, then the caller must be sure that it's safe
> > to
> > +
On Sun, Mar 24, 2019 at 7:11 PM Greg Steiner wrote:
>
> To me the error message that includes more detail is superior. Even though
> you can get the detail from the logs, it seems like it would much more
> convenient for it to be reported out via the error to allow
> users/applications to
Chapman Flack writes:
> On 03/24/19 21:04, Ryan Lambert wrote:
>> I am unable to get latest patches I found [1] to apply cleanly to current
>> branches. It's possible I missed the latest patches so if I'm using the
>> wrong ones please let me know. I tried against master, 11.2 stable and the
>>
On Sun, Mar 24, 2019 at 11:53 PM Simon Riggs wrote:
>
> On Sun, 24 Mar 2019 at 13:02, Amit Kapila wrote:
>>
>> I think we are inconsistent for a similar message at a few other
>> places as well. See, below two messages:
>>
>> column \"%s\" contains null values
>> column \"%s\" of table \"%s\"
>From: Vladimir Sitnikov [mailto:sitnikov.vladi...@gmail.com]
>
>Robert> This email thread is really short on clear demonstrations that X
>Robert> or Y is useful.
>
>It is useful when the whole database does **not** crash, isn't it?
>
>Case A (==current PostgeSQL mode): syscache grows, then
Hi,
>
> Hi,
>
> On 2019/03/23 2:36, Thibaut Madelaine wrote:
> > I tested your last patch and if I didn't mix up patches on the end of
> > a too long week, I get a problem when querying the sub-sub partition:
> >
> > test=# explain select * from test2_0_10 where id = 25;
> >
On 03/24/19 21:04, Ryan Lambert wrote:
> I am unable to get latest patches I found [1] to apply cleanly to current
> branches. It's possible I missed the latest patches so if I'm using the
> wrong ones please let me know. I tried against master, 11.2 stable and the
> 11.2 tag with similar
On Fri, Mar 22, 2019 at 9:07 PM, Tom Lane wrote:
> BTW, it strikes me that we could take advantage of the fact that baserels
> must all appear before otherrels in the rel array, by having loops over
> that array stop early if they're only interested in baserels. We could
> either save the index
I am unable to get latest patches I found [1] to apply cleanly to current
branches. It's possible I missed the latest patches so if I'm using the
wrong ones please let me know. I tried against master, 11.2 stable and the
11.2 tag with similar results. It's quite possible it's user error on my
Hi Robert!
On 2019/03/23 3:31, Robert Haas wrote:
On Tue, Mar 19, 2019 at 2:47 PM Robert Haas wrote:
how close you were getting to rewriting the entire heap. This is the
one thing I found but did not fix; any chance you could make this
change and update the documentation to match?
Hi, is
On 2019/03/22 17:17, Amit Langote wrote:
> I'll add this to July fest to avoid forgetting about this.
I'd forgotten to do this, but done today. :)
Thanks,
Amit
Hi,
On 2019/03/23 2:36, Thibaut Madelaine wrote:
> I tested your last patch and if I didn't mix up patches on the end of a
> too long week, I get a problem when querying the sub-sub partition:
>
> test=# explain select * from test2_0_10 where id = 25;
> QUERY PLAN
Hello Tom,
If this is done, some people with zipfian distribution that currently
work might be unhappy.
After giving it some thought, I think that this cannot be fully fixed for
12.
Just to clarify --- my complaint about "over engineering" referred to
the fact that a cache exists at all;
Fabien COELHO writes:
I remain of the opinion that we ought to simply rip out support for
zipfian with s < 1.
>>> +1 to that
>> If this is done, some people with zipfian distribution that currently
>> work might be unhappy.
> After giving it some thought, I think that this cannot be
On Sun, 24 Mar 2019 at 13:02, Amit Kapila wrote:
> On Sat, Mar 23, 2019 at 4:33 AM Fabrízio de Royes Mello
> wrote:
> >
> > On Fri, Mar 22, 2019 at 2:25 PM Simon Riggs
> wrote:
> > >
> > > As noted by a PostgreSQL user to me, error messages for NOT NULL
> constraints are inconsistent - they do
On Sun, Mar 24, 2019 at 7:45 PM Andres Freund wrote:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snapper=2019-03-23%2013%3A01%3A28
>
> 2019-03-23 14:28:31.147 CET [18056:45] pg_regress/jsonpath LOG: statement:
> select '$.g ? (@.a == 1 || !(@.x >= 123 || @.a == 4) && @.b ==
David Fetter writes:
> On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
>> I am sending a patch that when an PUBLICATION is created and the
>> wal_level is different from logical prints a WARNING in console/log:
> Is a WARNING sufficient? Maybe I'm misunderstanding something
>
Hello Tom & Tomas,
If the choice is between reporting the failure to the user, and
addressing the failure, surely the latter would be the default option?
Particularly if the user can't really address the issue easily
(recompiling psql is not very practical solution).
I remain of the opinion
On Thu, Mar 21, 2019 at 07:45:59PM -0300, Lucas Viecelli wrote:
> Hi everyone,
>
> A very common question among new users is how wal_level works and it
> levels. I heard about some situations like that, a user create a new
> publication in its master database and he/she simply does not change
>
Hi Robert! >On Tue, Mar 19, 2019 at 2:47 PM Robert Haas
wrote: >> how close you were getting to
rewriting the entire heap. This is the >> one thing I found but did not
fix; any chance you could make this >> change and update the documentation
to match? > > >Hi, is anybody working on this? Thank
> 22 марта 2019 г., в 17:03, Heikki Linnakangas написал(а):
>
I was working on new version of gist check in amcheck and understand one more
thing:
/* Can this page be recycled yet? */
bool
gistPageRecyclable(Page page)
{
return PageIsNew(page) ||
(GistPageIsDeleted(page) &&
Hi,
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snapper=2019-03-23%2013%3A01%3A28
2019-03-23 14:28:31.147 CET [18056:45] pg_regress/jsonpath LOG: statement:
select '$.g ? (@.a == 1 || !(@.x >= 123 || @.a == 4) && @.b == 7)'::jsonpath;
2019-03-23 14:28:31.157 CET [18055:59]
Hallo Peter,
In "xact.c", maybe I'd assign blockState in the else branch, instead of
overriding it?
I think it was better the way it is, since logically the block state is
first set, then set again after the new transaction starts.
Ok.
About the static _SPI_{commit,rollback} functions:
Hello Tomas,
What would a user do with this information, and how would they know
what to do?
Sure, but it was unclear what to do. Extending the cache to avoid that
would look like over-engineering.
That seems like a rather strange argument. What exactly is so complex on
resizing the cache
What is the point of that, and if there is a point, why is it nowhere
mentioned in pgbench.sgml?
The attached patch simplifies the code by erroring on cache overflow,
instead of the LRU replacement strategy and unhelpful final report.
The above lines are removed.
Eh? Do I understand
To me the error message that includes more detail is superior. Even though
you can get the detail from the logs, it seems like it would much more
convenient for it to be reported out via the error to allow
users/applications to identify the problem relation without fetching logs.
I understand if
On Sat, Mar 23, 2019 at 11:43 AM Alexander Korotkov
wrote:
> On Fri, Mar 22, 2019 at 11:05 AM Alexander Korotkov
> wrote:
> > On Fri, Mar 22, 2019 at 12:06 AM Alvaro Herrera
> > wrote:
> > > On 2019-Mar-21, Alexander Korotkov wrote:
> > >
> > > > However, I think this still can be backpatched
On Sat, Mar 23, 2019 at 4:33 AM Fabrízio de Royes Mello
wrote:
>
> On Fri, Mar 22, 2019 at 2:25 PM Simon Riggs wrote:
> >
> > As noted by a PostgreSQL user to me, error messages for NOT NULL
> > constraints are inconsistent - they do not mention the relation name in the
> > message, as all
On Sat, Mar 23, 2019 at 04:08:42PM -0700, Peter Geoghegan wrote:
> Seems like there might be a problem either caused by or detected by
> 016_min_consistency.pl on piculet:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet=2019-03-23%2022%3A28%3A59
Interesting. Based on what
On Sun, Mar 24, 2019 at 09:16:44PM +0900, Michael Paquier wrote:
> After testing and reviewing the patch, I noticed that all versions
> sent up to now missed two things done by logfile_open():
> - Bufferring is line-buffered. For current_logfiles it may not matter
> much as the contents are first
On Fri, Mar 22, 2019 at 01:01:44PM +0900, Michael Paquier wrote:
> On Fri, Mar 22, 2019 at 02:35:41PM +1100, Haribabu Kommi wrote:
> > Thanks for the correction. Yes, that is correct and it works fine.
>
> Thanks for double-checking. Are there any objections with this patch?
Done and committed
On Sat, Mar 23, 2019 at 2:23 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-03-22 05:00, Michael Paquier wrote:
> > On Fri, Mar 22, 2019 at 02:45:24PM +1100, Haribabu Kommi wrote:
> >> How about letting the pg_basebackup to decide group permissions of the
> >> standby
On Thu, 21 Mar 2019 at 00:39, PG Bug reporting form
wrote:
>
> This fails, seemingly because the RLS on 'bar' is being checked by alice,
> instead of the view owner bob:
>
Yes I agree, that appears to be a bug. The subquery in the RLS policy
should be checked as the view owner -- i.e., we need
Patch has been committed, thanks.
On 2019-03-18 21:20, Fabien COELHO wrote:
> Minor remarks:
>
> In "xact.c", maybe I'd assign blockState in the else branch, instead of
> overriding it?
I think it was better the way it is, since logically the block state is
first set, then set again after the
This results in an Assert failure on master and an elog ERROR prior to
c2fe139c201:
create role test_role with login;
create table ref(a int primary key);
grant references on ref to test_role;
set role test_role;
create table t1(a int, b int);
insert into t1 values(1,1);
alter table t1 add
Hi,
Marc (in Cc) reported me a problematic query using a GIN index hit in
production. The issue is that even if an GIN opclass says that the
index can be used for an operator, it's still possible that some
values aren't really compatible and requires a full index scan.
One simple example is
On Sat, Mar 23, 2019 at 11:08 PM legrand legrand
wrote:
>
> > This patch has multiple trailing whitespace, indent and coding style
> > issues. You should consider running pg_indent before submitting a
> > patch. I attach the diff after running pgindent if you want more
> > details about the
On Sat, 23 Mar 2019 at 19:42, Tom Lane wrote:
>
> David Rowley writes:
> > On Sat, 23 Mar 2019 at 05:40, Tom Lane wrote:
> >> BTW, another thing we could possibly do to answer this objection is to
> >> give the ordered-Append node an artificially pessimistic startup cost,
> >> such as the sum
On Sun, 24 Mar 2019 at 05:16, Julien Rouhaud wrote:
> ISTM that a query like
> SELECT * FROM nested ORDER BY 1, 2;
> could simply append all the partitions in the right order (or generate
> a tree of ordered appends), but:
>
> QUERY PLAN
>
ne 24. 3. 2019 v 10:25 odesílatel Erik Rijkers napsal:
> On 2019-03-24 06:57, Pavel Stehule wrote:
> > Hi
> >
> > rebase against current master
> >
>
> I ran into this:
>
> (schema 'varschema2' does not exist):
>
> drop variable varschema2.testv cascade;
> ERROR: schema "varschema2" does not
On 2019-03-24 06:57, Pavel Stehule wrote:
Hi
rebase against current master
I ran into this:
(schema 'varschema2' does not exist):
drop variable varschema2.testv cascade;
ERROR: schema "varschema2" does not exist
create variable if not exists testv as text;
server closed the connection
Hi, Michael!
> 19 марта 2019 г., в 14:53, pantilimonov misha
> написал(а):
>
> 2) Changing buffer manager strategy.
>Somewhere in 2016 Andres Freund made a presention[6] of possible
> improvements
>that can be done in buffer manager. I find the idea of changing hashtable
> to
>
On Sun, 24 Mar 2019 at 00:17, David Rowley wrote:
>
> On Sun, 24 Mar 2019 at 12:41, Tomas Vondra
> wrote:
> >
> > On 3/21/19 4:05 PM, David Rowley wrote:
>
> > > 29. Looking at the tests I see you're testing that you get bad
> > > estimates without extended stats. That does not really seem
Matsumura-san,
> Therefore, I think that the quoting statement name is needed in
> PREPARE/EXECUTE case, too.
I agree that we have to accept a quoted statement name and your
observations are correct of course, I am merely wondering if we need
the escaped quotes in the call to the ecpg functions
46 matches
Mail list logo
