Re: [HACKERS] Causal reads take II

> On 12 July 2017 at 23:45, Thomas Munro wrote: > I renamed it to "synchronous replay", because "causal reads" seemed a bit too > arcane. Hi I looked through the code of `synchronous-replay-v1.patch` a bit and ran a few tests. I didn't manage to break anything,

[HACKERS] Proposal about a "deep" versions for some jsonb functions

Hi As far as I know, since 9.5 we're missing some convenient features, namely a deepversion of `jsonb_concat` and `jsonb_minus`. There are already few feature requests about `jsonb_minus` (see [1], [2]) and a lot of confusion and requests about a deep version of `jsonb_concat`. From my point of

Re: [HACKERS] JSONB - JSONB operator feature request

> On 20 July 2017 at 16:24, David Fetter wrote: > > If we can agree to a definition, we can make this go. My vague > memories from graph theory indicate that that "agree to a definition" > part is the real problem to be solved. I tried to embody some relevant thoughts in this

Re: [HACKERS] Causal reads take II

> On 23 June 2017 at 13:48, Thomas Munro wrote: > > Apologies for the extended delay. Here is the rebased patch, now with a > couple of improvements (see below). Thank you. I started to play with it a little bit, since I think it's an interesting idea. And there

Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to a specific backend

> On 28 June 2017 at 12:17, Yugo Nagata wrote: > > Hi, > > Attached is a patch of pg_reload_backend that is a function signaling > SIGHUP to a specific backend. The original idea is from Michael Paquier[1]. > The documatation isn't included in this patch yet. I have few

Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to a specific backend

> On 29 Jun 2017 08:18, "Yugo Nagata" wrote: > > This is because this function is defined as strict Yes, I realized that few moments after I sent my message. > Arg type is needed. > > =# grant execute on function pg_reload_backend(int) to test_user; Oh, I see, thank you.

Re: [HACKERS] [PATCH] Generic type subscripting

> On 18 September 2017 at 11:39, Arthur Zakirov wrote: > I think it would be good to add new catalog table. It may be named as pg_type_sbs or pg_subscripting (second is better I think). > This table may have the fields: > - oid > - sbstype > - sbsinit > - sbsfetch > -

Re: [HACKERS] [PATCH] Generic type subscripting

> On 17 September 2017 at 00:04, Arthur Zakirov wrote: > > In my opinion, 'DEPENDS ON' syntax is not actually appropriate here. It > also looks like a not very good hack to me. Hm...why do you think about it as a hack? > Moreover user can implement subscripting to its

Re: [HACKERS] [PATCH] Generic type subscripting

> On 19 September 2017 at 10:21, Arthur Zakirov <a.zaki...@postgrespro.ru> wrote: > On Mon, Sep 18, 2017 at 12:25:04PM +0200, Dmitry Dolgov wrote: >> > I think it would be good to add new catalog table. It may be named as >> pg_type_sbs or pg_subscriptin

Re: [HACKERS] [PATCH] Generic type subscripting

> On 20 September 2017 at 17:19, Arthur Zakirov wrote: > As a conclusion: > * additional field are needed to pg_type for *_fetch and *_assign functions to solve dependency problem One last thing that I need to clarify. Initially there was an idea to minimize changes in

Re: [HACKERS] [PATCH] Generic type subscripting

> On 17 September 2017 at 23:34, Arthur Zakirov wrote: > > I have put some thought into it. What about the following syntax? > > CREATE SUBSCRIPTING FOR type_name > INITFUNC = subscripting_init_func > FETCHFUNC = subscripting_fetch_func > ASSIGNFUNC =

Re: [HACKERS] log_destination=file

