Alvaro Herrera writes:
> While messing with BRIN bugs, I noticed this debug message in the server
> log:
> 2017-11-01 12:33:24.042 CET [361429] DEBUG: rehashing catalog cache id 14
> for pg_opclass; 17 tups, 8 buckets en carácter 194
> notice that at the end it says "at character 194". I suppos
While messing with BRIN bugs, I noticed this debug message in the server
log:
2017-11-01 12:33:24.042 CET [361429] DEBUG: rehashing catalog cache id 14 for
pg_opclass; 17 tups, 8 buckets en carácter 194
notice that at the end it says "at character 194". I suppose that's
because of some leftove
On Thu, Jun 8, 2017 at 1:17 PM, Pavel Stehule wrote:
> 2017-06-08 17:19 GMT+02:00 Robert Haas :
>> On Wed, Jun 7, 2017 at 12:30 PM, Pavel Stehule
>> wrote:
>> > I got strange error message - false message - max connection is less on
>> > slave than on master, although these numbers was same. The
2017-06-08 17:19 GMT+02:00 Robert Haas :
> On Wed, Jun 7, 2017 at 12:30 PM, Pavel Stehule
> wrote:
> > I got strange error message - false message - max connection is less on
> > slave than on master, although these numbers was same. The issue was in
> > wrong connection string in recovery conf a
On Wed, Jun 7, 2017 at 12:30 PM, Pavel Stehule wrote:
> I got strange error message - false message - max connection is less on
> slave than on master, although these numbers was same. The issue was in
> wrong connection string in recovery conf and slave cannot to check master
> and used some defa
Hi
I got strange error message - false message - max connection is less on
slave than on master, although these numbers was same. The issue was in
wrong connection string in recovery conf and slave cannot to check master
and used some defaults.
Regards
Pavel
On Tue, Apr 11, 2017 at 12:15 PM, Robert Haas wrote:
> On Mon, Apr 10, 2017 at 7:17 PM, Tomas Vondra
> wrote:
>> At first I was like 'WTF? Why do we need a new GUC just becase of an
>> assert?' but you're actually not adding a new GUC parameter, you're adding a
>> constant which is then used as a
On Mon, Apr 10, 2017 at 7:17 PM, Tomas Vondra
wrote:
> At first I was like 'WTF? Why do we need a new GUC just becase of an
> assert?' but you're actually not adding a new GUC parameter, you're adding a
> constant which is then used as a max value for max for the two existing
> parallel GUCs.
>
>
On Tue, Apr 11, 2017 at 2:36 AM, Robert Haas wrote:
> On Mon, Apr 10, 2017 at 2:32 PM, Neha Khatri wrote:
>> On Tue, Apr 11, 2017 at 1:16 AM, Robert Haas wrote:
>>> 1. Forget BGW_NEVER_RESTART workers in
>>> ResetBackgroundWorkerCrashTimes() rather than leaving them around to
>>> be cleaned up a
On 04/10/2017 01:39 PM, Kuntal Ghosh wrote:
On Thu, Apr 6, 2017 at 6:50 AM, Robert Haas wrote:
On Wed, Apr 5, 2017 at 8:17 PM, Neha Khatri wrote:
The problem here seem to be the change in the max_parallel_workers value
while the parallel workers are still under execution. So this poses two
qu
On Mon, Apr 10, 2017 at 2:32 PM, Neha Khatri wrote:
> On Tue, Apr 11, 2017 at 1:16 AM, Robert Haas wrote:
>> 1. Forget BGW_NEVER_RESTART workers in
>> ResetBackgroundWorkerCrashTimes() rather than leaving them around to
>> be cleaned up after the conclusion of the restart, so that they go
>> away
On Tue, Apr 11, 2017 at 1:16 AM, Robert Haas wrote:
>
> 1. Forget BGW_NEVER_RESTART workers in
> ResetBackgroundWorkerCrashTimes() rather than leaving them around to
> be cleaned up after the conclusion of the restart, so that they go
> away before rather than after shared memory is reset.
Now
[ Adding Julien, whose patch this was. ]
On Thu, Apr 6, 2017 at 5:34 AM, Kuntal Ghosh wrote:
> While performing StartupDatabase, both master and standby server
> behave in similar way till postmaster spawns startup process.
> In master, startup process completes its job and dies. As a result,
> r
On Thu, Apr 6, 2017 at 6:50 AM, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 8:17 PM, Neha Khatri wrote:
>> The problem here seem to be the change in the max_parallel_workers value
>> while the parallel workers are still under execution. So this poses two
>> questions:
>>
>> 1. From usecase point
On Thu, Apr 06, 2017 at 03:04:13PM +0530, Kuntal Ghosh wrote:
> On Wed, Apr 5, 2017 at 6:49 PM, Amit Kapila wrote:
> > On Wed, Apr 5, 2017 at 12:35 PM, Kuntal Ghosh
> > wrote:
> >> On Tue, Apr 4, 2017 at 11:22 PM, Tomas Vondra
> >>> I'm probably missing something, but I don't quite understand how
On Wed, Apr 5, 2017 at 6:49 PM, Amit Kapila wrote:
> On Wed, Apr 5, 2017 at 12:35 PM, Kuntal Ghosh
> wrote:
>> On Tue, Apr 4, 2017 at 11:22 PM, Tomas Vondra
>>> I'm probably missing something, but I don't quite understand how these
>>> values actually survive the crash. I mean, what I observed is
On Wed, Apr 5, 2017 at 8:17 PM, Neha Khatri wrote:
> The problem here seem to be the change in the max_parallel_workers value
> while the parallel workers are still under execution. So this poses two
> questions:
>
> 1. From usecase point of view, why could there be a need to tweak the
> max_paral
On Wed, Apr 5, 2017 at 5:34 PM, Kuntal Ghosh
wrote:
> On Tue, Apr 4, 2017 at 12:16 PM, Neha Khatri
> wrote:
>
> > I feel there should be an assert if
> > (BackgroundWorkerData->parallel_register_count -
> > BackgroundWorkerData->parallel_terminate_count) > max_parallel_workers)
> >
> Backen
On 04/05/2017 04:26 PM, Kuntal Ghosh wrote:
On Wed, Apr 5, 2017 at 7:45 PM, Robert Haas wrote:
On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh
wrote:
Did you intend to attach that patch to this email?
Actually, I'm confused how we should ensure (register_count >
terminate_count) invariant. I
On Wed, Apr 5, 2017 at 7:45 PM, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh
> wrote:
>>> Did you intend to attach that patch to this email?
>>>
>> Actually, I'm confused how we should ensure (register_count >
>> terminate_count) invariant. I think there can be a system cras
On 04/05/2017 04:15 PM, Robert Haas wrote:
On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh
wrote:
Did you intend to attach that patch to this email?
Actually, I'm confused how we should ensure (register_count >
terminate_count) invariant. I think there can be a system crash what
Tomas has sugge
On 04/05/2017 04:09 PM, Kuntal Ghosh wrote:
On Wed, Apr 5, 2017 at 7:31 PM, Robert Haas wrote:
On Wed, Apr 5, 2017 at 6:36 AM, Kuntal Ghosh wrote:
Yes. But, as Robert suggested up in the thread, we should not use
(parallel_register_count = 0) as an alternative to define a bgworker
crash. Henc
On Wed, Apr 5, 2017 at 10:09 AM, Kuntal Ghosh
wrote:
>> Did you intend to attach that patch to this email?
>>
> Actually, I'm confused how we should ensure (register_count >
> terminate_count) invariant. I think there can be a system crash what
> Tomas has suggested up in the thread.
>
> Assert(pa
On Wed, Apr 5, 2017 at 7:31 PM, Robert Haas wrote:
> On Wed, Apr 5, 2017 at 6:36 AM, Kuntal Ghosh
> wrote:
>> Yes. But, as Robert suggested up in the thread, we should not use
>> (parallel_register_count = 0) as an alternative to define a bgworker
>> crash. Hence, I've added an argument named 'w
On Wed, Apr 5, 2017 at 6:36 AM, Kuntal Ghosh wrote:
> Yes. But, as Robert suggested up in the thread, we should not use
> (parallel_register_count = 0) as an alternative to define a bgworker
> crash. Hence, I've added an argument named 'wasCrashed' in
> ForgetBackgroundWorker to indicate a bgworke
On Tue, Apr 4, 2017 at 1:52 PM, Tomas Vondra
wrote:
> In any case, the comment right before BackgroundWorkerArray says this:
>
> * These counters can of course overflow, but it's not important here
> * since the subtraction will still give the right number.
>
> which means that this assert
>
> +
On Wed, Apr 5, 2017 at 12:35 PM, Kuntal Ghosh
wrote:
> On Tue, Apr 4, 2017 at 11:22 PM, Tomas Vondra
> wrote:
>> On 04/04/2017 06:52 PM, Robert Haas wrote:
>>>
>>> On Mon, Apr 3, 2017 at 6:08 AM, Kuntal Ghosh
>>> wrote:
On Fri, Mar 31, 2017 at 6:50 PM, Robert Haas
wrote:
>
>>
On 04/05/2017 01:09 PM, Kuntal Ghosh wrote:
On Wed, Apr 5, 2017 at 4:13 PM, Tomas Vondra
wrote:
The comment says that the counters are allowed to overflow, i.e. after a
long uptime you might get these values
parallel_register_count = UINT_MAX + 1 = 1
parallel_terminate_count = U
On Wed, Apr 5, 2017 at 4:13 PM, Tomas Vondra
wrote:
>>>
>>> The comment says that the counters are allowed to overflow, i.e. after a
>>> long uptime you might get these values
>>>
>>> parallel_register_count = UINT_MAX + 1 = 1
>>> parallel_terminate_count = UINT_MAX
>>>
>>> which is fine
On 04/05/2017 12:36 PM, Kuntal Ghosh wrote:
On Wed, Apr 5, 2017 at 3:07 PM, Tomas Vondra
wrote:
On 04/05/2017 09:05 AM, Kuntal Ghosh wrote:
AFAICU, during crash recovery, we wait for all non-syslogger children
to exit, then reset shmem(call BackgroundWorkerShmemInit) and perform
StartupDa
On Wed, Apr 5, 2017 at 3:07 PM, Tomas Vondra
wrote:
>
>
> On 04/05/2017 09:05 AM, Kuntal Ghosh wrote:
>>
>> AFAICU, during crash recovery, we wait for all non-syslogger children
>> to exit, then reset shmem(call BackgroundWorkerShmemInit) and perform
>> StartupDataBase. While starting the startup
On 04/05/2017 09:05 AM, Kuntal Ghosh wrote:
On Tue, Apr 4, 2017 at 11:22 PM, Tomas Vondra
wrote:
On 04/04/2017 06:52 PM, Robert Haas wrote:
On Mon, Apr 3, 2017 at 6:08 AM, Kuntal Ghosh
wrote:
On Fri, Mar 31, 2017 at 6:50 PM, Robert Haas
wrote:
On Thu, Mar 30, 2017 at 4:35 PM, Kuntal G
On Tue, Apr 4, 2017 at 12:16 PM, Neha Khatri wrote:
> I feel there should be an assert if
> (BackgroundWorkerData->parallel_register_count -
> BackgroundWorkerData->parallel_terminate_count) > max_parallel_workers)
>
Backend 1 > SET max_parallel_worker = 8;
Backend 1 > Execute a long running
On Tue, Apr 4, 2017 at 11:22 PM, Tomas Vondra
wrote:
> On 04/04/2017 06:52 PM, Robert Haas wrote:
>>
>> On Mon, Apr 3, 2017 at 6:08 AM, Kuntal Ghosh
>> wrote:
>>>
>>> On Fri, Mar 31, 2017 at 6:50 PM, Robert Haas
>>> wrote:
On Thu, Mar 30, 2017 at 4:35 PM, Kuntal Ghosh
wrote:
On 04/04/2017 06:52 PM, Robert Haas wrote:
On Mon, Apr 3, 2017 at 6:08 AM, Kuntal Ghosh wrote:
On Fri, Mar 31, 2017 at 6:50 PM, Robert Haas wrote:
On Thu, Mar 30, 2017 at 4:35 PM, Kuntal Ghosh
wrote:
2. the server restarts automatically, initialize
BackgroundWorkerData->parallel_register_co
On Mon, Apr 3, 2017 at 6:08 AM, Kuntal Ghosh wrote:
> On Fri, Mar 31, 2017 at 6:50 PM, Robert Haas wrote:
>> On Thu, Mar 30, 2017 at 4:35 PM, Kuntal Ghosh
>> wrote:
>>> 2. the server restarts automatically, initialize
>>> BackgroundWorkerData->parallel_register_count and
>>> BackgroundWorkerData
Looking further in this context, number of active parallel workers is:
parallel_register_count - parallel_terminate_count
Can active workers ever be greater than max_parallel_workers, I think no.
Then why should there be greater than check in the following condition:
if (parallel && (Back
On Fri, Mar 31, 2017 at 6:50 PM, Robert Haas wrote:
> On Thu, Mar 30, 2017 at 4:35 PM, Kuntal Ghosh
> wrote:
>> 2. the server restarts automatically, initialize
>> BackgroundWorkerData->parallel_register_count and
>> BackgroundWorkerData->parallel_terminate_count in the shared memory.
>> After th
On Thu, Mar 30, 2017 at 4:35 PM, Kuntal Ghosh
wrote:
> 2. the server restarts automatically, initialize
> BackgroundWorkerData->parallel_register_count and
> BackgroundWorkerData->parallel_terminate_count in the shared memory.
> After that, it calls ForgetBackgroundWorker and it increments
> paral
On Fri, Mar 31, 2017 at 5:43 AM, Neha Khatri wrote:
>
> On Fri, Mar 31, 2017 at 8:29 AM, Kuntal Ghosh
> wrote:
>>
>> On Fri, Mar 31, 2017 at 2:05 AM, Kuntal Ghosh
>> wrote:
>> >
>> > 1. Put an Assert(0) in ParallelQueryMain(), start server and execute
>> > any parallel query.
>> > In LaunchPara
On Fri, Mar 31, 2017 at 8:29 AM, Kuntal Ghosh
wrote:
> On Fri, Mar 31, 2017 at 2:05 AM, Kuntal Ghosh
> wrote:
> >
> > 1. Put an Assert(0) in ParallelQueryMain(), start server and execute
> > any parallel query.
> > In LaunchParallelWorkers, you can see
> >nworkers = n nworkers_launched
On Fri, Mar 31, 2017 at 2:05 AM, Kuntal Ghosh
wrote:
>
> 1. Put an Assert(0) in ParallelQueryMain(), start server and execute
> any parallel query.
> In LaunchParallelWorkers, you can see
>nworkers = n nworkers_launched = n (n>0)
> But, all the workers will crash because of the assert sta
On Fri, Mar 31, 2017 at 12:32 AM, Thomas Munro
wrote:
> On Fri, Mar 31, 2017 at 7:38 AM, Tomas Vondra
> wrote:
>> Hi,
>>
>> While doing some benchmarking, I've ran into a fairly strange issue with OOM
>> breaking LaunchParallelWorkers() after the restart. What I see happening is
>> this:
>>
>> 1)
On Fri, Mar 31, 2017 at 7:38 AM, Tomas Vondra
wrote:
> Hi,
>
> While doing some benchmarking, I've ran into a fairly strange issue with OOM
> breaking LaunchParallelWorkers() after the restart. What I see happening is
> this:
>
> 1) a query is executed, and at the end of LaunchParallelWorkers we g
Hi,
While doing some benchmarking, I've ran into a fairly strange issue with
OOM breaking LaunchParallelWorkers() after the restart. What I see
happening is this:
1) a query is executed, and at the end of LaunchParallelWorkers we get
nworkers=8 nworkers_launched=8
2) the query does a Ha
On Wed, Oct 5, 2016 at 8:18 AM, Tomas Vondra
wrote:
> Over the past couple of days I've been doing a bit of benchmarking for the
> "group clog" patch [1], and I've ran into what I suspect might be a fairly
> serious performance regression on newer kernels (essentially 4.3.0 and
> newer). I got to
Hi,
Over the past couple of days I've been doing a bit of benchmarking for
the "group clog" patch [1], and I've ran into what I suspect might be a
fairly serious performance regression on newer kernels (essentially
4.3.0 and newer). I got to a point where I need help with further
investigatio
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I think it's a bit too stupid as-is, though. We don't need to
> Tom> recalculate for Params in aggdirectargs, do we?
> In theory we would need to.
How come? Those are only passed to the final function, no? They
shouldn't affect what
> "Tom" == Tom Lane writes:
Tom> Hm, I was just working on inserting something of the sort into
Tom> ExecInitAgg. But I guess we could do it in the planner too. Will
Tom> run with your approach.
Tom> I think it's a bit too stupid as-is, though. We don't need to
Tom> recalculate for P
Andrew Gierth writes:
> How about:
Hm, I was just working on inserting something of the sort into
ExecInitAgg. But I guess we could do it in the planner too.
Will run with your approach.
I think it's a bit too stupid as-is, though. We don't need to
recalculate for Params in aggdirectargs, do w
> "Pavel" == Pavel Stehule writes:
Pavel> The result should not depend on GUC - hashagg on/off changing
Pavel> output - it is error.
I don't think anyone's suggesting leaving it unfixed, just whether the
fix should introduce unnecessary rescans of the aggregate input.
--
Andrew (irc:Rhod
> "Andrew" == Andrew Gierth writes:
> "Tom" == Tom Lane writes:
Tom> I'm not sure if it's worth trying to distinguish whether the Param
Tom> is inside any aggregate calls or not.
How about:
--
Andrew (irc:RhodiumToad)
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/execut
> "Tom" == Tom Lane writes:
Tom> I'm not sure if it's worth trying to distinguish whether the Param
Tom> is inside any aggregate calls or not. The existing code gets the
Tom> right answer for
Tom> select array(select x+sum(y) from generate_series(1,3) y group by y)
Tom> from generat
2016-08-24 17:08 GMT+02:00 Tom Lane :
> Andrew Gierth writes:
> > Something is wrong with the way chgParam is being handled in Agg nodes.
> > The code in ExecReScanAgg seems to assume that if the lefttree doesn't
> > have any parameter changes then it suffices to re-project the data from
> > the
Andrew Gierth writes:
> Something is wrong with the way chgParam is being handled in Agg nodes.
> The code in ExecReScanAgg seems to assume that if the lefttree doesn't
> have any parameter changes then it suffices to re-project the data from
> the existing hashtable; but of course this is nonsens
> "Andrew" == Andrew Gierth writes:
> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi,
Jeevan> While playing with LATERAL along with some aggregates in
Jeevan> sub-query, I have observed somewhat unusual behavior.
Andrew> Simpler example not needing LATERAL:
Andrew> select array(sele
> "Jeevan" == Jeevan Chalke writes:
Jeevan> Hi,
Jeevan> While playing with LATERAL along with some aggregates in
Jeevan> sub-query, I have observed somewhat unusual behavior.
Simpler example not needing LATERAL:
select array(select sum(x+y) from generate_series(1,3) y group by y)
from
Hi,
While playing with LATERAL along with some aggregates in sub-query, I have
observed somewhat unusual behavior.
Consider following steps:
create table tab1(c1 int, c2 int);
insert into tab1 select id, 1 from generate_series(1, 3) id;
create function sum_tab1(extra int) returns setof bigint as
Robert Haas writes:
> On Wed, Jun 1, 2016 at 7:29 AM, Pavel Stehule wrote:
>> When I tested some queries, I found strange plan
>> postgres=# explain analyze select s.nazev, o.nazev, o.pocet_obyvatel from
>> (select nazev, array(select id from obce_pocet_obyvatel where okresy.id =
>> okres_id orde
On Thu, Jul 7, 2016 at 4:13 PM, Pavel Stehule wrote:
> 2016-07-07 21:57 GMT+02:00 Robert Haas :
>> On Wed, Jun 1, 2016 at 7:29 AM, Pavel Stehule
>> wrote:
>> > Hi
>> >
>> > When I tested some queries, I found strange plan
>> >
>> > postgres=# explain analyze select s.nazev, o.nazev, o.pocet_obyva
2016-07-07 21:57 GMT+02:00 Robert Haas :
> On Wed, Jun 1, 2016 at 7:29 AM, Pavel Stehule
> wrote:
> > Hi
> >
> > When I tested some queries, I found strange plan
> >
> > postgres=# explain analyze select s.nazev, o.nazev, o.pocet_obyvatel from
> > (select nazev, array(select id from obce_pocet_ob
On Wed, Jun 1, 2016 at 7:29 AM, Pavel Stehule wrote:
> Hi
>
> When I tested some queries, I found strange plan
>
> postgres=# explain analyze select s.nazev, o.nazev, o.pocet_obyvatel from
> (select nazev, array(select id from obce_pocet_obyvatel where okresy.id =
> okres_id order by pocet_obyvate
"David G. Johnston" writes:
> A correlated subquery, on the other hand, has to be called once for every
> row and is evaluated within the context supplied by said row. Each time
> random is called it returns a new value.
> Section 4.2.11 (9.6 docs)
> https://www.postgresql.org/docs/9.6/static/sq
[ Please do not quote the entire thread in each followup. That's
disrespectful of your readers' time, and will soon cause people to
stop reading the thread, meaning you don't get answers. ]
Alex Ignatov writes:
> In this subquery(below) we have reference to outer variables but it is
> not worki
On 29.06.2016 15:30, David G. Johnston wrote:
More specifically...
On Wed, Jun 29, 2016 at 7:34 AM, Michael Paquier
mailto:michael.paqu...@gmail.com>>wrote:
On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov
mailto:a.igna...@postgrespro.ru>> wrote:
> Hello!
>
> Got some strange
More specifically...
On Wed, Jun 29, 2016 at 7:34 AM, Michael Paquier
wrote:
> On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov
> wrote:
> > Hello!
> >
> > Got some strange behavior of random() function:
> >
> > postgres=# select (select random() ) from generate_series(1,10) as i;
> > random
On Wed, Jun 29, 2016 at 7:43 PM, Alex Ignatov wrote:
> Hello!
>
> Got some strange behavior of random() function:
>
> postgres=# select (select random() ) from generate_series(1,10) as i;
> random
> ---
> 0.831577288918197
> [...]
> (10 rows)
I recall that this is treated a
Hello!
Got some strange behavior of random() function:
postgres=# select (select random() ) from generate_series(1,10) as i;
random
---
0.831577288918197
0.831577288918197
0.831577288918197
0.831577288918197
0.831577288918197
0.831577288918197
0.831577288918197
0.83
Alvaro Herrera writes:
> One thing I just noticed is that CREATE INDEX CONCURRENTLY cannot be
> used within CREATE SCHEMA, so perhaps the lines that match the
> CONCURRENTLY keyword should use Matches() rather than TailMatches().
> Similarly (but perhaps this is not workable) the lines that TailMa
Peter Eisentraut wrote:
> On 12/13/15 9:16 AM, Michael Paquier wrote:
> > Please see the attached to address those things (and others) with
> > extra fixes for a couple of comments.
>
> I have ported these changes to the new world order and divided them up
> into more logical changes that are more
On Mon, Jan 11, 2016 at 2:16 AM, Peter Eisentraut wrote:
> On 12/13/15 9:16 AM, Michael Paquier wrote:
>> Please see the attached to address those things (and others) with
>> extra fixes for a couple of comments.
>
> I have ported these changes to the new world order and divided them up
> into mor
On 12/13/15 9:16 AM, Michael Paquier wrote:
> Please see the attached to address those things (and others) with
> extra fixes for a couple of comments.
I have ported these changes to the new world order and divided them up
into more logical changes that are more clearly documented. Please
check t
> On Jan 1, 2016, at 11:14 AM, Tom Lane wrote:
>
> Oleg Bartunov writes:
>> I noticed, that psql's \e command doesn't worked for me complaining 'error
>> opening file'. I did research and found that following setting in joe's (if
>> I choose editor as joe) configuraton causes the problem:
>> -e
Oleg Bartunov writes:
> I noticed, that psql's \e command doesn't worked for me complaining 'error
> opening file'. I did research and found that following setting in joe's (if
> I choose editor as joe) configuraton causes the problem:
> -exask ^KX always confirms file name
> That worked f
Recently,
I noticed, that psql's \e command doesn't worked for me complaining 'error
opening file'. I did research and found that following setting in joe's (if
I choose editor as joe) configuraton causes the problem:
-exask ^KX always confirms file name
That worked for decades :), so I'
On Sat, Dec 12, 2015 at 11:17 AM, Peter Eisentraut wrote:
> These two tab completion pieces look strange to me:
>
> /* If we have CREATE|UNIQUE INDEX CONCURRENTLY, then add "ON" */
> else if ((pg_strcasecmp(prev3_wd, "INDEX") == 0 ||
>pg_strcasecmp(prev2_wd, "INDEX") == 0
These two tab completion pieces look strange to me:
/* If we have CREATE|UNIQUE INDEX CONCURRENTLY, then add "ON" */
else if ((pg_strcasecmp(prev3_wd, "INDEX") == 0 ||
pg_strcasecmp(prev2_wd, "INDEX") == 0) &&
pg_strcasecmp(prev_wd, "CONCURRENTLY") == 0)
On Wed, Aug 26, 2015 at 8:18 AM, Pavel Stehule wrote:
> if (options.single_txn && options.action != ACT_FILE &&
> options.action == ACT_NOTHING)
> {
> fprintf(stderr, _("%s: -1 can only be used in
> non-interactive mode\n"), pset.progname);
> exit(EX
Hi
if (options.single_txn && options.action != ACT_FILE &&
options.action == ACT_NOTHING)
{
fprintf(stderr, _("%s: -1 can only be used in
non-interactive mode\n"), pset.progname);
exit(EXIT_FAILURE);
}
the expression should be probably only?
Hi,
On 07/11/2015 11:40 PM, Tom Lane wrote:
Tomas Vondra writes:
So I think the predicate proofing is a better approach, but of
course the planning cost may be an issue. But maybe we can make
this cheaper by some clever tricks? For example, given two
predicates A and B, it seems that if A => B
Tomas Vondra writes:
> So I think the predicate proofing is a better approach, but of course
> the planning cost may be an issue. But maybe we can make this cheaper by
> some clever tricks? For example, given two predicates A and B, it seems
> that if A => B, then selectivity(A) <= selectivity(
On 07/11/2015 06:32 PM, Tom Lane wrote:
...
Presumably, this is happening because the numbers of rows actually
satisfying the index predicates are so small that it's a matter of
luck whether any of them are included in ANALYZE's sample.
Given this bad data for the index sizes, it's not totally
Andres Freund writes:
> On 2015-07-11 14:31:25 +0200, Tomas Vondra wrote:
>> While working on the "IOS with partial indexes" patch, I've noticed a bit
>> strange plan. It's unrelated to that particular patch (reproducible on
>> master), so I'm starting a new thread for it.
> It's indeed interesti
On 2015-07-11 14:31:25 +0200, Tomas Vondra wrote:
> While working on the "IOS with partial indexes" patch, I've noticed a bit
> strange plan. It's unrelated to that particular patch (reproducible on
> master), so I'm starting a new thread for it.
>
> To reproduce it, all you have to do is this (on
Hi,
While working on the "IOS with partial indexes" patch, I've noticed a
bit strange plan. It's unrelated to that particular patch (reproducible
on master), so I'm starting a new thread for it.
To reproduce it, all you have to do is this (on a new cluster, all
settings on default):
CREA
On Thu, Mar 19, 2015 at 2:44 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> I had a look at your modified version, and it looks good to me.
>
> Thanks, pushed. (Without the va_cols change proposed downthread.)
Thanks a lot! I will shortly work on the rebase for the other patch.
--
Mich
Michael Paquier wrote:
> I had a look at your modified version, and it looks good to me.
Thanks, pushed. (Without the va_cols change proposed downthread.)
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Se
On Wed, Mar 18, 2015 at 10:51 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>> On Wed, Mar 18, 2015 at 2:22 AM, Alvaro Herrera wrote:
>
>> > 1. ordered the argument list to vacuum(), hopefully it's more sensible
>> > now.
>>
>> Fine for me.
>
> Actually, why don't we move va_cols to VacuumPar
Michael Paquier wrote:
> On Wed, Mar 18, 2015 at 2:22 AM, Alvaro Herrera wrote:
> > 1. ordered the argument list to vacuum(), hopefully it's more sensible
> > now.
>
> Fine for me.
Actually, why don't we move va_cols to VacuumParams too?
--
Álvaro Herrerahttp://www.2ndQuadrant.
On Wed, Mar 18, 2015 at 2:22 AM, Alvaro Herrera wrote:
> Here's an updated patch. I took your latest version and made some extra
> changes:
Thanks for taking the time to look at it!
> 1. ordered the argument list to vacuum(), hopefully it's more sensible
> now.
Fine for me.
> 2. changed struct
On Tue, Mar 17, 2015 at 6:31 PM, Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > I went to change this patch status in the commitfest app, and the app
> > told me I cannot change the status in the current commitfest. Please
> > somebody with commitfest mace superpow
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> I went to change this patch status in the commitfest app, and the app
> told me I cannot change the status in the current commitfest. Please
> somebody with commitfest mace superpowers set it as ready for committer.
I'm afraid the issue is a bu
I went to change this patch status in the commitfest app, and the app
told me I cannot change the status in the current commitfest. Please
somebody with commitfest mace superpowers set it as ready for committer.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development,
>> On Sun, Mar 8, 2015 at 8:13 PM, Tatsuo Ishii wrote:
>>>
>>> > On Sat, Mar 7, 2015 at 10:18 PM, Tatsuo Ishii
>> wrote:
>>> >>
>>> >> When I set log_min_messages to debug5 and looked into walreciver log,
>>> >> I saw this:
>>> >>
>>> >> 3600 2015-03-08 09:47:38 JST DEBUG: sendtime 2015-03-08
>>
On 3/11/15 3:57 PM, Tom Lane wrote:
Alvaro Herrera writes:
But autovacuum is still manufacturing a VacuumStmt by hand. If we want
to get rid of that, I think it'd work to have a new
ExecVacuum(VacuumStmt, params) function which is called from
standard_ProcessUtility and does just vacuum(rel, r
Alvaro Herrera writes:
> But autovacuum is still manufacturing a VacuumStmt by hand. If we want
> to get rid of that, I think it'd work to have a new
> ExecVacuum(VacuumStmt, params) function which is called from
> standard_ProcessUtility and does just vacuum(rel, relid, params).
> Autovacuum o
On Wed, Mar 11, 2015 at 3:09 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Fri, Mar 6, 2015 at 1:39 AM, Michael Paquier
>> wrote:
>
>> > - 0001 is the previous one
>> > - 0002 removes VacuumStmt from the call stack of ANALYZE and VACUUM
>> > routines
>> > - 0003 moves for_wraparound in Va
Robert Haas wrote:
> On Fri, Mar 6, 2015 at 1:39 AM, Michael Paquier
> wrote:
> > - 0001 is the previous one
> > - 0002 removes VacuumStmt from the call stack of ANALYZE and VACUUM routines
> > - 0003 moves for_wraparound in VacuumParams.
>
> Yeah, I think something like this could be a sensible
On Fri, Mar 6, 2015 at 1:39 AM, Michael Paquier
wrote:
>> Do you mean removing totally VacuumStmt from the stack? We would then
>> need to add relation and va_cols as additional arguments of things
>> like vacuum_rel, analyze_rel, do_analyze_rel or similar.
>>
>> FWIW, adding do_toast and for_wrap
> On Sun, Mar 8, 2015 at 8:13 PM, Tatsuo Ishii wrote:
>>
>> > On Sat, Mar 7, 2015 at 10:18 PM, Tatsuo Ishii
> wrote:
>> >>
>> >> When I set log_min_messages to debug5 and looked into walreciver log,
>> >> I saw this:
>> >>
>> >> 3600 2015-03-08 09:47:38 JST DEBUG: sendtime 2015-03-08
>> > 09:47:
1 - 100 of 739 matches
Mail list logo
