On Thu, Feb 1, 2018 at 12:26 PM, Amit Langote
wrote:
> Hi.
>
> When addressing a review comment on the fast partition pruning thread [1],
> I noticed that specifying null in the IN-list will cause constraint
> exclusion to wrongly fail to refute a table's check predicate.
>
> create table foo (a i
Hi.
When addressing a review comment on the fast partition pruning thread [1],
I noticed that specifying null in the IN-list will cause constraint
exclusion to wrongly fail to refute a table's check predicate.
create table foo (a int check (a = 1));
insert into foo values (null), (1);
-- ExecEva
On Wed, Jan 31, 2018 at 6:14 PM, Amit Kapila wrote:
> On Wed, Jan 31, 2018 at 5:57 PM, 自己 wrote:
>> thank you for your quick reply.
>> and i have another question, for the following code, whether exist such
>> scene : page_found is false and
>> newmapbuf is invalid, if so, may be the statement Ma
On Wed, Jan 24, 2018 at 03:44:04PM +0900, Michael Paquier wrote:
> Good catch. Coverage reports mark those areas as empty! Similarly the
> functions for record_* are mostly not used. Some tests could be added
> for them at the same time. The four error paths of those functions are
> tested as well,
On Mon, Jan 22, 2018 at 03:12:58PM -0500, Stephen Frost wrote:
> I would think the next step here, as Michael suggested very early on in
> this thread, would be to bring the exclude list and perhaps logic for
> pg_basebackup into the common code and have pg_rewind leverage that
> instead of having
On 30 January 2018 at 14:14, David G. Johnston
wrote:
> This bug has an obvious if annoying work-around and fixing the bug will
> likely cause people's code, that uses said work-around, to fail. Breaking
> people's working code in stable release branches is generally a no-no.
>
> However, given t
On Wed, Jan 31, 2018 at 01:48:00AM +0100, Andreas Karlsson wrote:
> I too like the concept, but have not had the time to look into it.
This may happen at some point, for now I am marking the patch as
returned with feedback.
--
Michael
signature.asc
Description: PGP signature
On Thu, Feb 1, 2018 at 11:05 AM, Michael Paquier
wrote:
> On Sat, Jan 13, 2018 at 03:40:01PM +, Simon Riggs wrote:
> > The new two byte value is protected by CRC. The 2 byte value repeats
> > every 32768 WAL files. Any bit error in that value that made it appear
> > to be a current value woul
On Wed, 31 Jan 2018 21:12:51 -0500
Tom Lane wrote:
> Yugo Nagata writes:
> > I'm sorry the patch attached in the previous mail is broken and
> > not raises a compile error. I attached the fixed patch.
>
> This patch is almost certainly wrong: you can't assume that the scan-level
> state matches
On Sat, Jan 13, 2018 at 03:40:01PM +, Simon Riggs wrote:
> The new two byte value is protected by CRC. The 2 byte value repeats
> every 32768 WAL files. Any bit error in that value that made it appear
> to be a current value would need to have a rare set of circumstances.
If you use the two lo
On Wed, Jan 31, 2018 at 10:18:04PM +0900, Michael Paquier wrote:
> On Thu, Jan 25, 2018 at 10:26:55PM -0500, Peter Eisentraut wrote:
>> On 1/19/18 00:18, Michael Paquier wrote:
>>> +SELECT a, c FROM gtest12; -- FIXME: should be allowed
>>> +ERROR: permission denied for function gf1
>>
>> This is
On Tue, Jan 30, 2018 at 3:30 AM, Robert Haas wrote:
> On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila wrote:
>> If we want to get rid of Gather (Merge) checks in
>> apply_projection_to_path(), then we need some way to add a projection
>> path to the subpath of gather node even if that is capable of
On Wed, Jan 31, 2018 at 9:53 PM, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 3:57 AM, Amit Kapila wrote:
>>> * There might be some opportunity to share some of the new code with
>>> the code recently committed to WaitForParallelWorkersToFinish(). For
>>> one thing, the logic in this block could
Yugo Nagata writes:
> I'm sorry the patch attached in the previous mail is broken and
> not raises a compile error. I attached the fixed patch.
This patch is almost certainly wrong: you can't assume that the scan-level
state matches the tuple we are currently processing at top level. Any
sort of
On Wed, Jan 31, 2018 at 5:06 PM, Tom Lane wrote:
> We could imagine reimplementing WinGetFuncArgInFrame to fix this, but
> aside from the sheer inefficiency of simple fixes, I'm not very clear
> what seeking relative to WINDOW_SEEK_CURRENT should mean when the current
> row is excluded. (Of cour
On Thu, 01 Feb 2018 09:48:49 +0900 (JST)
Tatsuo Ishii wrote:
> > On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote:
> >> Looks good to me. If there's no objection, especially from Thomas
> >> Munro, I will mark this as "ready for committer".
> >
> > No objection from me.
>
> I marked this as
On 2018/02/01 6:08, Robert Haas wrote:
> On Mon, Jan 29, 2018 at 1:22 AM, Amit Langote
> wrote:
>>> Updated patch attached. Because I made no changes
>>> other than that, I'll make this as Ready for Committer.
>> Thanks a lot for reviewing.
>
> Committed and back-patched to v10.
Thank you.
Re
On Fri, Jan 26, 2018 at 05:58:48PM -0500, Tom Lane wrote:
> Daniel Gustafsson writes:
>> Oversight, completely missed that one.
>
> It looks like no core code uses that macro, so it's got no effect
> unless some third-party code does ... but I changed it anyway.
Good point. I missed this one as
> On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote:
>> Looks good to me. If there's no objection, especially from Thomas
>> Munro, I will mark this as "ready for committer".
>
> No objection from me.
I marked this as "Ready for Committer".
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
En
On Thu, Feb 1, 2018 at 2:01 AM, Robert Haas wrote:
> On Tue, Jan 30, 2018 at 7:04 PM, Tsunakawa, Takayuki
> wrote:
>> So a simple improvement would be to assign workers fairly to databases
>> facing a wraparound risk, as Sawada-san suggested.
>
> Is that always an improvement, or does it make so
On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote:
> Looks good to me. If there's no objection, especially from Thomas
> Munro, I will mark this as "ready for committer".
No objection from me.
--
Thomas Munro
http://www.enterprisedb.com
On 10 January 2018 at 09:54, Konstantin Knizhnik
wrote:
> (new version attached)
Why this comment?
Current implementation of projection optimization has to calculate
index expression twice
in case of hit (value of index expression is not changed) and three
times if values are different.
Old +
Oliver Ford writes:
> [ 0001-window-frame-v11.patch ]
I've realized that the exclusion clause aspect of this patch is rather
badly broken. In particular, the "seek to row" logic in
WinGetFuncArgInFrame is critically dependent on the assumption that the
rows of the frame are contiguous. Use of a
On 31 January 2018 at 21:03, Amit Langote wrote:
> Update patch set attached. Thanks again.
(My apologies for being slow to respond here. I've been on leave this
week and I'm off again next week. I now have a little time to reply)
Hi Amit,
Thanks for incorporating my changes into the patchset.
On 31 January 2018 at 21:51, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 5:52 AM, Dean Rasheed
> wrote:
>> On 30 January 2018 at 16:42, Tom Lane wrote:
>>> So I'm thinking that (a) we do not need to check for leaky functions used
>>> in window support, and (b) therefore there's no need to avoi
On Wed, Jan 31, 2018 at 05:13:41PM -0500, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 5:00 PM, Bruce Momjian wrote:
> > doc: clarify trigger behavior for inheritance
> >
> > The previous wording added in PG 10 wasn't specific enough about the
> > behavior of statement and row triggers when using
On Sun, Jan 28, 2018 at 06:35:06PM -0500, Bruce Momjian wrote:
> I used Robert's patch and modified it to match the ideas I had above.
> Specifically no white space can be before 'help', 'exit' or 'quit' and
> prompt_status is used to adjust the suggestion. Here is the visible
> behavior:
So what
Hello.
WIP-Patch for optimisation of OFFSET + IndexScan using visibility map.
Patch based on idea of Maxim Boguk [1] with some inspiration from Douglas
Doole [2].
-
Everyone knows - using OFFSET (especially big) is not an good practice.
But in reality they widely used mostly for paging (be
On Wed, Jan 31, 2018 at 5:00 PM, Bruce Momjian wrote:
> doc: clearify trigger behavior for inheritance
>
> The previous wording added in PG 10 wasn't specific enough about the
> behavior of statement and row triggers when using inheritance.
This may be a good change in general, but the change of
On Wed, Jan 31, 2018 at 5:52 AM, Dean Rasheed wrote:
> On 30 January 2018 at 16:42, Tom Lane wrote:
>> So I'm thinking that (a) we do not need to check for leaky functions used
>> in window support, and (b) therefore there's no need to avoid leaky
>> behavior in in_range support functions. Objec
On Wed, Jan 31, 2018 at 12:53 AM, Michael Paquier
wrote:
> On Wed, Jan 31, 2018 at 08:47:57AM +0300, Alexander Lakhin wrote:
>> Please consider committing the attached patch to fix a typo in error
>> message.
>
> Yeah..
Committed.
>> if (cxt->ofType)
>> erepor
On Sun, Jan 28, 2018 at 6:02 PM, Thomas Munro
wrote:
> Added to the next CF.
Committed. I also modified the reference in the regression test along
similar lines, and for good measure, I back-patched this change, as it
constitutes a clear error in the documentation.
--
Robert Haas
EnterpriseDB:
On Mon, Jan 29, 2018 at 1:22 AM, Amit Langote
wrote:
>> Updated patch attached. Because I made no changes
>> other than that, I'll make this as Ready for Committer.
> Thanks a lot for reviewing.
Committed and back-patched to v10.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The En
On Fri, Dec 22, 2017 at 12:13 AM, Kyotaro HORIGUCHI
wrote:
> The attached one-liner patch is just adding tranche registration
> to autprewarm.c.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Wed, Jan 31, 2018 at 2:49 PM, Andres Freund wrote:
>> We could do that, but I'd be more inclined just to let JIT be
>> magically enabled. In general, if a user could do 'yum install ip4r'
>> (for example) and have that Just Work without any further database
>> configuration, I think a lot of p
On 2018-01-31 14:45:46 -0500, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund wrote:
> >> The first one is a problem that's not going to go away. If the
> >> problem of JIT being enabled "magically" is something we're concerned
> >> about, we need to figure out a good solution
Hi hackers,
I saw this today: http://www.vldb.org/pvldb/vol11/p648-tian.pdf
It describes the "LDSF" (largest-dependency-set-first) lock scheduling
algorithm and related work, as an alternative to the FIFO scheduling
used by PostgreSQL and most other RDBMSs. LDSF been implemented in
MySQL 8. The
On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund wrote:
>> The first one is a problem that's not going to go away. If the
>> problem of JIT being enabled "magically" is something we're concerned
>> about, we need to figure out a good solution, not just disable the
>> feature by default.
>
> That's
On Mon, Jan 29, 2018 at 3:42 AM, Jeevan Chalke
wrote:
> Attached new patch set and rebased it on latest HEAD.
I strongly dislike add_single_path_to_append_rel. It adds branches
and complexity to code that is already very complex. Most
importantly, why are we adding paths to fields in
OtherUpper
Hi,
On 2018-01-31 11:56:59 -0500, Robert Haas wrote:
> On Tue, Jan 30, 2018 at 5:57 PM, Andres Freund wrote:
> > Given that we need a shared library it'll be best buildsystem wise if
> > all of this is in a directory, and there's a separate file containing
> > the stubs that call into it.
> >
> >
Hi,
On 2018-01-31 11:53:25 -0500, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 10:22 AM, Peter Eisentraut
> wrote:
> > On 1/30/18 21:55, Andres Freund wrote:
> >> I'm open to changing my mind on it, but it seems a bit weird that a
> >> feature that relies on a shlib being installed magically turn
On Wed, Jan 31, 2018 at 7:17 AM, Robert Haas wrote:
> I don't fully grok merge but suppose you have:
>
> WHEN MATCHED AND a = 0 THEN UPDATE ...
> WHEN MATCHED AND a = 1 THEN UPDATE ...
> WHEN NOT MATCHED THEN INSERT ...
>
> Suppose you match a tuple with a = 0 but, upon trying to update it,
> find
On Tue, Jan 30, 2018 at 7:04 PM, Tsunakawa, Takayuki
wrote:
> So a simple improvement would be to assign workers fairly to databases facing
> a wraparound risk, as Sawada-san suggested.
Is that always an improvement, or does it make some cases better and
others worse?
> One ultimate solution sh
On Tue, Jan 30, 2018 at 5:57 PM, Andres Freund wrote:
> Given that we need a shared library it'll be best buildsystem wise if
> all of this is in a directory, and there's a separate file containing
> the stubs that call into it.
>
> I'm not quite sure where to put the code. I'm a bit inclined to a
> On 12 January 2018 at 13:58, Arthur Zakirov wrote:
>
> I attached new version of the patch. Now (expected output):
>
Thanks for working on that! I haven't followed this thread before, and after a
quick review I have few side questions.
Why not write `is_separator_char` using `isprint`, `isalph
On Wed, Jan 31, 2018 at 10:22 AM, Peter Eisentraut
wrote:
> On 1/30/18 21:55, Andres Freund wrote:
>> I'm open to changing my mind on it, but it seems a bit weird that a
>> feature that relies on a shlib being installed magically turns itself on
>> if avaible. And leaving that angle aside, ISTM, t
Hi.
> 23 июня 2017 г., в 21:32, Peter Eisentraut
> написал(а):
>
> On 6/22/17 23:10, Peter Geoghegan wrote:
>> On Thu, Jun 22, 2017 at 7:10 PM, Tom Lane wrote:
>>> Is there some way I'm missing, or is this just a not-done-yet feature?
>>
>> It's a not-done-yet feature.
>
> It's something I h
On Thu, 1 Feb 2018 01:33:49 +0900
Yugo Nagata wrote:
I'm sorry the patch attached in the previous mail is broken and
not raises a compile error. I attached the fixed patch.
Regards,
> Hi,
>
> I found that updating a cursor by using CURRENT OF causes the
> following error when the query is exec
Hi,
I found that updating a cursor by using CURRENT OF causes the
following error when the query is executed by IndexOnlyScan.
ERROR: cannot extract system attribute from virtual tuple
IndexOnlyScan returns a virtual tuple that doesn't have system
column, so we can not get ctid in the same wa
On Wed, Jan 31, 2018 at 3:57 AM, Amit Kapila wrote:
>> * There might be some opportunity to share some of the new code with
>> the code recently committed to WaitForParallelWorkersToFinish(). For
>> one thing, the logic in this block could be refactored into a
>> dedicated function that is called
On 1/30/18 21:55, Andres Freund wrote:
> I'm open to changing my mind on it, but it seems a bit weird that a
> feature that relies on a shlib being installed magically turns itself on
> if avaible. And leaving that angle aside, ISTM, that it's a complex
> enough feature that it should be opt-in the
On Tue, Jan 30, 2018 at 2:28 PM, Peter Geoghegan wrote:
> What's at issue here specifically is the exact behavior of
> EvalPlanQual() in the context of having *multiple* sets of WHEN quals
> that need to be evaluated one at a time (in addition to conventional
> EPQ join quals). This is a specific,
On Thu, Jan 25, 2018 at 10:26:55PM -0500, Peter Eisentraut wrote:
> On 1/19/18 00:18, Michael Paquier wrote:
>> +SELECT a, c FROM gtest12; -- FIXME: should be allowed
>> +ERROR: permission denied for function gf1
>
> This is quite hard to fix and I would like to leave this for a future
> release
2018-01-31 13:58 GMT+01:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > This format is too important, so some special short or long option can be
> > practical (it will be printed in help)
> >
> > some like --csv
>
> I guess -C/--csv could be used, like there already is -H/--html.
>
> > I
Pavel Stehule wrote:
> This format is too important, so some special short or long option can be
> practical (it will be printed in help)
>
> some like --csv
I guess -C/--csv could be used, like there already is -H/--html.
> I found one issue - PostgreSQL default field separator is "|".
Hi,
I am trying to create logical decoding slot on a standby.
Enabling Hot_standby_feedback on standby is one of the requirement ; which will
delay vacuuming of stale data on Master server.
I am working on a hack to avoid Hot_standby_feedback so that Standby doesn't
have any dependency on Master
On Wed, Jan 31, 2018 at 5:57 PM, 自己 wrote:
> thank you for your quick reply.
> and i have another question, for the following code, whether exist such
> scene : page_found is false and
> newmapbuf is invalid, if so, may be the statement MarkBufferDirty(metabuf);
> should be placed outside the if s
Fabien COELHO wrote:
> > This patch implements csv as an output format in psql
> > (\pset format csv).
>
> Would you consider registering it in the next CF?
Done here:
https://commitfest.postgresql.org/17/1500/
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manit
On 30 January 2018 at 16:42, Tom Lane wrote:
> So I'm thinking that (a) we do not need to check for leaky functions used
> in window support, and (b) therefore there's no need to avoid leaky
> behavior in in_range support functions. Objections?
>
Yes, I concur. Since window functions can only ap
Hello Thomas,
Thank you for your suggestions, needless to say it helped a lot. As
you suggested, I have created an initial dsm segment and used it create dsa
area as well as to detach dsm. Thus, it helped me in using 'on_dsm_detach'
callback. I have tested the code and it work
Hello,
On Fri, Jan 12, 2018 at 11:47:39AM +0300, Anthony Bykov wrote:
> Hello, thank you for your message.
> The problem was that different perl compilers uses different infinity
> representations. Some of them use "Inf" others - use "inf". So, in
> attachments there is a new version of the patch.
On Mon, Jan 29, 2018 at 4:01 AM, Peter Geoghegan wrote:
> On Sat, Jan 27, 2018 at 12:14 AM, Amit Kapila wrote:
>
> I also found that all of these errors were propagated. The patch helps
> parallel CREATE INDEX as expected/designed.
>
Great!
> Some small things that I noticed about the patch:
>
At Wed, 31 Jan 2018 13:09:09 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20180131.130909.210233873.horiguchi.kyot...@lab.ntt.co.jp>
> At Sun, 21 Jan 2018 21:59:19 +0100, Emre Hasegeli wrote
> in
> > New versions are attached including all changes we discussed.
>
> Thanks for the
On Tue, 30 Jan 2018 19:21:04 +1300
Thomas Munro wrote:
> On Tue, Jan 30, 2018 at 6:48 PM, Tatsuo Ishii wrote:
> >>> You need to DROP VIEW lock_view4 and lock_view5 in the regression
> >>> test as well.
> >>
> >> Thank you for reviewing the patch.
> >>
> >> I fixed this and attached a updated pat
Horiguchi-san,
Thanks for the review.
On 2018/01/30 20:43, Kyotaro HORIGUCHI wrote:
> At Tue, 30 Jan 2018 09:57:44 +0900, Amit Langote wrote:
>> AFAICS, v22 cleanly applies to HEAD (c12693d8f3 [1]), compiles, and make
> I have some random comments on 0002.
>
> -extract_partition_key_clauses impl
On 31.01.2018 05:48, Thomas Munro wrote:
This seems to be a valid complaint. I don't think you should be
(indirectly) wrapping Types.h in extern "C". At a guess, your
llvmjit.h should be doing its own #ifdef __cplusplus'd linkage
specifiers, so you can use it from C or C++, but making sure
66 matches
Mail list logo