> On 8 September 2017 at 01:32, Magnus Hagander wrote: > > 1. where was stderr actually sent? To the console, to /dev/null or to a file? To the console (but I can also try other options, although I'm not sure if it would have any impact). > 2. Could you run the same thing

Re: [HACKERS] log_destination=file

Hi > On 31 August 2017 at 14:49, Tom Lane wrote: >> Are you actually asking for a benchmark of if logging gets slower? > > Yes. > >> If so, >> could you suggest a workload to make an actual benchmark of it (where >> logging would be high enough that it could be come a

Re: [HACKERS] log_destination=file

> On 7 September 2017 at 15:46, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > It seems that for this particular workload it was about 20-25% slower.​ Hmm...looks like I provided misleading data, sorry. The numbers from previous email are correct and I'm able to reproduce them, b

Re: [HACKERS] [PATCH] Generic type subscripting

> On 11 September 2017 at 23:19, Tom Lane wrote: > > Uh, what? Sure you can. Just because the existing code never has a > reason to create such a dependency doesn't mean it wouldn't work. Well, I thought that `pg_depend` was not intended to be used from user-defined code

Re: [HACKERS] [PATCH] Generic type subscripting

> On 11 September 2017 at 23:45, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Dmitry Dolgov <9erthali...@gmail.com> writes: > >> On 11 September 2017 at 23:19, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Uh, what? Sure you can. Just because the ex

Re: [HACKERS] [PATCH] Generic type subscripting

> On 9 September 2017 at 23:33, Arthur Zakirov wrote: > PostgreSQL and documentation with the patch compiles without any errors. All > regression tests passed. Thank you! > But honestly I still cannot say that I agree with *_extract() and *_assign() > functions

Re: [HACKERS] Causal reads take II

> On 31 July 2017 at 07:49, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: >> On Sun, Jul 30, 2017 at 7:07 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: >> >> I looked through the code of `synchronous-replay-v1.patch` a bit and ran a few >> tests. I

Re: [HACKERS] [PATCH] Generic type subscripting

> On Fri, Sep 22, 2017 at 3:51 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 9/21/17 11:24, Dmitry Dolgov wrote: >> One last thing that I need to clarify. Initially there was an idea to >> minimize changes in `pg_type` > > I see, but there i

[HACKERS] Json(b) extension

Hi all, As you know, PostgreSQL introduced Json(b) support at the 9.4 version [1], and hstore v2.0 saved in separate repository [2]. But although PostgreSQL has this support at the core level, there are many useful functions, which wasn't ported to Json(b) from hstore v2.0 and json. Here [3],

Re: [HACKERS] Json(b) extension

j...@agliodbs.com wrote: On 04/24/2014 03:46 AM, Dmitry Dolgov wrote: Hi all, As you know, PostgreSQL introduced Json(b) support at the 9.4 version [1], and hstore v2.0 saved in separate repository [2]. But although PostgreSQL has this support at the core level, there are many useful

[HACKERS] Jsonb: jbvBinary usage in the convertJsonbValue?

Hi all, I'm little confused by the *convertJsonbValue* functon at *jsonb_utils.c* Maybe I misunderstood something, so I need help =) if (IsAJsonbScalar(val) || val-type == jbvBinary) convertJsonbScalar(buffer, header, val); As I can see, the *convertJsonbScalar* function is used for

[HACKERS] JsonbValue to Jsonb conversion

Hi all, I'm faced with some troubles about the jsonb implementation, and I hope I'll get little advice =) If I understand correctly, an abstract function for jsonb modification should have the following stages: Jsonb - JsonbValue - Modification - JsonbValue - Jsonb One can convert the

Re: [HACKERS] GSoC 2015 - mentors, students and admins.

I would like to participate as student. On 10 February 2015 at 03:52, Thom Brown t...@linux.com wrote: Hi all, Google Summer of Code 2015 is approaching. I'm intending on registering PostgreSQL again this year. Before I do that, I'd like to have an idea of how many people are interested

Re: [HACKERS] GSoC 2015: Extra Jsonb functionality

alvhe...@2ndquadrant.com wrote: Thom Brown wrote: On 19 March 2015 at 14:12, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Dmitry Dolgov wrote: * jsonb_slice - extract a subset of an jsonb Example of usage: Okay, so it pulls it all parents? So I guess you'd get

Re: [HACKERS] GSoC 2015: Extra Jsonb functionality

). On 20 March 2015 at 18:39, Thom Brown t...@linux.com wrote: On 20 March 2015 at 11:21, Dmitry Dolgov 9erthali...@gmail.com wrote: Perhaph it's my misunderstanding, but this would seem to be more of an intersection operation on keys rather than a delete. Hm...why? We remove all elements

