Hi,
Because of pg_pwrite()[1], openLogOff, a static global variable in xlog.c,
seems taken over by a local variable startoffset and no longer used now.
I write the attached patch that removes openLogOff. Both "make check" and
"make installcheck" passed, and just after that, "pg_ctl -m immediate s
Andres Freund writes:
> I don't think we are actually contradicting each other. The aim of that
> error was to prevent pieces of code that aren't conditional on
> --with-llvm from including llvmjit.h. I was, for a moment and wrongly,
> thinking that we could style the header in a way that'd make
At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut
wrote in
<24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>
> On 28/01/2019 09:14, Kyotaro HORIGUCHI wrote:
> > 0002:
> >
> > The test 54-56 of 001_ssltest.pl failed, which succeeded before
> > applying 0002. Seems to need to use anothe
Hi,
On 2019-01-28 16:40:36 -0800, Andres Freund wrote:
> On 2019-01-28 15:49:33 -0800, Andres Freund wrote:
> > On 2019-01-28 18:08:59 -0500, Tom Lane wrote:
> > > Andres Freund writes:
> > > > I'm inclined to put back the
> > > >LockBuffer(buf, BUFFER_LOCK_UNLOCK);
> > > >
At Mon, 28 Jan 2019 17:30:57 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190128.173057.41178374.horiguchi.kyot...@lab.ntt.co.jp>
> At Wed, 26 Dec 2018 12:59:32 -0500, Tom Lane wrote in
> <32289.1545847...@sss.pgh.pa.us>
> > Hm, I agree that the para doesn't read very well now, b
(2019/01/28 19:37), Etsuro Fujita wrote:
> (2019/01/25 20:33), Etsuro Fujita wrote:
>> I noticed yet another thing while updating the patch for pushing down
>> ORDER BY LIMIT. Let me explain. When costing foreign paths on the
>> basis of local statistics, we calculate/cache the costs of an unsort
Andres Freund writes:
> I did that now. I couldn't reproduce it locally, despite a lot of
> runs. Looking at the buildfarm it looks like the failures were,
> excluding handfish which failed without recognizable symptoms before and
> after, on BSD derived platforms (netbsd, freebsd, OX), which cert
Hi all,
In 2016, a thread was started about implementing INSERT INTO ... SET ...
that included a patch and was basically ready for inclusion in
PostgreSQL. However, it seems as though it stagnated for some reason.
Does anybody remember this and is there perhaps someone who knows what
the curr
On Tue, Jan 29, 2019 at 11:49:37AM +0900, Takashi Menjo wrote:
> Because of pg_pwrite()[1], openLogOff, a static global variable in xlog.c,
> seems taken over by a local variable startoffset and no longer used
> now.
It seems to me that keeping openLogOff is still useful to get a report
about the
On Tue, Jan 29, 2019 at 12:18:29PM +0900, Kyotaro HORIGUCHI wrote:
> At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut
> wrote in
> <24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>
>> This is strange. The tests work for me, and also on the cfbot. The
>
> Agreed. It seemed so also to
On Mon, Jan 28, 2019 at 05:05:32PM -0500, Tom Lane wrote:
> Yeah, I thought about that too, but it doesn't seem like an improvement.
> If the query is very long (which isn't unlikely) I think people would
> prefer to see the option(s) up front.
Having these options at the front of the WITH clause
On Tue, Jan 29, 2019 at 12:35:30AM +, Jamison, Kirk wrote:
> I just checked the patch.
> As per advice, you removed the versioning and specified --jobs.
> The patch still applies, builds and passed the tests successfully.
I would document the optional VACUUM_OPTS on the page of pg_upgrade.
If
On Mon, Jan 28, 2019 at 10:33:06PM +0100, Dimitri Fontaine wrote:
> In other cases, it's important to measure and accept the possible
> performance cost of running a proxy server between the client connection
> and the PostgreSQL backend process. I believe the numbers shown in the
> previous email
On Mon, Jan 28, 2019 at 02:00:59PM +0100, Alex Kliukin wrote:
> While reading the doc page for the pg_basebackup, I've been confused
> by the fact that it says WAL files will be written to .tarballs
> (either base.tar or pg_wal.tar) when pg_basebackup is instructed to
> stream WALs alongside the ba
On Mon, 28 Jan 2019 at 20:15, Robert Haas wrote:
> On Fri, Jan 25, 2019 at 4:18 PM Alvaro Herrera
> wrote:
> > Right, the planner/executor "disconnect" is one of the challenges, and
> > why I was trying to keep the old copy of the PartitionDesc around
> > instead of building updated ones as need
On Sun, 27 Jan 2019 at 19:17, Tom Lane wrote:
> > * Allow a normal term to match a functional index, e.g. WHERE x =
> > 'abcdefgh' => WHERE substr(x, 1 , 5) = 'abcde' AND x = 'abcdefgh'
>
> I'm a bit confused about what you think this example means. I do
> intend to work on letting extensions d
Hi,
Peter Eisentraut wrote:
> When you manage the WAL (or perhaps in the future relation files)
> through PMDK, is there still a file system view of it somewhere, for
> browsing, debugging, and for monitoring tools?
First, I assume that our patchset is used with a filesystem that supports
direct
Simon Riggs writes:
> On Sun, 27 Jan 2019 at 19:17, Tom Lane wrote:
>> ... I don't
>> know whether that would satisfy your concern, because I'm not clear
>> on what your concern is.
> To be able to extract indexable clauses where none existed before.
That's a pretty vague statement, because it
On Tue, 29 Jan 2019 at 09:55, Tom Lane wrote:
> Simon Riggs writes:
> > On Sun, 27 Jan 2019 at 19:17, Tom Lane wrote:
> >> ... I don't
> >> know whether that would satisfy your concern, because I'm not clear
> >> on what your concern is.
>
> > To be able to extract indexable clauses where none
Sven Berkvens-Matthijsse writes:
> In 2016, a thread was started about implementing INSERT INTO ... SET ...
> that included a patch and was basically ready for inclusion in
> PostgreSQL. However, it seems as though it stagnated for some reason.
> Does anybody remember this and is there perhaps
> 29 янв. 2019 г., в 7:32, Andreas Karlsson написал(а):
>
> On 1/28/19 7:26 PM, Andrey Borodin wrote:
>>> * I am no fan of the tupdesc vs truncTupdesc separation and think that it
>>> is a potential hazard, but I do not have any better suggestion right now.
>> B-tree is copying tupdesc every t
On 2019/01/28 20:27, David Rowley wrote:
> On Mon, 28 Jan 2019 at 20:45, Amit Langote
> wrote:
>> It seems to me that plancache.c doesn't really need to perform
>> AcquireExecutorLocks()/LockRelationOid() to learn that a partition's
>> reloptions property has changed to discard a generic plan and
On 2019-Jan-28, Tom Lane wrote:
> (There was some mention of trying to split relation.h into multiple
> files, but I fail to see any advantage in that.)
Hmm, nodes/relation.h includes lots of other files and is widely
included. If we can split it usefully, I vote for that. However, I
failed to
On Wed, 23 Jan 2019 at 06:35, Tomas Vondra wrote:
> It turned out to be a tad more complex due to partitioning, because when
> we find the partitions do not match, the tuple is already allocated in
> the "current" context (be it per-tuple or batch). So we can't just free
> the whole context at tha
101 - 124 of 124 matches
Mail list logo
