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 o
Hi
rebase against current master
Regards
Pavel
schema-variables-20190324.patch.gz
Description: application/gzip
On 3/23/19 6:44 PM, Fabien COELHO wrote:
>
> Hello Tom,
>
>> I started to look through this, and the more I looked the more unhappy
>> I got that we're having this discussion at all. The zipfian support
>> in pgbench is seriously over-engineered and under-documented. As an
>> example, I was
On Sat, 23 Mar 2019 at 12:01, Hadi Moshayedi wrote:
> Yesterday while doing some tests, I noticed that the following doesn't work
> properly:
>
> 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 t
Hi,
On 2019-03-23 20:16:30 -0700, Andres Freund wrote:
> I'm pretty happy with that last version (of the first patch). I'm
> planning to do one more pass, and then push.
And done, after a bunch of mostly cosmetic changes (renaming
ExecCheckHeapTupleVisible to ExecCheckTupleVisible, removing an
un
On 3/23/19 7:45 PM, Fabien COELHO wrote:
>
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
Hi,
On 2019-03-21 11:15:57 -0700, Andres Freund wrote:
> Pending work:
> - Wondering if table_insert/delete/update should rather be
> table_tuple_insert etc. Would be a bit more consistent with the
> callback names, but a bigger departure from existing code.
I've left this as is.
> - I'm no
On 03/23/19 18:20, Chapman Flack wrote:
> On 03/23/19 17:05, Tom Lane wrote:
>> I've now pushed a somewhat-adjusted version of the XML-content fix
>> patch. The documentation patch needs some small rebasing to apply
>> after that one instead of before it.
>
> Will do.
>
>> Perhaps it'd make sens
On Sun, 24 Mar 2019 at 12:41, Tomas Vondra wrote:
>
> On 3/21/19 4:05 PM, David Rowley wrote:
> > 11. In get_mincount_for_mcv_list() it's probably better to have the
> > numerical literals of 0.0 instead of just 0.
>
> Why?
Isn't it what we do for float and double literals?
>
> > 12. I think it
On 03/23/19 18:20, Chapman Flack wrote:
>> Perhaps it'd make sense under the XML section in datatype.sgml,
>> but I think I might lean to making it a new section in Appendix D
>> (SQL Conformance).
>
> Sounds like the option (4) I proposed back in [1]. I suppose it won't
> be much trouble to move.
On 3/21/19 4:05 PM, David Rowley wrote:
> On Mon, 18 Mar 2019 at 02:18, Tomas Vondra
> wrote:
>> Yes, it was using the toasted value directly. The attached patch
>> detoasts the value explicitly, similarly to the per-column stats, and it
>> also removes the 1MB limit.
>
> I just made a pass over
On Wed, Mar 13, 2019 at 12:22 AM Michael Paquier wrote:
> On Tue, Mar 12, 2019 at 01:16:14PM +0300, Arthur Zakirov wrote:
> > On my environment installcheck passes as well as check. Also I ran tests
> > with reverted c186ba13, 016_min_consistency.pl doesn't pass as expected.
Seems like there migh
On 03/23/19 18:22, Tom Lane wrote:
>> Out of curiosity, what further processing would you expect libxml to do?
>
> Hm, I'd have thought it'd try to parse the arguments to some extent,
> but maybe not. Does everybody reimplement attribute parsing for
> themselves when using PIs?
Yeah, the content
Chapman Flack writes:
> On 03/23/19 16:59, Tom Lane wrote:
>> You're not really validating that the input
>> is something that libxml would accept, unless its processing of XML PIs
>> is far stupider than I would expect it to be.
> Out of curiosity, what further processing would you expect libxml
On 03/23/19 17:05, Tom Lane wrote:
> Just to update this thread --- per the other thread at
> https://postgr.es/m/can-v+g-6jquqeqz55q3toxen6d5ez5uvzl4vr+8ktvjkj31...@mail.gmail.com
> I've now pushed a somewhat-adjusted version of the XML-content fix
> patch. The documentation patch needs some sma
> 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 various issues.
fixed
> - * Track statement execution times acro
On 03/23/19 16:59, Tom Lane wrote:
> Unicode-code-point numbers. I removed that, made some other changes to
> bring the patch more in line with PG coding style, and pushed it.
Thanks! It looks good. I'm content with the extra PI checking being gone.
The magic Unicode-code-point numbers come stra
Chapman Flack writes:
> Alvaro has committed two of the patches in this CF entry[1], but the
> remaining two have yet to attract review.
> This message contains only those two, just as before[2] except rebased
> over Alvaro's commits of the others.
Just to update this thread --- per the other thr
Chapman Flack writes:
> I decided, for a first point of reference, to wear the green eyeshade and
> write a pre-check that exactly implements the applicable rules. That gives
> a starting point for simplifications that are probably safe.
> For example, a bunch of lines at the end have to do with v
Hello
Yet another review of this patch from me...
>An index build with the CONCURRENTLY option failed,
> leaving
>an invalid index. Such indexes are useless but it can be
> - convenient to use REINDEX to rebuild them. Note that
> - REINDEX will not perform a concurrent
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.
Same, but without the comp
Hello again,
I started to look through this, and the more I looked the more unhappy
I got that we're having this discussion at all. The zipfian support
in pgbench is seriously over-engineered and under-documented. As an
example, I was flabbergasted to find out that the end-of-run summary
stat
Hello Tom,
I started to look through this, and the more I looked the more unhappy
I got that we're having this discussion at all. The zipfian support
in pgbench is seriously over-engineered and under-documented. As an
example, I was flabbergasted to find out that the end-of-run summary
stati
Fabien COELHO writes:
> [ pgbench-zipf-doc-3.patch ]
I started to look through this, and the more I looked the more unhappy
I got that we're having this discussion at all. The zipfian support
in pgbench is seriously over-engineered and under-documented. As an
example, I was flabbergasted to fin
On Wed, Dec 19, 2018 at 3:01 PM David Rowley
wrote:
>
> On Thu, 20 Dec 2018 at 01:58, Julien Rouhaud wrote:
> >
> > The multi-level partitioning case is another
> > thing that would need to be handled for instance (and that's the main
> > reason I couldn't submit a new patch when I was working on
Greetings,
* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> On 23/03/2019 02:38, Michael Paquier wrote:
> > On Fri, Mar 22, 2019 at 08:41:06PM +0800, Andrey Borodin wrote:
> >> 22 марта 2019 г., в 19:17, Petr Jelinek
> >> написал(а):
> >>> I still don't like that we are running the subscri
Bonjour Michaël,
Here is an attempt at improving the Notes.
Mostly it is a reordering from more important (cluster corruption) to less
important (if interrupted a restart is needed), some reordering from
problem to solutions instead of solution/problem/solution, some sentence
simplification.
On 23/03/2019 02:38, Michael Paquier wrote:
> On Fri, Mar 22, 2019 at 08:41:06PM +0800, Andrey Borodin wrote:
>> 22 марта 2019 г., в 19:17, Petr Jelinek
>> написал(а):
>>> I still don't like that we are running the subscription workers as
>>> superuser even for subscriptions created by regular us
On Sat, Mar 23, 2019 at 08:54:26AM -0300, Fabrízio de Royes Mello wrote:
> The attached patch just a very minor adjustment to
> src/bin/pg_checksums/pg_checksums.c to add new line between some IF
> statements.
Thanks. This makes the code more consistent with the surroundings, so
done. At the sam
On Sat, Mar 23, 2019 at 9:50 AM Alvaro Herrera wrote:
>
> On 2019-Mar-23, Amit Kapila wrote:
>
> > I think some users might also be interested in the write transactions
> > happened in the system, basically, those have consumed xid.
>
> Well, do they really want to *count* these transactions, or i
Hi all,
The attached patch just a very minor adjustment to
src/bin/pg_checksums/pg_checksums.c to add new line between some IF
statements.
Regards,
--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On Fri, Mar 22, 2019 at 11:46 PM legrand legrand
wrote:
>
> Here is a rebased and corrected version .
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 wan
On Fri, Mar 22, 2019 at 10:27 PM Michael Paquier
wrote:
>
> On Fri, Mar 22, 2019 at 04:49:57PM -0300, Fabrízio de Royes Mello wrote:
> > So attached patch aims to introduce MIN/MAX aggregate functions to
pg_lsn
>
> Fine by me. This looks helpful for monitoring.
>
> Please make sure to register it
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 correctly. We can
> > > determine whether xlog record data contains deleteX
What I'm going to do now is to write a patch to remove the \cset part of
the commit and post it, intending to push at some point next week.
Per your request, here is a patch which removes \cset from pgbench. Sigh.
Again, only the removal is a little deeper. This lifts the constraint
about n
On Sat, Mar 23, 2019 at 10:20:16AM +0900, Michael Paquier wrote:
> On Fri, Mar 22, 2019 at 08:20:53PM -0400, Jeff Janes wrote:
> > PostgreSQL 12devel on aarch64-unknown-linux-gnu, compiled by gcc
> > (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04) 7.3.0, 64-bit
>
> Adding Noah in CC as he has done the updat
36 matches
Mail list logo
