On Sat, Feb 6, 2016 at 7:11 AM, Tom Lane wrote:
> I've done a first pass at next week's release notes; please review.
>
> Committed at
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7008e70d105b572821406744ce080771b74c06ab
> and should be visible in the website's devel-branch
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm of the opinion that this is a stop-ship bug for 9.5.1. Barring
> somebody producing a fix over the weekend, I will deal with it by
> reverting the aforementioned commit.
Agreed.
Thanks!
Stephen
signature.asc
Description: Digital signature
On Mon, Sep 07, 2015 at 05:05:10PM +0100, Greg Stark wrote:
> I feel like I remember hearing about this before but I can't find any
> mention of it in my mail archives. It seems pretty simple to add
> support for LLVM's Address Sanitizer (asan) by using the hooks we
> already have for valgrind.
Ni
I have sussed what's happening in bug #13908. Basically, commit
45f6240a8fa9d355 ("Pack tuples in a hash join batch densely, to save
memory") broke things for the case where a hash join is using a skew
table. The reason is that that commit only changed the storage of tuples
going into the main ha
Robert Haas writes:
> On Fri, Feb 5, 2016 at 10:17 AM, Filip RembiaÅkowski
> wrote:
>> - new GUC in "Statement Behaviour" section, notify_duplicate_removal
> I agree with what Merlin said about this:
> http://www.postgresql.org/message-id/CAHyXU0yoHe8Qc=yc10ahu1nfia1tbhsg+35ds-oeueuapo7...@mail
On 12/25/2015 03:23 AM, Ildus Kurbangaliev wrote:
On Fri, 25 Dec 2015 13:34:25 +0300
Teodor Sigaev wrote:
First, variables (high and low) should not be declared in the middle
of code. Second, assert will fail if ua.v64[0] == ub.v64[0] and
ua.v64[1] > ub.v64[1] although it's a possible and allow
On Fri, Feb 5, 2016 at 10:17 AM, Filip Rembiałkowski
wrote:
> - new GUC in "Statement Behaviour" section, notify_duplicate_removal
> (default true)
>
> Initial discussion in this thread:
> http://www.postgresql.org/message-id/CAP_rwwmpzk9=sbjrztod05bdctyc43wnknu_m37dygvl4sa...@mail.gmail.com
>
> R
On Fri, Feb 5, 2016 at 1:16 PM, Stephen Frost wrote:
> An in-core auditing solution would provide us with proper grammar
> support, ability to directly mark objects for auditing in the catalog,
> allow us to much more easily maintain auditing capability over time as
> a small incremental bit of wo
I've done a first pass at next week's release notes; please review.
Committed at
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7008e70d105b572821406744ce080771b74c06ab
and should be visible in the website's devel-branch docs after the next
guaibasaurus buildfarm run, due a coup
On Fri, Feb 5, 2016 at 4:23 AM, Ashutosh Bapat
wrote:
> I have corrected this in this set of patches. Also, I have included the
> change to build the join relation description while constructing fpinfo in
> the main patch since that avoids repeated building of the same at a small
> cost of constru
On Fri, Feb 5, 2016 at 9:09 AM, Ashutosh Bapat
wrote:
>> Would it be nuts to set fdw_scan_tlist in all cases? Would the code
>> come out simpler than what we have now?
>
> PFA the patch that can be applied on v9 patches.
>
> If there is a whole-row reference for base relation, instead of adding t
* Joe Conway (m...@joeconway.com) wrote:
> On 02/05/2016 10:16 AM, Stephen Frost wrote:
> > An in-core auditing solution would provide us with proper grammar
> > support, ability to directly mark objects for auditing in the catalog,
> > allow us to much more easily maintain auditing capability over
On 02/05/2016 10:16 AM, Stephen Frost wrote:
> An in-core auditing solution would provide us with proper grammar
> support, ability to directly mark objects for auditing in the catalog,
> allow us to much more easily maintain auditing capability over time as
> a small incremental bit of work for ea
All,
* Robert Haas (robertmh...@gmail.com) wrote:
> OK, I'll bite: I'm worried that this patch will be a maintenance
> burden. It's easy to imagine that changes to core will result in the
> necessity or at least desirability of changes to pgaudit, but I'm
> definitely not prepared to insist that
> On Feb 3, 2016, at 2:38 AM, Peter Moser wrote:
>
> Does anyone had similar problems? Do I have to configure Eclipse to
> understand the PG_RMGR macro or is there another possibility to teach Eclipse
> these macros?
I just built 9.6 under Eclipse CDT to try this out and was able to open e.g.
On Thu, Feb 4, 2016 at 6:14 AM, Peter Geoghegan wrote:
> The economics of using 4MB or even 20MB to sort 10GB of data are
> already preposterously bad for everyone that runs a database server,
> no matter how budget conscious they may be. I can reluctantly accept
> that we need to still use a heap
On 02/04/2016 09:59 AM, Michael Paquier wrote:
On Tue, Feb 2, 2016 at 9:59 AM, Andres Freund wrote:
On 2016-02-02 09:56:40 +0900, Michael Paquier wrote:
And there is no actual risk of data loss
Huh?
More precise: what I mean here is that should an OS crash or a power
failure happen, we wou
On Wed, Feb 03, 2016 at 06:02:57PM -0600, Jim Nasby wrote:
> I just discovered that ./configure will happily accept '--with-pgport=' (I
> was actually doing =$PGPORT, and didn't realize $PGPORT was empty). What you
> end up with is a compile error in guc.c, with no idea why it's broken. Any
> reaso
- new GUC in "Statement Behaviour" section, notify_duplicate_removal
(default true)
Initial discussion in this thread:
http://www.postgresql.org/message-id/CAP_rwwmpzk9=sbjrztod05bdctyc43wnknu_m37dygvl4sa...@mail.gmail.com
Rationale: for some legitimate use cases, duplicate removal is not
require
Would it be nuts to set fdw_scan_tlist in all cases? Would the code
> come out simpler than what we have now?
>
>
PFA the patch that can be applied on v9 patches.
If there is a whole-row reference for base relation, instead of adding that
as an additional column deparseTargetList() creates a list
On Thu, Feb 4, 2016 at 4:39 AM, Michael Paquier
wrote:
> I just bumped into the following typo in slot.c:
> /*
> * If we'd now fail - really unlikely - we wouldn't know
> whether this slot
> * would persist after an OS crash or not - so, force a restart. The
> -*
On Fri, Feb 5, 2016 at 6:14 AM, Peter Geoghegan wrote:
> On Wed, Feb 3, 2016 at 11:31 AM, Robert Haas wrote:
>> Thanks for the review. I fixed the OID conflict, tweaked a few
>> comments, and committed this.
>
> Thanks. I noticed a tiny, preexisting typo in the string abbreviated
> key code. The
Per discussion at the Brussels developer meeting and within the
release team, the high level schedule for 9.6 will be:
Beta: May (before PGCon)
Release: September
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgre
On Thu, Feb 4, 2016 at 11:30 PM, Amit Kapila wrote:
> On Fri, Feb 5, 2016 at 3:17 AM, Robert Haas wrote:
>>
>> On Thu, Feb 4, 2016 at 7:00 AM, Amit Kapila
>> wrote:
>> > [ new patch ]
>>
>> I've committed this after heavy rewriting. In particular, I merged
>> two loops, used local variables to
On Fri, Feb 5, 2016 at 4:46 PM, Rushabh Lathia
wrote:
>
>
> On Wed, Feb 3, 2016 at 3:31 PM, Etsuro Fujita > wrote:
>
>> On 2016/01/28 15:20, Rushabh Lathia wrote:
>>
>>> On Thu, Jan 28, 2016 at 11:33 AM, Etsuro Fujita
>>> mailto:fujita.ets...@lab.ntt.co.jp>>
>>> wrote:
>>>
>>> On 2016/01/27
On Tue, Feb 2, 2016 at 9:19 PM, Andres Freund wrote:
>
> On 2016-01-28 16:53:08 +0530, Dilip Kumar wrote:
> > test_script:
> >
> > ./psql -d postgres -c "truncate table data"
> > ./psql -d postgres -c "checkpoint"
> > ./pgbench -f copy_script -T 120 -c$ -j$ postgres
> >
> > Shared Buf
On Wed, Feb 3, 2016 at 3:31 PM, Etsuro Fujita
wrote:
> On 2016/01/28 15:20, Rushabh Lathia wrote:
>
>> On Thu, Jan 28, 2016 at 11:33 AM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>> On 2016/01/27 21:23, Rushabh Lathia wrote:
>>
>> If I understood correctly, above
On Wed, Feb 3, 2016 at 11:31 AM, Robert Haas wrote:
> Thanks for the review. I fixed the OID conflict, tweaked a few
> comments, and committed this.
Thanks. I noticed a tiny, preexisting typo in the string abbreviated
key code. The attached patch fixes it.
--
Peter Geoghegan
diff --git a/src/b
On 2016-02-05 05:06, Tom Lane wrote:
I wrote:
Pavel Stehule writes:
[ num_nulls_v6.patch ]
I started looking through this. It seems generally okay, but I'm not
very pleased with the function name "num_notnulls". I think it would
be better as "num_nonnulls", as I see Oleksandr suggested al
Attached patch fixes an issue reported by William Felipe Welter about
a year ago [1]. It is loosely based on his original patch.
As Heikki goes into on that thread, the appropriate action seems to be
to constantly reset the error queue, and to make sure that we
ourselves clear the queue consistent
On Fri, Feb 5, 2016 at 12:19 PM, Masahiko Sawada wrote:
> On Fri, Feb 5, 2016 at 5:36 PM, Michael Paquier
> wrote:
> I agree with adding new system catalog to easily checking replication
> status for user. And group name will needed for this.
> What about adding group name with ":" to immediately
On Thu, Feb 4, 2016 at 2:34 PM, Michael Paquier
wrote:
> On Thu, Feb 4, 2016 at 12:02 PM, Michael Paquier
> wrote:
>> On Tue, Feb 2, 2016 at 4:20 PM, Michael Paquier wrote:
>>> Not wrong, and this leads to the following:
>>> void rename_safe(const char *old, const char *new, bool isdir, int eleve
On Fri, Feb 5, 2016 at 5:36 PM, Michael Paquier
wrote:
> On Thu, Feb 4, 2016 at 11:06 PM, Michael Paquier
> wrote:
>> On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier
>> wrote:
>>> On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote:
On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier
wro
> We may have a good idea of how to define a custom language, still we
> are going to need to design a clean interface at catalog level more or
> less close to what is written here. If we can get a clean interface,
> the custom language implemented, and TAP tests that take advantage of
> this user
On 2016/02/04 21:57, Ashutosh Bapat wrote:
One more: I think the following in postgresGetForeignJoinPaths() is
a good idea, but I think it's okay to just check whether
root->rowMarks is non-NIL, because that since we have rowmarks for
all base relations except the target, if we h
> Btw, IIUC, I think the patch fails to adjust the targetlist of the top
> plan created that way, to output the fdw_scan_tlist, as discussed in [1]
> (ie, I think the attached patch is needed, which is created on top of your
> patch pg_fdw_join_v8.patch).
>
>
fdw_scan_tlist represents the output fe
On Thu, Feb 4, 2016 at 11:06 PM, Michael Paquier
wrote:
> On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier
> wrote:
>> On Thu, Feb 4, 2016 at 10:40 PM, Robert Haas wrote:
>>> On Thu, Feb 4, 2016 at 2:21 PM, Michael Paquier
>>> wrote:
Yes, please let's use the custom language, and let's not
Peter Moser wrote:
I have some strange error message inside Eclipse, that some symbols cannot
be found. I work with version 9.6 currently. For instance,
Symbol 'RM_HEAP_ID' could not be resolved
src/backend/access/heap/heapam.c
It affects all occurrences of symbols that are defined in
src/incl
On 2016/02/04 21:42, Ashutosh Bapat wrote:
* Is it safe to replace outerjoinpath with its fdw_outerpath the
following way? I think that if the join relation represented by
outerjoinpath has local conditions that can't be executed remotely,
we have to keep outerjoinpath in the pa
Hello,
Please find attached updated patch.
>The point of having pgstat_report_progress_update_counter() is so that
>you can efficiently update a single counter without having to update
>everything, when only one counter has changed. But here you are
>calling this function a whole bunch of time
Hello,
I considered how to make tab-completion robust for syntactical
noises, in other words, optional words in syntax. Typically "IF
(NOT) EXISTS", UNIQUE and TEMPORARY are words that don't affect
further completion. However, the current delimit-matching
mechanism is not so capable (or is complex
41 matches
Mail list logo