Re: [HACKERS] GSoC 2015: Extra Jsonb functionality

Frankly, I think the whole proposal needs to be rethought with an eye towards supporting and preserving nested elements instead of trying to just flatten everything out. Can you pls show me few examples what do you mean exactly? On 21 March 2015 at 06:51, Jim Nasby jim.na...@bluetreble.com

[HACKERS] GSoC 2015: Extra Jsonb functionality

Hi, everyone I'm Dmitry Dolgov, a phd student at the KemSU, Russia. I would like to submit a proposal to the GSoC about additional jsonb functionality, and I want to get any feedback and thougths about this.

Re: [HACKERS] GSoC 2015: Extra Jsonb functionality

for extension as a whole. Unfortunately, this proposal isn't submitted to the GSoC system yet (I'm planning to do this in the next Tuesday). [1]: https://github.com/erthalion/jsonbx [2]: https://commitfest.postgresql.org/4/154/ On 19 March 2015 at 20:16, Dmitry Dolgov 9erthali...@gmail.com wrote: Hi

Re: [HACKERS] mogrify and indent features for jsonb

Hi, Petr, thanks for the review. I think it would be better if the ident printing didn't put the start of array ([) and start of dictionary ({) on separate line Did you mean this? [ { a: 1, b: 2 } ] I tried to verify this in several ways

Re: [HACKERS] mogrify and indent features for jsonb

Hi, Thom. Would this support deleting type and the value 'dd' With this patch you can delete them one by one: select '{a: 1, b: 2, c: {type: json, stuff: test}, d: [aa,bb,cc,dd]}'::jsonb - '{c, type}'::text[] - '{d, -1}'::text[]; ?column?

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

creates the specified path if it does not exist. Does it? No, jsonb_replace() doesn't create an element, if it doesn't exist. I think, otherwise it can be confusing, so probably jsonb_add() may be more appropriate (and, actually, this function was already mentioned in previous discussions). On

Re: [HACKERS] jsonb concatenate operator's semantics seem questionable

Historical note: I think it's based on the nested hstore work, not on current hstore, but Dmitry can answer on that. Yes, you're right. And I agree with thoughts above, that both concatenation modes (simple and deep) definitely can be useful. I can try to figure out how much work that would be

[HACKERS] jsonb array-style subscripting

Hi, Some time ago the array-style subscripting for the jsonb data type was discussed in this mailing list. I think it will be quite convenient to have a such nice syntax to update jsonb objects, so I'm trying to implement this. I created a patch, that allows doing something like this: =# create

Re: [HACKERS] jsonb_set array append hack?

I'm sorry, but I'm not sure, what behavior is expected in this case? Right now the following logic was implemented: "we trying to set an element inside an array, but we've got a non-integer path item ("nonsense" in this particular case), so we're going to add a new element at the end of

Re: [HACKERS] jsonb_set array append hack?

>> For that matter, we should probably disallow NULL path elements also, shouldn't we? > I'd say yes. Well, here is the new `setPath` function with this modification. Is it what did you mean? non_integer_in_path2.patch Description: Binary data -- Sent via pgsql-hackers mailing list

Re: [HACKERS] jsonb_set array append hack?

ECT jsonb_set( '{"name": "Joe", "vehicle_types": ["car", "van"]}'::jsonb, '{vehicle_types, nonsense}', '"motorcycle"', true); ERROR: path element at the position 2 is not an integer On 20 September 2015 at 23:50, Thom Brown &

Re: [HACKERS] jsonb - jsonb operators

> if there's any future intention to add a delete operator that removes element/pair matches? I think the operator (jsonb - jsonb) is logical because we have a shallow concatenation function (something like a "union" operation), but we have nothing like "set difference" and "intersection"

[HACKERS] jsonb array-style subscription

Hi, Here is a reworked version of patch for jsonb subscription. There weren't many changes in functionality: =# create TEMP TABLE test_jsonb_subscript ( id int, test_json jsonb ); =# insert into test_jsonb_subscript values (1, '{}'), (2, '{}'); =# update test_jsonb_subscript set

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

