On Wed, Jun 20, 2018 at 8:47 PM, Bruce Momjian wrote:
> On Sat, Jun 2, 2018 at 05:18:17PM -0400, Asim Praveen wrote:
>> Hi Amit
>>
>> On Mon, May 28, 2018 at 4:25 AM, Amit Kapila wrote:
>> >
>> > This is one way, but I think there are other choices as well. We can
>> > identify and flush all th
On Tue, Jun 19, 2018 at 6:13 AM, Fujii Masao wrote:
> On Sat, Jun 16, 2018 at 2:54 AM, Teodor Sigaev wrote:
>>> We just had a customer hit this issue. I kind of wonder whether this
>>> shouldn't be backpatched: Currently the execution on the primary is
>>> O(NBuffers * log(ndrels)) whereas it's O
On 21 June 2018 at 01:15, Andres Freund wrote:
> On 2018-06-20 13:10:57 -0400, Robert Haas wrote:
> > On Wed, Jun 20, 2018 at 12:10 PM, Andres Freund
> wrote:
> > > If we instead had a backtrace enabled for all PANICs and some FATALs by
> > > default (and perhaps a SIGSEGV handler too), we'd be
On 2018-06-18 11:13:47 -0700, Andres Freund wrote:
> On 2018-06-19 03:06:54 +0900, Fujii Masao wrote:
> > On Sat, Jun 16, 2018 at 3:28 AM, Andres Freund wrote:
> > > Hi,
> > >
> > > On 2018-06-15 10:45:04 -0700, Andres Freund wrote:
> > >> > +
> > >> > + srels = palloc(sizeof(SMgrRelation) * nde
This is what the stacks look like btw
[2018-06-21 12:26:45.309 AWST] [7293] [] [] [:0] DEBUG: 0:
find_in_dynamic_libpath: trying
"/home/craig/pg/10/lib/postgresql/pglogical.so"
[2018-06-21 12:26:45.309 AWST] [7293] [] [] [:0] LOCATION:
find_in_dynamic_libpath, dfmgr.c:639
[2018-06-21 12:26:4
On Thu, Jun 21, 2018 at 12:35:10PM +0800, Craig Ringer wrote:
> I wrote it because I got sick of Assert(false) debugging, and I was chasing
> down some "ERROR: 08P01: insufficient data left in message" errors. Then I
> got kind of caught up in it... you know how it is.
Yes, I know that feeling!
On Wed, Jun 20, 2018 at 06:34:42PM +0530, Ashutosh Bapat wrote:
> Thanks. I have checked that make check passes with this patch. I have
> marked this entry as ready for committer.
Thanks, Ashutosh.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jun 20, 2018 at 08:43:11PM -0700, Andres Freund wrote:
> On 2018-06-18 11:13:47 -0700, Andres Freund wrote:
>> We could do that - but add_to_unowned_list() is actually a bottleneck in
>> other places during recovery too. We pretty much never (outside of
>> dropping relations / databases) cl
On Thu, Jun 21, 2018 at 10:05:41AM +0900, Masahiko Sawada wrote:
> On Thu, Jun 21, 2018 at 6:57 AM, Nico Williams wrote:
> > On Wed, Jun 20, 2018 at 05:16:46PM -0400, Bruce Momjian wrote:
> >> On Mon, Jun 18, 2018 at 12:29:57PM -0500, Nico Williams wrote:
> >> > Note that unless the pg_catalog is
Tomas Vondra wrote:
> On 06/20/2018 10:12 PM, Heikki Linnakangas wrote:
> > Currently, the planner always first decides the scan/join order, and
> > adds Group/Agg nodes on top of the joins. Sometimes it would be legal,
> > and beneficial, to perform the aggregation below a join. I've been
> > ha
On 20 June 2018 at 14:28, Amit Khandekar wrote:
> On 20 June 2018 at 14:24, Amit Kapila wrote:
>> On Mon, Jun 18, 2018 at 3:11 PM, Amit Khandekar
>> wrote:
>>> On 16 June 2018 at 10:44, Amit Kapila wrote:
On Thu, Jun 14, 2018 at 10:05 PM, Tom Lane wrote:
>
> It looks to me like t
On Wed, Jun 20, 2018 at 02:52:23PM +0200, Magnus Hagander wrote:
> On Mon, Jun 18, 2018 at 6:42 AM, Michael Paquier
> wrote:
>> Okay, so this makes two votes in favor of keeping the messages simple
>> without context, shaped like "could not read file %s", with Robert and
>> Alvaro, and two votes f
Hi.
I noticed a bug with creating an expression index on a partitioned table.
The fact that a partition may have differing attribute numbers is not
accounted for when recursively *creating* the index on partition. The
partition index gets created but is unusable.
create table p (a int) partition
101 - 113 of 113 matches
Mail list logo
