Hi,
I've been looking at the version submitted on Thursday, planning to
commit it, but I think it needs a wee bit more work on the error messages.
1) The example in sgml docs does not work, because it's missing a
semicolon after the CREATE FUNCTION. And the output was not updated
after tweaking t
On 07/14/2018 12:10 AM, Peter Geoghegan wrote:
> On Fri, Jul 13, 2018 at 3:04 PM, Kefan Yang wrote:
>> 1. Slow on CREATE INDEX cases.
>>
>> I am still trying to figure out where the bottleneck is. Is the data pattern
>> in index creation very different from other cases? Also, pg_qsort has
>> 10%-2
I wrote:
> This looks to me like it's probably a low-probability timing problem in
> the test script itself.
> ...
> We could maybe hack around that with a short "sleep" in this script, but
> a less cruddy solution would be to change PostgresNode::reload so that
> it somehow waits for the server to
> 14 июля 2018 г., в 14:39, Heikki Linnakangas написал(а):
>
> On 14/07/18 10:26, Andrey Borodin wrote:
>> This is tradeoff between complex concurrency feature and possibility
>> of few dead tuples left after VACUUM. I want to understand: is it
>> something dangerous in this dead tuples?
> Yeah
David Rowley writes:
> On 10 July 2018 at 11:44, RK wrote:
>> There is a costing bug in hash join logic seems to have been introduced by
>> the patch related to inner_unique enhancements(commit:
>> 9c7f5229ad68d7e0e4dd149e3f80257893e404d4).
> Thanks for the analysis and the report. I agree the c
Peter Eisentraut writes:
> ... For
> partitioning, we can rely on all the columns being inherited, but not
> for plain inheritance.
Uh, what?
regards, tom lane
Hi Thomas,
here's a rebased patch, with your observations corrected.
Thomas Munro wrote on 2018-07-13:
> + In this case, the CN (nommon name) provided in
> "common name"
> + CN (Common Name) in the certificate matches
> "common"? (why a capital letter here?)
I've resorted to "CN (Common Name
On Sat, Jul 14, 2018 at 03:47:38PM +0700, John Naylor wrote:
> I hope you don't mind, but since it might be tedious to piece together
> the addenda I left behind in this thread, I thought it might be useful
> to update Joe's patch. The attached was rebased over the new
> regression test, passes the
On 12.07.18 00:56, Mai Peng wrote:
> We discovered our pg_wal partition was full few days after setting our
> first logical publication on a PG 10.4 instance.
> Then, we can not synchronise our slave to the master, it triggers a
> segfault on the slave. We had to drop manually the subscription on s
On 12.07.18 00:52, Tom Lane wrote:
>> Another question that could be raised is why we are refusing to use
>> stats for a child table when the caller has select on the parent.
>> It's completely trivial to extract data from a child table if you
>> have select on the parent, so it seems like we are c
On 06.07.18 09:45, Alexander Lakhin wrote:
> ./configure --enable-tap-tests
> make install
> make install -C contrib
> chown -R postgres:postgres /usr/local/pgsql/
> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
> /usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
> /make
On 14/07/18 10:26, Andrey Borodin wrote:
This is tradeoff between complex concurrency feature and possibility
of few dead tuples left after VACUUM. I want to understand: is it
something dangerous in this dead tuples?
Yeah, that's bad. When a new heap tuple is inserted in the same
location, the o
On 02.07.18 12:07, Peter Eisentraut wrote:
> psql's \df command current has options a/n/t/w to show
> aggregates/normal/trigger/window functions. Do we want to add something
> for procedures?
Here is a patch.
The updated help string doesn't read particularly elegantly. Better ideas?
--
Peter
On 12.07.18 18:43, Andres Freund wrote:
> On 2018-06-29 13:52:23 +0200, Peter Eisentraut wrote:
>> From 95fc7156afe521b715fab08d44606774df875e92 Mon Sep 17 00:00:00 2001
>> From: Peter Eisentraut
>> Date: Fri, 29 Jun 2018 13:28:39 +0200
>> Subject: [PATCH] Fix assert in nested SQL procedure call
>
On 7/12/18, Peter Eisentraut wrote:
> To get things rolling, I have committed the regression test addition.
>
> I'll look through the other stuff soon.
Hi Peter,
I hope you don't mind, but since it might be tedious to piece together
the addenda I left behind in this thread, I thought it might be
> 14 июля 2018 г., в 0:28, Heikki Linnakangas написал(а):
>
> On 13/07/18 21:28, Andrey Borodin wrote:
>>> 13 июля 2018 г., в 18:25, Heikki Linnakangas
>>> написал(а):
>>> Looking at the second patch, to scan the GiST index in physical
>>> order, that seems totally unsafe, if there are any con
16 matches
Mail list logo
