On 2016/08/22 13:51, Ashutosh Bapat wrote:
> The parent-child relationship of multi-level partitioned tables is not
> retained when creating the AppendRelInfo nodes. We create RelOptInfo nodes
> for all the leaf and intermediate tables. The AppendRelInfo nodes created
> for these RelOptInfos set th
On Thu, Aug 25, 2016 at 1:41 AM, Anastasia Lubennikova
wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:not tested
>
On 2016/08/25 5:29, Robert Haas wrote:
On Wed, Aug 24, 2016 at 2:41 AM, Etsuro Fujita
wrote:
On 2016/04/04 20:11, Etsuro Fujita wrote:
I found an incorrect comment in contrib/postgres_fdw/deparse.c: s/FOR
SELECT or FOR SHARE/FOR UPDATE or FOR SHARE/ Attached is a patch to fix
that comment.
On 2016/08/25 1:08, Robert Haas wrote:
On Tue, Aug 23, 2016 at 11:18 PM, Etsuro Fujita
wrote:
OK, I think we should fix the issue that postgres_fdw produces incorrect
aliases for joining relations shown in the Relations line in EXPLAIN for a
join pushdown query like the above) in advance of the
Hi Artur Zakirov,
0001-to-timestamp-format-checking-v3.patch looks pretty reasonable to me, other
than following concern:
#1.
Whitespace @ line # 317.
#2. Warning at compilation;
formatting.c: In function ‘do_to_timestamp’:
formatting.c:3049:37: warning: ‘prev_type’ may be used uninitialized i
2016-08-25 13:46 GMT+09:00 Haribabu Kommi :
> On Thu, Aug 25, 2016 at 6:57 AM, Robert Haas wrote:
>> On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi
>> wrote:
>>>
>>> Based on the performance impact with the additional timing calculations,
>>> we can decide the view default behavior, Are there an
On Thu, Jun 9, 2016 at 12:56 AM, Tom Lane wrote:
> Thom Brown writes:
>> On 15 May 2014 at 19:56, Bruce Momjian wrote:
>>> On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote:
A recent question from Tim Kane prompted me to measure the overhead
costs of EXPLAIN ANALYZE, which I'd n
Hello hackers,
I'm no PG hacker, so maybe I'm completely wrong, so sorry if I have wasted your
time. I try to make the best out of Tom Lanes comment.
What would happen if there's a database on a server with initdb (or whatever)
parameter -with-wal-size=64MB and later someone decides to make it t
On 25 August 2016 at 09:22, Craig Ringer wrote:
> On 25 August 2016 at 03:26, Vladimir Gordiychuk wrote:
>> Hi. It has already passed a few months but patch still have required review
>> state. Can I help to speed up the review, or should i wait commitfest?
>> I plane complete changes in pgjdbc d
On Thu, Aug 25, 2016 at 6:57 AM, Robert Haas wrote:
> On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi
> wrote:
>>
>> Based on the performance impact with the additional timing calculations,
>> we can decide the view default behavior, Are there any objections to the
>> concept?
>
> There have been
On Thu, Aug 25, 2016 at 12:35 AM, Andres Freund wrote:
> FWIW, I'm also doubtful that investing time into making this initdb
> configurable is a good use of time: The number of users that'll adjust
> initdb time parameters is going to be fairly small.
I have to admit that I was skeptical about th
On 2016-08-25 00:28:58 -0400, Robert Haas wrote:
> On Wed, Aug 24, 2016 at 11:52 PM, Andres Freund wrote:
> > On 2016-08-24 23:26:51 -0400, Robert Haas wrote:
> >> On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote:
> >> > and I'm also rather doubtful that it's actually without overhead.
> >>
On Wed, Aug 24, 2016 at 11:52 PM, Andres Freund wrote:
> On 2016-08-24 23:26:51 -0400, Robert Haas wrote:
>> On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote:
>> > and I'm also rather doubtful that it's actually without overhead.
>>
>> Really? Where do you think the overhead would come from
On Wed, Aug 24, 2016 at 11:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> What am I missing?
>
> Maybe nothing. But I'll point out that of the things that can currently
> be configured at initdb time, such as LC_COLLATE, there is not one single
> one that matters to walsender/walreceiver. If y
On Wed, Aug 24, 2016 at 11:46 PM, Alvaro Herrera
wrote:
> Amit Kapila wrote:
>> $SUBJECT will make hash indexes reliable and usable on standby.
>
> Nice work.
>
> Can you split the new xlog-related stuff to a new file, say hash_xlog.h,
> instead of cramming it in hash.h? Removing the existing #in
On 2016-08-24 23:26:51 -0400, Robert Haas wrote:
> On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote:
> > and I'm also rather doubtful that it's actually without overhead.
>
> Really? Where do you think the overhead would come from?
ATM we do a math involving XLOG_BLCKSZ in a bunch of place
Robert Haas writes:
> What am I missing?
Maybe nothing. But I'll point out that of the things that can currently
be configured at initdb time, such as LC_COLLATE, there is not one single
one that matters to walsender/walreceiver. If you think there is zero
risk involved in introducing a paramet
On Thu, Aug 18, 2016 at 3:37 PM, Michael Paquier
wrote:
> On Tue, Aug 16, 2016 at 11:06 PM, Stephen Frost
> wrote:
> > I could see supporting an additional "pause" option that means "pause at
> > the end of WAL if you don't reach the recovery target point". I'd also
> > be happy with a warning
Robert Haas writes:
> On Wed, Aug 24, 2016 at 10:33 PM, Tom Lane wrote:
>> ... but I think this is just folly. You'd have to do major amounts
>> of work to keep, eg, slave servers on the same page as the master
>> about what the segment size is.
> I said an initdb-time parameter, meaning not ca
On Wed, Aug 24, 2016 at 11:02 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2016-08-24 22:33:49 -0400, Tom Lane wrote:
>>> ... but I think this is just folly. You'd have to do major amounts
>>> of work to keep, eg, slave servers on the same page as the master
>>> about what the segment size
On Wed, Aug 24, 2016 at 10:36 PM, Gerdan Santos wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, pa
On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote:
> On 2016-08-24 22:33:49 -0400, Tom Lane wrote:
>> > Possibly it would make sense for this to be configurable at initdb
>> > time instead of requiring a recompile;
>>
>> ... but I think this is just folly. You'd have to do major amounts
>> of
On Wed, Aug 24, 2016 at 10:33 PM, Tom Lane wrote:
> ... but I think this is just folly. You'd have to do major amounts
> of work to keep, eg, slave servers on the same page as the master
> about what the segment size is.
I said an initdb-time parameter, meaning not capable of being changed
withi
Andres Freund writes:
> On 2016-08-24 22:33:49 -0400, Tom Lane wrote:
>> ... but I think this is just folly. You'd have to do major amounts
>> of work to keep, eg, slave servers on the same page as the master
>> about what the segment size is.
> Don't think it'd actually be all that complicated,
On 2016-08-24 22:33:49 -0400, Tom Lane wrote:
> > Possibly it would make sense for this to be configurable at initdb
> > time instead of requiring a recompile;
>
> ... but I think this is just folly. You'd have to do major amounts
> of work to keep, eg, slave servers on the same page as the maste
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Considering those three factors, I think we should consider pushing the
> default value up somewhat higher for v10. Reverting to the 64MB size that
> we had prior to 47937403676d913c
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Sorry, my mistake!
I could not find a way to disable this fu
Robert Haas writes:
> I'd like to propose that we increase the default WAL segment size,
> which is currently 16MB.
That seems like a reasonable thing to consider ...
> Possibly it would make sense for this to be configurable at initdb
> time instead of requiring a recompile;
... but I think th
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation:tested, failed
I could not find a way to disable this functionality , I see
On Wed, Aug 24, 2016 at 10:31 PM, Robert Haas wrote:
> 1. Transaction rates are vastly higher these days. In 1999, I think
> we were still limited to ~2^32 transactions during the entire lifetime
> of the server; transaction ID wraparound hadn't been invented yet.[1]
> Today, some installations d
Hi,
I'd like to propose that we increase the default WAL segment size,
which is currently 16MB. It was first set to that value in commit
47937403676d913c0e740eec6b85113865c6c8ab in October of 1999; prior to
that, it was 64MB. Between 1999 and now, there have been three
significant changes that m
On 08/25/2016 01:45 AM, Tom Lane wrote:
Over in the thread about the SP-GiST inet opclass, I threatened to post
a patch like this, and here it is.
The basic idea is to track more than just the very latest page we've used
in each of the page categories that SP-GiST works with. I started with a
On 24 August 2016 at 19:42, roshan_myrepublic wrote:
> Now, I am able to see the last added row in my subscriber table. All the
> other 4 rows which were added in the beginning are still missing. What am I
> doing wrong here?
Hi. This isn't really on topic for the pgsql-hackers mailing list.
We'
2016-08-24 21:34 GMT-03:00 Michael Paquier :
>
> Yes, you are right. If I look at the diffs this morning I am seeing
> the ACLs being dumped for this aggregate. So we could just fix the
> test and be done with it. I did not imagine the index issue though,
> and this is broken for some time, so that
On 25 August 2016 at 03:26, Vladimir Gordiychuk wrote:
> Hi. It has already passed a few months but patch still have required review
> state. Can I help to speed up the review, or should i wait commitfest?
> I plane complete changes in pgjdbc drive inside PR
> https://github.com/pgjdbc/pgjdbc/pull
On Wed, Aug 24, 2016 at 11:15 PM, Stephen Frost wrote:
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> The patch attached includes all those tests and they are failing. We
>> are going to need a patch able to pass all that, and even for master
>> this is going to need more thoughts, and
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi
> calculations may cause performance problem. Is there any need of writing
> this stats information to file? As this just provides the wait time
> information.
Yes, saving the workloa
Over in the thread about the SP-GiST inet opclass, I threatened to post
a patch like this, and here it is.
The basic idea is to track more than just the very latest page we've used
in each of the page categories that SP-GiST works with. I started with an
arrangement that gave an equal number of c
2016-08-24 17:01 GMT-03:00 Martín Marqués :
> 2016-08-24 11:15 GMT-03:00 Stephen Frost :
>> Michael,
>>
>> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>>> The patch attached includes all those tests and they are failing. We
>>> are going to need a patch able to pass all that, and even for
On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi
wrote:
> There was some discussion earlier in adding pg_stat_lwlock view in [1].
> The main objections which I observed for that patch was showing LWLOCK
> information to the user that don't understand what this lock used for and etc.
>
> Currently a
On Wed, Aug 24, 2016 at 2:41 AM, Etsuro Fujita
wrote:
> On 2016/04/04 20:11, Etsuro Fujita wrote:
>> I found an incorrect comment in contrib/postgres_fdw/deparse.c: s/FOR
>> SELECT or FOR SHARE/FOR UPDATE or FOR SHARE/ Attached is a patch to fix
>> that comment.
>
> Other than this, I ran into so
2016-08-24 11:15 GMT-03:00 Stephen Frost :
> Michael,
>
> * Michael Paquier (michael.paqu...@gmail.com) wrote:
>> The patch attached includes all those tests and they are failing. We
>> are going to need a patch able to pass all that, and even for master
>> this is going to need more thoughts, and
Hi. It has already passed a few months but patch still have required review
state. Can I help to speed up the review, or should i wait commitfest?
I plane complete changes in pgjdbc drive inside PR
https://github.com/pgjdbc/pgjdbc/pull/550 but PR blocked current problem
with not available stop logi
On Wed, Aug 24, 2016 at 1:00 PM, Kevin Grittner wrote:
> On Wed, Aug 24, 2016 at 12:40 PM, Alvaro Herrera
> wrote:
>> #include catalog/catalog.h in storage/bufmgr.h.
>> Can we get it removed?
>
> Will do that now.
Done. Back-patched to 9.6 (although I see I forgot to mention that
in the comm
Alvaro Herrera wrote:
> Many have expressed their interest in this topic, but I haven't seen any
> design of how it should work. Here's my attempt; I've been playing with
> this for some time now and I think what I propose here is a good initial
> plan.
I regret to announce that I'll have to stay
Amit Kapila wrote:
> $SUBJECT will make hash indexes reliable and usable on standby.
Nice work.
Can you split the new xlog-related stuff to a new file, say hash_xlog.h,
instead of cramming it in hash.h? Removing the existing #include
"xlogreader.h" from hash.h would be nice. I volunteer for pus
On Wed, Aug 24, 2016 at 12:40 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
>> Modify BufferGetPage() to prepare for "snapshot too old" feature
>
> I just noticed that this commit added a line to #include catalog/catalog.h
> in storage/bufmgr.h. I can't find any reason for it doing so, and I
Sorry. I did not get last two mails from Amul. Don't know why. So I
reply to another mail.
Documented as working case, but unfortunatly it does not :
postgres=# SELECT to_timestamp('2000JUN', ' MON');
ERROR: invalid value "---" for "MON"
DETAIL: The given value did not match any of t
Kevin Grittner wrote:
> Modify BufferGetPage() to prepare for "snapshot too old" feature
I just noticed that this commit added a line to #include catalog/catalog.h
in storage/bufmgr.h. I can't find any reason for it doing so, and I
think it's a bad line to have there. Can we get it removed?
--
> Aside from the disturbing frequency of 100-to-1 split ratios, it also
> looks like the inclusion of the masklen bit is hardly pulling its weight,
> though that might be a artifact of this data set.
I was expecting this. Including masklen bit to decision was something
we could easily do. It doe
On Tue, Aug 23, 2016 at 10:05 PM, Amit Kapila
wrote:
> On Wed, Aug 24, 2016 at 2:37 AM, Jeff Janes wrote:
>
> >
> > After an intentionally created crash, I get an Assert triggering:
> >
> > TRAP: FailedAssertion("!(((freep)[(bitmapbit)/32] &
> > (1<<((bitmapbit)%32", File: "hashovfl.c", Line
On Wed, Aug 24, 2016 at 2:34 AM, Amit Kapila wrote:
> On Wed, Aug 24, 2016 at 11:38 AM, Ashutosh Sharma
> wrote:
>>> Well, that change should be part of Amit's patch to add WAL logging,
>>> not this patch, whose mission is just to improve test coverage.
>>
>> I have just removed the warning mess
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi,
I haven't tested the performance yet, but the patch itself looks pret
On August 24, 2016 9:32:48 AM PDT, Tomas Vondra
wrote:
>
>
>On 08/24/2016 12:20 AM, Andres Freund wrote:
>> On 2016-08-23 19:18:04 -0300, Claudio Freire wrote:
>>> On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra
>>> wrote:
Could someone please explain how the unlogged tables are supposed
>t
On 08/24/2016 12:20 AM, Andres Freund wrote:
On 2016-08-23 19:18:04 -0300, Claudio Freire wrote:
On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra
wrote:
Could someone please explain how the unlogged tables are supposed to fix the
catalog bloat problem, as stated in the initial patch submission?
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
On Tue, Aug 23, 2016 at 6:11 PM, Tomas Vondra
wrote:
> Could someone please explain how the unlogged tables are supposed to fix the
> catalog bloat problem, as stated in the initial patch submission? We'd still
> need to insert/delete the catalog rows when creating/dropping the temporary
> tables,
On Tue, Aug 23, 2016 at 11:18 PM, Etsuro Fujita
wrote:
>> Yes, it seems what we are doing now is not consistent with what
>> happens for plain tables; that should probably be fixed.
>
> OK, I think we should fix the issue that postgres_fdw produces incorrect
> aliases for joining relations shown i
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
> That would require changing it from an AlterEnumStmt to a RenameStmt
> instead. Those look to me like they're for renaming SQL objects,
> i.e. things addressed by identifiers, whereas enum labels are just
> strings. Looking at the implementation of a few of the functions called
> by ExecRenameS
I wrote:
> Peter Eisentraut writes:
>> What does it do if you are displaying more than one function?
> It prints more than one footer. It's very much like the way that, say,
> rules are printed for tables by \d.
Or to be concrete: instead of
regression=# \df+ foo*
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> The patch attached includes all those tests and they are failing. We
> are going to need a patch able to pass all that, and even for master
> this is going to need more thoughts, and let's focus on HEAD/9.6
> first.
Are you sure you
I wrote:
> I've pushed this patch with mostly (not entirely) cosmetic adjustments.
> I still think it'd be worth looking into why the produced index is larger
> than the GiST equivalent, and for that matter exactly why the GiST
> equivalent is so much slower to search.
I spent some time poking at
Peter Eisentraut writes:
> On 8/22/16 1:52 PM, Pavel Stehule wrote:
>> If I understand to purpose of this patch - it is compromise - PL source
>> is removed from table, but it is printed in result.
> What does it do if you are displaying more than one function?
It prints more than one footer. I
On Tue, Aug 23, 2016 at 8:43 PM, Tom Lane wrote:
> It's interesting that nobody has complained about this behavior.
We have been known to emphasize that unless you have an ORDER BY
clause at the outermost level of a query, there is no guarantee
about the order of rows returned. In general, even
> "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
On 8/22/16 1:52 PM, Pavel Stehule wrote:
> If I understand to purpose of this patch - it is compromise - PL source
> is removed from table, but it is printed in result.
What does it do if you are displaying more than one function?
--
Peter Eisentraut http://www.2ndQuadrant.com/
Post
On Wed, Aug 24, 2016 at 2:35 PM, Tsunakawa, Takayuki
wrote:
> From: Peter Geoghegan [mailto:p...@heroku.com]
>> On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote:
>> >> [Windows]
>> >> #clients onoff
>> >> 12 29793 38169
>> >> 24 31587 87237
>> >> 48 32588 83335
>> >> 96
Hi Craig,
I am trying to set up pglogical replication. I have a table which has
around 4 rows in the provider server.
=
employee_id | visitor_email | vistor_id |date |
message
-+---+---+-+-
Emre Hasegeli writes:
>> Here is v4, which changes the command from ALTER VALUE to RENAME VALUE,
>> for consistency with RENAME ATTRIBUTE.
>
> It looks like we always use "ALTER ... RENAME ... old_name TO
> new_name" syntax, so it is better that way. I have noticed that all
> the other RENAMEs g
On Wed, Aug 24, 2016 at 11:54 AM, Heikki Linnakangas
wrote:
> On 08/23/2016 06:18 PM, Heikki Linnakangas wrote:
>
>> On 08/22/2016 08:38 PM, Andres Freund wrote:
>>
>>> On 2016-08-22 20:32:42 +0300, Heikki Linnakangas wrote:
>>>
I
remember seeing ProcArrayLock contention very visible ea
On Wed, Aug 24, 2016 at 4:35 AM, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Peter Geoghegan [mailto:p...@heroku.com]
> > On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote:
> > >> [Windows]
> > >> #clients onoff
> > >> 12 29793 38169
> > >> 24 31587 87237
On 08/23/2016 06:18 PM, Heikki Linnakangas wrote:
On 08/22/2016 08:38 PM, Andres Freund wrote:
On 2016-08-22 20:32:42 +0300, Heikki Linnakangas wrote:
I
remember seeing ProcArrayLock contention very visible earlier, but I can't
hit that now. I suspect you'd still see contention on bigger hardwa
On 22 August 2016 at 16:56, Simon Riggs wrote:
> On 22 August 2016 at 13:44, Kuntal Ghosh wrote:
>
>> Please let me know your thoughts on this.
>
> Do the regression tests pass with this option enabled?
Hi,
I'd like to be a reviewer on this. Please can you add this onto the CF
app so we can tra
On 2016/04/04 23:24, Tom Lane wrote:
Amit Langote writes:
On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote:
* .Observation: *Prepare statement execution plan is not getting changed
even after altering foreign table to point to new schema.
I wonder if performing relcache invalidation upon ATE
There was some discussion earlier in adding pg_stat_lwlock view in [1].
The main objections which I observed for that patch was showing LWLOCK
information to the user that don't understand what this lock used for and etc.
Currently as part of wait_event information in pg_stat_activity the LWLOCK
i
On Tue, Aug 23, 2016 at 3:59 AM, Andres Freund wrote:
>> Haribabu's categorization
>> scheme seems to need some work, but the idea of categorizing
>> statements by type and counting executions per type seems very
>> reasonable.
>
> I'd consider instead using something like COALESCE(commandType,
>
--On 20. August 2016 12:41:48 -0400 Tom Lane wrote:
> So at this point I'm pretty baffled as to what the actual use-case is
> here. I am tempted to say that a standalone backend should refuse to
> start at all if a recovery.conf file is present. If we do want to
> allow the case, we need some
On Wed, Aug 24, 2016 at 9:07 AM, Michael Paquier
wrote:
> On Wed, Aug 24, 2016 at 5:34 AM, Martín Marqués
> wrote:
>> Hi,
>>
>> 2016-08-23 16:46 GMT-03:00 Martín Marqués :
>>>
>>> I will add tests for sequence and functions as you mention and test again.
>>>
>>> Then I'll check if other tests sh
86 matches
Mail list logo
