Hello,
I encountered a strange behavior of lightweight lock in PostgreSQL 9.2. That
appears to apply to 9.6, too, as far as I examine the code. Could you tell me
if the behavior is intended or needs fix?
Simply put, the unfair behavior is that waiters for exclusive mode are
overtaken by shar
On Mon, May 23, 2016 at 6:25 PM, Craig Ringer wrote:
> On 24 May 2016 at 09:12, Michael Paquier wrote:
>>
>> Hi all,
>>
>> Today somebody has pointed me out that it could be interesting to be
>> able to recovery up to a given LSN position. One argument behind that
>> was to allow a maximum of thi
Craig Ringer writes:
> On 24 May 2016 at 00:00, Michael Paquier wrote:
>> Did you consider the use of simple_list.c instead of introducing a new
>> mimic as PGcommandQueueEntry? It would be cool avoiding adding new
>> list emulations on frontends.
> I'd have to extend simple_list to add a generi
On 24 May 2016 at 00:00, Michael Paquier wrote:
>
> Did you consider the use of simple_list.c instead of introducing a new
> mimic as PGcommandQueueEntry? It would be cool avoiding adding new
> list emulations on frontends.
>
I'd have to extend simple_list to add a generic object version, like
On Mon, May 23, 2016 at 8:09 PM, Tom Lane wrote:
> Does it appear to compile without that?
It does. The only thing that's absent is the pgrminclude directive,
which is of course just a C comment.
> (More generally, is there a better answer for that problem?)
My unpublished parallel B-Tree index
On 24 May 2016 at 00:05, Merlin Moncure wrote:
>
> This feature was very much a product of the time, at the height of the
> "Object Relational" fad. The trend for postgres has been in the exact
> opposite direction, towards the SQL standard. Further complicating
> matters, inheritance has been
Peter Geoghegan writes:
> If BTREE_BUILD_STATS needs a "tcopprot.h pgrminclude ignore" within
> nbtree.c, then ISTM that the similar include directive within
> nbtsort.c ought to receive the same treatment.
Does it appear to compile without that?
(More generally, is there a better answer for tha
On 24 May 2016 at 00:00, Michael Paquier wrote:
> On Mon, May 23, 2016 at 8:50 AM, Andres Freund wrote:
>
> > yay^2.
>
> I'll follow this mood. Yeha.
BTW, I've publushed the HTML-ified SGML docs to
http://2ndquadrant.github.io/postgres/libpq-batch-mode.html as a preview.
--
Craig Ringer
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Mon, May 23, 2016 at 5:05 PM, Tom Lane wrote:
> > Michael Paquier writes:
> >> I just bumped into the following typo for $subject:
> >> - 'role names cannot being with "pg_"');
> >> + 'role names cannot begin with "pg_"');
> >
On 24 May 2016 at 09:12, Michael Paquier wrote:
> Hi all,
>
> Today somebody has pointed me out that it could be interesting to be
> able to recovery up to a given LSN position. One argument behind that
> was to allow a maximum of things to recover up to the point where a
> relation block got cor
On 24 May 2016 at 00:00, Michael Paquier wrote:
> On Mon, May 23, 2016 at 8:50 AM, Andres Freund
> wrote:
>
>> This should be very useful for optimising FDWs, Postgres-XC, etc.
> >
> > And optimizing normal clients.
> >
> > Not easy, but I'd be very curious how much psql's performance improves
>
On Mon, May 23, 2016 at 5:05 PM, Tom Lane wrote:
> Michael Paquier writes:
>> I just bumped into the following typo for $subject:
>> - 'role names cannot being with "pg_"');
>> + 'role names cannot begin with "pg_"');
>
> Pushed, thanks.
Thanks.
--
Michael
--
Sent via pgsql-hacke
Hi all,
Today somebody has pointed me out that it could be interesting to be
able to recovery up to a given LSN position. One argument behind that
was to allow a maximum of things to recover up to the point where a
relation block got corrupted by a specific record because of a broken
segment. So t
On Mon, May 23, 2016 at 4:41 PM, Tom Lane wrote:
> Pushed, thanks.
Thanks.
If BTREE_BUILD_STATS needs a "tcopprot.h pgrminclude ignore" within
nbtree.c, then ISTM that the similar include directive within
nbtsort.c ought to receive the same treatment.
--
Peter Geoghegan
--
Sent via pgsql-ha
Michael Paquier writes:
> I just bumped into the following typo for $subject:
> - 'role names cannot being with "pg_"');
> + 'role names cannot begin with "pg_"');
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Peter Geoghegan writes:
> The attached patch fixes the BTREE_BUILD_STATS build. Looks like
> 65c5fcd353a859da9e61bfb2b92a99f12937de3b broke this. That commit was
> made back in January, so no backpatch is required.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-ha
On Mon, May 23, 2016 at 4:27 PM, Tom Lane wrote:
>> You also have to be aware of the new thing, which a lot of hackers
>> will not be, if awareness of COPY_PARSE_PLAN_TREES is anything to go
>> by.
>
> I doubt that anybody ever enables that in manual builds anyway.
> The important thing is to have
Peter Geoghegan writes:
> On Mon, May 23, 2016 at 4:11 PM, Tom Lane wrote:
>> And after further thought, I decided that that was penny-wise and
>> pound-foolish; it's more readable if the #define is just an independent
>> pg_config_manual.h entry. The only work it'd save is the need to update
>>
On Mon, May 23, 2016 at 4:11 PM, Tom Lane wrote:
> And after further thought, I decided that that was penny-wise and
> pound-foolish; it's more readable if the #define is just an independent
> pg_config_manual.h entry. The only work it'd save is the need to update
> a buildfarm animal or two to a
I wrote:
> Peter Geoghegan writes:
>>> If that sounds like a plausible choke-point, the next question is what
>>> to use to enable the debug test. I propose "#ifdef COPY_PARSE_PLAN_TREES"
>>> since that enables similar sanity checking for other parts of
>>> backend/nodes/, and we do have at least
Tom Lane wrote:
> My feeling about it is that we need to provide a partitioning feature
> that doesn't rely on the current notion of inheritance at all. We've
> heard from multiple users who want to use large numbers of partitions,
> enough that simply having a separate relcache entry for each pa
Joe Conway writes:
> But then again, maybe we need to start with a clear notion of what
> problems people are trying to solve when they use partitions. At least
> some of the historic reasons are no longer valid.
That's true. Just because people want to have a gazillion partitions
doesn't necess
On 05/23/2016 03:05 PM, Tom Lane wrote:
> Jim Nasby writes:
>> I don't see why partitioning complicates fixing these issues. ISTM it's
>> the exact same complaint for both inheritance and partitioning.
>
> My feeling about it is that we need to provide a partitioning feature
> that doesn't rely
Jim Nasby writes:
> On 5/23/16 11:05 AM, Merlin Moncure wrote:
>> This feature was very much a product of the time, at the height of the
>> "Object Relational" fad. The trend for postgres has been in the exact
>> opposite direction, towards the SQL standard. Further complicating
>> matters, inhe
On 05/23/2016 02:37 PM, David G. Johnston wrote:
> But then I don't get Joe's point - if its an implementation detail why
> should it matter if rewriting the SRF-in-tlist to be laterals changes
> execution from a serial to an interleaved implementation. Plus, Joe's
> claim: "the capability to pi
On 5/23/16 11:05 AM, Merlin Moncure wrote:
Postgres doesn't work that way, and the documentation disclaims this:
"Note: Although inheritance is frequently useful, it has not been
integrated with unique constraints or foreign keys, which limits its
usefulness. See Section 5.8 for more detail."
Pe
Peter Geoghegan writes:
> What I meant is that I think naively adding the choke-point for a
> top-level SelectStmt would do the job (although perhaps we could do
> better). I wasn't suggesting that we'd avoid recursing from there;
> only that we could reasonably avoid recursing from someplace else
On Mon, May 23, 2016 at 5:38 PM, Jim Nasby wrote:
> On 5/23/16 11:55 AM, Peter van Hardenberg wrote:
>
>> Fortunately, this seems quite easy to resolve by taking advantage of our
>> ability to add json_*(jsonb) form of the functions.
>>
>
> Another issue no one has mentioned is functions that ret
On 5/23/16 11:55 AM, Peter van Hardenberg wrote:
Fortunately, this seems quite easy to resolve by taking advantage of our
ability to add json_*(jsonb) form of the functions.
Another issue no one has mentioned is functions that return JSON/JSONB.
IMO those should NOT be overloaded, because that
On Mon, May 23, 2016 at 4:42 PM, Tom Lane wrote:
> "David G. Johnston" writes:
> > On Mon, May 23, 2016 at 4:24 PM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>
> > wrote:
> >> Ah, so that's what "pipeline results" mean! I hadn't gotten that. I
> >> agree; Abhijit had a patch or a plan for thi
On Mon, May 23, 2016 at 4:37 PM, Tom Lane wrote:
> Peter van Hardenberg writes:
> > Great question, Marko. If you can point me towards an example I'll take a
> > look, but I'll proceed with the current understanding and suggestions and
> > see what people have to say.
>
> I believe Marko's just
I'll look into it, thanks for the explanation.
On Mon, May 23, 2016 at 1:37 PM, Tom Lane wrote:
> Peter van Hardenberg writes:
> > Great question, Marko. If you can point me towards an example I'll take a
> > look, but I'll proceed with the current understanding and suggestions and
> > see what
The attached patch fixes the BTREE_BUILD_STATS build. Looks like
65c5fcd353a859da9e61bfb2b92a99f12937de3b broke this. That commit was
made back in January, so no backpatch is required.
--
Peter Geoghegan
From 06d2150ff20dfa3e6fbc579a9e41ff3f6487 Mon Sep 17 00:00:00 2001
From: Peter Geoghegan
On Mon, May 23, 2016 at 1:55 PM, Tom Lane wrote:
> Um, I think not --- you need the case cited by the OP, namely an INSERT
> ON CONFLICT in a CTE in a SelectStmt. If we'd had any of those in the
> regression tests, we'd have found the bug, but we don't; and it's not
> an obvious combination to tr
Peter Geoghegan writes:
> On Mon, May 23, 2016 at 12:48 PM, Tom Lane wrote:
>> Also, related to this complaint though not this patch, it's disturbing
>> that this oversight wasn't detected long ago. My first thought was to add
>> some conditionally-compiled debugging code that just performs a no
On Mon, May 23, 2016 at 12:48 PM, Tom Lane wrote:
>> I saw no reason to avoid the extra cycles. A noticeable omission has a
>> cost: it gets noticed. Given this code path is likely to hardly ever
>> be hit, this mechanical approach seemed best. That's all.
>
> I agree that performance isn't much o
"David G. Johnston" writes:
> On Mon, May 23, 2016 at 4:24 PM, Alvaro Herrera
> wrote:
>> Ah, so that's what "pipeline results" mean! I hadn't gotten that. I
>> agree; Abhijit had a patch or a plan for this, a long time ago ...
> âIs this sidebar strictly an implementation detail, not user v
Peter van Hardenberg writes:
> Great question, Marko. If you can point me towards an example I'll take a
> look, but I'll proceed with the current understanding and suggestions and
> see what people have to say.
I believe Marko's just complaining about the case for unknown-type
arguments, for exa
On Mon, May 23, 2016 at 4:24 PM, Alvaro Herrera
wrote:
> Tom Lane wrote:
> > Joe Conway writes:
>
> > > I'll also note that, unless I missed something, we also have to
> consider
> > > that the capability to pipeline results is still only available in the
> > > target list.
> >
> > Yes, we would
On Mon, May 23, 2016 at 4:15 PM, Tom Lane wrote:
> Merlin Moncure writes:
> > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote:
> >> On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote:
> >>> +1 on removing LCM.
>
> >> As a green field project, that would make total sense. As a t
Tom Lane wrote:
> Joe Conway writes:
> > I'll also note that, unless I missed something, we also have to consider
> > that the capability to pipeline results is still only available in the
> > target list.
>
> Yes, we would definitely want to improve nodeFunctionscan.c to perform
> better for Va
Joe Conway writes:
> I would be in favor of rewriting it to a LATERAL, but that would not be
> backwards compatible entirely either IIUC.
It could be made so, I think, but it may be more trouble than it's worth;
see my previous message.
> I'll also note that, unless I missed something, we also h
On Mon, May 23, 2016 at 4:05 PM, David Fetter wrote:
> On Mon, May 23, 2016 at 02:39:54PM -0500, Merlin Moncure wrote:
> > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote:
> > > On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote:
> > >> On Mon, May 23, 2016 at 12:10 PM, Tom Lane
Great question, Marko. If you can point me towards an example I'll take a
look, but I'll proceed with the current understanding and suggestions and
see what people have to say.
On Mon, May 23, 2016 at 10:47 AM, Marko Tiikkaja wrote:
> On 2016-05-23 18:55, Peter van Hardenberg wrote:
>
>> I talke
Merlin Moncure writes:
> On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote:
>> On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote:
>>> +1 on removing LCM.
>> As a green field project, that would make total sense. As a thing
>> decades in, it's not clear to me that that would break
On Mon, May 23, 2016 at 02:39:54PM -0500, Merlin Moncure wrote:
> On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote:
> > On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote:
> >> On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote:
> >> > Andres Freund writes:
> >> >> discussing execut
On 05/23/2016 12:39 PM, Merlin Moncure wrote:
> On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote:
>> On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote:
>>> On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote:
Andres Freund writes:
> discussing executor performance with a nu
Peter Geoghegan writes:
> On Mon, May 23, 2016 at 12:22 PM, Tom Lane wrote:
>> It seems unlikely to me that recursing into the name lists is helpful
>> here: those are not going to contain any data that is interpretable
>> without context. Did you have a reason to do that?
> I saw no reason to
On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote:
> On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote:
>> On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote:
>> > Andres Freund writes:
>> >> discussing executor performance with a number of people at pgcon,
>> >> several hackers - m
On Mon, May 23, 2016 at 12:22 PM, Tom Lane wrote:
> It seems unlikely to me that recursing into the name lists is helpful
> here: those are not going to contain any data that is interpretable
> without context. Did you have a reason to do that?
I saw no reason to avoid the extra cycles. A notice
Peter Geoghegan writes:
> Attached patch fixes this issue by adding the appropriate
> raw_expression_tree_walker handler. This isn't the first quasi-utility
> node to need such a handler, so the fix is simple.
It seems unlikely to me that recursing into the name lists is helpful
here: those are n
On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote:
> On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote:
> > Andres Freund writes:
> >> discussing executor performance with a number of people at pgcon,
> >> several hackers - me included - complained about the additional
> >> complexity
On Sat, May 21, 2016 at 5:03 PM, Peter Geoghegan wrote:
> On Sat, May 21, 2016 at 4:28 PM, wrote:
>> ERROR: XX000: unrecognized node type: 920
>> LOCATION: raw_expression_tree_walker, nodeFuncs.c:3410
>>
>> I expected the query run successfully and return one row with 'a'.
>
> This is clearly
On Mon, May 23, 2016 at 1:44 PM, David Fetter wrote:
> On Mon, May 23, 2016 at 01:36:57PM -0400, Tom Lane wrote:
> > David Fetter writes:
> > > On Mon, May 23, 2016 at 01:10:29PM -0400, Tom Lane wrote:
> > >> This seems a bridge too far to me. It's just way too common to do
> > >> "select gener
Marko Tiikkaja writes:
> On 2016-05-23 18:55, Peter van Hardenberg wrote:
>> Anyone have any concerns or suggestions?
> What about cases like json_whatever($1) which previously worked but
> will now be ambiguous? (Or will they somehow not be ambiguous?)
Good point, that would have to be look
On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote:
> Andres Freund writes:
>> discussing executor performance with a number of people at pgcon,
>> several hackers - me included - complained about the additional
>> complexity, both code and runtime, required to handle SRFs in the target
>> list.
>
David Fetter writes:
> On Mon, May 23, 2016 at 01:36:57PM -0400, Tom Lane wrote:
>> David Fetter writes:
>>> How about making "TABLE generate_series(1,n)" work? It's even
>>> shorter in exchange for some cognitive load.
>> No thanks --- the word after TABLE ought to be a table name, not some
>>
David Rowley writes:
> On 20 May 2016 at 19:13, Hao Lee wrote:
>> Today, I am do some works on adding some customized featues to PostgreSQL
>> 9.6 beta1. But, when i do some output to psql using the fuction
>> "do_text_output_multiline" with the string just like mentioned in mail
>> tilte, suc
On 2016-05-23 18:55, Peter van Hardenberg wrote:
I talked this over with Andrew who had no objections and suggested I float
it on the list before writing a patch. Looks pretty straightforward, just a
few new data rows in pg_proc.h.
Anyone have any concerns or suggestions?
What about cases like
I wrote:
>> ... the pg_dump process has crashed with a SIGPIPE without printing
>> any message whatsoever, and without coming anywhere near finishing the
>> dump.
> Attached is a proposed patch for this. It reverts exit_horribly() to
> what it used to be pre-9.3, ie just print the message on stde
On Mon, May 23, 2016 at 01:36:57PM -0400, Tom Lane wrote:
> David Fetter writes:
> > On Mon, May 23, 2016 at 01:10:29PM -0400, Tom Lane wrote:
> >> This seems a bridge too far to me. It's just way too common to do
> >> "select generate_series(1,n)". We could tell people they have to
> >> rewrite
David Fetter writes:
> On Mon, May 23, 2016 at 01:10:29PM -0400, Tom Lane wrote:
>> This seems a bridge too far to me. It's just way too common to do
>> "select generate_series(1,n)". We could tell people they have to
>> rewrite to "select * from generate_series(1,n)", but it would be far
>> mor
On Mon, May 23, 2016 at 01:10:29PM -0400, Tom Lane wrote:
> This seems a bridge too far to me. It's just way too common to do
> "select generate_series(1,n)". We could tell people they have to
> rewrite to "select * from generate_series(1,n)", but it would be far
> more polite to do that for them
Peter van Hardenberg writes:
> I talked this over with Andrew who had no objections and suggested I float
> it on the list before writing a patch. Looks pretty straightforward, just a
> few new data rows in pg_proc.h.
I think you might find that you need to add new C function entry points to
keep
On Mon, May 23, 2016 at 11:14 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, May 23, 2016 at 12:55 PM, Peter van Hardenberg wrote:
>
>> Hi there,
>>
>> I noticed it was very easy to accidentally call the json_* form of JSON
>> manipulation functions with jsonb data as input.
Alvaro Herrera writes:
> Tom Lane wrote:
>> You'd have to alter the index opfamily to disconnect the function from it,
>> drop/recreate the function, then re-add it to the opfamily. Kind of icky,
>> but probably better than the alternatives.
> What happens if the upgraded database contains index
On Mon, May 23, 2016 at 12:55 PM, Peter van Hardenberg wrote:
> Hi there,
>
> I noticed it was very easy to accidentally call the json_* form of JSON
> manipulation functions with jsonb data as input. This is pretty
> sub-optimal, since it involves rendering the jsonb then reparsing it and
> call
Hi there,
I noticed it was very easy to accidentally call the json_* form of JSON
manipulation functions with jsonb data as input. This is pretty
sub-optimal, since it involves rendering the jsonb then reparsing it and
calling the json_* form of the function.
Fortunately, this seems quite easy to
Andres Freund writes:
> discussing executor performance with a number of people at pgcon,
> several hackers - me included - complained about the additional
> complexity, both code and runtime, required to handle SRFs in the target
> list.
Yeah, this has been an annoyance for a long time.
> One i
Tom Lane wrote:
> Michael Paquier writes:
> > On Sat, May 21, 2016 at 6:16 PM, Andreas Karlsson wrote:
> >> My immediate thought is first doing an UPDATE of pg_proc and then updating
> >> the catcache with CREATE OR REPLACE with the new arguments. Does that work?
> >> Is there a less ugly way to
On Mon, May 23, 2016 at 12:01 PM, Jeff Davis wrote:
> On Fri, May 20, 2016 at 1:41 PM, David G. Johnston
> wrote:
> > How does the relatively new FILTER clause play into this, if at all?
>
> My interpretation of the standard is that FILTER is not allowable for
> a window function, and IGNORE|RES
Michael Paquier writes:
> On Fri, Sep 11, 2015 at 11:29 AM, Robert Haas wrote:
>> On Wed, Sep 9, 2015 at 3:00 PM, Tom Lane wrote:
>>> The specific reason there's a problem is that there's a disconnect between
>>> RelationClearRelation's test for whether a relcache entry has valid index
>>> info
Andreas Seltenreich wrote:
> There was one instance of this PANIC when testing with the regression db
> of master at 50e5315.
>
> ,
> | WARNING: specified item offset is too large
> | PANIC: failed to add BRIN tuple
> | server closed the connection unexpectedly
> `
>
> It is reproducibl
Michael Paquier writes:
> On Sat, May 21, 2016 at 6:16 PM, Andreas Karlsson wrote:
>> My immediate thought is first doing an UPDATE of pg_proc and then updating
>> the catcache with CREATE OR REPLACE with the new arguments. Does that work?
>> Is there a less ugly way to accomplish this?
> Isn't
On Mon, May 23, 2016 at 10:21 AM, Jim Nasby wrote:
> On 5/22/16 1:37 AM, Jan Johansson wrote:
>>
>> - Allow single (behavior) inheritance (model here is quite a few modern
>> languages, such as C#, D, ...)
>> - Allow multiple declarative inheritance (interface like, the
>> inheritance almost wor
On Fri, May 20, 2016 at 1:41 PM, David G. Johnston
wrote:
> How does the relatively new FILTER clause play into this, if at all?
My interpretation of the standard is that FILTER is not allowable for
a window function, and IGNORE|RESPECT NULLS is not allowable for an
ordinary aggregate.
So if we
On Mon, May 23, 2016 at 8:50 AM, Andres Freund wrote:
> On 2016-05-23 17:19:09 +0800, Craig Ringer wrote:
>> Following on from the foreign table batch inserts thread[1], here's a patch
>> to add support for pipelining queries into asynchronous batches in libpq.
>
> Yay!
>> I'm measuring 300x (not
Hi,
On 2016-05-23 17:19:09 +0800, Craig Ringer wrote:
> Hi all
> Following on from the foreign table batch inserts thread[1], here's a patch
> to add support for pipelining queries into asynchronous batches in libpq.
Yay!
> I'm measuring 300x (not %) performance improvements doing batches on
>
On 5/22/16 1:37 AM, Jan Johansson wrote:
- Allow single (behavior) inheritance (model here is quite a few modern
languages, such as C#, D, ...)
- Allow multiple declarative inheritance (interface like, the
inheritance almost works like this today though)
If, with these restrictions (or maybe o
Amit Kapila writes:
> Earlier problems were due to the reason that some unsafe/restricted
> expressions were pushed below Gather node as part of target list whereas in
> the plan6, it seems some unsafe node is pushed below Gather node. It will
> be helpful if you can share the offending query?
pl
On Mon, May 23, 2016 at 2:19 PM, Andreas Seltenreich
wrote:
>
> I wrote:
> >> There's another class of parallel worker core dumps when testing master
> >> with sqlsmith. In these cases, the following assertion fails for all
> >> workers simulataneously:
> >>
> >> TRAP: FailedAssertion("!(mqh->mqh
On 20 May 2016 at 23:18, Craig Ringer wrote:
> On 20 May 2016 at 15:35, Craig Ringer wrote:
>
>
>>
>> You can, however, omit Sync from between messages and send a series of
>> protocol messages, like
>>
>> Parse/Bind/Execute/Bind/Execute/Bind/Execute/Sync
>>
>> to avoid round-trip overheads.
>>
Hi all
Following on from the foreign table batch inserts thread[1], here's a patch
to add support for pipelining queries into asynchronous batches in libpq.
Attached, and also available at
https://github.com/2ndQuadrant/postgres/tree/dev/libpq-async-batch (subject
to rebasing and force pushes).
I wrote:
>> There's another class of parallel worker core dumps when testing master
>> with sqlsmith. In these cases, the following assertion fails for all
>> workers simulataneously:
>>
>> TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File:
>> "shm_mq.c", Line: 386)
>
> I no longe
84 matches
Mail list logo
