Hi all
Currently the client must know the size of a large lob/clob field, like
a 'bytea' or 'text' field, in order to send it to the server. This can
force the client to buffer all the data before sending it to the server.
It would be helpful if the v4 protocol permitted the client to specify
the
On 24 November 2014 11:29, Amit Kapila Wrote,
>I think still some of the comments given upthread are not handled:
>
>a. About cancel handling
Your Actual comment was -->
>One other related point is that I think still cancel handling mechanism
>is not completely right, code is doing that when th
On 11/10/14, 7:52 PM, Tom Lane wrote:
On the whole, I'm +1 for just logging the events and seeing what we learn
that way. That seems like an appropriate amount of effort for finding out
whether there is really an issue.
Attached is a patch that does this.
--
Jim Nasby, Data Architect, Blue Tre
On Mon, Nov 17, 2014 at 11:39 PM, Jeff Davis wrote:
> I can also just move isReset there, and keep mem_allocated as a uint64.
> That way, if I find later that I want to track the aggregated value for
> the child contexts as well, I can split it into two uint32s. I'll hold
> off any any such optimi
Alvaro Herrera writes:
> Tom Lane wrote:
>> All of the MSVC critters are failing at "make check".
> Yeah, I noticed that, thanks. As far as I can see the only way to fix
> it is to install dummy_seclabel to run the core seclabel test. That
> doesn't seem smart; I think it'd be better to remove
On Tue, Nov 25, 2014 at 4:13 PM, Peter Geoghegan wrote:
> If I don't hear anything in the next day or two,
> I'll more or less preserve aliases-related aspects of the patch.
FYI, I didn't go ahead and work on this, because I thought that the
thanksgiving holiday in the US probably kept you from g
Emre Hasegeli writes:
>> Thanks. Overall, my impression of this patch is that it works very
>> well. But damned if I understood *how* it works :-). There's a lot
>> of statistics involved, and it's not easy to see why something is
>> multiplied by something else. I'm adding comments as I read thro
Tom Lane wrote:
> All of the MSVC critters are failing at "make check".
Yeah, I noticed that, thanks. As far as I can see the only way to fix
it is to install dummy_seclabel to run the core seclabel test. That
doesn't seem smart; I think it'd be better to remove that part of the
core seclabel te
On Tue, Nov 25, 2014 at 4:01 AM, Robert Haas wrote:
> There's a lot of stuff in this patch I'm still trying to digest
I spotted a bug in the most recent revision. Mea culpa.
I think that the new field Tuplesortstate.abbrevNext should be an
int64, not an int. The fact that Tuplesortstate.memtupco
This fixes a missing space here:
http://www.postgresql.org/docs/devel/static/wal-reliability.html
(present in 9.3 onwards).
Regards
Ian Barwick
--
Ian Barwick http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/doc/src/sgml
I'm curious to know what the expected behavior is for an insert / update
conflict on a primary key field.
The wiki suggested "divergence conflicts" would be logged and replication
would halt for the downstream master. There is a case where the databases
"diverge" such that they are no longer cons
On 11/30/2014 04:31 PM, Tom Lane wrote:
Andrew Dunstan writes:
OK, here's the patch.
Can we make IsValidJsonNumber() take a "const char *"? Also its
comment should specify that it doesn't require nul-terminated
input, if indeed it doesn't. Otherwise +1.
Then I h
Andrew Dunstan writes:
> OK, here's the patch.
Can we make IsValidJsonNumber() take a "const char *"? Also its
comment should specify that it doesn't require nul-terminated
input, if indeed it doesn't. Otherwise +1.
regards, tom lane
--
Sent via pgsql-hackers mailing
On 11/30/2014 11:45 AM, Tom Lane wrote:
Andrew Dunstan writes:
what do you want to do about this? In the back branches, exposing a
function like this would be an API change, wouldn't it? Perhaps there we
just need to pick up the 100 lines or so involved from json.c and copy
them into hstore_io
On 1 December 2014 at 06:51, Tom Lane wrote:
> David Rowley writes:
> > I see this is quite a fundamental change to how things currently work and
> > it could cause planning to take place during the execution of PREPAREd
> > statements, which might not impress people too much, but it would
> cer
Hi Craig
Is there agreement on proposed syntax ROW(x AS something, y AS
somethingelse) ?
I can start work on this topic this week.
Regards
Pavel
2014-11-25 2:33 GMT+01:00 Craig Ringer :
>
>
> > ROW(x AS something, y AS somethingelse)
>
> Apologies, it looks like Pavel already bought this
David Rowley writes:
> I see this is quite a fundamental change to how things currently work and
> it could cause planning to take place during the execution of PREPAREd
> statements, which might not impress people too much, but it would certainly
> fix the weird anomalies that I'm currently facin
Andrew Dunstan writes:
> what do you want to do about this? In the back branches, exposing a
> function like this would be an API change, wouldn't it? Perhaps there we
> just need to pick up the 100 lines or so involved from json.c and copy
> them into hstore_io.c, suitably modified. In the dev
On 11/26/2014 11:48 AM, Andrew Dunstan wrote:
On 11/26/2014 11:19 AM, Tom Lane wrote:
bo...@edookit.com writes:
The hstore_to_json_loose(hstore) produces an invalid JSON in the
following
case:
SELECT hstore_to_json_loose(hstore(ARRAY ['name'], ARRAY ['1.'] :: TEXT
[]))
Output: {"name": 1.}
T
On 30 November 2014 at 23:19, Mart Kelder wrote:
>
> I think performance can be greatly improved if the planner is able to use
> information based on the current data. I think these patches are just two
> examples of where assumptions during planning are usefull. I think there
> are
> more possib
Hi David (and others),
David Rowley wrote:
> Hi,
>
> Starting a new thread which continues on from
> http://www.postgresql.org/message-id/caaphdvoec8ygwoahvsri-84en2k0tnh6gpxp1k59y9juc1w...@mail.gmail.com
>
> To give a brief summary for any new readers:
>
> The attached patch allows for INNER J
21 matches
Mail list logo