> I'd strongly prefer the jsonb_array_insert naming though > I don't think it's a good idea to use set when this is used on object, I think that we should throw error in that case. Well, I thought it's wrong to introduce different functions and behaviour patterns for objects and arrays, because

Re: [HACKERS] jsonb array-style subscription

On 20 January 2016 at 02:14, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Dmitry Dolgov wrote: > > > I've cleaned up the code, created a separate JsonbRef node (and there > are a > > lot of small changes because of that), abandoned an idea of "deep > n

[HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

Hi As far as I see there is one basic update function for jsonb, that can't be covered by `jsonb_set` - insert a new value into an array at arbitrary position. Using `jsonb_set` function we can only append into array at the end/at the beginning, and it looks more like a hack: ``` =# select

Re: [HACKERS][REVIEW]: Password identifiers, protocol aging and SCRAM protocol

On 1 March 2016 at 06:34, Michael Paquier wrote: > On Mon, Feb 29, 2016 at 8:43 PM, Valery Popov > wrote: > > vpopov@vpopov-Ubuntu:~/Projects/pwdtest/postgresql$ git branch > > Thanks for the input! > > >

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

Hi Vitaly, thanks for the review. I've attached a new version of path with improvements. Few notes: > 7. Why did you remove "skip"? It is a comment what "true" means... Actually, I thought that this comment was about skipping an element from jsonb in order to change/delete it, not about the last

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 31 March 2016 at 05:04, Vitaly Burovoy wrote: > The documentation changes still has to be fixed. > Thanks for help. Looks like I'm not so good at text formulation. Fixed. > Moreover it seems the logic in the code is correct No - I see now, that I made the same

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 6 April 2016 at 03:29, Andrew Dunstan wrote: > > Yeah, keeping it but rejecting update of an existing key is my preference > too. > > cheers > > andrew > Yes, it sounds quite reasonable. Here is a new version of patch (it will throw an error for an existing key). Is it

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

> I still don't like that this works on path leading to an object given that we can't fulfill the promise of inserting to an arbitrary position there. I'm thinking about this following way - `jsonb_insert` is just a function to insert a new value, which has specific options to enforce arbitrary

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

Here is a new version of path, I hope I didn't miss anything. Few notes: > 4. > or even create a new constant (there can be better name for it): > #define JB_PATH_CREATE_OR_INSERT (JB_PATH_INSERT_BEFORE | > JB_PATH_INSERT_AFTER | JB_PATH_CREATE) Good idea, thanks. > 5. > > if (op_type !=

Re: [HACKERS] jsonb array-style subscription

> Do you have an updated patch ready? No, I'm afraid it will not be ready for Monday.

Re: [HACKERS] jsonb array-style subscription

> If the patch were proposing a similar amount of new infrastructure to > support some datatype-extensible concept of subscripting, I'd be much > happier about it. Well, actually, I agree with that. I can try to rework the patch to achieve this goal.

Re: [HACKERS] [PATH] Jsonb, insert a new value into an array at arbitrary position

On 31 March 2016 at 17:31, Vitaly Burovoy wrote: > it is logical to insert new value if "before", then current value, then new > value if "after". > Oh, I see now. There is a slightly different logic: `v` is a current value and `newval` is a new value. So basically we

[HACKERS] Jsonb array-style subscripting, generic version

Hi With regard to previous conversations: http://www.postgresql.org/message-id/flat/CA+q6zcV8qvGcDXurwwgUbwACV86Th7G80pnubg42e-p9gsSf=g...@mail.gmail.com#CA+q6zcV8qvGcDXurwwgUbwACV86Th7G80pnubg42e-p9gsSf=g...@mail.gmail.com

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

​Hi I tried to dig into this patch (which seems pretty interesting) to help bring it in good shape. Here are few random notes, I hope they can be helpful: > I think we actually need a real API here. Definitely, there are plenty places in the new code with the same pattern: * figure out if it's

Re: [HACKERS] [PATCH] Generic type subscription

On 24 January 2017 at 02:36, Tom Lane wrote: > It might be possible to get away with having only one pg_type column, > pointing at the parse-analysis function. That function would generate > a SubscriptingRef tree node containing the OID of the appropriate > execution

Re: [HACKERS] [PATCH] Generic type subscription

> On 24 January 2017 at 02:07, Tom Lane wrote: > I took an extremely quick look over the patch Thank you for the feedback. It took some time for me to think about all suggestions and notes. > 1. As I mentioned previously, it's a seriously bad idea that ArrayRef > is used for

[HACKERS] [PATCH] few fts functions for jsonb

Hi all I would like to propose patch with a set of new small functions for fts in case of jsonb data type: * to_tsvector(config, jsonb) - make a tsvector from all string values and elements of jsonb object. To prevent the situation, when tsquery can find a phrase consisting of lexemes from

Re: [HACKERS] [PATCH] Generic type subscription

On 5 October 2016 at 03:00, Oleg Bartunov wrote: > > have you ever run 'make check' ? > > = > 53 of 168 tests failed. > = > > Sure, how else could I write tests for this feature? But right now on my machine everything is ok

Re: [HACKERS] [PATCH] Generic type subscription

> On 15 November 2016 at 15:03, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > Hello. > > I took a look on the latest -v4 patch. I would like to note that this > patch breaks a backward compatibility. For instance sr_plan extension[1] > stop to compile with errors Thank you for the

Re: [HACKERS] jsonb_delete with arrays

> On 15 November 2016 at 22:53, Magnus Hagander wrote: > Attached is an implantation of jsonb_delete that instead of taking a single key to remove accepts an array of keys (it still does just keys, so it's using the - operator, it's not like the path delete function that also

Re: [HACKERS] jsonb_delete with arrays

> Attached is an implantation of jsonb_delete that instead of taking a single key to remove accepts an array of keys Since I already saw this patch, here is my small review. Speaking about implementation of `jsonb_delete_array` - it's fine, but I would like to suggest two modifications: *

Re: [HACKERS] [PATCH] Generic type subscription

> On 4 January 2017 at 18:06, Artur Zakirov wrote: > But I'm not convinced about how to distinguish ArrayRef node with new > SubscriptingRef node. I'm not sure I understood you correctly. You're talking about having two nodes `ArrayRef` and `SubscriptingRef` at the same

Re: [HACKERS] [PATCH] Generic type subscription

, 2016 at 10:56 PM, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> > wrote: > > > On 15 November 2016 at 15:03, Aleksander Alekseev < > a(dot)alekseev(at)postgrespro(dot)ru> wrote: > > Hello. > > > > I took a look on the latest -v4 patch. I would like

Re: [HACKERS] [PATCH] Generic type subscription

> On 5 December 2016 at 12:03, Haribabu Kommi wrote: > > Moved to next CF with "needs review" status. Looks like we stuck here little bit. Does anyone else have any suggestions/improvements, or this patch is in good enough shape?

Re: [HACKERS] [PATCH] Generic type subscripting

On 28 March 2017 at 11:58, Arthur Zakirov wrote: > > Your patch reverts commits from 25-26 march. And therefore contains 15000 lines. Wow, I didn't notice that, sorry - will fix it shortly.

Re: [HACKERS] [PATCH] few fts functions for jsonb

> I'm not through looking at this. However, here are a few preliminary comments I've attached new versions of the patches with improvements related to these commentaries. diff --git a/src/backend/tsearch/to_tsany.c b/src/backend/tsearch/to_tsany.c index 6e5de8f..8f7bcfe 100644 ---

Re: [HACKERS] [PATCH] few fts functions for jsonb

> On 29 March 2017 at 18:28, Andrew Dunstan wrote: > > These patches seem fundamentally OK. But I'm still not happy with the > naming etc. I've changed names for all functions and action definitions, moved out the changes in header file to `jsonapi.h` and removed

Re: [HACKERS] [PATCH] Generic type subscripting

On 24 March 2017 at 15:39, David Steele wrote: > > Do you have an idea when you will have a patch ready? Yes, I'll prepare a new version with most important changes in two days.

Re: [HACKERS] [PATCH] Generic type subscripting

00:10, Tom Lane <t...@sss.pgh.pa.us> wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: > > I looked through this a bit. > Thank you for the feedback. > > On 10 March 2017 at 06:20, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > I see a poss

Re: [HACKERS] [PATCH] few fts functions for jsonb

> On 21 March 2017 at 03:03, Andrew Dunstan wrote: > > However, I think it should probably be broken up into a couple of pieces - > one for the generic json/jsonb transforms infrastructure (which probably > needs some more comments) and one for the FTS functions

Re: [HACKERS] [PATCH] few fts functions for jsonb

On 31 March 2017 at 00:01, Andrew Dunstan wrote: > > I have just noticed as I was writing/testing the non-existent docs for > this patch that it doesn't supply variants of to_tsvector that take a > regconfig as the first argument. Is there a reason for that? Why >

Re: [HACKERS] [PATCH] Generic type subscripting

On 30 March 2017 at 19:36, Arthur Zakirov wrote: > > The last point is about the tutorial. As Tom pointed it is not useful when the tutorial doesn't execute. It happens because there is not "custom" type in subscripting.sql. I'm confused. Maybe I'm missing something,

Re: [HACKERS] [PATCH] few fts functions for jsonb

> On 28 February 2017 at 19:21, Oleg Bartunov wrote: > 1. add json support I've added json support for all functions. > Its_headline should returns the original json with highlighting Yes, I see now. I don't think it's worth it to add a special option for that purpose,

Re: [HACKERS] Function to move the position of a replication slot

> On 4 May 2017 at 20:05, Magnus Hagander wrote: > > PFA a patch that adds a new function, pg_move_replication_slot, that makes it > possible to move the location of a replication slot without actually > consuming all the WAL on it. Just a few questions just a few questions

[HACKERS] Valgrind & tests for `numeric`

Hi Recently I noticed, that when I'm running the regression tests under Valgrind 3.9.0, one test for `numeric` is constantly failing: Here is what expected: ``` SELECT i as pow, round((-2.5 * 10 ^ i)::numeric, -i), round((-1.5 * 10 ^ i)::numeric, -i), round((-0.5 * 10 ^ i)::numeric, -i),

Re: [HACKERS] logical decoding of two-phase transactions

Hi > On 4 April 2017 at 19:13, Masahiko Sawada wrote: > > Other than that issue current patch still could not pass 'make check' > test of contrib/test_decoding. Just a note about this patch. Of course time flies by and it needs rebase, but also there are few failing tests

Re: [HACKERS] logical decoding of two-phase transactions

On 13 May 2017 at 22:22, Tom Lane wrote: > > Apparently you are not testing against current HEAD. That's been there > since d10c626de (a whole two days now ;-)) Indeed, I was working on a more than two-day old antiquity. Unfortunately, it's even more complicated to apply

[HACKERS] Create subscription with `create_slot=false` and incorrect slot name

Hi Maybe this question was already raised before, but I couldn't find a discussion. When I'm creating a subscription with `create_slot=false` looks like it's possible to pass a slot name with invalid characters. In this particular case both publisher and subscriber were on the same machine:

Re: [HACKERS] Create subscription with `create_slot=false` and incorrect slot name

On 23 May 2017 at 07:26, Euler Taveira wrote: > > ReplicationSlotValidateName() should be called in parse_subscription_options() to avoid a pilot error. > IMHO we should prevent a future error (use of invalid slot name). Yes, I see now. I assume this little patch should be

Re: [HACKERS] Causal reads take II

Hi I'm wondering about status of this patch and how can I try it out? > On 3 January 2017 at 02:43, Thomas Munro wrote: > The replay lag tracking patch this depends on is in the current commitfest I assume you're talking about this patch [1] (at least it's the

Re: [HACKERS] Create subscription with `create_slot=false` and incorrect slot name

> On 26 May 2017 at 23:05, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > > On 5/25/17 19:16, Petr Jelinek wrote: > >> The reported error is just one of many errors that can happen when DROP > >> SUBSCRIPTION tries to drop the slot (doens't exist, still active, no > >> permission,

Re: [HACKERS] type cache for concat functions

> On 20 May 2017 at 10:03, Pavel Stehule wrote: > > Now concat is 2x times slower than || operator. With cached FmgrInfo for > output function it will be only 5%. Looks nice and does what's expected (what else one may need from a Saturday evening). I just can mention