> "Jonathan" == Jonathan Jacobson writes:
Jonathan> As opposed to config_file, hba_file, etc. the name and
Jonathan> location of the autoconfig file is fixed to
Jonathan> $PGDATA/postgresql.auto.conf (guc.h)
The reason it's in a fixed location is that the server needs to be able
to rewrit
On Fri, Oct 05, 2018 at 03:31:49PM +0900, Amit Langote wrote:
> Thanks for making those changes yourself and posting the new version.
>
> Can you check the attached diff file for some updates to the documentation
> part of the patch. Other parts look fine.
OK, I merged that into my local branch.
On Fri, Oct 05, 2018 at 09:39:03AM +0300, Jonathan Jacobson wrote:
> As opposed to config_file, hba_file, etc. the name and location of the
> autoconfig file is fixed to $PGDATA/postgresql.auto.conf (guc.h)
>
> The static name also appears in some other locations, such as
> pg_basebackup, pg_rewin
As opposed to config_file, hba_file, etc. the name and location of the
autoconfig file is fixed to $PGDATA/postgresql.auto.conf (guc.h)
The static name also appears in some other locations, such as
pg_basebackup, pg_rewind & initdb.c.
New feature suggestion: Allow to set the file's location, as w
On Fri, Oct 05, 2018 at 12:16:03PM +0900, Michael Paquier wrote:
> 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 improved. Thoughts?
And so... I have been looking at com
On 2018/10/05 14:56, Michael Paquier wrote:
> 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 Am
Thanks for the report.
On 2018/10/04 3:58, Rajkumar Raghuwanshi wrote:
> 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 LA
pá 5. 10. 2018 v 7:57 odesílatel Michael Paquier
napsal:
> 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
>
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
vers
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 singl
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, lo
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",
fileName=0x5614525
"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.
T
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 improve
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 lane
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 integra
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 mai
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 ind
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 noth
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 really
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. Wh
> "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?
Yes.
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 signature
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.
--
Mi
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, a
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 l
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 done
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 EState
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 int
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 enoug
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 track_fu
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 tak
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 c
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 │
├─┤
│ a
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 force_parallel_mod
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 rewr
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 patches
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 inte
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 co
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() calls
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 P
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 this will be helpful to you (and I appreciate there's still
the underlying P
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
> th
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 extremel
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 1000
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 te
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.
No
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 si
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 again
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 abil
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 p
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 upth
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 a
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. OTO
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 revie
> 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());
>>
>> https://ci.appveyor.
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
Looki
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 t
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 o
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 2
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 com
80 matches
Mail list logo
