Masahiko Sawada wrote:
> On Wed, Oct 9, 2019 at 3:57 PM Antonin Houska wrote:
> >
> > Moon, Insung wrote:
> >
> > v04-0011-Make-buffile.c-aware-of-encryption.patch in [1] changes buffile.c
> > so
> > that data is read and written in 8kB blocks if encryption is enabled. In
> > order
> > to rec
On Fri, Oct 04, 2019 at 01:39:38PM -0700, Andres Freund wrote:
> but that reasoning seems bogus to me. For one, on just about any
> platform close always closes the fd, even when returning an error
> (unless you pass in a bad fd, in which case it obviously doesn't). So
> the reasoning that this fix
On Sun, Oct 13, 2019 at 5:24 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > This patch also changes the way timestamp to timestamptz cast works.
> > Previously it did timestamp2tm() then tm2timestamp(). Instead, after
> > timestamp2tm() it calculates timezone offset and applies it to
> > or
On Mon, Oct 14, 2019 at 6:51 AM Craig Ringer wrote:
>
> On Sun, 13 Oct 2019 at 19:50, Amit Kapila wrote:
>>
>
>
> Does anyone object if we add the reorder buffer total size & in-memory size
> to struct WalSnd too, so we can report it in pg_stat_replication?
>
There is already a patch
(0011-Trac
On Sun, 13 Oct 2019 at 19:50, Amit Kapila wrote:
> On Sun, Oct 13, 2019 at 12:25 PM Dilip Kumar
> wrote:
> >
> > On Thu, Oct 3, 2019 at 2:43 PM Amit Kapila
> wrote:
> > >
> > > 3.
> > > + *
> > > + * While updating the existing change with detoasted tuple data, we
> need to
> > > + * update the
On Sun, Oct 13, 2019 at 04:18:34PM -0300, Alvaro Herrera wrote:
> True. And we can copy the resulting comment to the other spot.
>
> (FWIW I expect the crash is possible not just in reindex but also in
> CREATE INDEX CONCURRENTLY.)
I need to think about that, but shouldn't we have a way to repro
On Sun, Oct 13, 2019 at 03:02:17PM -0500, Justin Pryzby wrote:
> On Thu, Sep 19, 2019 at 05:15:37PM +0900, Amit Langote wrote:
> > Please find attached updated patches.
>
> Tom pointed me to this thread, since we hit it in 12.0
> https://www.postgresql.org/message-id/flat/16802.1570989962%40sss.pg
During the cleanup of the _MSC_VER versions (commit
38d8dce61fff09daae0edb6bcdd42b0c7f10ebcd), I found it useful to use
-Wundef, but that resulted in a bunch of gratuitous warnings. Here is a
patch to fix those. Most of these are just stylistic cleanups, but the
change in pg_bswap.h is potentiall
On 2019-Oct-13, Justin Pryzby wrote:
> On Sun, Oct 13, 2019 at 03:10:21PM -0300, Alvaro Herrera wrote:
> > On 2019-Oct-13, Justin Pryzby wrote:
> >
> > > Looks like it's a race condition and dereferencing *holder=NULL. The
> > > first
> > > crash was probably the same bug, due to report query r
Noah Misch writes:
> On Wed, Oct 09, 2019 at 01:15:29PM -0400, Tom Lane wrote:
>> * I still think that the added configure test is a waste of build cycles.
>> It'd be sufficient to test "#ifdef HAVE__BUILTIN_CONSTANT_P" where you
>> are testing HAVE_I_CONSTRAINT__BUILTIN_CONSTANT_P, because our pr
Resending this message, which didn't make it to the list when I sent it
earlier. (And, notified -www).
On Sun, Oct 13, 2019 at 06:06:43PM +0900, Michael Paquier wrote:
> On Fri, Oct 11, 2019 at 07:44:46PM -0500, Justin Pryzby wrote:
> > Unfortunately, there was no core file, and I'm still trying
Filed at
https://bugzilla.kernel.org/show_bug.cgi?id=205183
We'll see what happens ...
regards, tom lane
Andres Freund writes:
> On 2019-10-13 10:29:45 -0400, Tom Lane wrote:
>> How recent do you think it needs to be?
> My experience reporting kernel bugs is that the latest released version,
> or even just the tip of the git tree, is your best bet :/.
Considering that we're going to point them at c
Hi,
On 2019-10-11 16:03:20 -0500, Justin Pryzby wrote:
> I'm not sure why we have that index, and my script probably should have known
> to choose a better one to cluster on, but still..
>
> ts=# CLUSTER huawei_m2000_config_enodebcell_enodeb USING
> huawei_m2000_config_enodebcell_enodeb_coalesce_
Hi,
On 2019-10-13 10:29:45 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Probably requires reproducing on a pretty recent kernel first, to have a
> > decent chance of being investigated...
>
> How recent do you think it needs to be? The machine I was testing on
> yesterday is under a year
On Sun, Oct 13, 2019 at 12:25 PM Dilip Kumar wrote:
>
> On Thu, Oct 3, 2019 at 2:43 PM Amit Kapila wrote:
> >
> > 3.
> > + *
> > + * While updating the existing change with detoasted tuple data, we need to
> > + * update the memory accounting info, because the change size will differ.
> > + * Oth
On Sat, Oct 12, 2019 at 09:51:45PM -0500, Justin Pryzby wrote:
> Variations on this seem to leave the locks table (?) or something else in a
> Real Bad state, such that I cannot truncate the table or drop it; or at least
> commands are unreasonably delayed for minutes, on this otherwise-empty test
On Fri, Oct 11, 2019 at 07:44:46PM -0500, Justin Pryzby wrote:
> That's an index on a table partition, but not itself a child of a relkind=I
> index.
Interesting. Testing with a partition tree, and indexes on leaves
which do not have dependencies with a parent I cannot reproduce
anything. Perhap
On Mon, Oct 07, 2019 at 09:55:23AM +0900, Amit Langote wrote:
> One cannot currently add partitioned tables to a publication.
>
> create table p (a int, b int) partition by hash (a);
> create table p1 partition of p for values with (modulus 3, remainder 0);
> create table p2 partition of p for val
19 matches
Mail list logo
