>
> > After further thought, I wonder whether instead of having an incoming
> > listener initialize its "pos" to QUEUE_TAIL, we couldn't have it
> > initialize to the maximum "pos" among existing listeners (with a floor of
> > QUEUE_TAIL of course). If any other listener has advanced over a
On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote:
> Matt Newell <newe...@blur.com> writes:
> > 1. When a connection issues it's first LISTEN command, in
> > Exec_ListenPreCommit QUEUE_BACKEND_POS(MyBackendId) = QUEUE_TAIL;
> > this causes the connection to i
On Tuesday, September 29, 2015 09:58:35 PM Tom Lane wrote:
> Matt Newell <newe...@blur.com> writes:
> > On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote:
> >> Possibly. sinval catchup notification works like that, so you could
> >> maybe
> >> inve
d most
likely end up staying very small. If the backend local list does grow too
large then the connection could be killed or handled in some other appropriate
way.
I am happy to attempt coming up with a patch if the ideas are deemed
worthwhile.
Thanks,
Matt Newell
--
Sent via p
the guarantee that a PGquery
won't be reused twice in a row should be sufficient, and the only alternative
is
to add a unique id, but that will add further complexity that I don't think is
warranted.
Feedback is very welcome and appreciated.
Thanks,
Matt Newell
diff --git a/doc/src/sgml/libpq.sgml b
unnecessary complexity and might also make
it easy for users to never retrieve and free some results.
There are probably plenty of other wrinkly bits to think about.
Yup, I'm sure i'm still missing some significant things at this point...
Matt Newell
/*
* src/test/examples/testlibpqpipeline2
On Thursday, December 04, 2014 04:30:27 PM Claudio Freire wrote:
On Thu, Dec 4, 2014 at 4:11 PM, Matt Newell newe...@blur.com wrote:
With the API i am proposing, only 2 new functions (PQgetFirstQuery,
PQgetLastQuery) are required to be able to match each result to the query
that caused
On Thursday, December 04, 2014 11:39:02 PM Heikki Linnakangas wrote:
Adding the ability to set a user supplied pointer on the PGquery struct
might make it much easier for some frameworks, and other users might want
a callback, but I don't think either are required.
I don't like exposing
)
checkResult(conn,result,curQuery,PGRES_FATAL_ERROR);
if (curQuery == query3)
checkResult(conn,result,curQuery,PGRES_TUPLES_OK);
}
Note that the curQuery == queryX check will work no matter how many results a
query produces.
Matt Newell
--
Sent via
instead of a sync per PQsendQuery will be needed. That could make things
tricky though with multi-statement queries, because currently the only way to
detect when results change from one query to the next are a ReadyForQuery
message.
Matt Newell
/*
* src/test/examples/testlibpqpipeline.c
On Thursday 10 November 2005 15:58, you wrote:
The multi-table-unique-constraint problem has to
be solved before we can even think much about multi-table FKs :-(
Do you have ideas about how this should be solved?
There's some discussions in the pghackers archives --- look for
On Friday 11 November 2005 11:07, you wrote:
It's an idea, but you are now staring directly into the hornet's nest:
1. How do you avoid deadlock among multiple processes all doing the
above for similar (same page anyway) keys? It's difficult if not
impossible to ensure that they'll
12 matches
Mail list logo
