On Thu, Oct 04, 2018 at 05:18:07PM +0900, Michael Paquier wrote:
> So it seems that I am clearly outvoted here ;)
>
> Okay, let's do as you folks propose.
And attached is a newer version with this isleaf stuff and the previous
feedback from Amit integrated, as long as I recall about it. The
On Fri, Oct 5, 2018 at 12:16 PM Michael Paquier wrote:
>
> On Wed, Oct 03, 2018 at 04:37:29PM +0900, Masahiko Sawada wrote:
> > Thank you for the comment. Attached the updated patch.
>
> So, I have come back to this stuff, and finished with the attached
> instead, so as the assertion is in a
On Thu, Oct 4, 2018 at 8:25 PM Alvaro Herrera wrote:
>
> On 2018-Oct-01, Rajkumar Raghuwanshi wrote:
>
> > On Tue, Sep 18, 2018 at 11:20 AM amul sul wrote:
> >
> > > Here is the complete patch proposes the aforesaid fix with regression
> > > test.
> >
> > Thanks, This worked for me.
>
> Yeah,
Hi all,
Running installcheck on an instance with log_min_messages = DEBUG1, I
can bump into the following assertion failure:
#2 0x56145231e82c in ExceptionalCondition
(conditionName=0x56145258ae0b "!(strvalue != ((void *)0))",
errorType=0x56145258adfb "FailedAssertion",
"Jonathan S. Katz" writes:
> On 10/4/18 8:34 PM, Michael Paquier wrote:
>> I am suggesting to fix the issue after RC1 is released, but before GA.
> That approach would mean we would require an RC2, which would further
> delay the GA.
Not sure about that. Alvaro seems to think there's a generic
On 10/4/18 8:34 PM, Michael Paquier wrote:
> On Thu, Oct 04, 2018 at 04:54:45PM -0700, Andres Freund wrote:
>> Are you suggesting we fix after RC1, or delay RC1? I'm not 100% sure
>> I'm parsing your sentence correctly.
>
> I am suggesting to fix the issue after RC1 is released, but before GA.
On Wed, Oct 03, 2018 at 04:37:29PM +0900, Masahiko Sawada wrote:
> Thank you for the comment. Attached the updated patch.
So, I have come back to this stuff, and finished with the attached
instead, so as the assertion is in a single place. I find that
clearer. The comments have also been
Thomas Munro writes:
> I suppose someone might mistake this for a function that converts -42
> to 42... would something like INVERT_COMPARE_RESULT() be better?
I have no particular allegiance to the macro name; it's just the
first idea that came to mind.
regards, tom
On Fri, Oct 5, 2018 at 3:12 PM Tom Lane wrote:
> Here's a draft patch against HEAD for this.
+ * Invert the sign of a qsort-style comparison result, ie, exchange negative
+ * and positive integer values, being careful not to get the wrong answer
+ * for INT_MIN. The argument should be an
I wrote:
> Andres Freund writes:
>> On 2018-10-01 12:13:57 -0400, Tom Lane wrote:
>>> (2) Drop the restriction. This'd require at least changing the
>>> DESC correction, and maybe other things. I'm not sure what the
>>> odds would be of finding everyplace we need to check.
>> (2) seems more
On 2018/10/05 5:59, Tom Lane wrote:
> Amit Langote writes:
>> I've rebased the remaining patches. I broke down one of the patches into
>> 2 and re-ordered the patches as follows:
>
>> 0001: introduces a function that opens range table relations and maintains
>> them in an array indexes by RT
gSQL function
> stacked_diagnostics_test() line 6 at PERFORM]
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.15234
please, check attached patch
Thank you for report
Pavel
>
> --
> Thomas Munro
> http://www.enterprisedb.com
>
schema-variables-20181004-02.patch.gz
Description: application/gzip
Hi all,
The topic of $subject has been discussed a bit times, resulting in a
couple of patches on the way:
https://www.postgresql.org/message-id/20180830200258.gg15...@paquier.xyz
https://www.postgresql.org/message-id/cabuevezekrwpegk2o-ov4z2mjft6cu8clfa-v1s1j4z8x7w...@mail.gmail.com
However
On Wed, 3 Oct 2018 at 17:36, David Rowley wrote:
> I know commit fest is over, but I made a pass of this to hopefully
> provide a bit of guidance so that it's closer for the November 'fest.
Hi David. Thanks for the review. It's fairly thorough and you must
have put some time into it -- I
On 10/4/18, 7:31 PM, "Michael Paquier" wrote:
> Committed this way with a catalog version bump.
Thanks!
Nathan
čt 4. 10. 2018 v 23:57 odesílatel Tom Lane napsal:
> I wrote:
> > Pavel Stehule writes:
> >> I found two parts
>
> > Thanks for the report, will push something.
>
> On closer look, I'm not sure that these are the only places that are
> assuming that any PLpgSQL_variable struct has a refname.
> "Andreas" == Andreas Karlsson writes:
> On 10/03/2018 05:57 PM, David Fetter wrote:
>> Is there any meaningful distinction between "inlining," by which I
>> mean converting to a subquery, and predicate pushdown, which
>> would happen at least for a first cut, at the rewrite stage?
On Thu, Oct 04, 2018 at 04:54:45PM -0700, Andres Freund wrote:
> Are you suggesting we fix after RC1, or delay RC1? I'm not 100% sure
> I'm parsing your sentence correctly.
I am suggesting to fix the issue after RC1 is released, but before GA.
--
Michael
signature.asc
Description: PGP
On Thu, Oct 04, 2018 at 02:23:34PM +0200, Laurenz Albe wrote:
> Bossart, Nathan wrote:
>> Alright, here's an updated patch.
>
> Looks, good; marking as "ready for committer".
Like Tom, I think it is less dirty to use the two-function approach.
Committed this way with a catalog version bump.
--
Hi,
On 2018-10-05 08:29:29 +0900, Michael Paquier wrote:
> On Thu, Oct 04, 2018 at 06:04:49PM -0400, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> I'm tied up in something else at the moment so can't spend more time on
> >> it, but I hope to have time to give it a look over the weekend.
> >
>
On Thu, Aug 3, 2017 at 1:41 PM Robert Haas wrote:
> On Wed, Aug 2, 2017 at 9:33 PM, Peter Eisentraut
> wrote:
> > On 8/2/17 16:52, Robert Haas wrote:
> >> I actually don't think it's that unreasonable to get notified when
> >> system-wide processes like the autovacuum launcher or the logical
>
On Thu, Oct 04, 2018 at 06:04:49PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> I'm tied up in something else at the moment so can't spend more time on
>> it, but I hope to have time to give it a look over the weekend.
>
> Keep in mind that RC1 is scheduled to wrap Monday afternoon ...
Alvaro Herrera writes:
> I'm tied up in something else at the moment so can't spend more time on
> it, but I hope to have time to give it a look over the weekend.
Keep in mind that RC1 is scheduled to wrap Monday afternoon ...
regards, tom lane
On 2018-Oct-03, Michael Paquier wrote:
> Okay. I have spent more time on this issue, and I have been able to
> integrate a test in the existing event_trigger.sql which is able to
> reproduce the reported failure. Attached is what I am finishing with.
>
> I still want to do more testing on it,
I wrote:
> Pavel Stehule writes:
>> I found two parts
> Thanks for the report, will push something.
On closer look, I'm not sure that these are the only places that are
assuming that any PLpgSQL_variable struct has a refname. What seems
like a safer answer is to make sure they all do, more or
Pavel Stehule writes:
> There are new assert
> Assert(strvalue != NULL);
> probably all refname usage inside plpgsql dump functions has problem with
> it.
This isn't so much a "new assert" as a modeling of the fact that some
printf implementations dump core on a null string pointer, and have
Amit Langote writes:
> I've rebased the remaining patches. I broke down one of the patches into
> 2 and re-ordered the patches as follows:
> 0001: introduces a function that opens range table relations and maintains
> them in an array indexes by RT index
> 0002: introduces a new field in
Hi
Today I had broken plpgsql_check tests aganst PostgreSQL 12. After command
create or replace function ml_trg()
returns trigger as $$
#option dump
declare
begin
if TG_OP = 'INSERT' then
if NEW.status_from IS NULL then
begin
-- performance issue only
select status
Robert Haas writes:
> On Thu, Oct 4, 2018 at 3:28 PM Tom Lane wrote:
>> What we've determined so far in this thread is that workers *do* get
>> their own locks (or did before yesterday), but I'd been supposing that
>> that was accidental not intentional.
> Nope, that was intentional.
Fair
Hi,
On 2018-10-04 12:15:28 -0700, Lukas Fittl wrote:
> Hi all,
>
> It seems that currently procedures do not get tracked when track_functions
> is enabled, which means one needs to resort to other workarounds in order
> to monitor procedure calls/runtime.
>
> To illustrate:
>
> =# SHOW
On Thursday, October 4, 2018 4:46:26 PM CEST Geoff Winkless wrote:
> On Thu, 4 Oct 2018 at 13:11, Pierre Ducroquet wrote:
> > Our developpers ORM (Django's) sadly can not use EXISTS in the where
> > clauses
> > without having it in the expression part of the SELECT statement.
>
> I don't know if
On Thu, Oct 4, 2018 at 3:28 PM Tom Lane wrote:
> I'm possibly confused, but I thought that the design of parallel query
> involved an expectation that workers didn't need to get their own locks.
You are, indeed, confused. A heck of a lot of effort went into making
sure that the workers COULD
On 2018-10-04 12:34:44 -0700, Andres Freund wrote:
> Hi,
>
> On 2018-10-04 15:27:59 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > I've not really followed this thread, and just caught up to here. It
> > > seems entirely unacceptable to not acquire locks on workers to me.
> > > Maybe I'm
Hi,
On 2018-10-04 15:27:59 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I've not really followed this thread, and just caught up to here. It
> > seems entirely unacceptable to not acquire locks on workers to me.
> > Maybe I'm missing something, but why do/did the patches in this thread
>
Andres Freund writes:
> I've not really followed this thread, and just caught up to here. It
> seems entirely unacceptable to not acquire locks on workers to me.
> Maybe I'm missing something, but why do/did the patches in this thread
> require that / introduce that? We didn't have that kind of
Hi all,
It seems that currently procedures do not get tracked when track_functions
is enabled, which means one needs to resort to other workarounds in order
to monitor procedure calls/runtime.
To illustrate:
=# SHOW track_functions;
┌─┐
│ track_functions │
├─┤
│
Hi,
On 2018-10-03 16:16:11 -0400, Tom Lane wrote:
> I wrote:
> > Amit Langote writes:
> >> Should this check that we're not in a parallel worker process?
>
> > Hmm. I've not seen any failures in the parallel parts of the regular
> > regression tests, but maybe I'd better do a
Today Brazil's president announced that the DST for all our time zones
would start at November 18th instead of November 4th
There's already a thread at IANA about it
https://mm.icann.org/pipermail/tz/2018-October/026921.html
*Emílio B. Pedrollo*
Full Stack Developer
+55 (55) 99134-7922
On Thu, Oct 04, 2018 at 11:22:32AM +0200, Andreas Karlsson wrote:
> On 10/03/2018 05:57 PM, David Fetter wrote:
> >Is there any meaningful distinction between "inlining," by which I
> >mean converting to a subquery, and predicate pushdown, which
> >would happen at least for a first cut, at the
I have only done the below two changes yet. After doing that and
rebasing with latest master, in the regression I got crashes, and I
suspect the reason being that I have used Virtual tuple slot for the
destination slot of execute_attr_map_slot(). I am analyzing it. I am
anyway attaching the
On 2018-Oct-04, Alvaro Herrera wrote:
> I admit I'm surprised that your patch fixes the bug. sql_drop was added
> before the command-stashing was added for pg_event_trigger_ddl_commands
> was added, and sql_drop only processes objects from the list passed to
> performMultipleDeletions, so adding
> On Wed, 3 Oct 2018 at 09:53, Michael Paquier wrote:
>
> On Fri, Sep 28, 2018 at 12:17:00PM +0900, Michael Paquier wrote:
> > I think that Alvaro should definitely look at this patch to be sure, or
> > I could do it, but I would need to spend way more time on this and check
> > event trigger
On 04.10.2018 12:19, David Rowley wrote:
On 4 October 2018 at 22:11, Konstantin Knizhnik
wrote:
On 04.10.2018 06:19, David Rowley wrote:
Please, can you also add a test which tests this code which has a
partition with columns in a different order than it's parent. Having
an INT and a TEXT
I admit I'm surprised that your patch fixes the bug. sql_drop was added
before the command-stashing was added for pg_event_trigger_ddl_commands
was added, and sql_drop only processes objects from the list passed to
performMultipleDeletions, so adding the EventTriggerAlterTableStart() /
End()
On 2018-Oct-01, Rajkumar Raghuwanshi wrote:
> On Tue, Sep 18, 2018 at 11:20 AM amul sul wrote:
>
> > Here is the complete patch proposes the aforesaid fix with regression test.
>
> Thanks, This worked for me.
Yeah, looks good to me, pushed. I added one more regression test to
ensure that the
Amit Langote writes:
> On 2018/10/04 5:16, Tom Lane wrote:
>> I think that we ought to adjust parallel query to insist that children
>> do take locks, and then revert the IsParallelWorker() exceptions I made
>> here.
> Maybe I'm missing something here, but isn't the necessary adjustment just
>
Amit Kapila writes:
> All the affected members (gharial, chipmunk, anole) are happy. It
> feels good to see chipmunk becoming green after so many days.
Yup. I've marked this item fixed on the open-items list.
regards, tom lane
Hi,
It's the same logic with any polling system. An integration calculation using
monte-carlo method with only a few points won't be accurate enough and can even
be completely wrong etc.
Polling is OK to troubleshoot a problem on the fly but 2 points are not enough.
A few seconds are needed to
Bossart, Nathan wrote:
> >> AFAICT the cleanest way to do this in system_views.sql is to hard-code
> >> the pg_default tablespace OID in the DEFAULT expression. So, it might
> >> be best to use the two function approach if we want pg_ls_tmpdir() to
> >> default to the pg_default tablespace.
> >
>
Hello
Our developpers ORM (Django's) sadly can not use EXISTS in the where clauses
without having it in the expression part of the SELECT statement.
I was expecting it to create queries performing a bit worse than queries
without this useless expression, but it turns out this trigger an
Hi;
System is PostgreSQL 10.5, all partitioning done the old way (via
inheritance).
Last month we had some performance issues caused by statistics being out of
date and the planner choosing the wrong index for a large number of
queries. The proximal fix was to increase the stats target from
Hi,
I am getting ERROR: null relpartbound for relation 18159 while doing
pg_upgrade from v11 to v11/master.
-- user-defined operator class in partition key
CREATE FUNCTION my_int4_sort(int4,int4) RETURNS int LANGUAGE sql
AS $$ SELECT CASE WHEN $1 = $2 THEN 0 WHEN $1 > $2 THEN 1 ELSE -1 END;
Michael Paquier wrote:
> > In that vein, I propose a function pg_promote() to promote
> > physical standby servers.
>
> No fundamental issues from me regarding the concept of being able to
> trigger a promotion remotely, so +1. Do we want this capability as well
> for fallback_promote? My gut
On Thu, Oct 04, 2018 at 10:06:06AM +0200, Daniel Gustafsson wrote:
> Yes, you are correct, the signalfuncs.h includes in 0001 are a rebase error
> from when I renamed the file. They are not present in the v15 patch but got
> introduced in v16 when I clearly wasn’t caffeinated enough to rebase.
On Thu, Oct 04, 2018 at 09:32:37AM +, Phil Florent wrote:
> I am a DB beginner, so please tell me. It says that you can find
> events that are bottlenecks in sampling, but as you saw above, you can
> not find events shorter than the sampling interval, right?
Yes, which is why it would be as
On 01.10.2018 09:49, Michael Paquier wrote:
On Mon, Aug 20, 2018 at 06:00:39PM +0300, Konstantin Knizhnik wrote:
New version of the patch is attached: I removed -Z options form pgbench and
psql and add checking that server and client are implementing the same
compression algorithm.
The patch
Hi,
I am a DB beginner, so please tell me. It says that you can find events that
are bottlenecks in sampling, but as you saw above, you can not find events
shorter than the sampling interval, right?
If an event occurs frequently and if it is reported in pg_stat_activity, you
will catch it
On 10/03/2018 05:57 PM, David Fetter wrote:
Is there any meaningful distinction between "inlining," by which I
mean converting to a subquery, and predicate pushdown, which
would happen at least for a first cut, at the rewrite stage?
Sorry, but I do not think I understand your question. The
On 4 October 2018 at 22:11, Konstantin Knizhnik
wrote:
> On 04.10.2018 06:19, David Rowley wrote:
>> Please, can you also add a test which tests this code which has a
>> partition with columns in a different order than it's parent. Having
>> an INT and a TEXT column is best as if the translations
On Mon, Oct 1, 2018 at 7:20 PM Masahiko Sawada wrote:
>
> Hi,
>
> Attached patch adds a new option FREEZE_ONLY to VACUUM command. This
> option is same as FREEZE option except for it disables reclaiming dead
> tuples. That is, with this option vacuum does pruning HOT chain,
> freezing live tuples
On 04.10.2018 06:19, David Rowley wrote:
On 12 September 2018 at 08:32, Konstantin Knizhnik
wrote:
Also the patch proposed by you is much simple and does mostly the same. Yes,
it is not covering CHECK constraints,
I started to look at this and found a problem in regards to varno
during the
Imai-san,
On 2018/10/04 17:11, Imai, Yoshikazu wrote:
> Hi, Amit!
>
> On Thu, Sept 13, 2018 at 10:29 PM, Amit Langote wrote:
>> Attached is what I have at the moment.
>
> I also do the code review of the patch.
Thanks a lot for your review. I'm working on updating the patches as
mentioned
On Thu, July 26, 2018 at 1:25 AM, Michael Paquier wrote:
> Even if you have spiky workloads, sampling may miss those, but even with
> adding counters for each event
> you would need to query the table holding the counters at an insane frequency
> to be able to perhaps get
> something out of it
On Thu, Oct 04, 2018 at 04:53:02PM +0900, Amit Langote wrote:
> As mentioned in my other reply, that might be considered as asking the
> user to know inner details like relkind. Also, if a database has many
> partitioned tables with lots of partitions, the pg_class join might get
> expensive.
Hi, Amit!
On Thu, Sept 13, 2018 at 10:29 PM, Amit Langote wrote:
> Attached is what I have at the moment.
I also do the code review of the patch.
I could only see a v3-0001.patch so far, so below are all about v3-0001.patch.
I am new to inheritance/partitioning codes and code review, so my
> On 4 Oct 2018, at 09:59, Michael Paquier wrote:
>
> On Wed, Oct 03, 2018 at 12:09:54PM +1300, Thomas Munro wrote:
>> It looks like you missed another case that needs tolerance for late
>> signal delivery on Windows:
>>
>> +select pg_cancel_backend(pg_backend_pid());
>>
>>
On Wed, Oct 03, 2018 at 12:09:54PM +1300, Thomas Munro wrote:
> It looks like you missed another case that needs tolerance for late
> signal delivery on Windows:
>
> +select pg_cancel_backend(pg_backend_pid());
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.15263
On 2018/10/04 9:27, Michael Paquier wrote:
> On Wed, Oct 03, 2018 at 08:12:59AM -0400, Jesper Pedersen wrote:
>> Removing isleaf would require extra round trips to the server to get
>> that information. So, I think we should keep it.
>
> I don't really get your point about extra round trips with
On 2018/10/03 12:37, Michael Paquier wrote:
> On Mon, Oct 01, 2018 at 04:27:57PM +0900, Amit Langote wrote:
>> Yeah, maybe there is no reason to delay proceeding with
>> pg_partition_children which provides a useful functionality.
>
> So, I have been looking at your patch, and there are a couple
On Thu, Oct 4, 2018 at 9:50 AM Adrien Nayrat wrote:
>
> On 10/3/18 11:29 PM, Daniel Wood wrote:
> > If running benchmarks or you are a customer which is currently impacted by
> > GetSnapshotData() on high end multisocket systems be wary of Skylake-S.
> >
> >
> > Performance differences of nearly
On 2018/10/04 5:16, Tom Lane wrote:
> I wrote:
>> Amit Langote writes:
>>> Should this check that we're not in a parallel worker process?
>
>> Hmm. I've not seen any failures in the parallel parts of the regular
>> regression tests, but maybe I'd better do a force_parallel_mode
>> run before
On 10/3/18 11:29 PM, Daniel Wood wrote:
> If running benchmarks or you are a customer which is currently impacted by
> GetSnapshotData() on high end multisocket systems be wary of Skylake-S.
>
>
> Performance differences of nearly 2X can be seen on select only pgbench due to
> nothing else but
72 matches
Mail list logo
