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
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
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
>
> 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
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
"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
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
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
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 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
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 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
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
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
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
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 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
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
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...
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
> -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
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.
>
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 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 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
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 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
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
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 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
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
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 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
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 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
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
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
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
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 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 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 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 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
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
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
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
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 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
>
>
>
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
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 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
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
> -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 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
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 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 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 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
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
[ 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.
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,
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 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
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
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
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
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
>
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
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
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
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 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 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
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
74 matches
Mail list logo
