I'm getting errors while executing "make dist" on git master head.
$ make dist
make dist
rm -rf postgresql-9.4devel* =install=
for x in `cd . && find . \( -name CVS -prune \) -o \( -name .git -prune \) -o
-print`; do \
file=`expr X$x : 'X\./\(.*\)'`; \
if test -d "./$file" ; t
Hi Rushabh,
(2013/07/16 14:58), Rushabh Lathia wrote:
Hello Satoshi,
I assigned myself for the reviewer of this patch. Issue status is waiting on
author.
Thank you for picking it up.
Now looking at the discussion under the thread it seems like we are waiting
for the suggestion for the new f
(2013/07/04 3:58), Fujii Masao wrote:
> On Wed, Jun 26, 2013 at 12:39 AM, Robert Haas wrote:
>> On Thu, Jun 20, 2013 at 2:32 PM, Fujii Masao wrote:
>>> Since pg_relpages(oid) doesn't exist, pg_relpages() is in the same
>>> situation as pgstatindex(), i.e., we cannot just replace pg_relpages(text)
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 overl
On Monday, July 15, 2013 11:51 PM Fujii Masao wrote:
On Mon, Jul 15, 2013 at 10:43 PM, Amit Kapila 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
>> wrote:
>> > On Wednesday, July
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/K
On Mon, Jul 15, 2013 at 9:27 AM, Markus Wanner 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 level user that
>
On Sat, Jul 6, 2013 at 11:49 PM, Robins Tharakan 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 Robert too no
Robert Haas escribió:
> On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
> 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 b
On Mon, Jul 15, 2013 at 5:59 PM, Alvaro Herrera
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 thread died withou
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 tha
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 07/14/2013 12:28 AM, Pavel Stehule wrote:
Hello
2013/7/14 Andrew Dunstan :
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 NULL;
Previously
* 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 impac
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 b
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
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 spe
On Wed, Jul 10, 2013 at 11:28 AM, Josh Kupershmidt 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 Enterprise PostgreSQ
On Mon, Jul 15, 2013 at 10:43 PM, Amit Kapila 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
>> wrote:
>> > On Wednesday, July 03, 2013 2:58 AM Alvaro Herrera wrote:
>> >> Amit Kap
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
On Fri, Jul 12, 2013 at 5:42 AM, Andres Freund 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
> always obvious from the
On Mon, Jul 8, 2013 at 6:16 PM, Heikki Linnakangas
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 master, I got the follo
On Sun, Jul 7, 2013 at 1:15 PM, Robins Tharakan 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;
+INVALID_COMMAN
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 subscr
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 new
On 15 July 2013 15:06, Robert Haas 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 discovered an interesting
On Mon, Jul 15, 2013 at 11:48 AM, Fabien COELHO 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 near-infinite num
On Sun, Jul 7, 2013 at 12:17 PM, Robins Tharakan 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. Consistency may be the
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 wrote:
> On 9 July 2013 18:43, Andres Freund wrote:
>> On 2013-07-05 21:28:59 +0400, ivan babrou wrote:
>>> Hi, guys! I made a quick patch to support floating number in
>
On 10 Jul 2013, at 19:26, Josh Berkus 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. I was unde
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 for
On Mon, Jul 15, 2013 at 10:23 AM, Robins Tharakan 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 probably
> wasn't clear
On Mon, Jul 15, 2013 at 10:32 AM, Andres Freund 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. I'm going to attem
On Sun, Jul 7, 2013 at 10:35 AM, Robins Tharakan wrote:
> On 26 June 2013 01:55, Robins Tharakan 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 (missed out earlier).
Databa
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 9:30 AM, Josh Kupershmidt wrote:
> On Mon, Nov 12, 2012 at 5:14 PM, Andrew Dunstan 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 our
>> this resulted in an out of m
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 b
On 6 July 2013 20:25, Robins Tharakan 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 still doesn't addr
On Sun, Jul 7, 2013 at 9:24 AM, Simon Riggs wrote:
> On 3 January 2012 18:42, Tom Lane 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
backend's rate of wanting to acq
> 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 separ
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
On 9 July 2013 08:41, Fabien COELHO 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 for clarity).
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 < ../regress_sche
On 9 July 2013 08:57, Fabien COELHO 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 doesn't even show anyt
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 frustr
On Wed, Jul 3, 2013 at 5:16 PM, Noah Misch wrote:
> On Wed, Jul 03, 2013 at 06:17:18AM +0200, Pavel Stehule wrote:
> > 2013/7/2 Noah Misch :
> > > Here's a revision bearing the discussed name changes and protocol
> > > documentation tweaks, along with some cosmetic adjustments. If this
> seems
>
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 fr
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 pro
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: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
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
> (well
On 2013-07-14 23:49:47 -0400, Robert Haas wrote:
> On Fri, Jul 5, 2013 at 4:27 PM, Markus Wanner 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 model of a t
On Mon, Jul 15, 2013 at 8:58 AM, Tatsuo Ishii 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 UTF-8 (I'm sure we
>> On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
> 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 with Asian l
> On Mon, Jul 15, 2013 at 4:37 AM, Robert Haas wrote:
>> On Fri, Jul 5, 2013 at 2:35 PM, Pavel Stehule
>> 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;
Hi Tom,
On Sat, Jul 13, 2013 at 10:43 PM, Tom Lane wrote:
> I wrote:
> > Jeevan Chalke writes:
> >> Following example does not work as expected:
> >>
> >> -- Should return TRUE but returning FALSE
> >> SELECT 'Programmer' ~ '(\w).*?\1' as t;
>
> > This is clearly broken, but I'm uncomfortable
56 matches
Mail list logo
