2017-02-05 7:54 GMT+01:00 Pavan Deolasee :
>
> On Sat, Feb 4, 2017 at 11:54 PM, Tom Lane wrote:
>
>>
>> Based on Pavan's comments, I think trying to force this into next week's
>> releases would be extremely unwise. If the bug went undetected this long,
>> it can wait for a fix for another three
On 24 January 2017 at 02:36, Tom Lane wrote:
> It might be possible to get away with having only one pg_type column,
> pointing at the parse-analysis function. That function would generate
> a SubscriptingRef tree node containing the OID of the appropriate
> execution function, which execQual.c
On Sat, Feb 4, 2017 at 11:27 PM, Tom Lane wrote:
> First-draft release notes are available at
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9863017b87f3592ff663d03fc663a4f1f8fdb8b2
> They should appear in a more readable form at
> https://www.postgresql.org/docs/devel/static
On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule wrote:
> I agree with Pavan - a release with known important bug is not good idea.
This bug has been around for some time, so I would recommend taking
the time necessary to make the best fix possible, even if it means
waiting for the next round of min
On Wed, Feb 1, 2017 at 11:09 PM, Robert Haas wrote:
Here are the latest version of the patch, which address all the
comments given by Robert.
> https://www.postgresql.org/message-id/20161017201558.cr34stc6zvxy3...@alap3.anarazel.de
> that you should try to share only the iteration arrays, I beli
Hi, Jeff!
2017-02-05 3:45 GMT+05:00 Jeff Davis :
> On Sun, Jan 22, 2017 at 10:32 PM, Jeff Davis wrote:
>> On Sat, Jan 21, 2017 at 4:25 AM, Andrew Borodin wrote:
>> One idea I had that might be simpler is to use a two-stage page
>> delete. The first stage would remove the link from the parent and
Noah Misch writes:
> DefineIndex() has a check_rights argument that determines whether to perform a
> namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets
> that flag. The theory goes that use of DROP INDEX and CREATE INDEX is a mere
> implementation detail of ALTER TABLE
Michael Paquier writes:
> On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule wrote:
>> I agree with Pavan - a release with known important bug is not good idea.
> This bug has been around for some time, so I would recommend taking
> the time necessary to make the best fix possible, even if it means
>
Amit Kapila writes:
> On Sat, Feb 4, 2017 at 11:27 PM, Tom Lane wrote:
>> Fix possible miss of socket read events while waiting on Windows (Amit
>> Kapial)
> Typo
> Amit Kapial/Amit Kapila
Wups. Copied-and-pasted that from the commit log without stopping to
question it. Will fix, thanks for
2017-02-05 18:51 GMT+01:00 Tom Lane :
> Michael Paquier writes:
> > On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule
> wrote:
> >> I agree with Pavan - a release with known important bug is not good
> idea.
>
> > This bug has been around for some time, so I would recommend taking
> > the time neces
El 05/02/17 a las 10:03, Michael Paquier escribió:
> On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule wrote:
>> I agree with Pavan - a release with known important bug is not good idea.
>
> This bug has been around for some time, so I would recommend taking
> the time necessary to make the best fix
On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > DefineIndex() has a check_rights argument that determines whether to
> > perform a
> > namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets
> > that flag. The theory goes that use of DROP I
Noah Misch writes:
> On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote:
>> Is there any likely use-case for providing separate control flags for the
>> two permission checks? That would require an API change for DefineIndex,
>> making this considerably more invasive, so I'm not pushing for
On Sun, Feb 05, 2017 at 01:48:09PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote:
> >> Is there any likely use-case for providing separate control flags for the
> >> two permission checks? That would require an API change for DefineIndex,
[ Having now read the whole thread, I'm prepared to weigh in ... ]
Pavan Deolasee writes:
> This seems like a real problem to me. I don't know what the consequences
> are, but definitely having various attribute lists to have different view
> of the set of indexes doesn't seem right.
For sure.
Hi Julien,
Thank you for taking the time to do this review, and my
apologies for the very delayed response. I lost track of
this work and have only jumped back into it today.
Please find attached a new version of the patch with your
feedback integrated. I've also rebased the patch against
the cur
On Sat, Feb 04, 2017 at 03:41:29PM +0700, Boris Muratshin wrote:
> Hi hackers,
>
> The low-level implementation of 3D Z-curve index
> (https://github.com/bmuratshin/zcurve/tree/master)
> is getting close to GiST R-Tree performance at
> significantly lesser number of pages read from disk.
>
> See
On Fri, Feb 3, 2017 at 9:14 PM, Ashutosh Sharma wrote:
> On Fri, Feb 3, 2017 at 8:29 PM, Robert Haas wrote:
>> On Fri, Feb 3, 2017 at 7:41 AM, Ashutosh Sharma
>> wrote:
>>> I think UInt32GetDatum(metad->hashm_procid) looks fine, the reason
>>> being 'hashm_procid' is defined as 32-bit unsigned
On Sun, Feb 5, 2017 at 1:34 PM, Martín Marqués wrote:
> El 05/02/17 a las 10:03, Michael Paquier escribió:
>> On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule
>> wrote:
>>> I agree with Pavan - a release with known important bug is not good idea.
>>
>> This bug has been around for some time, so I w
On Sun, Feb 5, 2017 at 4:09 PM, Robert Haas wrote:
> I don't think this kind of black-and-white thinking is very helpful.
> Obviously, data corruption is bad. However, this bug has (from what
> one can tell from this thread) been with us for over a decade; it must
> necessarily be either low-prob
On 2017-02-05 12:51:09 -0500, Tom Lane wrote:
> Michael Paquier writes:
> > On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule
> > wrote:
> >> I agree with Pavan - a release with known important bug is not good idea.
>
> > This bug has been around for some time, so I would recommend taking
> > the t
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Claudio Freire
> Sent: Saturday, February 04, 2017 8:47 AM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Amit Kapila ; Robert Haas
> ; pgsql-hackers
> Subject: Re: ParallelFinish-
On 2017-02-05 15:14:59 -0500, Tom Lane wrote:
> I do not like any of the other patches proposed in this thread, because
> they fail to guarantee delivering an up-to-date attribute bitmap to the
> caller. I think we need a retry loop, and I think that it needs to look
> like the attached.
That loo
On 02/06/2017 01:11 AM, Peter Geoghegan wrote:
On Sun, Feb 5, 2017 at 4:09 PM, Robert Haas wrote:
I don't think this kind of black-and-white thinking is very
helpful. Obviously, data corruption is bad. However, this bug has
(from what one can tell from this thread) been with us for over a
decad
Hi,
On 2017-02-05 16:37:33 -0800, Andres Freund wrote:
> > RelationGetIndexList(Relation relation)
> > @@ -4746,8 +4747,10 @@ RelationGetIndexPredicate(Relation relat
> > * we can include system attributes (e.g., OID) in the bitmap
> > representation.
> > *
> > * Caller had better hold at
On Fri, Feb 3, 2017 at 8:28 PM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
> On 30.12.2016 06:55, Haribabu Kommi wrote:
>
>
> Hi All,
>
> Fujitsu was interested in developing a columnar storage extension with
> minimal
> changes the server backend.
>
>
> We in PostgresPRO are also ve
On Wed, Feb 1, 2017 at 6:27 AM, Vitaly Burovoy
wrote:
> Hello,
>
> I've reviewed the patch[1].
>
> Result of testing:
>
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, passed
>
>
>
From: Tom Lane [mailto:t...@sss.pgh.pa.us]:
> Kyle Gearhart writes:
>> The guts of pqRowProcessor in libpq does a good bit of work to maintain the
>> internal data structure of a PGresult. There are a few use cases where the
>> caller doesn't need the ability to access the result set row by row
On Sun, Feb 5, 2017 at 4:57 PM, Tomas Vondra
wrote:
> OTOH I disagree with the notion that bugs that are not driven by user
> reports are somehow less severe. Some data corruption bugs cause quite
> visible breakage - segfaults, immediate crashes, etc. Those are pretty clear
> bugs, and are report
Hi.
I'm going through project-by-project offering spelling fixes.
I have read your submission suggestions [1][2] and am choosing to
disregard them.
Could someone please review the changes I have [3] and suggest a
series of commits that this project might like?
It is quite likely that someone will
Hi,
On 2017-02-05 21:05:50 -0500, Josh Soref wrote:
> Could someone please review the changes I have [3] and suggest a
> series of commits that this project might like?
I think the current split seem excessive... I'd suggest splitting
things first into:
- straight up spelling/typo fixes in comme
On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane wrote:
>
>
> > 2. In the second patch, we tried to recompute attribute lists if a
> relcache
> > flush happens in between and index list is invalidated. We've seen
> problems
> > with that, especially it getting into an infinite loop with
> > CACHE_CLOBBER
On Mon, Feb 6, 2017 at 6:27 AM, Andres Freund wrote:
> Hi,
>
> On 2017-02-05 16:37:33 -0800, Andres Freund wrote:
>> > RelationGetIndexList(Relation relation)
>> > @@ -4746,8 +4747,10 @@ RelationGetIndexPredicate(Relation relat
>> > * we can include system attributes (e.g., OID) in the bitmap
On Mon, Feb 6, 2017 at 5:41 AM, Peter Geoghegan wrote:
> On Sun, Feb 5, 2017 at 4:09 PM, Robert Haas wrote:
> > I don't think this kind of black-and-white thinking is very helpful.
> > Obviously, data corruption is bad. However, this bug has (from what
> > one can tell from this thread) been wi
On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee wrote:
>
>
> On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane wrote:
>>
>>
>>
>> > 2. In the second patch, we tried to recompute attribute lists if a
>> > relcache
>> > flush happens in between and index list is invalidated. We've seen
>> > problems
>> > wit
On Sun, Feb 5, 2017 at 6:42 PM, Pavan Deolasee wrote:
> I'm not sure that just because the bug wasn't reported by a user, makes it
> any less critical. As Tomas pointed down thread, the nature of the bug is
> such that the users may not discover it very easily, but that doesn't mean
> it couldn't
On 2017-02-06 08:08:01 +0530, Amit Kapila wrote:
> I don't see in your patch that you are setting rd_bitmapsvalid to 0.
IIRC a plain relcache rebuild should do that (note there's also no place
that directly resets rd_indexattrs).
> Also, I think this suffers from the same problem as the patch pr
Andres Freund writes:
> I've not yet read the full thread, but I'm a bit confused so far. We
> obviously can get changing information about indexes here, but isn't
> that something we have to deal with anyway? If we guarantee that we
> don't loose knowledge that there's a pending invalidation, wh
It's now split more or less to your suggestion:
https://github.com/jsoref/postgres/commits/spelling
diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -7088,7 +7088,7 @@ test -z "$INSTALL_SCRIPT" && INSTALL_SCR
test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644'
# Whe
On Mon, Feb 6, 2017 at 8:15 AM, Amit Kapila wrote:
> On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee
> wrote:
> >
> >
> > On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane wrote:
> >>
> >>
> >>
> >> > 2. In the second patch, we tried to recompute attribute lists if a
> >> > relcache
> >> > flush happens
On Mon, Feb 6, 2017 at 5:44 AM, Andres Freund wrote:
> On 2017-02-05 12:51:09 -0500, Tom Lane wrote:
> > Michael Paquier writes:
> > > On Sun, Feb 5, 2017 at 6:53 PM, Pavel Stehule
> wrote:
> > >> I agree with Pavan - a release with known important bug is not good
> idea.
> >
> > > This bug has
On 2017-02-05 21:49:57 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I've not yet read the full thread, but I'm a bit confused so far. We
> > obviously can get changing information about indexes here, but isn't
> > that something we have to deal with anyway? If we guarantee that we
> > don't
Pavan Deolasee writes:
> On Mon, Feb 6, 2017 at 5:44 AM, Andres Freund wrote:
>> +1. I don't think we serve our users by putting out a nontrivial bugfix
>> hastily. Nor do I think we serve them in this instance by delaying the
>> release to cover this fix; there's enough other fixes in the relea
On 2017-02-05 22:34:34 -0500, Tom Lane wrote:
> Pavan Deolasee writes:
> The point is that there's a nontrivial chance of a hasty fix introducing
> worse problems than we fix.
>
> Given the lack of consensus about exactly how to fix this, I'm feeling
> like it's a good idea if whatever we come up
On Sun, Feb 5, 2017 at 9:19 PM, Kouhei Kaigai wrote:
>> If the use case for this is to gather instrumentation, I'd suggest calling
>> the hook in RetrieveInstrumentation, and calling it appropriately. It would
>> make the intended use far clearer than it is now.
>>
>> And if it saves some work, al
The algorithm for 2D is described in articles (in Russian)
https://habrahabr.ru/post/319810/ and
https://habrahabr.ru/post/319096/ .
Goggle-translator generates (IMHO) suitable for understanding text.
3D version article is not finished yet.
The data in figures are obtained in the following way:
1
On Mon, Feb 6, 2017 at 1:00 AM, Claudio Freire wrote:
> On Sun, Feb 5, 2017 at 9:19 PM, Kouhei Kaigai wrote:
>>> If the use case for this is to gather instrumentation, I'd suggest calling
>>> the hook in RetrieveInstrumentation, and calling it appropriately. It would
>>> make the intended use far
On Mon, Feb 6, 2017 at 8:35 AM, Pavan Deolasee wrote:
>
>
> On Mon, Feb 6, 2017 at 8:15 AM, Amit Kapila wrote:
>>
>> On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee
>> wrote:
>> >
>> >
>> > On Mon, Feb 6, 2017 at 1:44 AM, Tom Lane wrote:
>> >>
>> >>
>> >>
>> >> > 2. In the second patch, we tried
Hi all,
Lately I have bumped into a case where it would have been useful to
make the difference between a failure because of a slot already
dropped and an internal failure of Postgres. Is there any interest for
support of IE and INE for CREATE and DROP_REPLICATION_SLOT?
My use case involved only t
On Mon, Feb 6, 2017 at 9:41 AM, Amit Kapila wrote:
>
>
> Hmm. Consider that the first time relcahe invalidation occurs while
> computing id_attrs, so now the retry logic will compute the correct
> set of attrs (considering two indexes, if we take the example given by
> Alvaro above.).
I don't
On Mon, Feb 6, 2017 at 8:01 AM, Pavan Deolasee
wrote:
>
>>
> I like this approach. I'll run the patch on a build with
> CACHE_CLOBBER_ALWAYS, but I'm pretty sure it will be ok.
>
While it looks certain that the fix will miss this point release, FWIW I
ran this patch with CACHE_CLOBBER_ALWAYS and
On Sat, Feb 4, 2017 at 6:39 AM, Robert Haas wrote:
> On Fri, Feb 3, 2017 at 5:21 AM, Stephen Frost wrote:
>> Daniel,
>>
>> * Daniel Verite (dan...@manitou-mail.org) wrote:
>>> What if we look at the change from the pessimistic angle?
>>> An example of confusion that the change would create:
>>> a
On Sat, Feb 4, 2017 at 1:12 AM, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 10:13 PM, Michael Paquier
> wrote:
>> On Tue, Jan 24, 2017 at 8:36 PM, Kuntal Ghosh
>> wrote:
>>> Nothing else to add from my side. I'm marking this 'Ready for commiter'.
>>
>> Moved to CF 2017-03 with the same status.
>
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Claudio Freire
> Sent: Monday, February 06, 2017 1:05 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: Amit Kapila ; Robert Haas
> ; pgsql-hackers
> Subject: Re: ParallelFinish-ho
Hi,
Both build_simple_rel() and build_join_rel() allocate RelOptInfo using
makeNode(), which returned a zeroed out memory. The functions then
assign values like false, NULL, 0 or NIL which essentially contain
zero valued bytes. This looks like needless work. So, we are spending
some CPU cycles unne
On Sun, Feb 5, 2017 at 5:04 AM, Fujii Masao wrote:
> With this patch, when normal users type TAB after SUBSCRIPTION,
> they got "permission denied" error. I don't think that's acceptable.
Right, I can see that now. pg_stat_get_subscription() does not offer
as well a way to filter by databases...
I think UInt32GetDatum(metad->hashm_procid) looks fine, the reason
being 'hashm_procid' is defined as 32-bit unsigned integer but then we
may have to define procid as int8 in SQL function.
>>>
>>> No, you're wrong. The GetDatum you choose macro has to match the SQL
>>> type, not the
Ashutosh Bapat writes:
> Both build_simple_rel() and build_join_rel() allocate RelOptInfo using
> makeNode(), which returned a zeroed out memory. The functions then
> assign values like false, NULL, 0 or NIL which essentially contain
> zero valued bytes. This looks like needless work. So, we are s
On Mon, Feb 6, 2017 at 10:34 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> Both build_simple_rel() and build_join_rel() allocate RelOptInfo using
>> makeNode(), which returned a zeroed out memory. The functions then
>> assign values like false, NULL, 0 or NIL which essentially contain
>> zero v
Ashutosh Bapat wrote:
>> We may want to think about a third goal: preventing too many workers
>> from executing the same plan. As per comment in get_parallel_divisor()
>> we do not see any benefit if more than 4 workers execute the same
>> node. So, an append node can distribute more than 4 worker
Ashutosh Bapat writes:
> On Mon, Feb 6, 2017 at 10:34 AM, Tom Lane wrote:
>> I'd vote for not. The general programming style in the backend is to
>> ignore the fact that makeNode() zeroes the node's storage and initialize
>> all the fields explicitly. The primary advantage of that, IMO, is that
On Mon, Feb 6, 2017 at 9:47 AM, Pavan Deolasee wrote:
>
>
> On Mon, Feb 6, 2017 at 9:41 AM, Amit Kapila wrote:
>>
>>
>>
>> Hmm. Consider that the first time relcahe invalidation occurs while
>> computing id_attrs, so now the retry logic will compute the correct
>> set of attrs (considering two i
On Mon, Feb 06, 2017 at 11:04:12AM +0700, Boris Muratshin wrote:
> The algorithm for 2D is described in articles (in Russian)
> https://habrahabr.ru/post/319810/ and
> https://habrahabr.ru/post/319096/ .
> Goggle-translator generates (IMHO) suitable for understanding text.
Welcome to the community
Hello, all
Could you give me your opinions on the message style? Recently, I got
different comments from Magnus and Alvaro during the review of "Supporting
huge_pages on Windows", which is now shifted to CommitFest 2017-3. To be more
specific, I'm modifying src/backend/port/win32_shmem.c
b/s
On Mon, Feb 6, 2017 at 2:56 PM, Tsunakawa, Takayuki
wrote:
> I'm rather inclined to choose Option 1 to reduce message translation work.
> Actually, is the Option 3 the best so that it aligns with the existing
> messages by putting the error code in the primary message?
I find it hard to have a
On Mon, Feb 6, 2017 at 10:06 AM, Ashutosh Sharma wrote:
> On Sat, Feb 4, 2017 at 1:12 AM, Robert Haas wrote:
>>
>> Committed with those changes.
>
> Thanks for above corrections and commit. But, There are couple of
> things that we might have to change once the patch for 'WAL in Hash
> Indexes' g
On Mon, Feb 6, 2017 at 11:10 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> On Mon, Feb 6, 2017 at 10:34 AM, Tom Lane wrote:
>>> I'd vote for not. The general programming style in the backend is to
>>> ignore the fact that makeNode() zeroes the node's storage and initialize
>>> all the fields
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> I find it hard to have an opinion on the matter as a non-translator.
> Why not asking translators directly on pgsql-translators?
>
I didn't think of pgsql-translators. I'll ask t
"Tsunakawa, Takayuki" writes:
> I added a few ereport() calls that emit the same message except for the Win32
> API name. Which of the following do you think is the best? I'd like to
> follow the majority.
> [Option 1]
> ereport(elevel,
> (errmsg("could not enable Lock pages in me
On Mon, Feb 6, 2017 at 1:42 AM, Kouhei Kaigai wrote:
> I also had thought an idea to have extra space to Instrumentation structure,
> however, it needs to make Instrumentation flexible-length structure according
> to the custom format by CSP/FDW. Likely, it is not a good design.
> As long as exten
>
> Hmmm. ISTM that control-c must at least reset the stack, otherwise their
> is not easy way to get out. What can be left to another patch is doing a
> control-C for contents and then another one for the stack when there is no
> content.
>
And so it shall be.
> - put Fabien's tap test in place
v2 patch was not rebased over the latest master branch commits. Please
refer to the attached ParallelAppend_v3.patch, instead.
On 6 February 2017 at 11:06, Amit Khandekar wrote:
> Ashutosh Bapat wrote:
>>> We may want to think about a third goal: preventing too many workers
>>> from executing th
Hello, all
Could you give me your opinions on whether the SHOW command should display the
effective value or the specified value for huge_pages? During the review of
"Supporting huge_pages on Windows", which is now shifted to CommitFest 2017-3,
Magnus gave me a comment that the huge_page varia
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> TBH, I think you are worried about the wrong thing here. You could drop
> both of those errdetail calls altogether and be little worse off. In the
> places where we have errdetail calls like "failed system call was xxx",
> the main point is to show the
74 matches
Mail list logo