> On Thu, Sep 5, 2019 at 9:41 PM Alvaro Herrera from 2ndQuadrant
> wrote:
>
> On 2019-Sep-05, Dmitry Dolgov wrote:
>
> > Here is the version in which stepping between the pages works better. It
> > seems
> > sufficient to fix the case you've men
> On Tue, Jul 2, 2019 at 9:28 AM Michael Paquier wrote:
>
> On Thu, Feb 21, 2019 at 04:40:13PM +0900, Michael Paquier wrote:
> > Rebased version fixing some conflicts with HEAD.
>
> And rebased version for this stuff on HEAD (66c5bd3), giving visibly
> v16.
Thanks for the patch! I couldn't check
> On Wed, Sep 25, 2019 at 3:03 AM Kyotaro Horiguchi
> wrote:
>
> At Tue, 24 Sep 2019 09:06:27 -0300, Alvaro Herrera
> wrote in <20190924120627.GA12454@alvherre.pgsql>
> > On 2019-Sep-24, Kyotaro Horiguchi wrote:
> >
> > > Sorry, it's not a boolean. A tristate value. From the definition
> > > (B
> On Tue, Sep 24, 2019 at 1:58 AM Michael Paquier wrote:
>
> Please feel free to use the updated versions attached. These can
> apply on top of HEAD at 30d1379.
Thanks for the update. Looking at v17 0003 I have one more question. In all the
places where we have to do systable_endscan, it followe
> On Mon, Jun 17, 2019 at 10:29:26AM -0400, Dave Cramer wrote:
> > Which is what I have done. Thanks
> >
> > I've attached both patches for comments.
> > I still have to add documentation.
>
> Additional patch for documentation.
Thank you for the patch! Unfortunately 0002 has some conflicts, could
> On Thu, Feb 28, 2019 at 9:24 PM Alvaro Herrera
> wrote:
>
> Pushed, thanks. I added the reminder comment I mentioned.
Thank you, sorry for troubles.
> On Thu, Feb 28, 2019 at 10:45 PM Jeff Janes wrote:
>
> This version of the patch can return the wrong answer.
Yes, indeed. In fact it answers my previous question related to the backward
cursor scan, when while going back we didn't skip enough. Within the current
approach it can be fixed by pro
> On Sat, Mar 9, 2019 at 4:13 AM Andres Freund wrote:
>
> While 0001 is pretty bulky, the interesting bits concentrate on a
> comparatively small area. I'd appreciate if somebody could give the
> comments added in tableam.h a read (both on callbacks, and their
> wrappers, as they have different au
> On Mon, Mar 4, 2019 at 7:15 PM Andres Freund wrote:
>
> The pluggable storage patchset contains exactly that... I've attached
> the precursor patch (CREATE ACCESS METHOD ... TYPE TABLE), and the patch
> for pg_dump support. They need a bit more cleanup, but it might be
> useful information for t
> On Tue, Mar 5, 2019 at 4:05 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Although there are still some rough edges, e.g. going forth, back and forth
> again leads to a sutiation, when `_bt_first` is not applied anymore and the
> first element is wrongly skipped. I&
> On Fri, Mar 15, 2019 at 4:55 AM Kyotaro HORIGUCHI
> wrote:
> I have some comments on the latest v11 patch.
Thank you!
> L619:
> > +indexstate->ioss_NumDistinctKeys = node->distinctPrefix;
>
> The number of distinct prefix keys has various names in this
> patch. They should be unified as
> On Sat, Mar 16, 2019 at 5:14 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Fri, Mar 15, 2019 at 4:55 AM Kyotaro HORIGUCHI
> > wrote:
> > I have some comments on the latest v11 patch.
>
> Thank you!
In the meantime here is a new version, rebas
> On Mon, Mar 25, 2019 at 11:39 AM David Steele wrote:
>
> On 3/25/19 1:04 PM, Konstantin Knizhnik wrote:
> >
> >
> > On 25.03.2019 11:06, David Steele wrote:
> >> Konstantin,
> >>
> >>
> >> This patch appears to be failing tests so I have marked it Waiting on
> >> Author.
> >>
> >> I have also re
> On Tue, Mar 19, 2019 at 2:07 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sat, Mar 16, 2019 at 5:14 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >
> > > On Fri, Mar 15, 2019 at 4:55 AM Kyotaro HORIGUCHI
> > > wrote:
&g
> On Mon, Jul 22, 2019 at 7:10 PM Jesper Pedersen
> wrote:
>
> On 7/22/19 1:44 AM, David Rowley wrote:
> > Here are the comments I noted down during the review:
> >
> > cost_index:
> >
> > I know you've not finished here, but I think it'll need to adjust
> > tuples_fetched somehow to account for
> On Thu, Jul 25, 2019 at 1:21 PM Kyotaro Horiguchi
> wrote:
>
> I have some comments.
Thank you for the review!
> + * The order of columns in the index should be the same, as for
> + * unique distincs pathkeys, otherwise we cannot use _bt_search
> + * in the skip
> On Thu, Jul 25, 2019 at 1:21 PM Kyotaro Horiguchi
> wrote:
>
> I feel uncomfortable to look into indexinfo there. Couldnd't we
> use indexskipprefix == -1 to signal !amcanskip from
> create_index_path?
Looks like it's not that straightforward to do this only in create_index_path,
since to make
> On Mon, Aug 5, 2019 at 12:05 PM Floris Van Nee
> wrote:
>
> The root->distinct_pathkeys is already filtered for redundant keys, so column
> 'a' is not in there anymore. Still, it'd be much faster to use the skip scan
> here, because a regular scan will scan all entries with a=1, even though
> we
Hi,
For already some time I'm following the new linux IO interface "io_uring", that
was introduced relatively recently [1]. Short description says:
Shared application/kernel submission and completion ring pairs, for
supporting fast/efficient IO.
For us the important part is probably th
> On Tue, Aug 20, 2019 at 4:45 PM Rafia Sabih wrote:
>
> This does not sound very convenient. I was thinking of having some
> mechanism for such insertions which automatically creates a default
> partition and gives a notice for the user to know that it is going to
> the default partition.
If I r
> On Mon, Aug 19, 2019 at 10:21 PM Andres Freund wrote:
>
> > For us the important part is probably that it's an asynchronious IO, that
> > can
> > work not only with O_DIRECT, but with also with buffered access.
>
> Note that while the buffered access does allow for some acceleration, it
> curre
> On Mon, Aug 5, 2019 at 10:46 PM Fabien COELHO wrote:
>
> > The index builds are done serially. The vacuum could be replaced by COPY
> > FREEZE.
>
> Well, it could be added?
While doing benchmarking using different tools, including pgbench, I found it
useful as a temporary hack to add copy freez
> On Wed, Aug 28, 2019 at 7:37 AM Fabien COELHO wrote:
>
> > While doing benchmarking using different tools, including pgbench, I found
> > it
> > useful as a temporary hack to add copy freeze and maintenance_work_mem
> > options
> > (the last one not as an env variable, just as a set before, al
> On Mon, Aug 5, 2019 at 10:38 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Of course we can modify it to read a whole page and leave visibility check
> for the code after `index_getnext_tid` (although in case if we know that all
> tuples on this page are visilbe I gu
> On Wed, Aug 28, 2019 at 9:32 PM Floris Van Nee
> wrote:
>
> I'm afraid I did manage to find another incorrect query result though
Yes, it's an example of what I was mentioning before, that the current modified
implementation of `_bt_readpage` wouldn't work well in case of going between
pages.
> On 2 January 2018 at 20:52, Tom Lane wrote:
>
> I did find one case where the patch makes things significantly slower:
>
> select * from test where true is true
> and true is true
> and true is true
> and true is true
> ... (100 times altogether)
Yes, indeed, I never tested this kind of con
> On 7 January 2018 at 23:39, Tom Lane wrote:
>> Dmitry Dolgov <9erthali...@gmail.com> writes:
>>> On 4 January 2018 at 03:05, Tom Lane wrote:
>>> I wonder what happened to the plan to separate assignment and fetch into two
>>> different node types. I
> On 4 January 2018 at 07:32, Fabien COELHO wrote:
>
> Another rebase to try to please the patch tester.
Thanks for working on this. I had just a quick look at it, but I hope I'll have
time to post a proper review. In the meantime I'm wondering what am I doing
wrong here (I see a similar example
> On 8 January 2018 at 19:36, Fabien COELHO wrote:
> What you are trying to do is the result of combining the pgbench-if patch
> and the pgbench-more-ops-and-funcs patch.
Oh, I see. I missed the first message about this patch, sorry. But for some
reason I can't apply both patches (pgbench-more-o
Hi,
>From what I see some time ago the write lifetime hints support for NVMe multi
streaming was merged into Linux kernel [1]. Theoretically it allows data
written together on media so they can be erased together, which minimizes
garbage collection, resulting in reduced write amplification as well
> On 27 January 2018 at 16:03, Tomas Vondra
> wrote:
>
> Aren't those numbers far lower that you'd expect from NVMe storage? I do
> have a NVMe drive (Intel 750) in my machine, and I can do thousands of
> transactions on it with two clients. Seems a bit suspicious.
Maybe an NVMe storage can prov
> On 27 January 2018 at 23:53, Tomas Vondra
> wrote:
>
> Amazon actually does provide instance types (f1 and i3) with real NVMe
> devices. That's what I'd be testing.
Yes, indeed, that's a better target for testing, thanks. I'll write back when
will get some results.
> On 12 January 2018 at 13:58, Arthur Zakirov wrote:
>
> I attached new version of the patch. Now (expected output):
>
Thanks for working on that! I haven't followed this thread before, and after a
quick review I have few side questions.
Why not write `is_separator_char` using `isprint`, `isalph
> On 1 February 2018 at 11:24, Arthur Zakirov wrote:
>
> I fixed those messages, but in a different manner. I think that an
> unexpected character is unknown and neither space nor separator. And
> better to say that was expected space/separator character.
Sounds good, thanks.
> Attached fixed pa
> On 6 February 2018 at 10:17, Arthur Zakirov wrote:
> It is strange. I still can apply both v9 [1] and v10 [2] via 'git
> apply'. And Patch Tester [3] says that it is applied. But maybe
> it is because of my git (git version 2.16.1).
>
> You can try also 'patch -p1':
Yes, looks like the problem
> On 8 February 2018 at 10:29, Andreas Karlsson wrote:
>> On 02/07/2018 03:54 PM, Andres Freund wrote:
>>
>> I've pushed v10.0. The big (and pretty painful to make) change is that
>> now all the LLVM specific code lives in src/backend/jit/llvm, which is
>> built as a shared library which is loaded
> On 7 February 2018 at 22:51, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On 6 February 2018 at 10:17, Arthur Zakirov wrote:
>> It is strange. I still can apply both v9 [1] and v10 [2] via 'git
>> apply'. And Patch Tester [3] says that it is applied. But
> On 8 February 2018 at 21:26, Thomas Munro
> wrote:
> On Fri, Feb 9, 2018 at 3:14 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> $ ./configure --prefix=/build/postgres-jit/ --with-llvm
>> --enable-debug --enable-depend --enable-cassert
>
>> /us
> On 12 February 2018 at 12:49, Arthur Zakirov
wrote:
>
> Yes, I somehow missed it. I changed the behaviour of separator
> characters in format string. They are greedy now and eat whitespaces
> before a separator character in an input string. I suppose that there
> should be no such problems as in
> On Wed, Sep 25, 2019 at 2:33 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> v27-0001-Index-skip-scan.patch
>
> Some random thoughts on this:
Thanks a lot for the commentaries!
> * Is _bt_scankey_within_page() really doing the right thing within empty
> pages?
> On Sun, Nov 03, 2019 at 05:45:47PM +0100, Dmitry Dolgov wrote:
> > * The extra scankeys that you are using in most of the new nbtsearch.c
> > code is an insertion scankey -- not a search style scankey. I think
> > that you should try to be a bit clearer on that distinction i
> On Tue, Nov 05, 2019 at 07:16:10AM -0500, Dave Cramer wrote:
>
> See attached
--- a/src/backend/replication/logical/worker.c
+++ b/src/backend/replication/logical/worker.c
@@ -1779,6 +1779,7 @@ ApplyWorkerMain(Datum main_arg)
options.slotname = myslotname;
options.pro
> On Thu, Oct 31, 2019 at 05:35:28AM +0300, Nikita Glukhov wrote:
> Hi. I added new 5th patch to this patch set.
Thank you!
> Performance was compared on 4 tables with 10M rows:
>
> -- [ i ]
> CREATE TABLE arr_1 AS
> SELECT jsonb_build_array(i)::jsonb js
> FROM generate_series(1, 1000) i;
>
>
> On Mon, Nov 11, 2019 at 11:15:45AM -0500, Dave Cramer wrote:
> On Fri, 8 Nov 2019 at 11:20, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > > On Tue, Nov 05, 2019 at 07:16:10AM -0500, Dave Cramer wrote:
> > >
> > > See attached
> >
> &
> On Wed, Jul 31, 2019 at 11:51:17PM -0700, Noah Misch wrote:
Hi,
> > Also, if I understand the data-loss hazard properly, it's what you
> > said in the other thread: the latest_page_number could advance after
> > we make our decision about what to truncate, and then maybe we could
> > truncate n
> On Sun, Nov 17, 2019 at 10:14:26PM -0800, Noah Misch wrote:
>
> Though I did reproduce this bug, I'm motivated by the abstract problem more
> than any particular way to reproduce it. Commit 996d273 inspired me; by
> removing a GetCurrentTransactionId(), it allowed the global xmin to advance at
>
> On Mon, Jun 17, 2019 at 05:31:40AM +0200, Pavel Stehule wrote:
>
> > I like anycompatible and anycompatiblearray.
> >
> > I'll update the patch
> >
>
> and here it is
Thanks for the patch! I've reviewed it a bit, and have a few small
commentaries:
* There are few traces of copy paste in comment
Hi,
Probably a simple question, but I don't see a simple answer so far. In
one extension I want to convert uint64 into a numeric to put it
eventually into a jsonb object. As far as I see in numeric.c there are
functions only for signed int64. Is there a way to achive this with
uint64 (without dupl
> On Wed, Dec 04, 2019 at 11:49:20AM +, Andrew Gierth wrote:
>
> >>>>> "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes:
>
> Dmitry> Hi,
>
> Dmitry> Probably a simple question, but I don't see a simple answer so
> Dmi
> On Tue, Jul 16, 2019 at 06:49:10PM -0700, Melanie Plageman wrote:
>
> We implemented Approach B in the attached patch set (patch 0001) and
> then implemented Approach A (patch 0002) to sanity check the pruned
> list of columns to scan we were getting at plan-time.
> We emit a notice in SeqNext()
> On Thu, Jan 02, 2020 at 05:21:55PM -0800, Melanie Plageman wrote:
>
> That makes me think that maybe the function name,
> extract_used_columns() is bad, though. Maybe extract_scan_columns()?
> I tried this in the attached, updated patch.
Thanks, I'll take a look at the new version. Following you
> On Mon, Jan 20, 2020 at 05:05:33PM -0800, Peter Geoghegan wrote:
>
> I suggest that you find a way to add assertions to code like
> _bt_readpage() that verify that we do in fact have the buffer content
> lock. Actually, there is an existing assertion here that covers the
> pin, but not the buffer
> On Mon, Jan 20, 2020 at 01:19:30PM -0800, Peter Geoghegan wrote:
Thanks for the commentaries. I'm trying to clarify your conclusions for
myself, so couple of questions.
> > > - nbtsearch.c in general
> > > Most of the code seems to rely quite heavily on the fact that
> > > xs_want_itup forces
> On Wed, Jan 22, 2020 at 07:50:30AM +, Floris Van Nee wrote:
>
> Anyone please correct me if I'm wrong, but I think one case where the current
> patch relies on some data from the page it has locked before it in checking
> this hi/lo key. I think it's possible for the following sequence to h
> On Wed, Jan 22, 2020 at 05:24:43PM +, Floris Van Nee wrote:
>
> > > Anyone please correct me if I'm wrong, but I think one case where the
> > > current patch relies on some data from the page it has locked before it
> > > in checking this hi/lo key. I think it's possible for the following
> On Wed, Jan 22, 2020 at 09:08:59PM +, Floris Van Nee wrote:
> > Note in particular that index scans cannot return the same index tuple
> > twice -
> > - processing a page at a time ensures that that cannot happen.
> >
> > Can a loose index scan return the same tuple (i.e. a tuple with the sa
> On Wed, Jan 22, 2020 at 10:36:03PM +0100, Dmitry Dolgov wrote:
>
> > Let me try to clarify. After we return the first tuple, so->currPos.buf is
> > pointing to page=1 in my example (it's the only page after all). We've
> > returned item=8. Then the split ha
Oh, interesting, thank you. I believe I know what happened, there is
one unnecessary locking part that eventually gives only problems, plus
one direct access to a page items without _bt_readpage. Will post a
new version soon.
On Mon, Jan 27, 2020 at 3:00 PM Floris Van Nee wrote:
>
> Hi Dmitry,
>
> On Thu, Jan 31, 2019 at 12:24 PM Andres Freund wrote:
>
> As nothing has happened since, I'm marking this as returned with
> feedback.
This patch was on my radar for some time in the past and we've seen use cases
where it could be pretty useful (probably even without the incremental sort
patch)
> On Tue, Apr 9, 2019 at 4:12 AM Haribabu Kommi
> wrote:
>
> On Sat, Apr 6, 2019 at 7:25 AM Andres Freund wrote:
>>
>> With regards to storing the rows themselves, the second biggest
>> limitation is a limitation that is not actually a part of tableam
>> itself: WAL. Many tableam's would want to
> On Fri, Apr 5, 2019 at 10:25 PM Andres Freund wrote:
>
> A second set of limitations is around making more of tableam
> optional. Right now it e.g. is not possible to have an AM that doesn't
> implement insert/update/delete. Obviously an AM can just throw an error
> in the relevant callbacks, bu
> On Wed, Apr 17, 2019 at 10:25 PM Andres Freund wrote:
>
> I assume you're aware, but it's probably not going to be applied for 12...
Sure, the patch was mostly to express more clearly what I was thinking about :)
> I think most of the read-only stuff just needs to be non-optional, and most
> o
> On Thu, Apr 25, 2019 at 8:24 PM Tom Lane wrote:
>
> The proximate cause of the crash is that we have {PARAM 1}
> (representing the output of the InitPlan) in the path's fdw_exprs, and
> also the identical expression in fdw_scan_tlist, and that means that when
> setrefs.c processes the ForeignSca
> On Tue, Apr 9, 2019 at 5:21 PM Tomas Vondra
> wrote:
>
> So I personally would suggest to treat those patches as independent until
> the very last moment, develop the costing improvements needed by each
> of them, and then decide which of them are committable / in what order.
I had the same id
> On Thu, Mar 28, 2019 at 11:01 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Rebase after refactoring of nbtree insertion scankeys. But so far it's purely
> mechanical, just to make it work - I guess I'll need to try to rewrite some
> parts of the pat
> On Thu, May 16, 2019 at 8:56 PM Fujii Masao wrote:
>
> Yes. Thanks for the comment!
> Attached is the updated version of the patch.
> It adds such common rule.
If I understand correctly, it resulted in the commit fc7c281f8. For some reason
it breaks vacuum tests for me, is it expected?
AN
> On Mon, May 20, 2019 at 9:20 PM Andres Freund wrote:
>
> Hi,
>
> On May 20, 2019 12:14:30 PM PDT, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >> On Thu, May 16, 2019 at 8:56 PM Fujii Masao
> >wrote:
> >>
> >> Yes. Thanks for the comm
> On Wed, May 22, 2019 at 10:34 AM Michael Paquier wrote:
>
> Trying to do pg_dump[all] on a 9.5 or older server results in spurious
> failures:
> pg_dump: column number -1 is out of range 0..36
>
> After looking around, the problem comes from
> check_tuple_field_number(), more specifically from g
> On Fri, May 3, 2019 at 11:55 PM Tomas Vondra
> wrote:
>
> I don't recall the exact details of the discussion, since most of it
> happened almost a year ago, but the main concern about the original
> costing approach is that it very much assumes uniform distribution.
>
> For example if you have
> On Sat, May 11, 2019 at 6:35 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Here is the updated version with the changes I was talking about (mostly about
> readability and code cleanup). I've also added few tests for a cursor
> behaviour.
And one more cosme
> On Wed, May 29, 2019 at 6:17 PM Pavel Stehule wrote:
>
> st 29. 5. 2019 v 17:49 odesílatel Dmitry Dolgov <9erthali...@gmail.com>
> napsal:
>>
>> Rebase after pg_indent. Besides, off the list there was a suggestion that
>> this
>> could be useful to a
> On Sat, Jun 1, 2019 at 6:10 AM Floris Van Nee
> wrote:
>
> After some talks with Jesper at PGCon about the Index Skip Scan, I started
> testing this patch, because it seems to have great potential in speeding up
> many of our queries (great conference by the way, really enjoyed my first
> time
> On Sat, Jun 1, 2019 at 5:34 PM Floris Van Nee
> wrote:
>
> I did a little bit of investigation and it seems to occur because in
> pathkeys.c the function pathkey_is_redundant considers pathkeys redundant if
> there is an equality condition with a constant in the corresponding WHERE
> clause.
>
> On Sat, Jun 1, 2019 at 6:57 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Sat, Jun 1, 2019 at 5:34 PM Floris Van Nee
> > wrote:
> >
> > I did a little bit of investigation and it seems to occur because in
> > pathkeys.c the function pathkey
> On Tue, 9 Oct 2018 at 15:43, Pavel Stehule wrote:
>
> Hi
>
> I tested last patch and I have some notes:
>
> 1.
>
> postgres=# explain select distinct a1 from foo;
> +---+
> |
> On Tue, 9 Oct 2018 at 18:13, Pavel Stehule wrote:
>
>> It looks like good idea, but then the node should be named "index scan" and
>> other info can be displayed in detail parts. It can be similar like "sort".
>> The combination of unique and index skip scan looks strange :)
>
> maybe we don't n
> On Wed, 10 Oct 2018 at 14:26, Pavel Stehule wrote:
>
> I am playing with this feature little bit
Thanks a lot!
> I have one idea - can be possible to use integer subscript for record fields?
> It can helps with iteration over record.
>
> example:
>
> select ('{"a":{"a":[10,20]}}'::jsonb)[0];-
> On Sun, 14 Oct 2018 at 06:19, Thomas Munro
> wrote:
>
> Cache-oblivious hash joins cause a lot of TLB and cache misses.
> ...
> (There is another class of cache-aware hash join algorithms that partition
> carefully up front to avoid them; that's not us.)
Just out of curiosity, can you please e
if not found, then search
> from the root of the tree for the next item > the current item.
I'm not sure that I understand it correctly, can you elaborate please? From
what I see it's quite similar to what's already implemented - we look for a
distinct item on the page, and
> On Fri, 26 Oct 2018 at 13:25, Haribabu Kommi wrote:
>
> Here I attached the cumulative patch with all fixes that are shared in
> earlier mails by me.
> Except fast_default test, rest of test failures are fixed.
Hi,
If I understand correctly, these patches are for the branch "pluggable-storage
> On Mon, 29 Oct 2018 at 05:56, Haribabu Kommi wrote:
>
>> This problem couldn't be reproduced on the master branch, so I've tried to
>> investigate it. It comes from nodeModifyTable.c:1267, when we've got
>> HeapTupleInvisible as a result, and this value in turn comes from
>> table_lock_tuple. Ev
> On Thu, 1 Nov 2018 at 13:05, Daniel Gustafsson wrote:
>
> Dmitry: Are you still interested in running this commitfest?
Yes, I'm still interested. Do I need to have any special permissions in CF app
for that (e.g. now I can't "push the button" to start the current one)?
> On Thu, 1 Nov 2018 at 14:11, Stephen Frost wrote:
> I've added you to the 'cf admins' group
Thanks.
> so please give it a shot now and let me know if you run into any troubles.
Hm...I don't see any difference in CF app, what should be changed?
> On Thu, 1 Nov 2018 at 15:11, Stephen Frost wrote:
> Hmm... Can you try it again?
Yep, now I see the administration menu, thanks.
On Fri, 2 Nov 2018 at 10:24, Fabien COELHO wrote:
>
>
> Bonjour Michaël,
>
> >> Because the same patch submission is already counted? It is a rare
> >> occurence, so just a "Withdrawn" state could be enough, and slightly false
> >> CF stats are no big deal.
> >
> > Or as we are dealing with duplic
> On Sun, 1 Apr 2018 at 19:58, Yura Sokolov wrote:
>
> I didn't change serialized format. Therefore is no need to change
> SerializeSnapshot.
> But in-memory representation were changed, so RestoreSnapshot is changed.
This patch went through the last tree commit fests without any noticeable
activ
> On Mon, 9 Apr 2018 at 14:16, Ashutosh Bapat
> wrote:
>
> On Mon, Apr 9, 2018 at 5:34 PM, Kyotaro HORIGUCHI
> wrote:
> >
> > The new code doesn't seem to work as written.
> >
> >> arg = eval_const_expressions_mutator((Node *) cre->arg,
> >>context);
> >
>On Sun, 15 Apr 2018 at 09:09, Sergei Kornilov wrote:
>
> Attached updated patch follows recent Reorganize partitioning code commit.
> regards, Sergei
This patch went through the last tree commit fests without any noticeable
activity, but cfbot says it still applies and doesn't break any tests. T
> On Sun, 4 Nov 2018 at 15:48, Andrew Gierth
> wrote:
>
> >>>>> "Dmitry" == Dmitry Dolgov <9erthali...@gmail.com> writes:
>
> Dmitry> This patch went through the last tree commit fests without any
> Dmitry> noticeable activity, but cf
> On Mon, 21 May 2018 at 15:46, Robert Haas wrote:
>
> On Sat, May 19, 2018 at 12:59 PM, Greg Stark wrote:
> > On 19 May 2018 at 01:13, Stephen Frost wrote:
> >> I'm not entirely sure about the varlena suggestion, seems like that
> >> would change a great deal more code and be slower, though per
> On Thu, 17 May 2018 at 06:10, Higuchi, Daisuke
> wrote:
>
> Currently our customer uses PostgreSQL 9.6 and hits ECPG's bug during using
> numeric data type by SQLDA.
> I confirmed that this problem is occurred on master and 9.6 latest branch.
>
> FIX
> ---
>
> On Tue, 6 Nov 2018 at 10:19, Higuchi, Daisuke
> wrote:
>
> Thank you for checking!
> I rebased patches on the current master, so I attach them.
After adding 'EXEC SQL ALLOCATE DESCRIPTOR sqlda' I've managed to reproduce the
problem you're talking about, and indeed it looks strange:
=# table t
> On Fri, 12 Oct 2018 at 07:52, Pavel Stehule wrote:
>
>> > postgres=# insert into test(v) values( '[]');
>> > INSERT 0 1
>> > postgres=# update test set v[1000] = 'a';
>> > UPDATE 1
>> > postgres=# update test set v[1000] = 'a';
>> > UPDATE 1
>> > postgres=# update test set v[1000] = 'a';
>> > UP
> On Wed, 7 Nov 2018 at 17:09, Pavel Stehule wrote:
>
> I don't agree. If we use a same syntax for some objects types, we should to
> enforce some consistency.
Just to make it clear, consistency between what?
> I don't think so you should to introduce nulls for JSONs. In this case, the
> most
> On Thu, 8 Nov 2018 at 06:14, Pavel Stehule wrote:
>
>> Now it's my turn to disagree. As an argument I have this thread [1], where
>> similar discussion happened about flexibility of jsonb and throwing an errors
>> (in this particular case whether or not to throw an error when a non existing
>> p
> On Fri, 15 Jun 2018 at 17:09, Nathan Bossart wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:not tested
>
> -
> On Mon, 2 Jul 2018 at 15:54, Jesper Pedersen
> wrote:
>
> The patch from November 27, 2017 still applies (with hunks),
>
> https://commitfest.postgresql.org/18/1166/
>
> passes "make check-world" and shows performance improvements.
>
> Keeping it in "Ready for Committer".
Looks like for some
> On Mon, 12 Nov 2018 at 13:29, Sergei Kornilov wrote:
>
> I found reproducible crash due assert failure: FailedAssertion("!(numCols >
> 0)", File: "pathnode.c", Line: 2795)
> > create table tablename (i int primary key);
> > select distinct i from tablename where i = 1;
> Query is obviously stra
> On Sun, 4 Nov 2018 at 19:03, Sergei Kornilov wrote:
>
> > If not properly cataloguing NOT NULL constraints would be fixed, can it
> > potentially conflict with the current patch or not?
> We already doing same stuff for "alter table attach partition" and in this
> patch i use exactly this routi
> On Wed, 14 Nov 2018 at 00:44, Thomas Munro
> wrote:
>
> Here is a rebased version of the patch, post pread()/pwrite(). I have
> also rewritten the commit message to try to explain the rationale
> concisely, instead of requiring the reader to consult multiple
> discussions that jump between len
101 - 200 of 725 matches
Mail list logo
