On Tue, Nov 3, 2020 at 6:06 PM Dilip Kumar wrote:
>
> On Thu, Oct 29, 2020 at 12:53 PM bu...@sohu.com wrote:
> >
> > > 1) It's better to always include the whole patch series - including the
> > > parts that have not changed. Otherwise people have to scavenge the
> > > thread and search for all t
Alvaro Herrera writes:
> On 2020-Nov-08, Tomas Vondra wrote:
>> While rebasing some of the BRIN patches, I noticed some of the code in
>> brin_memtuple_initialize is duplicated. This happened in 8bf74967dab
>> which moved some of the code from brin_new_memtuple, not removing the
>> shared pieces.
On 2020-Nov-08, Tomas Vondra wrote:
> While rebasing some of the BRIN patches, I noticed some of the code in
> brin_memtuple_initialize is duplicated. This happened in 8bf74967dab
> which moved some of the code from brin_new_memtuple, not removing the
> shared pieces. In practice this is benign, o
Hi,
While rebasing some of the BRIN patches, I noticed some of the code in
brin_memtuple_initialize is duplicated. This happened in 8bf74967dab
which moved some of the code from brin_new_memtuple, not removing the
shared pieces. In practice this is benign, of course.
Barring objections I'll get t
On 11/7/20 11:21 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 11/7/20 3:52 AM, Tom Lane wrote:
>>> Do you have some suggested text?
>
>> I think this might work:
>
> I dunno ... given that we have zero field reports, I doubt this is
> something we need to tell every BRIN user to do. The tex
On Sat, Nov 07, 2020 at 11:57:20AM -0500, Tom Lane wrote:
> The problems discussed in bug #16703 [1] show that pg_dump needs a
> version of LOCK TABLE that behaves differently for views than
> what we have now. Since v11, LOCK TABLE on a view recurses to all
> tables and views named in the view, a
Thanks for looking! Pushed.
Tomas Vondra writes:
> On 11/7/20 3:52 AM, Tom Lane wrote:
>> Do you have some suggested text?
> I think this might work:
I dunno ... given that we have zero field reports, I doubt this is
something we need to tell every BRIN user to do. The text I put in
earlier today just recommends reindexin
On 2020-11-05 13:27, Peter Eisentraut wrote:
A few client tools duplicate error messages already provided by libpq,
such as
pg_rewind: fatal: could not connect to server: could not connect to
server: No such file or directory
pg_basebackup: error: could not connect to server: could not connect
Hi,
On 11/7/20 3:52 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> We should probably include instructions what to do about the BRIN
>> data corruption fixed by 7577dd8480 - a query to list might be
>> affected by the bug and should be rebuilt.
>
> Do you have some suggested text?
>
I think thi
"Wang, Shenhao" writes:
> I met an error as below when I use ecpg
> a.pgc:5: ERROR: invalid bit string literal
> a.pgc:5: ERROR: internal error: unreachable state; please report this to
>
Indeed. This has apparently been broken for a very long time (though
the "unreachable state" part is fair
On 2020-11-07 13:24, Jürgen Purtz wrote:
Because there have been no more comments in the last days I created a
consolidated patch. It contains Erik's suggestion and some tweaks for
the text size within graphics.
[0011-architecture.patch]
Hi,
I went through architecture.sgml once more; some
Em sáb., 7 de nov. de 2020 às 14:55, Marina Polyakova <
m.polyak...@postgrespro.ru> escreveu:
> On 2020-11-06 23:54, Ranier Vilela wrote:
> > Hi Marina,
>
> Hello!
>
> 1) If you mean the function pgwin32_select in the file
> src/backend/port/win32/socket.c, IIUC it is only used in the backend,
> s
On 2020-11-06 23:54, Ranier Vilela wrote:
Hi Marina,
Hello!
Nice catch.
Thank you!
rc/bin/pgbench/pgbench.c, the function add_socket_to_set:
if (fd < 0 || fd >= FD_SETSIZE)
{
/*
* Doing a hard exit here is a bit grotty, but it doesn't seem worth
* complicating the API to make it less grot
Hello,
Indeed. I took your next patch with an added explanation. I'm unclear
whether proceeding makes much sense though, that is some thread would run
the test and other would have aborted. Hmmm.
Your comment looks good, thanks. In the previous version pgbench starts
benchmarking even if so
The problems discussed in bug #16703 [1] show that pg_dump needs a
version of LOCK TABLE that behaves differently for views than
what we have now. Since v11, LOCK TABLE on a view recurses to all
tables and views named in the view, and it does so using the view
owner's permissions, meaning that a v
> 5 нояб. 2020 г., в 22:20, Justin Pryzby написал(а):
>
> On Thu, Nov 05, 2020 at 10:11:52PM +0500, Andrey Borodin wrote:
>> To test that functions are actually called for sorting build we should
>> support directive sorting build like "CREATE INDEX ON A USING GIST(B)
>> WITH(sorting=surely,a
On Fri, Nov 6, 2020 at 11:00 PM Fujii Masao wrote:
>
> >> I'm not quite sure to replace all the places in the walreceiver
> >> process, for instance in WalRcvForceReply() we are using spinlock to
> >> acquire the latch pointer and . Others may have better thoughts on
> >> this.
> >
> > The SIGTERM
On Thu, Nov 5, 2020 at 6:33 PM Hou, Zhijie wrote:
>
> Hi
>
> >
> > my $bytes = $ARGV[0];
> > for(my $i = 0; $i < $bytes; $i+=8){
> > print "longdata";
> > }
> > print "\n";
> >
> >
> > postgres=# copy longdata from program 'perl /tmp/longdata.pl 1'
> > with (parallel 2);
> >
Hi
I had to solve a slow due very slow JIT preparing. I found very unpleased
situation where some subplan was strangely slow
-> Hash Anti Join (cost=11.35..19.41 rows=143 width=3011) (actual
time=5039.022..5039.105 rows=203 loops=1)
Hash Cond: (term_p.id_i = term_d_1.id_i)
-> Se
On 2020-11-05 12:59, John Naylor wrote:
And yes, this doesn't materially change the patch, it's just nitpicking
:-) . Materially, I believe it's fine.
OK, committed.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
21 matches
Mail list logo
