Thanks for the review.
On 2019/01/15 22:24, Peter Eisentraut wrote:
> On 15/01/2019 07:31, Amit Langote wrote:
>>> Is "partition bound" the right term? For list partitioning, it's not
>>> really a bound. Maybe it's OK.
>>
>> Hmm, maybe "partition bound value"? Just want to stress that the
>>
On Wed, Jan 16, 2019 at 02:59:15PM +0900, Etsuro Fujita wrote:
> (2019/01/07 20:26), Etsuro Fujita wrote:
>> On second thought I'd like to propose another option:
>> execute_foreign_modify because I think this would match the existing
>> helper functions for updating foreign tables in
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Certainly, what I've done here doesn't preclude adding some wider solution
> to
> the issue of extremely large catcaches.
I'm relieved to hear that.
> I think it takes the pressure off
> for one rather narrow problem case, and the mechanism could be
> From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
>> But pg_is_in_recovery() returns true even for a promoting standby. So
>> you have to wait and retry to send pg_is_in_recovery() until it
>> finishes the promotion to find out it is now a primary. I am not sure
>> if backend out to be responsible
(2019/01/07 20:26), Etsuro Fujita wrote:
(2018/11/30 19:55), Etsuro Fujita wrote:
One thing we would need to discuss more about this is the name of a new
function added by the patch. IIRC, we have three options so far [1]:
1) perform_one_foreign_dml proposed by Ashutosh
2)
Hi Ashutosh,
(2019/01/15 13:29), Ashutosh Bapat wrote:
I think, there's something better possible. Two partitioned relations
won't use partition-wise join, if their partition schemes do not match.
Partitioned relations with same partitioning scheme share
PartitionScheme pointer. PartitionScheme
Amit-san,
(2019/01/15 10:46), Amit Langote wrote:
On 2019/01/11 20:04, Etsuro Fujita wrote:
(2019/01/11 13:46), Amit Langote wrote:
However, what you proposed here as-is would
not keep that behavior, because rel->part_scheme is created for those
tables as well
(even though there would be
From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> But pg_is_in_recovery() returns true even for a promoting standby. So
> you have to wait and retry to send pg_is_in_recovery() until it
> finishes the promotion to find out it is now a primary. I am not sure
> if backend out to be responsible for
> On 2018-Dec-03, Tatsuo Ishii wrote:
>
>> To:
>> ---
>> -M querymode
>> --protocol=querymode
>>
>> Protocol to use for submitting queries to the server:
>>
>> simple: use simple query protocol.
>>
>> extended:
Andres Freund writes:
> On 2019-01-16 11:02:08 +0900, Michael Paquier wrote:
>> f3db7f16 has proved that it can be a bad idea to run pg_resetwal on a
>> data folder which does not match the version it has been compiled
>> with.
>>
>> As of HEAD, PG_CONTROL_VERSION is still 1100:
>> $
David Rowley writes:
> On Wed, 16 Jan 2019 at 14:29, James Coleman wrote:
>> Is your preference in this kind of case to comment the code and/or
>> tests but stick with int4pl even though it doesn't demonstrate the
>> "problem", or try to engineer a different test case such that the
>> *_holds
>> I'm confused as to how this would work. Who or what determines if the server
>> is a primary or standby?
>
> Overall, the server determines the server role (primary or standby) using the
> same mechanism as pg_is_in_recovery(), and set the server_role GUC parameter.
> As the parameter is
James Coleman writes:
> On Tue, Jan 15, 2019 at 3:53 PM Tom Lane wrote:
>> I quite dislike taking the responsibility out of clause_is_strict_for
>> and putting it in the callers.
> The reason I moved it was that we're no longer just proving
> strictness, so it seemed odd to put it in a function
From: Dave Cramer [mailto:p...@fastcrypt.com]
> The original desire should have been the ability to connect to a
> primary or a standby. So, I think we should go back to the original thinking
> (and not complicate the feature), and create a read only GUC_REPORT variable,
> say, server_role,
On Fri, Jan 11, 2019 at 3:54 AM John Naylor
wrote:
>
> On Wed, Jan 9, 2019 at 10:50 PM Amit Kapila
wrote:
> > Thanks, Mithun for performance testing, it really helps us to choose
> > the right strategy here. Once John provides next version, it would be
> > good to see the results of regular
On Tue, Jan 15, 2019 at 1:43 PM Andres Freund wrote:
> Hi,
>
> On 2019-01-11 12:01:36 -0500, Robert Haas wrote:
> > On Thu, Jan 10, 2019 at 7:05 PM Andres Freund
> wrote:
> > > ISTM that the first block would best belong into new files like
> > > access/rel[ation].h and
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Michael Paquier writes:
> > On Tue, Jan 15, 2019 at 02:00:57AM +, Tsunakawa, Takayuki wrote:
> >> The original desire should have been the ability to connect to a
> >> primary or a standby. So, I think we should go back to the original
> >>
On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> On reflection, maybe the problem is not that we're giving the file
> the wrong permissions, but that we're putting it in the wrong place?
> That is, seems like it should be in the logfile directory not the
> data directory. That would
Hi,
On 2019-01-16 11:02:08 +0900, Michael Paquier wrote:
> f3db7f16 has proved that it can be a bad idea to run pg_resetwal on a
> data folder which does not match the version it has been compiled
> with.
>
> As of HEAD, PG_CONTROL_VERSION is still 1100:
> $ pg_controldata | grep "pg_control
Hi all,
f3db7f16 has proved that it can be a bad idea to run pg_resetwal on a
data folder which does not match the version it has been compiled
with.
As of HEAD, PG_CONTROL_VERSION is still 1100:
$ pg_controldata | grep "pg_control version"
pg_control version number:1100
Wouldn't it
On Tue, Jan 15, 2019 at 07:40:12PM +0300, Maksim Milyutin wrote:
> Could you specify all cases when buffers will not be aligned with BLCKSZ?
>
> AFAIC shared and temp buffers are aligned. And what ones are not?
SLRU buffers are not aligned with the OS pages (aka alignment with
4096 at least).
On Sat, Jan 12, 2019 at 08:10:07AM +0900, Michael Paquier wrote:
> On Fri, Jan 11, 2019 at 12:52:08PM -0500, Robert Haas wrote:
>> With the patch, the PrimaryConnInfo and PrimarySlotName arguments are
>> removed from RequestXLogStreaming. That means that the new
>> walreceiver could come to a
On Tue, Jan 15, 2019 at 06:03:36PM +0100, Adrien NAYRAT wrote:
> The goal is not to find slow queries in a transaction, but troubleshoot
> applicative issue when you have short queries.
>
> Sometimes you want to understand what happens in a transaction, either you
> perfectly know your
On Wed, 16 Jan 2019 at 14:29, James Coleman wrote:
>
> On Tue, Jan 15, 2019 at 8:14 PM David Rowley
> > While int4pl might do what you want, some other strict function might
> > not. A simple example would be a strict function that decided to
> > return NULL when the two ints combined overflowed
On Tue, Jan 15, 2019 at 8:14 PM David Rowley
wrote:
>
> On Wed, 16 Jan 2019 at 14:05, James Coleman wrote:
> > At the risk of missing something obvious, I'm not sure I see a case
> > where "x is not null" does not imply "(x + x) is not null", at least
> > for integers. Since an integer + an
On Wed, 16 Jan 2019 at 14:05, James Coleman wrote:
> At the risk of missing something obvious, I'm not sure I see a case
> where "x is not null" does not imply "(x + x) is not null", at least
> for integers. Since an integer + an integer results in an integer,
> then it must imply the addition of
On Tue, Jan 15, 2019 at 4:36 PM David Rowley
wrote:
> I wasn't suggesting any code changes. I just thought the code was
> sufficiently hard to understand to warrant some additional tests that
> ensure we don't assume that if the int4 column x is not null that also
> x+x is not null. Only the
On Tue, Jan 15, 2019 at 3:53 PM Tom Lane wrote:
>
> James Coleman writes:
> > [ saop_is_not_null-v6.patch ]
>
> I quite dislike taking the responsibility out of clause_is_strict_for
> and putting it in the callers. Aside from requiring duplicative code,
> it means that this fails to prove
Dear Adrien,
> Your messages looks normal to me, you will have same messages if you put
> log_min_duration to 0.
That was my lack of understanding. Sorry.
By the way, I think the name of this parameter should be changed.
In the Cambridge dictionary, the word "rate" means as follows:
the speed
Hello Arthur,
I've looked at the patch today, and in general is seems quite solid to
me. I do have a couple of minor points
1) I think the comments need more work. Instead of describing all the
individual changes here, I've outlined those improvements in attached
patches (see the attached
Andrew Gierth writes:
> On a slightly unrelated note, is the small-is-zero variant output file
> for the float tests still required?
Hm, good question. I had been about to respond that it must be,
but looking more closely at pg_regress.c I see that the default
expected-file will be tried if the
I recently purchased a copy of "The Benchmark Handbook", a book from
the early 1990s that was edited by Jim Gray. It features analysis of
the Wisconsin Benchmark in chapter 3 -- that's a single client
benchmark that famously showed real limitations in the optimizers that
were current in the early
On Fri, Jan 4, 2019 at 10:08 AM Thomas Munro
wrote:
> On Fri, Jan 4, 2019 at 3:36 AM Peter Eisentraut
> wrote:
> > On 23/12/2018 09:04, Michael Paquier wrote:
> > > On Tue, Nov 27, 2018 at 02:21:39PM +, Peter Eisentraut wrote:
> > >> Update ssl test certificates and keys
> > >>
> > >> Debian
On Wed, 16 Jan 2019 at 03:33, James Coleman wrote:
> > 2. I was also staring predicate_implied_by_simple_clause() a bit at
> > the use of clause_is_strict_for() to ensure that the IS NOT NULL's
> > operand matches the ScalarArrayOpExpr left operand. Since
> > clause_is_strict_for() = "Can we
James Coleman writes:
> [ saop_is_not_null-v6.patch ]
I quite dislike taking the responsibility out of clause_is_strict_for
and putting it in the callers. Aside from requiring duplicative code,
it means that this fails to prove anything for recursive situations
(i.e., where the ScalarArrayOp
> "Tom" == Tom Lane writes:
On a slightly unrelated note, is the small-is-zero variant output file
for the float tests still required?
--
Andrew (irc:RhodiumToad)
Hi,
On 2018-12-20 15:04:11 -0800, Andres Freund wrote:
> On 2018-12-19 16:56:36 -0800, Andres Freund wrote:
> > On 2018-12-19 19:39:33 -0500, Tom Lane wrote:
> > > Robert Haas writes:
> > > > On Wed, Dec 19, 2018 at 5:37 PM Andres Freund
> > > > wrote:
> > > >> What's gained by the logic of
Robert Haas writes:
> You should redesign this whole representation so that you just pass
> the whole query through to the optimizer without any structural
> change. Just as we do for other statements, you need to do the basic
> transformation stuff like looking up relation OIDs: that has to do
On Mon, Jan 14, 2019 at 9:24 PM Masahiko Sawada wrote:
> I think that because the tuples that got dead after heap_page_prune()
> looked are recorded but not removed without lazy_vacuum_page() we need
> to process them in lazy_vacuum_page(). For decision about whether to
> truncate we should not
On Wed, Jan 2, 2019 at 6:36 AM Alexander Kukushkin wrote:
> I was also thinking about changing the value in PG_CONTROL_VERSION,
> because we added the new field into the control file, but decided to
> leave this change to committer.
We typically omit catversion bumps from submitted patches to
On Mon, Jan 14, 2019 at 5:17 PM Tom Lane wrote:
> The problem here of course is that whoever invented target_session_attrs
> was unconcerned with following that precedent, so what we have is
> "target_session_attrs=(any | read-write)".
> Are we prepared to add some aliases in service of unifying
Andrew Gierth writes:
> Funny thing: I've been devoting considerable effort to testing this, and
> the one failure mode I've found is very interesting; it's not a problem
> with strtod(), in fact it's a bug in our float4in caused by _misuse_ of
> strtod().
> In particular, float4in thinks it's
Hi,
On 2019-01-15 14:05:25 -0500, Robert Haas wrote:
> On Mon, Jan 14, 2019 at 1:37 AM Pavan Deolasee
> wrote:
> > Can you please help me understand what's fundamentally wrong with
> > the approach and more importantly, can you please explain what would
> > the the architecturally sound way to
On Mon, Jan 14, 2019 at 1:37 AM Pavan Deolasee wrote:
> Can you please help me understand what's fundamentally wrong with the
> approach and more importantly, can you please explain what would the the
> architecturally sound way to do this? The same also applies to the executor
> side where
On Tue, Jan 15, 2019 at 01:32:36PM -0500, Tom Lane wrote:
> ...
> > FYI, Oracle provides one parameter, shared_pool_size, that determine the
> > size of a memory area that contains SQL plans and various dictionary
> > objects. Oracle decides how to divide the area among constituents. So
> > it
Hi,
On 2019-01-15 13:32:36 -0500, Tom Lane wrote:
> Well, we *had* an LRU mechanism for the catcaches way back when. We got
> rid of it --- see commit 8b9bc234a --- because (a) maintaining the LRU
> info was expensive and (b) performance fell off a cliff in scenarios where
> the cache size limit
"Tsunakawa, Takayuki" writes:
> But the syscache/relcache bloat still remains a problem, when there are many
> live tables and application connections. Would you agree to solve this in
> some way? I thought Horiguchi-san's latest patches would solve this and the
> negative entries. Can we
Hi!
On Tue, Jan 15, 2019 at 10:17 AM Shay Rojansky wrote:
> Unfortunately I'm extremely tight for time at the moment and don't have time
> to do the appropriate hot standby setup to test this... As the patch is
> pretty straightforward, and since I'm hoping you guys execute the tests on
>
Mitar, thanks for giving this your attention!
So patch looks good to me, but documentation changes are missing from it.
> UNLISTEN should be removed from the list of commands not allowed and moved
> to the list of those which are allowed [1]. Moreover,
>
James Coleman writes:
> I'm attaching the current version of the patch with the new tests, but
> I'm not sure I understand the *_holds results mentioned above. Are
> they an artifact of the data under test? Or do they suggest a
> remaining bug? I'm a bit fuzzy on what to expect for *_holds though
On 1/15/19 11:42 AM, Masahiko Sawada wrote:
When you troubleshoot applicative issues with multi-statements transaction, you
may have to log all queries to find all statements of one transaction. With
high throughput, it could be hard to log all queries without causing troubles.
Hm, can we use
Hi,
On 2019-01-15 14:37:36 +0530, Amit Khandekar wrote:
> Then for each of the calls, we would need to declare that structure
> variable (with = {0}) and assign required fields in that structure
> before passing it to ArchiveEntry(). But a major reason of
> ArchiveEntry() is to avoid doing this
On 1/15/19 11:28 AM, Michael Paquier wrote:
On Tue, Jan 15, 2019 at 11:19:48AM +0500, Andrey Borodin wrote:
Is it possible to avoid those memcpy's by aligning available buffers
instead? I couldn't understand this from the patch and this thread.
Sure, it had better do that. That's just a
I wrote:
> Haribabu Kommi writes:
>> Excluding the file in the backup can solve the problem of backup by an
>> unprivileged user. Is there any scenarios it can cause problems if it
>> doesn't follow the group access mode?
> The point of this file, as I understood it, was to allow someone who's
>
Hello,
Today I bumped into need to limit first VACUUM time on data import.
I'm using utility called osmium together with COPY FREEZE to import
openstreetmap data into database.
osmium export -c osmium.config -f pg belarus-latest.osm.pbf -v --progress
| psql -1 -c 'create table byosm(geom
On 14/01/2019 13:23, Daniel Verite wrote:
> On a table with pre-existing contents, the creation of a unique index
> does not seem to detect the duplicates that are equal per the
> collation and different binary-wise.
Fixed in the attached updated patch.
--
Peter Eisentraut
Haribabu Kommi writes:
> Excluding the file in the backup can solve the problem of backup by an
> unprivileged user. Is there any scenarios it can cause problems if it
> doesn't follow the group access mode?
The point of this file, as I understood it, was to allow someone who's
allowed to read
On Tue, Jan 15, 2019 at 12:47 AM David Rowley
wrote:
> 1. In:
>
> + if (IsA(clause, ScalarArrayOpExpr))
> + {
> + ScalarArrayOpExpr *saop = (ScalarArrayOpExpr *) clause;
> + Node *subexpr = (Node *) ((NullTest *) predicate)->arg;
> + if (op_strict(saop->opno) &&
> + clause_is_strict_for((Node *)
On 15/01/2019 07:31, Amit Langote wrote:
>> Is "partition bound" the right term? For list partitioning, it's not
>> really a bound. Maybe it's OK.
>
> Hmm, maybe "partition bound value"? Just want to stress that the
> expression specifies "bounding" value of a partition.
I was more concerned
On Mon, 14 Jan 2019 at 21:19, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > The problem here of course is that whoever invented target_session_attrs
> > was unconcerned with following that precedent, so what we have is
> >
Dave Cramer
On Sun, 13 Jan 2019 at 23:19, Craig Ringer wrote:
> On Mon, 3 Dec 2018 at 19:38, Dave Cramer wrote:
>
>> Dmitry,
>>
>> Please see attached rebased patches
>>
>
> I'm fine with patch 0001, though I find this comment a bit hard to follow:
>
> + * The send_data callback must enqueue
On Wed, Jan 2, 2019, at 12:36, Alexander Kukushkin wrote:
> Hi,
>
> On Wed, 2 Jan 2019 at 12:17, Oleksii Kliukin wrote:
>
> > Thank you. Attached the new version(called it v8) with the following
> > changes to the documentation:
>
> Thank you for jumping on it. Your changes look good to me.
>
> On Tue, Jan 15, 2019 at 10:52 AM Amit Khandekar
> wrote:
>
> Need to bump K_VERS_MINOR as well.
I've bumped it up, but somehow this change escaped the previous version. Now
should be there, thanks!
> On Mon, 14 Jan 2019 at 18:36, Amit Khandekar wrote:
> > +static void
On 1/15/19 11:07 AM, Surafel Temesgen wrote:
>
>
> On Wed, Jan 2, 2019 at 6:19 PM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
> After looking at the "FETCH FIRST ... PERCENT" patch, I wonder if this
> patch should tweak estimates in some way. Currently, the
On 15/01/2019 11:49, Andrew Gierth wrote:
>> "Jack" == Jack LIU writes:
>
> Jack> Hi Andrew,
> Jack> This is my code to call the procedure with
> Jack> SPI_connect_ext(SPI_OPT_NONATOMIC).
>
> Ah. You need to take a look at exec_stmt_call in plpgsql, and do the
> same things it does with
> "Jack" == Jack LIU writes:
Jack> Hi Andrew,
Jack> This is my code to call the procedure with
Jack> SPI_connect_ext(SPI_OPT_NONATOMIC).
Ah. You need to take a look at exec_stmt_call in plpgsql, and do the
same things it does with snapshot management (specifically, setting the
On Sat, Jan 5, 2019 at 12:57 AM Adrien Mobile
wrote:
>
> Le 4 janvier 2019 13:20:09 GMT+01:00, Peter Eisentraut
> a écrit :
> >On 12/12/2018 22:32, Adrien Nayrat wrote:
> >> Per idea of Nikolay Samokhvalov[1] I propose this patch to add the
> >possibility
> >> to log all statements from a
> "Andres" == Andres Freund writes:
>> In particular, how does it know how every strtod() on the planet
>> will react to specific input?
Andres> strtod()'s job ought to computationally be significantly easier
Andres> than the other way round, no? And if there's buggy strtod()
Andres>
On Sat, Dec 1, 2018 at 10:49 AM Thomas Munro
wrote:
>
> On Sat, Dec 1, 2018 at 9:06 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > Unfortunately, cfbot says that patch can't be applied without conflicts,
> > could
> > you please post a rebased version and address commentaries from Masahiko?
On Wed, Jan 2, 2019 at 6:19 PM Tomas Vondra
wrote:
> After looking at the "FETCH FIRST ... PERCENT" patch, I wonder if this
> patch should tweak estimates in some way. Currently, the cardinality
> estimate is the same as for plain LIMIT, using the requested number of
> rows. But let's say there
On 1/15/19 9:00 AM, Kuroda, Hayato wrote:
Dear Adrien,
I applied your file and faced a bug-candidate.
(I have not read your source yet. Sorry.)
When I tried to use tab-complition, some dirty messages were appeared.
Messages I faced are attached in this mail.
Best Regards,
Hayato Kuroda
On Tue, 15 Jan 2019 at 12:27, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Mon, Jan 14, 2019 at 2:07 PM Amit Khandekar
> > wrote:
> >
> > createPQExpBuffer() should be moved after the below statement, so that
> > it does not leak memory
>
> Thanks for noticing, fixed.
Looks good.
>
>
út 15. 1. 2019 v 10:47 odesílatel Pavel Stehule
napsal:
> Hi
>
> make check-world fails
>
> t/008_diff_schema.pl .. ok
> t/009_matviews.pl . ok
> t/010_truncate.pl . ok
> t/011_generated.pl # Looks like your test exited with 29 before it
> could output anything.
> t/011_generated.pl
Hi
make check-world fails
t/008_diff_schema.pl .. ok
t/009_matviews.pl . ok
t/010_truncate.pl . ok
t/011_generated.pl # Looks like your test exited with 29 before it
could output anything.
t/011_generated.pl Dubious, test returned 29 (wstat 7424, 0x1d00)
Failed 2/2 subtests
On Sat, 12 Jan 2019 at 18:11, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > On Sat, Jan 12, 2019 at 1:44 AM Andres Freund wrote:
> > > /* other fields were zeroed above */
> > >
> > > @@ -9355,7 +9370,7 @@ dumpComment(Archive *fout, const char *type, const
> > > char *name,
> >
On Tue, Jan 15, 2019 at 4:15 PM Michael Paquier wrote:
> On Tue, Jan 15, 2019 at 03:08:41PM +1100, Haribabu Kommi wrote:
> > current_logfiles is a meta data file, that stores the current log writing
> > file, and this file presents in the data directory. This file
> > doesn't follow the group
On Tue, Jan 15, 2019 at 11:19:48AM +0500, Andrey Borodin wrote:
> Is it possible to avoid those memcpy's by aligning available buffers
> instead? I couldn't understand this from the patch and this thread.
Sure, it had better do that. That's just a lazy implementation.
--
Michael
signature.asc
> 12 янв. 2019 г., в 9:46, Michael Paquier написал(а):
>
> Note that pg_attribute_aligned() cannot be used as that's not an
> option with clang and a couple of other comilers as far as I know, so
> the patch uses a simple set of placeholder buffers large enough to be
> aligned with the OS
Dear Adrien,
I applied your file and faced a bug-candidate.
(I have not read your source yet. Sorry.)
When I tried to use tab-complition, some dirty messages were appeared.
Messages I faced are attached in this mail.
Best Regards,
Hayato Kuroda
Fujitsu LIMITED
postgres=# SET
79 matches
Mail list logo
