On Sat, Jan 02, 2010 at 08:21:35PM -0500, Tom Lane wrote:
3. Inefficient. It seems likely to me that filtering on the prefix on
the backend side isn't going to be more efficient than doing it on the
client side, except maybe in the schema-name cases. If the conditions
were phrased in a way
On Fri, Jan 01, 2010 at 03:31:58PM -0500, Kris Jurka wrote:
The JDBC driver does want cancel if active behavior. The JDBC API
specifies Statement.cancel() where Statement is running one particular
backend query. So it really does want to cancel just that one query.
Already this is
I tried this but didn't have any luck crashing the backend. libpq gets
tremendously confused by the extra ReadyForQuery responses, which is
unsurprising. The postmaster log shows
LOG: could not send data to client: Broken pipe
ERROR: relation foo does not exist at character 15
Andrew Dunstan wrote:
Andrew Dunstan wrote:
I think the plperl glue code should check returned strings using
pg_verifymbstr().
Please test this patch. I think we'd probably want to trap the
encoding error and issue a customised error message, but this plugs
all the holes I can see
On Sat, Jan 2, 2010 at 2:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
KaiGai Kohei kai...@kaigai.gr.jp writes:
(2009/12/30 10:38), Robert Haas wrote:
No longer applies. Can you rebase?
The attached patch is the rebased revision.
I'm not really impressed with this patch, because it will reject
On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn
On Fri, Jan 1, 2010 at 1:39 PM, Simon Riggs si...@2ndquadrant.com wrote:
Interesting. It's not obvious to me how killing an *idle* session can
resolve a deadlock. AIUI a deadlock requires a cycle in the waits-for
graph, and an idle transaction is not waiting for a lock acquisition.
In strict
Hitoshi Harada wrote:
2010/1/3 Andrew Dunstan and...@dunslane.net:
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
Why should we reinvent a wheel someone else has already
On fre, 2010-01-01 at 20:25 +0100, Magnus Hagander wrote:
The win64 port has showed that we have two sockets declared
incorrectly. They are supposed to be declared as SOCKET on win32, but
they are declared as int. See attached patch.
Given that SOCKET is actually defined as int on win32 (no
Jeff Davis wrote:
I started a wiki page here:
http://wiki.postgresql.org/wiki/Serializable
I've filled it in with all relevant information which came to mind.
If you can spot something I missed, please feel free to correct that
or let me know so that I can.
-Kevin
--
Sent via
Andrew Dunstan and...@dunslane.net writes:
One thing that I am pondering is: how does SPI handle things if the
client encoding and server encoding are not the same?
What? client_encoding is not used anywhere within the backend.
Everything should be server_encoding.
Robert Haas robertmh...@gmail.com writes:
Upthread you appeared to be endorsing what KaiGai has implemented here:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00147.php
No, I said that forbidding conflicting renames would be a good solution.
I did not endorse any specific means of
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
One thing that I am pondering is: how does SPI handle things if the
client encoding and server encoding are not the same?
What? client_encoding is not used anywhere within the backend.
Everything should be server_encoding.
On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote:
I think the minimal functionality I'd want is:
convert record to JSON
convert JSON to record
With caveats as to dealing with nested structures (can a record be an attribute
of a record?).
extract a value, or set of values, from JSON
On Jan 1, 2010, at 6:01 PM, Kevin Grittner wrote:
It's very soon going to be critical that I be able to test particular
interleavings of statements in particular concurrent transaction sets
to be able to make meaningful progress on the serializable
transaction work. It would be wonderful if
On Jan 3, 2010, at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In practice the reasonable engineering alternatives may just be to do
what KaiGai's patch does, or to do nothing. In that case I think a
good
argument can be made for the latter. Nobody has ever complained about
this from the
On Sun, Jan 3, 2010 at 17:45, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2010-01-01 at 20:25 +0100, Magnus Hagander wrote:
The win64 port has showed that we have two sockets declared
incorrectly. They are supposed to be declared as SOCKET on win32, but
they are declared as int. See
David E. Wheeler wrote:
On Jan 3, 2010, at 8:00 AM, Andrew Dunstan wrote:
I think the minimal functionality I'd want is:
convert record to JSON
convert JSON to record
With caveats as to dealing with nested structures (can a record be an attribute
of a record?).
We allow
I wrote:
I think the attached patch plugs the direct SPI holes as well.
There are two issues with this patch. First, how far if at all should it
be backpatched? All the way, or 8.3, where we tightened the encoding
rules, or not at all?
Second, It produces errors like this:
andrew=#
On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
We allow composites as fields. The biggest mismatch in the type model is
probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
AIUI.
Cool, that sounds right.
OK, but hstores are flat, unlike JSON. We need some way to
On Jan 3, 2010, at 11:54 AM, Andrew Dunstan wrote:
There are two issues with this patch. First, how far if at all should it be
backpatched? All the way, or 8.3, where we tightened the encoding rules, or
not at all?
8.3 seems reasonable.
Second, It produces errors like this:
andrew=#
Andrew Dunstan and...@dunslane.net writes:
andrew=# select 'a' || invalid_utf_seq() || 'b';
ERROR: invalid byte sequence for encoding UTF8: 0xd0
HINT: This error can also happen if the byte sequence does not
match the encoding expected by the server, which is controlled by
Andrew Dunstan and...@dunslane.net writes:
There are two issues with this patch. First, how far if at all should it
be backpatched? All the way, or 8.3, where we tightened the encoding
rules, or not at all?
Forgot to mention --- I'm not in favor of backpatching. First because
tightening
This was a random attempt to figure something out about min/max on row
types:
= select min(a) from (values (row(1,2,3)), (row(3,4,5))) as x(a);
ERROR: 42809: record type has not been registered
LOCATION: lookup_rowtype_tupdesc_internal, typcache.c:341
I don't know whether it's supposed to
David E. Wheeler wrote:
Second, It produces errors like this:
andrew=# select 'a' || invalid_utf_seq() || 'b';
ERROR: invalid byte sequence for encoding UTF8: 0xd0
HINT: This error can also happen if the byte sequence does not
match the encoding expected by the server, which is
Peter Eisentraut pete...@gmx.net writes:
This was a random attempt to figure something out about min/max on row
types:
= select min(a) from (values (row(1,2,3)), (row(3,4,5))) as x(a);
ERROR: 42809: record type has not been registered
LOCATION: lookup_rowtype_tupdesc_internal,
Bruce Momjian wrote:
pg_migrator has become more popular recently, so it seems time to look
at some enhancements that would improve pg_migrator. None of these are
required, but rather changes that would be nice to have:
1) Right now pg_migrator preserves relfilenodes for TOAST files
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
andrew=# select 'a' || invalid_utf_seq() || 'b';
ERROR: invalid byte sequence for encoding UTF8: 0xd0
HINT: This error can also happen if the byte sequence does not
match the encoding expected by the server, which
On Mon, Dec 28, 2009 at 2:52 AM, Robert Haas robertmh...@gmail.com wrote:
Hearing no thoughts, I have implemented as per the above. PFA the
latest version. Any reviews, comments, feedback, etc. much
appreciated.
btw, you need to change
STATRELATT,
for
STATRELATTINH,
in
(2010/01/04 4:06), Robert Haas wrote:
On Jan 3, 2010, at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In practice the reasonable engineering alternatives may just be to do
what KaiGai's patch does, or to do nothing. In that case I think a good
argument can be made for the latter. Nobody has
2010/1/4 David E. Wheeler da...@kineticode.com:
On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
We allow composites as fields. The biggest mismatch in the type model is
probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
AIUI.
Cool, that sounds right.
Does it
Hitoshi Harada wrote:
2010/1/4 David E. Wheeler da...@kineticode.com:
On Jan 3, 2010, at 11:40 AM, Andrew Dunstan wrote:
We allow composites as fields. The biggest mismatch in the type model is
probably w.r.t arrays. JSON arrays can be heterogenous and non-rectangular,
AIUI.
Robert Haas robertmh...@gmail.com wrote:
The attached patch verifies variable names at definition.
$ pgbench -D var:name=value
(global): invalid variable name 'var:name'
I have reviewed this patch. I think that the basic idea of rejecting
invalid variable names is probably a
Robert Haas robertmh...@gmail.com wrote:
If we want to keep backward compatibility, the issue can be fixed
by adding pg_verifymbstr() to the function.
I don't feel good about changing the return type of an existing
function, so I guess +1 from me on the approach quoted above.
Ok, I just
Robert Haas robertmh...@gmail.com wrote:
So, what is the roadmap for getting this done? It seems like to get
rid of VFI completely, we would need to implement something like what
Tom described here:
http://archives.postgresql.org/pgsql-hackers/2009-09/msg00249.php
I'm not sure whether
I wrote:
Actually, in the problematic cases, it's interesting to consider the
following strategy: when scalarineqsel notices that it's being asked for
a range estimate that's outside the current histogram bounds, first try
to obtain the actual current max() or min() of the column value ---
Robert Haas robertmh...@gmail.com wrote:
I have reviewed this patch and I think it looks pretty good. A couple
of minor nits:
- There are needless whitespace changes in the definition of struct
Counters. The changes to the existing four members should be
reverted, and the new members
Bruce,
Sorry for not having replied sooner...
On Sun, Jan 3, 2010 at 5:43 PM, Bruce Momjian br...@momjian.us wrote:
1) Right now pg_migrator preserves relfilenodes for TOAST files because
this is required for proper migration. Now that we have shown that
strategically-placed global
On Sun, Jan 3, 2010 at 10:17 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
I have reviewed this patch and I think it looks pretty good. A couple
of minor nits:
- There are needless whitespace changes in the definition of struct
On Jan 3, 2010, at 4:18 PM, Hitoshi Harada wrote:
That sounds good and seems possible, as far as operator returns JSON
always. Perhaps every JSON fetching returns JSON even if the result
would be a number. You can cast it.
% SELECT ('{foo:{bar:[a,b,c]}}' - '[foo][1]')::text;
1
On Sun, Jan 3, 2010 at 11:00 AM, Andrew Dunstan and...@dunslane.net wrote:
Hitoshi Harada wrote:
2010/1/3 Andrew Dunstan and...@dunslane.net:
Hitoshi Harada wrote:
A question: Isn't there no possibility that we have our own
implementation to handle JSON (i.e. no use of external libraries)?
On Sun, Jan 3, 2010 at 9:10 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
If we want to keep backward compatibility, the issue can be fixed
by adding pg_verifymbstr() to the function.
I don't feel good about changing the return type of
2010/1/3 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/01/04 4:06), Robert Haas wrote:
On Jan 3, 2010, at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In practice the reasonable engineering alternatives may just be to do
what KaiGai's patch does, or to do nothing. In that case I think a good
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 3, 2010 at 10:17 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
- There are needless whitespace changes in the definition of struct
Counters. The changes to the existing four members
Robert Haas robertmh...@gmail.com writes:
2010/1/3 KaiGai Kohei kai...@ak.jp.nec.com:
if (number_of_attribute_origin(myrelid, oldattname) 1)
ereport(ERROR, ...);
Am I missing something?
That sounds about right to me,
It looks remarkably inefficient to me. Do you propose to search
--- 49,63
*
*/
! #define Natts_pg_tablespace 6
Should be 5?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via
On Sun, Jan 3, 2010 at 10:39 PM, Robert Haas robertmh...@gmail.com wrote:
in syscache.c
Hmm, I see this needs to be rebased over Tom's latest changes, but the
conflict I got was in syscache.h, rather than syscache.c. Not sure if
that's what you were going for or if there's another issue.
(2010/01/04 13:18), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
2010/1/3 KaiGai Koheikai...@ak.jp.nec.com:
�if (number_of_attribute_origin(myrelid, oldattname) 1)
� � �ereport(ERROR, ...);
Am I missing something?
That sounds about right to me,
It looks remarkably
48 matches
Mail list logo
