On 2018/04/18 22:40, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 2018/04/18 0:04, Alvaro Herrera wrote:
>>> Amit Langote wrote:
>>>
I just confirmed my hunch that this wouldn't somehow do the right thing
when the OID system column is involved. Like this case:
>>>
>>> This looks too
On Wed, Apr 18, 2018 at 06:44:00PM -0700, Peter Geoghegan wrote:
> What I have in mind here is something that's a bit like
> AssertNotInCriticalSection(). We don't need to pepper
> AssertNotInCriticalSection() everywhere in practice, because calling
> palloc() is a pretty good proxy for "function s
On Thu, Apr 19, 2018 at 01:52:26AM +0900, Fujii Masao wrote:
> No. But after my colleague truncated more than one hundred tables on
> the server with shared_buffers = 300GB, the recovery could not finish
> even after 10 minutes since the startup of the recovery. So I had to
> shutdown the server im
On Wed, Apr 18, 2018 at 10:36 PM, Alvaro Herrera
wrote:
> Pavan Deolasee wrote:
>> On Wed, Apr 18, 2018 at 7:37 AM, Wood, Dan wrote:
>
>> > My analysis is that heap_prepare_freeze_tuple->FreezeMultiXactId()
>> > returns FRM_NOOP if the MultiXACT locked rows haven't committed. This
>> > results i
On Wed, Apr 18, 2018 at 6:53 PM, Michael Paquier wrote:
>> I'm curious about what we'll find by just by adding
>> Assert(!AnyBufferLockHeldByMe()) to the top of
>> heap_tuple_fetch_attr(). AssertNotInCriticalSection() certainly found
>> several bugs when it was first added.
>
> Yep.
I wrote a sim
At Mon, 16 Apr 2018 18:39:24 +0530, Ashutosh Bapat
wrote in
> On Mon, Apr 16, 2018 at 4:10 PM, Martin Swiech
> wrote:
> > Hi folks,
> >
> > I got some complex query which works on PostgreSQL 9.6 , but fails on
> > PostgreSQL 10.
> >
> > Version of PostgreSQL:
> > PostgreSQL 10.3 on x86_64-app
On Wed, Apr 18, 2018 at 5:04 PM, Thomas Munro
wrote:
> On Wed, Apr 11, 2018 at 10:22 PM, Heikki Linnakangas wrote:
>>> On Tue, Apr 10, 2018 at 12:53 PM, Andres Freund
>>> wrote:
That person said he'd work on adding an equivalent of linux'
prctl(PR_SET_PDEATHSIG) to FreeBSD.
>
> Here is
On Wed, Apr 18, 2018 at 6:55 PM, Thomas Munro
wrote:
> Here's a draft patch that does that.
Here's a better one (the previous version could read past the end of
the occurred_events array).
--
Thomas Munro
http://www.enterprisedb.com
0001-Exit-by-default-if-postmaster-dies-v2.patch
Description
in commit 8561e48, _SPI_stack alloc from TopMemoryContext. But AtEOXact_SPI
just set _SPI_stack = NULL. Is this a memory leak?
2018-04-19 5:01 GMT+02:00 Kyotaro HORIGUCHI :
> At Mon, 16 Apr 2018 18:39:24 +0530, Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote in fg2sub360mg3cbxq1...@mail.gmail.com>
> > On Mon, Apr 16, 2018 at 4:10 PM, Martin Swiech
> wrote:
> > > Hi folks,
> > >
> > > I got some complex query w
On Thu, Apr 19, 2018 at 2:54 AM, David Rowley
wrote:
> If we just did it at plan time then
> pre-PREPAREd queries might still prune. That does not seem very
> useful if it's being disabled due to the discovery of some bug.
>
As you have pointed out upthread, that's a problem with every enable_*
From: Konstantin Knizhnik [mailto:k.knizh...@postgrespro.ru]
Oracle, for example, you can create dedicated and non-dedicated backends.
> I wonder why we do not want to have something similar in Postgres.
Yes, I want it, too. In addition to dedicated and shared server processes,
Oracle provides D
On Wed, Apr 18, 2018 at 04:49:17PM -0400, Tom Lane wrote:
> Just to throw out a possibly-crazy idea: maybe we could fix this by
> PANIC'ing if truncation fails, so that we replay the row deletions from
> WAL. Obviously this would be intolerable if the case were frequent,
> but we've had only two s
Hi all,
I was just testing the VACUUM truncation logic, and bumped into what
looks like a corrupted btree index. Here is a reproducer:
create table aa (a int primary key, b bool);
insert into aa values (generate_series(1,100), false);
checkpoint;
update aa set b = false where a > 50; -- D
Will see...
Michael Paquier wrote:
Hi all,
I was just testing the VACUUM truncation logic, and bumped into what
looks like a corrupted btree index. Here is a reproducer:
create table aa (a int primary key, b bool);
insert into aa values (generate_series(1,100), false);
checkpoint;
update a
There have been several discussions of replacing PG's autoconf +
src/tools/msvc system. The last example is happening now at the bottom of
the Setting rpath on llvmjit.so thread.
I see potentially big advantages to moving but also to PG's conservative
approach that keeps it running on edge and old
From: Fujii Masao [mailto:masao.fu...@gmail.com]
> a very long time before accessing to the relation. Which would cause the
> response-time spikes, for example, I observed such spikes several times
> on
> the server with shared_buffers = 300GB while running the benchmark.
FYI, a long transaction t
Hi David.
On 2018/04/19 9:04, David Rowley wrote:
> On 19 April 2018 at 03:13, Robert Haas wrote:
>> On Mon, Apr 16, 2018 at 10:46 PM, David Rowley
>> wrote:
>>> The patch does happen to improve performance slightly, but that is
>>> most likely due to the caching of the ExprStates rather than th
From: Fujii Masao [mailto:masao.fu...@gmail.com]
> Yeah, it's worth working on this problem. To decrease the number of scans
> of
> shared_buffers, you would need to change the order of truncations of files
> and
> WAL logging. In RelationTruncate(), currently WAL is logged after FSM and
> VM
> are
Thank you, pushed.
Actually, I see one tiny issue with extra '*' characters here:
+* The number of attributes won't be explicitly represented if the
+* negative infinity tuple was generated during a page split that
+* occurred with a version of Postgres befo
At Wed, 18 Apr 2018 13:23:06 +0530, Ashutosh Bapat
wrote in
> On Wed, Apr 18, 2018 at 9:43 AM, Kyotaro HORIGUCHI
> wrote:
> >
> > Anyway I think we should warn or error out if one nondirect
> > update touches two nor more tuples in the first place.
> >
> > =# UPDATE fplt SET b = (CASE WHEN ran
On Thu, Apr 19, 2018 at 11:38:09AM +0800, jian.l...@i-soft.com.cn wrote:
> in commit 8561e48, _SPI_stack alloc from TopMemoryContext. But
> AtEOXact_SPI just set _SPI_stack = NULL. Is this a memory leak?
You are right. I can easily see the leak if I use for example a
background worker which conn
On Wed, Apr 18, 2018 at 10:47 PM, Teodor Sigaev wrote:
> Thank you, pushed.
Thanks.
I saw another preexisting issue, this time one that has been around
since 2007. Commit bc292937 forgot to remove a comment above
_bt_insertonpg() (the 'afteritem' stuff ended up being moved to the
bottom of _bt_f
On April 18, 2018 8:05:50 PM PDT, Thomas Munro
wrote:
>On Wed, Apr 18, 2018 at 5:04 PM, Thomas Munro
> wrote:
>> On Wed, Apr 11, 2018 at 10:22 PM, Heikki Linnakangas
> wrote:
On Tue, Apr 10, 2018 at 12:53 PM, Andres Freund
>
wrote:
> That person said he'd work on adding an equival
On Wed, Apr 18, 2018 at 10:29 PM, Teodor Sigaev wrote:
> Will see...
I'll take a look tomorrow.
--
Peter Geoghegan
101 - 125 of 125 matches
Mail list logo
