On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Well, not *everything*
Hi Tom,
On Sat, Jul 13, 2013 at 10:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
Following example does not work as expected:
-- Should return TRUE but returning FALSE
SELECT 'Programmer' ~ '(\w).*?\1' as t;
This is clearly
On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Yes, what I know almost all use utf8 without problems. Long time I didn't
see any request for multi encoding support.
Well, not
On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
pavel.steh...@gmail.com wrote:
Yes, what I know almost all use utf8 without problems. Long time I
didn't see any request for multi encoding support.
Well, not *everything* can be represented as UTF-8; I think this is
particularly an issue
On Mon, Jul 15, 2013 at 8:58 AM, Tatsuo Ishii is...@postgresql.org wrote:
Also I don't understand why you need UTF-16 support as a database
encoding because UTF-8 and UTF-16 are logically equivalent, they are
just different represention (encoding) of Unicode. That means if we
already support
On 2013-07-14 23:49:47 -0400, Robert Haas wrote:
On Fri, Jul 5, 2013 at 4:27 PM, Markus Wanner mar...@bluegap.ch wrote:
One way to resolve that - and that seems to be the direction Dimitri's
patch is going - is to make the extension depend on its template. (And
thereby breaking the mental
Robert,
thanks for answering. I think you responded to the (or some) idea in
general, as I didn't see any relation to the quoted part. (Otherwise
this is a hint that I've not been clear enough.)
On 07/15/2013 05:49 AM, Robert Haas wrote (in a slightly different order):
There is a lot of
On 2013-07-15 12:12:36 +0200, Markus Wanner wrote:
Granted, the internalization of the DSO is somewhat critical to
implement. Running as a non-root user, Postgres has less power than that
and can certainly not protect the internalized DSO from modification by
root. It can, however, store the
On 07/15/2013 12:05 PM, Andres Freund wrote:
A superuser can execute native code as postges user. That's it.
Oh, I though Robert meant postgres users, i.e. non-superusers.
I hereby withdraw my pitchforks: I'm certainly not opposing to simplify
the life of superusers, who already have the power.
On 2013-07-15 12:20:15 +0200, Markus Wanner wrote:
On 07/15/2013 12:05 PM, Andres Freund wrote:
A superuser can execute native code as postges user. That's it.
Oh, I though Robert meant postgres users, i.e. non-superusers.
Oh, I am talking about *postgres* superusers ;). The example
On 07/15/2013 12:19 PM, Andres Freund wrote:
On 2013-07-15 12:12:36 +0200, Markus Wanner wrote:
Granted, the internalization of the DSO is somewhat critical to
implement. Running as a non-root user, Postgres has less power than that
and can certainly not protect the internalized DSO from
On Wed, Jul 3, 2013 at 5:16 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote:
2013/7/2 Noah Misch n...@leadboat.com:
Here's a revision bearing the discussed name changes and protocol
documentation tweaks, along with some cosmetic
On 2013-07-15 16:34:07 +0400, ivan babrou wrote:
Is there any hope to see it in libpq? If so, can anyone review latest
version of my patch?
A littlebit of patience please. There are heaps of other patches still
being reviewed that have been posted earlier than yours ;). I know it
can be
On 9 July 2013 08:57, Fabien COELHO coe...@cri.ensmp.fr wrote:
I cannot apply the patch, it seems to be truncated:
Hi Fabien,
Please find attached the updated patch.
It seems the only difference between v5 and v6 is probably a newline at the
end (Line 291 was the last line), in fact meld
Hi Fabien,
Please find attached the updated patch.
It seems the only difference between v5 and v6 is probably a newline at the
end (Line 291 was the last line), in fact meld doesn't even show anything.
I'll try to be more careful though.
git reset --hard HEAD
git pull
patch -p1
On 9 July 2013 08:41, Fabien COELHO coe...@cri.ensmp.fr wrote:
I do not see any difference between both regress_sequence_v[45].patch**.
I guess you sent the earlier version.
Thanks Fabien. This was a wrong attachment to the email.
Please find attached the updated patch (I've renamed v5 as v6
Robert,
On 07/15/2013 12:12 PM, Markus Wanner wrote:
On 07/15/2013 05:49 AM, Robert Haas wrote (in a slightly different order):
There is a lot of
(well-founded, IMHO) resistance to the idea of letting users install C
code via an SQL connection.
Nowhere did I propose anything close to that.
ToDo
1. currently this patch supports synchronous transfer. so we can't set
different synchronous transfer mode to each server.
we need to improve the patch for support following cases.
- SYNC standby and make separate ASYNC failback safe standby
- ASYNC standby and make separate
On Sun, Jul 7, 2013 at 9:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 3 January 2012 18:42, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Another point that requires some thought is that switching SnapshotNow
to be MVCC-based will presumably result in a noticeable increase in each
On 6 July 2013 20:25, Robins Tharakan thara...@gmail.com wrote:
Do let me know your view on this second point, so that I can remove these
tests if so required.
Hi,
Please find attached the updated patch.
It address the first issue regarding reducing the repeated CREATE / DROP
ROLEs.
It
On 2013-07-15 10:06:31 -0400, Robert Haas wrote:
Noah discovered an interesting one recently: apparently, the relcache
machinery has some logic in it that depends on the use of
AccessExclusiveLock in subtle ways. I'm going to attempt to explain
it, and maybe he can jump in and explain it
On Sun, Jul 7, 2013 at 9:30 AM, Josh Kupershmidt schmi...@gmail.com wrote:
On Mon, Nov 12, 2012 at 5:14 PM, Andrew Dunstan and...@dunslane.net wrote:
vacuumlo is rather simpleminded about dealing with the list of LOs to be
removed - it just fetches them as a straight resultset. For one of my
On 7/15/13 1:26 AM, Arulappan, Arul Shaji wrote:
Yes, the idea is that users will be able to declare columns of type
NCHAR or NVARCHAR which will use the pre-determined encoding type. If we
say that NCHAR is UTF-8 then the NCHAR column will be of UTF-8 encoding
irrespective of the database
On Sun, Jul 7, 2013 at 10:35 AM, Robins Tharakan thara...@gmail.com wrote:
On 26 June 2013 01:55, Robins Tharakan thara...@gmail.com wrote:
Code coverage improved from 36% to 68%.
Updated patch:
- Renamed ROLEs as per Robert's feedback (prepend regress_xxx)
- Added test to serial_schedule
On Mon, Jul 15, 2013 at 10:32 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-15 10:06:31 -0400, Robert Haas wrote:
Noah discovered an interesting one recently: apparently, the relcache
machinery has some logic in it that depends on the use of
AccessExclusiveLock in subtle ways.
On Mon, Jul 15, 2013 at 10:23 AM, Robins Tharakan thara...@gmail.com wrote:
It still doesn't address the excessive (syntactical) checks tough. I am
still unclear as to how to identify which checks to skip. (As in, although I
have a personal preference of checking everything, my question
I simply don't understand how we can be getting any meaningful test
coverage out of those cases. I mean, if we want to check every bit of
syntax that could lead to a syntax error, we could probably come up
with a near-infinite number of test cases:
I think that it would be enough to check
On 10 Jul 2013, at 19:26, Josh Berkus j...@agliodbs.com wrote:
Huh? LISTEN/NOTIFY across replication has been a desired feature since
we introduced streaming replication. We want it, there's just no
obvious way to do it.
Your email kinda implies that it's not desirable.
Thanks Josh.
Is there any hope to see it in libpq? If so, can anyone review latest
version of my patch?
On 10 July 2013 11:49, ivan babrou ibob...@gmail.com wrote:
On 9 July 2013 18:43, Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-05 21:28:59 +0400, ivan babrou wrote:
Hi, guys! I made a quick
On Sun, Jul 7, 2013 at 12:17 PM, Robins Tharakan thara...@gmail.com wrote:
Updated the patch:
- Updated ROLEs as per Robert's feedback
You managed to use a naming convention different from the one that you
used before. Before, you had regress_rol_op1; here, you've got
regress_lock_rol1.
On Mon, Jul 15, 2013 at 11:48 AM, Fabien COELHO coe...@cri.ensmp.fr wrote:
I simply don't understand how we can be getting any meaningful test
coverage out of those cases. I mean, if we want to check every bit of
syntax that could lead to a syntax error, we could probably come up
with a
On 15 July 2013 15:06, Robert Haas robertmh...@gmail.com wrote:
Generally, the question on the table is: to what extent do MVCC
catalog scans make the world safe for concurrent DDL, or put
negatively, what hazards remain?
On Tom's test I've been unable to find a single problem.
Noah
To clarify what state this is all in: Fabien's latest
pgbench-throttle-v15.patch is the ready for a committer version. The
last two revisions are just tweaking the comments at this point, and his
version is more correct than my last one.
My little pgbench-delay-finish-v1.patch is a brand
On Thu, 2013-07-11 at 10:51 -0400, Nicholas White wrote:
I've attached a revised version that fixes the issues above:
I'll get to this soon, sorry for the delay.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sun, Jul 7, 2013 at 1:15 PM, Robins Tharakan thara...@gmail.com wrote:
Updated the patch:
- Updated ROLE names as per Robert's feedback (regress_xxx)
- Added test to serial_schedule
Please see my comments on the LOCK tests related to these points and
update accordingly.
+BEGIN TRANSACTION;
On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Ok, I've committed this patch now. Finally, phew!
I found that this patch causes the assertion failure. When I set up simple
replication environment and promoted the standby before executing any
transaction on the
On Fri, Jul 12, 2013 at 5:42 AM, Andres Freund and...@2ndquadrant.com wrote:
I'd like to add an Assert like in the attached patch making sure we're
in a transaction. Otherwise it's far too easy not to hit an error during
development because everything is cached - and syscache usage isn't
On Sun, 2013-07-14 at 23:06 -0400, Robert Haas wrote:
Of course, there's a reason that PD_ALL_VISIBLE is not like a normal
hint: we need to make sure that inserts/updates/deletes clear the VM
bit. But my patch already addresses that by keeping the VM page pinned.
I'm of the opinion that
On Mon, Jul 15, 2013 at 10:43 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Friday, July 12, 2013 6:46 PM Amit kapila wrote:
On Friday, July 12, 2013 12:02 AM Fujii Masao wrote:
On Fri, Jul 5, 2013 at 2:19 PM, Amit Kapila amit.kap...@huawei.com
wrote:
On Wednesday, July 03, 2013 2:58 AM
On Wed, Jul 10, 2013 at 11:28 AM, Josh Kupershmidt schmi...@gmail.com wrote:
Is there any reason not to tab-complete the local filename used by the
\lo_import command? Small patch to do so attached.
Looks good to me. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On Sun, Jul 14, 2013 at 10:15:12PM -0400, Noah Misch wrote:
On Sun, Jul 07, 2013 at 06:37:26PM -0700, David Fetter wrote:
On Sat, Jul 06, 2013 at 11:49:21AM +0100, Dean Rasheed wrote:
Overall I think this patch offers useful additional functionality, in
compliance with the SQL spec, which
np, optimising for quality not speed :)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Noah Misch said:
I twitched upon reading this, because neither ORDER BY nor FILTER preclude
the aggregate being MIN or MAX. Perhaps Andrew can explain why he put
aggorder there back in 2009.
The bottom line is that I intentionally avoided assuming that an agg with an
aggsortop could only be
* ISTM that the impact of the chosen 1000 should appear somewhere.
I don't have a problem with that, but I didn't see that the little table you
included was enough to do that. I think if someone knows how this type of
random generation works, they don't need the comment to analyze the
On 07/14/2013 12:28 AM, Pavel Stehule wrote:
Hello
2013/7/14 Andrew Dunstan and...@dunslane.net:
On 06/29/2013 03:29 PM, Pavel Stehule wrote:
5. This patch has user visibility, i.e. now we are throwing an error
when
user only says VARIADIC NULL like:
select concat(variadic NULL) is
Xi Wang escribió:
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a vulnerable binary.
This thread died without reaching a conclusion. Noah Misch, Robert Haas
and Greg Stark
On Mon, Jul 15, 2013 at 06:56:17PM +, Andrew Gierth wrote:
Noah Misch said:
I twitched upon reading this, because neither ORDER BY nor FILTER preclude
the aggregate being MIN or MAX. Perhaps Andrew can explain why he put
aggorder there back in 2009.
The bottom line is that I
On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Xi Wang escribió:
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a vulnerable binary.
This
Robert Haas escribió:
On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Xi Wang escribió:
Intel's icc and PathScale's pathcc compilers optimize away several
overflow checks, since they consider signed integer overflow as
undefined behavior. This leads to a
On Sat, Jul 6, 2013 at 11:49 PM, Robins Tharakan thara...@gmail.com wrote:
Thanks Fabrizio.
Although parallel_schedule was a miss for this specific patch, however, I
guess I seem to have missed out serial_schedule completely (in all patches)
and then thanks for pointing this out. Subsequently
On Mon, Jul 15, 2013 at 9:27 AM, Markus Wanner mar...@bluegap.ch wrote:
To clarify: In the above agreement, I had the Postgres level ordinary
users in mind, who certainly shouldn't ever be able to upload and run
arbitrary native code.
I'm not quite as enthusiastic if you meant the system
In 9af4159f in combination with cb9b66d3 a bunch of error messages were
changed from something like
SELECT FOR UPDATE/SHARE is not allowed with UNION/INTERSECT/EXCEPT
to
row-level locks are not allowed with UNION/INTERSECT/EXCEPT
because the intermediate state of
SELECT FOR UPDATE/SHARE/KEY
On Monday, July 15, 2013 11:51 PM Fujii Masao wrote:
On Mon, Jul 15, 2013 at 10:43 PM, Amit Kapila amit.kap...@huawei.com wrote:
On Friday, July 12, 2013 6:46 PM Amit kapila wrote:
On Friday, July 12, 2013 12:02 AM Fujii Masao wrote:
On Fri, Jul 5, 2013 at 2:19 PM, Amit Kapila
Hello Satoshi,
I assigned myself for the reviewer of this patch. Issue status is waiting on
author.
Now looking at the discussion under the thread it seems like we are waiting
for the suggestion for the new function name, right ?
I am wondering why actually we need new name ? Can't we just
54 matches
Mail list logo
