Hello David & Surafel,
I think this can be marked as ready for committer now, but I'll defer
to Fabien to see if he's any other comments.
Patch v16 applies and compiles cleanly, local and global "make check"
are ok. Doc build is ok.
I did some manual testing with limit cases which did
Andrew Dunstan writes:
> On 3/1/19 6:49 PM, Tom Lane wrote:
>> No patch referenced, but I assume you mean only for the
>> zero-bytes-received case, right? No objection if so.
> Patch proposed by Christoph Berg is here:
> https://www.postgresql.org/message-id/20190228151336.GB7550%40msg.df7cb.de
On 3/1/19 6:49 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> So I propose shortly to commit this patch unconditionally demoting the
>> message to DEBUG1.
> No patch referenced, but I assume you mean only for the
> zero-bytes-received case, right? No objection if so.
>
>
On Fri, Mar 1, 2019 at 5:00 PM Peter Geoghegan wrote:
> I favor keeping the test, but having it throw a
> ERRCODE_INDEX_CORRUPTED error, just like _bt_pagedel() does already. A
> comment could point out that the test is historical/defensive, and
> probably isn't actually necessary. What do you
On Fri, Mar 1, 2019 at 4:41 PM Tom Lane wrote:
> > FWIW, I notice that the logic that appears after the
> > _bt_lock_branch_parent() call to _bt_getstackbuf() anticipates that it
> > must defend against interrupted splits in at least the
> > grandparent-of-leaf page, and maybe even the parent, so
David Rowley writes:
> I think you're fighting a losing battle here with adding OR quals to
> the join condition.
Yeah --- that has a nontrivial risk of making things significantly worse,
which makes it a hard sell. I think the most reasonable bet here is
simply to not perform the
Peter Geoghegan writes:
> _bt_lock_branch_parent() is used by VACUUM during page deletion, and
> calls _bt_getstackbuf(), which always finishes incomplete page splits
> for the parent page that it exclusive locks and returns. ISTM that
> this may be problematic, since it contradicts the general
On Fri, Mar 01, 2019 at 05:05:54PM -0500, Joe Conway wrote:
> Seems like it would be better to modify the arguments to
> CloseTransientFile() to include the filename being closed, errorlevel,
> and fail_on_error or something similar. Then all the repeated ereport
> stanzas could be eliminated.
Hello all!
I am Sumukha PK a student of NITK. I am interested in the WAL-G backup tool. I
haven’t been able to catch hold of anyone through the IRC channels so I need
someone to point me to appropriate resources so that I can be introduced to it.
I am proficient in Golang an would be
On Sat, 2 Mar 2019 at 12:39, Li, Zheng wrote:
> However, if s.a is nullable, we would do this transformation:
> select count(*) from big b where not exists(select 1 from small s
> where s.a = b.a or s.a is null);
I understand you're keen to make this work, but you're assuming again
that
_bt_lock_branch_parent() is used by VACUUM during page deletion, and
calls _bt_getstackbuf(), which always finishes incomplete page splits
for the parent page that it exclusive locks and returns. ISTM that
this may be problematic, since it contradicts the general rule that
VACUUM isn't supposed to
Andrew Dunstan writes:
> So I propose shortly to commit this patch unconditionally demoting the
> message to DEBUG1.
No patch referenced, but I assume you mean only for the
zero-bytes-received case, right? No objection if so.
regards, tom lane
Chapman Flack writes:
> On 03/01/19 17:34, Tom Lane wrote:
>> Using custom operator names would work better/more reliably.
> Or a new base type (LIKE float8) rather than a domain?
Yeah, it'd be more work but you would have control over the
coercion rules.
regards, tom
The current transformation would not add "or s.a is NULL" in the example
provided since it is non-nullable. You will be comparing these two cases in
terms of the transformation:
select count(*) from big b where not exists(select 1 from small s
where s.a = b.a);
Time: 51.416 ms
select count(*)
On 03/01/19 17:34, Tom Lane wrote:
> but I think it'd be fragile to use. (See the "Type Conversion"
> chapter in the manual for the gory details, and note that domains
> get smashed to their base types mighty readily.)
>
> Using custom operator names would work better/more reliably.
Or a new
On 2/28/19 10:13 AM, Christoph Berg wrote:
> Re: Magnus Hagander 2016-04-13
>
>> It's fairly common to see a lot of "Incomplete startup packet" in the
>> logfiles caused by monitoring or healthcheck connections.
> I've also seen it caused by port scanning.
Yes, definitely.
On Sat, 2 Mar 2019 at 12:13, Tom Lane wrote:
>
> "Li, Zheng" writes:
> > Although adding "or var is NULL" to the anti join condition forces the
> > planner to choose nested loop anti join, it is always faster compared to
> > the original plan.
>
> TBH, I am *really* skeptical of sweeping
"Li, Zheng" writes:
> Although adding "or var is NULL" to the anti join condition forces the
> planner to choose nested loop anti join, it is always faster compared to the
> original plan.
TBH, I am *really* skeptical of sweeping claims like that. The existing
code will typically produce a
Peter Geoghegan writes:
> On Fri, Mar 1, 2019 at 11:56 AM Robert Haas wrote:
>> It would be neat if there were a tool you could run to somehow tell
>> you whether catversion needs to be changed for a given patch.
> That seems infeasible because of stored rules. A lot of things bleed
> into
On Tue, Sep 18, 2018 at 10:37 AM Michael Banck
wrote:
> I have added a retry for this as well now, without a pg_sleep() as well.
> This catches around 80% of the half-reads, but a few slip through. At
> that point we bail out with exit(1), and the user can try again, which I
> think is fine?
Thanks all for the feedbacks! I'm working on a refined patch.
Although adding "or var is NULL" to the anti join condition forces the planner
to choose nested loop anti join, it is always faster compared to the original
plan. In order to enable the transformation from NOT IN to anti join when
David Rowley writes:
> On Sat, 2 Mar 2019 at 05:44, Tom Lane wrote:
>> I'm not sure if the second one is actually a semantics bug or just a
>> misoptimization? But yeah, +1 for putting in some simple tests for
>> corner cases right now. Anyone want to propose a specific patch?
> The second is
Chapman Flack writes:
> I wanted to try this out a little before assuming it would work,
> and there seems to be no trouble creating a trivial domain over
> float8 (say, CREATE DOMAIN ieeedouble AS float8), and then creating
> operators whose operand types are the domain type.
While you can do
James Coleman writes:
> [ saop_is_not_null-v10.patch ]
I went through this again, and this time (after some more rewriting
of the comments) I satisfied myself that the logic is correct.
Hence, pushed.
I stripped down the regression test cases somewhat. Those were
good for development, but they
On Sat, 2 Mar 2019 at 05:44, Tom Lane wrote:
>
> Andres Freund writes:
> > I've not checked, but could we please make sure these cases are covered
> > in the regression tests today with a single liner?
>
> I'm not sure if the second one is actually a semantics bug or just a
> misoptimization?
On Fri, Mar 1, 2019 at 4:51 PM Chapman Flack wrote:
> On 3/1/19 3:49 PM, Matt Pulver wrote:
>
> > In many applications, I would much rather see calculations carried out
> > via IEEE 754 all the way to the end, with nans and infs, which
> > provides much more useful diagnostic information than an
On 2/28/19 9:33 PM, Michael Paquier wrote:
> Hi all,
>
> Joe's message here has reminded me that we have lacked a lot of error
> handling around CloseTransientFile():
> https://www.postgresql.org/message-id/c49b69ec-e2f7-ff33-4f17-0eaa4f2ce...@joeconway.com
>
> This has been mentioned by Alvaro
On Fri, Mar 1, 2019 at 9:11 PM Konstantin Knizhnik
wrote:
> One more thing... From my point of view one of the drawbacks of Postgres
> is that it requires underlaying file system and is not able to work with
> raw partitions.
> It seems to me that bypassing fle system layer can significantly
On 3/1/19 3:49 PM, Matt Pulver wrote:
> In many applications, I would much rather see calculations carried out
> via IEEE 754 all the way to the end, with nans and infs, which
> provides much more useful diagnostic information than an exception that
> doesn't return any rows at all. As Andres
On Fri, Mar 1, 2019 at 3:35 PM Shawn Debnath wrote:
> On Fri, Mar 01, 2019 at 03:03:19PM -0500, Robert Haas wrote:
> > On Fri, Mar 1, 2019 at 2:36 PM Shawn Debnath wrote:
> > > I disagree, at least with combining and retaining enums. Encoding all
> > > the possible request types with the
On Fri, Mar 1, 2019 at 3:52 PM Haribabu Kommi wrote:
> The Cybertec proposed patches are doing the encryption at the instance
> level, AFAIK, the current discussion is also trying to reduce the scope of the
> encryption to object level like (tablesapce, database or table) to avoid the
>
On Fri, Sep 14, 2018 at 10:04 AM Antonin Houska wrote:
> Toshi Harada wrote:
> > Even if you apply "data-at-rest-encryption-wip-2018.07.25.patch" to the
> > master branch,
> > the same patch error will occur.
>
> The version attached to this email should be applicable to the current
> branch.
On Sat, Mar 2, 2019 at 7:27 AM Robert Haas wrote:
> On Thu, Feb 7, 2019 at 3:28 AM Masahiko Sawada
> wrote:
> > WAL encryption will follow as an additional feature.
>
> I don't think WAL encryption is an optional feature. You can argue
> about whether it's useful to encrypt the disk files in
On Fri, Mar 1, 2019 at 12:59 PM Andrew Gierth
wrote:
> > "Matt" == Matt Pulver writes:
>
> Matt> ERROR: division by zero
>
> Matt> Question: If Infinity and NaN are supported, then why throw an
> Matt> exception here, instead of returning Infinity?
>
> Spec says so:
>
> 4) The dyadic
On Sat, Mar 2, 2019 at 9:35 AM Shawn Debnath wrote:
> On Fri, Mar 01, 2019 at 03:03:19PM -0500, Robert Haas wrote:
> > On Fri, Mar 1, 2019 at 2:36 PM Shawn Debnath wrote:
> > > I disagree, at least with combining and retaining enums. Encoding all
> > > the possible request types with the
On Fri, Mar 1, 2019 at 11:56 AM Robert Haas wrote:
> It would be neat if there were a tool you could run to somehow tell
> you whether catversion needs to be changed for a given patch.
That seems infeasible because of stored rules. A lot of things bleed
into that. We could certainly do better at
On Thu, Feb 7, 2019 at 3:28 AM Masahiko Sawada wrote:
> WAL encryption will follow as an additional feature.
I don't think WAL encryption is an optional feature. You can argue
about whether it's useful to encrypt the disk files in the first place
given that there's no privilege boundary between
On Fri, Mar 1, 2019 at 2:36 PM Shawn Debnath wrote:
> I disagree, at least with combining and retaining enums. Encoding all
> the possible request types with the current, planned and future SMGRs
> would cause a sheer explosion in the number of enum values.
How big of an explosion would it be?
On 3/1/19 2:26 PM, David G. Johnston wrote:
> Upon further reading you are correct - IEEE 754 has chosen to treat n/0
> differently for n=0 and n<>0 cases. I'm sure they have their reasons but
> ... I don't use,
> or have time for the distraction, to understand why such a decision was
> made and
On Sat, Mar 2, 2019 at 8:36 AM Shawn Debnath wrote:
> On Fri, Mar 01, 2019 at 01:15:21PM -0500, Robert Haas wrote:
> > > >
> > > > +typedef enum syncrequestowner
> > > > +{
> > > > + SYNC_MD = 0 /* md smgr */
> > > > +} syncrequestowner;
> > > >
> > > > I have a feeling that
On Thu, Feb 28, 2019 at 5:36 PM Peter Geoghegan wrote:
> I have attempted to institute some general guidelines for what the
> thicket of rules are by creating the "committing checklist" page. This
> is necessarily imperfect, because the rules are in many cases open to
> interpretation, often for
On Thu, Feb 28, 2019 at 6:40 PM Tom Lane wrote:
> 1. Encourage people to develop new patches using chosen-at-random
> high OIDs, in the 7K-9K range. They do this already, it'd just
> be encouraged instead of discouraged.
>
> 2. Commit patches as received.
>
> 3. Once each devel cycle, after
Andrew Dunstan writes:
> On 3/1/19 2:14 PM, Tom Lane wrote:
>> Indeed, but I'm not sure that the use-cases are the same. In particular,
>> unless somebody has done some rather impossible magic, it would be
>> disastrous to apply DISABLE_INDEX_CLEANUP as a reloption, because then
>> it would be
Andres Freund writes:
> On 2019-03-01 14:17:33 -0500, Tom Lane wrote:
>> I think we should reject the whole patch, tbh, and go do something
>> about the underlying problem instead. Once we've made truncation
>> not require AEL, this will be nothing but a legacy wart that we'll
>> have a hard
On 3/1/19 2:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> I want to make one other point about this patch, which is that over on
>> the thread "New vacuum option to do only freezing" we have a patch
>> that does a closely-related thing. Both patches skip one phase of the
>> overall VACUUM
On Friday, March 1, 2019, Chapman Flack wrote:
>
> But if someone wanted to write a user-defined division function or
> operator that would return Inf for (anything > 0) / 0 and for
> (anything < 0) / -0, and -Inf for (anything < 0) / 0 and for
> (anything > 0) / -0, and NaN for (either zero) /
Hi,
On 2019-03-01 14:17:33 -0500, Tom Lane wrote:
> Andres Freund writes:
> > OTOH, as the main reason for wanting to disable truncation is that a
> > user is getting very undesirable HS conflicts, it doesn't seem right to
> > force them to change the reloption on all tables, and then somehow
Andres Freund writes:
> OTOH, as the main reason for wanting to disable truncation is that a
> user is getting very undesirable HS conflicts, it doesn't seem right to
> force them to change the reloption on all tables, and then somehow force
> it to be set on all tables created at a later stage.
On Thu, Feb 28, 2019 at 11:54 PM Tatsuro Yamada
wrote:
> Attached patch is wip patch.
+ CLUSTER and VACUUM FULL,
showing current progress.
and -> or
+ certain commands during command execution. Currently, the suppoted
+ progress reporting commands are VACUUM and
CLUSTER.
suppoted
Robert Haas writes:
> I want to make one other point about this patch, which is that over on
> the thread "New vacuum option to do only freezing" we have a patch
> that does a closely-related thing. Both patches skip one phase of the
> overall VACUUM process. THIS patch wants to skip
Hi,
On 2019-02-27 10:55:49 -0500, Robert Haas wrote:
> I don't think that a VACUUM option would be out of place, but a GUC
> sounds like an attractive nuisance to me. It will encourage people to
> just flip it blindly instead of considering the particular cases where
> they need that behavior,
On 3/1/19 1:43 PM, Robert Haas wrote:
> On Thu, Feb 28, 2019 at 3:17 AM Tsunakawa, Takayuki
> wrote:
>> Uh, thanks. I've just recognized I didn't know the meaning of "nuisance."
>> I've looked up the meaning in the dictionary. Nuisance is like a trouble
>> maker...
> My proposal would be
Hi,
On 2019-02-28 10:18:36 -0800, Andres Freund wrote:
> On 2019-02-28 18:28:37 +0900, Etsuro Fujita wrote:
> > > I'm currently
> > > converting the EPQ machinery to slots, and in course of that I (with
> > > Horiguchi-san's help), converted RefetchForeignRow to return a slot. But
> > > there's
On Fri, Mar 1, 2019 at 12:19 AM Masahiko Sawada wrote:
> > I wonder if we really want this behavior. Should a setting that
> > controls the degree of parallelism when scanning the table also affect
> > VACUUM? I tend to think that we probably don't ever want VACUUM of a
> > table to be parallel
On Thu, Feb 28, 2019 at 3:12 AM Masahiko Sawada wrote:
> Attached the updated version patch.
Regarding the user interface for this patch, please have a look at the
concerns I mention in
https://www.postgresql.org/message-id/ca+tgmozorx_uuv67rjasx_aswkdzwv8kwfkfrwxyldcqfqj...@mail.gmail.com
I
On Thu, Feb 28, 2019 at 3:17 AM Tsunakawa, Takayuki
wrote:
> Uh, thanks. I've just recognized I didn't know the meaning of "nuisance."
> I've looked up the meaning in the dictionary. Nuisance is like a trouble
> maker...
Yes, and "attractive nuisance" means something that, superficially, it
On 2019-03-01 11:04:04 -0700, David G. Johnston wrote:
> Changing the behavior is not going to happen for any existing data types.
For the overflow case that really sucks, because we're leaving a very
significant amount of performance on the table because we recheck for
overflow in every op. The
On 3/1/19 1:04 PM, David G. Johnston wrote:
> 1/0 is an illegal operation. We could return NaN for it but the choice of
> throwing an error is just as correct. Returning infinity is strictly
> incorrect.
That differs from my understanding of how the operations are specified
in IEEE 754 (as
Hello,
On 2/15/19 3:24 PM, Adrien NAYRAT wrote:
On 2/14/19 9:14 PM, Andres Freund wrote:
I wonder if this doesn't need a warning, explaining that using this when
there are large transactions could lead to slowdowns.
Yes, I will add some wording
Warning added.
It seems pretty weird to
On Fri, Mar 1, 2019 at 12:43 PM Andres Freund wrote:
> Obviously it's nicer looking this way, but OTOH, that means we have to
> send more data over the queue, because we can't easily combine the
> request + "owner". I don't have too strong feelings about it though.
Yeah, I would lean toward
Hi,
On 2019-03-01 12:46:55 -0500, Matt Pulver wrote:
> PostgreSQL FLOAT appears to support +/-Infinity and NaN per the IEEE 754
> standard, with expressions such as CAST('NaN' AS FLOAT) and CAST('Infinity'
> AS FLOAT) and even supports ordering columns of floats that contain NaN.
>
> However the
On Friday, March 1, 2019, Matt Pulver wrote:
> However the query "SELECT 1.0/0.0;" produces an exception:
>
> ERROR: division by zero
>
>
> Question: If Infinity and NaN are supported, then why throw an exception
> here, instead of returning Infinity? Is it purely for historical reasons,
> or
> "Matt" == Matt Pulver writes:
Matt> ERROR: division by zero
Matt> Question: If Infinity and NaN are supported, then why throw an
Matt> exception here, instead of returning Infinity?
Spec says so:
4) The dyadic arithmetic operators , ,
, and (+, -, *, and /, respectively)
Hello,
PostgreSQL FLOAT appears to support +/-Infinity and NaN per the IEEE 754
standard, with expressions such as CAST('NaN' AS FLOAT) and CAST('Infinity'
AS FLOAT) and even supports ordering columns of floats that contain NaN.
However the query "SELECT 1.0/0.0;" produces an exception:
ERROR:
Hi,
On 2019-03-01 13:33:23 +0530, tushar wrote:
> While testing this feature found that - if lots of insert happened on the
> master cluster then pg_recvlogical is not showing the DATA information on
> logical replication slot which created on SLAVE.
>
> Please refer this scenario -
>
> 1)
>
Hi,
On 2019-03-01 23:17:27 +1300, Thomas Munro wrote:
> @@ -8616,7 +8617,7 @@ CreateCheckPoint(int flags)
> * the REDO pointer. Note that smgr must not do anything that'd have
> to
> * be undone if we decide no checkpoint is needed.
> */
> - smgrpreckpt();
> +
On 2/25/19 10:38 AM, Konstantin Knizhnik wrote:
> Hi hackers,
>
> Small issue with readir implementation for Windows.
> Right now it returns ENOENT in case of any error returned by
> FindFirstFile.
> So all places in Postgres where opendir/listdir are used will assume
> that directory is empty
On 01.03.2019 19:17, Robert Haas wrote:
On Thu, Feb 28, 2019 at 8:19 PM Nikita Glukhov wrote:
Attached 34th version of the patches.
Kinda strange version numbering -- the last post on this thread is v21.
For simplicity of dependence tracking, version numbering of JSON_TABLE patches
matches
Andres Freund writes:
> On March 1, 2019 4:53:03 AM PST, David Rowley
> wrote:
>> On Fri, 1 Mar 2019 at 15:27, Richard Guo wrote:
>>> 1. The patch would give wrong results when the inner side is empty.
>>> 2. Because of the new added predicate 'OR (var is NULL)', we cannot
>>> use hash join or
Michael Paquier writes:
> On Thu, Feb 28, 2019 at 11:50:16PM -0500, Tom Lane wrote:
>> But, having said that, we've learned that it's generally bad for
>> catalog-query functions to fail outright just because they're pointed
>> at the wrong kind of catalog object. So I think that what we want
Michael Paquier writes:
> On Thu, Feb 28, 2019 at 10:52:52PM -0500, Tom Lane wrote:
>> If you're suggesting that we disable that security restriction
>> during extension creation, I really can't see how that'd be a
>> good thing ...
> No, I don't mean that. I was just wondering if someone can
Hi,
On March 1, 2019 4:53:03 AM PST, David Rowley
wrote:
>On Fri, 1 Mar 2019 at 15:27, Richard Guo wrote:
>> I have reviewed your patch. Good job except two issues I can find:
>>
>> 1. The patch would give wrong results when the inner side is empty.
>In this
>> case, the whole data from outer
On 3/1/19 2:31 AM, Kyotaro HORIGUCHI wrote:
> Hello.
>
> At Thu, 28 Feb 2019 21:16:25 +0100, Tomas Vondra
> wrote in
>
>>> One biggest issue seems to be we don't know the total number of
>
> # One *of* the biggest *issues*?
>
>>> outer tuples before actually reading a null tuple. I doubt
On Thu, Feb 28, 2019 at 8:19 PM Nikita Glukhov wrote:
> Attached 34th version of the patches.
Kinda strange version numbering -- the last post on this thread is v21.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Thank you Michael!
What can I do if I'm sure I will not use the CTAS creation ? Take a look
at the "heap_create_with_catalog" function, it check it and raise error.
Even I change it to "check it && if_not_existing", raise error, it is
still be problematic since we may some other session
Etsuro Fujita wrote:
> (2019/03/01 20:00), Antonin Houska wrote:
> > Etsuro Fujita wrote:
> > I used gdb to help me understand, however the condition
> >
> > if (fpextra&& !IS_UPPER_REL(foreignrel))
> >
> > never evaluated to true with the query above.
>
> Sorry, my explanation was not
On Fri, Mar 1, 2019 at 5:47 AM Etsuro Fujita
wrote:
> Robert, I CCed you because you are the author of that commit. Before
> that commit ("Rewrite the code that applies scan/join targets to
> paths."), apply_scanjoin_target_to_paths() had a boolean parameter named
> modify_in_place, and used
On Thu, Feb 28, 2019 at 6:13 PM Alvaro Herrera wrote:
> Tablespaces already behave a little bit especially in another sense:
> it doesn't recurse to indexes. I think it's not possible to implement a
> three-way flag, where you tell it to move only the table, or to recurse
> to child tables but
Hi Alvaro,
On 2/28/19 1:28 PM, Alvaro Herrera wrote:
Rebased to current master. I'll reply later to handle the other issues
you point out.
Applying with hunks.
With 0003 using
export CFLAGS="-DCOPY_PARSE_PLAN_TREES -O0 -fno-omit-frame-pointer" &&
CC="ccache gcc" ./configure --prefix
Suraj Kharage writes:
> The Commit 5955d934194c3888f30318209ade71b53d29777f has changed the logic
> to avoid dumping creation and comment commands for the public schema.
Yup.
> As reported by Prabhat, if we try to restore the custom/tar dump taken from
> v10 and earlier versions, we get the
Hi,
Yes it is working fine with \a option in psql.
Cheers
Ram 4.0
On 03/01/19 07:15, Ramanarayana wrote:
> Hi,
> I have tested bug fixes provided by all the patches. They are working
> great. I found one minor issue
>
> select * from xmltable('*' PASSING 'pre arg?>deeppost' COLUMNS x XML PATH '/');
>
> The above query returns the xml. But there is an extra
Magnus Hagander wrote:
> Maybe have the first note say "This method is deprecated bceause it has
> serious
> risks (see bellow)" and then list the actual risks at the end?
Good idea. That may attract the attention of the dogs among the readers.
Yours,
Laurenz Albe
Re: Tom Lane 2019-01-31 <12792.1548965...@sss.pgh.pa.us>
> initdb hasn't depended on those libpq exports since 8.2, and it was
> a bug that it did so even then.
9.2 psql (and createuser, ...) is also broken:
/usr/lib/postgresql/9.2/bin/psql: symbol lookup error:
On Fri, Mar 1, 2019 at 2:07 PM David Steele wrote:
> On 3/1/19 1:13 PM, Peter Eisentraut wrote:
> > Please follow the 1-space indentation in the documentation files.
>
> Whoops. Will fix.
>
> > I think the style of mentioning all the problems in a note before the
> > actual description is a bit
On 3/1/19 1:13 PM, Peter Eisentraut wrote:
Please follow the 1-space indentation in the documentation files.
Whoops. Will fix.
I think the style of mentioning all the problems in a note before the
actual description is a bit backwards.
In the case of an important note like this I think it
On 2019/03/01 22:01, Amit Langote wrote:
> Of course, I had to make sure that query_planner (which is not
> in the charge of adding source inheritance child objects) can notice that.
Oops, I meant to write "query_planner (which *is* in the charge of adding
source inheritance child objects)..."
Imai-san,
Thanks for testing and sorry it took me a while to reply.
On 2019/02/25 15:24, Imai, Yoshikazu wrote:
> [update_pt_with_joining_another_pt.sql]
> update rt set c = jrt.c + 100 from jrt where rt.b = jrt.b;
>
> [pgbench]
> pgbench -n -f update_pt_with_joining_another_pt_for_ptkey.sql -T
Hi Matsumura-san,
> I must use a midrule action like the following that works as
> expected.
> I wonder how to write the replacement to ecpg.addons.
> I think it's impossible, right? Please give me some advice.
You are right, for this change you have to replace the whole rule. This
cannot be
On Fri, 1 Mar 2019 at 15:27, Richard Guo wrote:
> I have reviewed your patch. Good job except two issues I can find:
>
> 1. The patch would give wrong results when the inner side is empty. In this
> case, the whole data from outer side should be in the outputs. But with the
> patch, we will lose
On Fri, Mar 1, 2019 at 4:33 AM Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello.
>
> At Thu, 28 Feb 2019 21:16:25 +0100, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote in <
> fbd08ad3-5dd8-3169-6cba-38d610d7b...@2ndquadrant.com>
> > > One biggest issue seems to be we
(2019/03/01 20:00), Antonin Houska wrote:
Etsuro Fujita wrote:
(2019/02/22 22:54), Antonin Houska wrote:
Etsuro Fujita wrote:
So, the two changes are handling different
cases, hence both changes would be required.
+ /*
+* If this is an UPPERREL_ORDERED step performed on
On Fri, Mar 01, 2019 at 07:17:04PM +0800, Andy Fan wrote:
> for a createStmt, it will call transformCreateStmt, and then
> heap_create_with_catalog.
> but looks it just check the if_not_exists in transformCreateStmt.
>
> is it designed as this on purpose or is it a bug?
That's a bug. Andreas
On Sun, 15 Apr 2018 at 19:09, Sergei Kornilov wrote:
> Attached updated patch follows recent Reorganize partitioning code commit.
I've made a pass over v10. I think it's in pretty good shape, but I
did end up changing a few small things.
1. Tweaked the documents a bit. I was going to just
Hi Meskes-san
I must use a midrule action like the following that works as expected.
I wonder how to write the replacement to ecpg.addons.
I think it's impossible, right? Please give me some advice.
PrepareStmt:
PREPARE prepared_name prep_type_clause AS
{
prepared_name =
Hi,
I have tested bug fixes provided by all the patches. They are working
great. I found one minor issue
select * from xmltable('*' PASSING 'predeeppost' COLUMNS x XML PATH '/');
The above query returns the xml. But there is an extra plus symbol at the
end
predeeppost+
Regards,
Ram
Hi Matsumura-san,
> I will read README.parser, ecpg.addons, and *.pl to understand.
Feel free to ask, when anything comes up.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes
Hello,
We probably identified a bug in the pg_background implementation:
https://github.com/vibhorkum/pg_background
It is a race condition when starting the process and BGWH_STOPPED is returned -
see the pull request for more info:
https://github.com/RekGRpth/pg_background/pull/1
I think I
for a createStmt, it will call transformCreateStmt, and then
heap_create_with_catalog.
but looks it just check the if_not_exists in transformCreateStmt.
so there is a chance that when the transformCreateStmt is called, the table
is not created, but before the heap_create_with_catalog is called,
Hi,
The Commit 5955d934194c3888f30318209ade71b53d29777f has changed the logic
to avoid dumping creation and comment commands for the public schema.
>From v11 onwards, we are using the DUMP_COMPONENT_ infrastructure in
selectDumpableNamespace() to skip the public schema creation.
As reported by
1 - 100 of 119 matches
Mail list logo
