Hi all!
I am sending our comments to mentioned issues. I was trying to send it
month ago
(https://www.postgresql.org/message-id/CA%2B8wVNUOt2Bh4x7YQEVoq5BfP%3DjM-F6cDYKxJiTODG_VCGhUVQ%40mail.gmail.com),
but it somehow doesn't append in the "thread" (sorry, I am new in
mailing list practice...).
On Wed, Apr 17, 2019 at 2:04 AM Andres Freund wrote:
>
> Hi,
>
> I'm somewhat unhappy in how much the no-fsm-for-small-rels exposed
> complexity that looks like it should be purely in freespacemap.c to
> callers.
>
>
> extern Size GetRecordedFreeSpace(Relation rel, BlockNumber heapBlk);
> -extern
>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>Sent: Wednesday, December 5, 2018 2:42 PM
>Subject: RE: Copy data to DSA area
Hi
It's been a long while since we discussed this topic.
Let me recap first and I'll give some thoughts.
It seems things we got consensus is:
- Want to
David Rowley writes:
> On Wed, 17 Apr 2019 at 15:54, Tom Lane wrote:
>> What I'm more worried about is whether this breaks any internal behavior
>> of explain.c, as the comment David quoted upthread seems to think.
>> If we need to have a tlist to reference, can we make that code look
>> to the p
On 2019/04/17 12:58, David Rowley wrote:
> On Wed, 17 Apr 2019 at 15:54, Tom Lane wrote:
>>
>> Amit Langote writes:
>>> On 2019/04/17 11:29, David Rowley wrote:
Where do you think the output list for EXPLAIN VERBOSE should put the
output column list in this case? On the Append node, or
Bruce Momjian writes:
> I have found that log_planner_stats only outputs stats until the generic
> plan is chosen. For example, if you run the following commands:
Uh, well, the planner doesn't get run after that point ...
regards, tom lane
On Wed, 17 Apr 2019 at 15:54, Tom Lane wrote:
>
> Amit Langote writes:
> > On 2019/04/17 11:29, David Rowley wrote:
> >> Where do you think the output list for EXPLAIN VERBOSE should put the
> >> output column list in this case? On the Append node, or just not show
> >> them?
>
> > Maybe, not sho
Amit Langote writes:
> On 2019/04/17 11:29, David Rowley wrote:
>> Where do you think the output list for EXPLAIN VERBOSE should put the
>> output column list in this case? On the Append node, or just not show
>> them?
> Maybe, not show them?
Yeah, I think that seems like a reasonable idea. If
I have found that log_planner_stats only outputs stats until the generic
plan is chosen. For example, if you run the following commands:
SET client_min_messages = 'log';
SET log_planner_stats = TRUE;
PREPARE e AS SELECT relkind FROM pg_class WHERE relname = $1 ORD
On 2019/04/17 11:29, David Rowley wrote:
> On Wed, 17 Apr 2019 at 13:13, Amit Langote
> wrote:
>> When you see this:
>>
>> explain select * from t1 where dt = current_date + 400;
>> QUERY PLAN
>>
>> Append (cos
On Wed, 17 Apr 2019 at 13:13, Amit Langote
wrote:
> When you see this:
>
> explain select * from t1 where dt = current_date + 400;
> QUERY PLAN
>
> Append (cost=0.00..198.42 rows=44 width=8)
>Subplans Remov
Hi,
On 2019/04/16 21:09, David Rowley wrote:
> On Tue, 16 Apr 2019 at 23:55, Yuzuko Hosoya
> wrote:
>> postgres=# explain analyze select * from t1 where dt = current_date + 400;
>> QUERY PLAN
>> ---
On Mon, Apr 15, 2019 at 7:57 PM wrote:
> I forgot to mention that this is happening in a docker container.
Huh, so there may be some configuration of Linux container that can
fail here with EPERM, even though that error that does not appear in
the man page, and doesn't make much intuitive sense.
On Tue, Apr 16, 2019 at 08:03:22PM +0900, Masahiko Sawada wrote:
> Agreed. There are also some code which raise an ERROR after close a
> transient file but I think it's a good idea to not include them for
> safety. It looks to me that the patch you proposed cleans places as
> much as we can do.
Th
On Tue, Apr 16, 2019 at 08:50:31AM +0200, Peter Eisentraut wrote:
> Looks good to me.
Thanks, committed. If there are additional discussions on various
points of the feature, let's move to a new thread please. This one
has been already extensively used ;)
--
Michael
signature.asc
Description:
Hi,
On 2019-04-16 17:05:36 -0700, Andres Freund wrote:
> On 2019-04-16 18:59:37 -0400, Robert Haas wrote:
> > On Tue, Apr 16, 2019 at 6:45 PM Tom Lane wrote:
> > > Do we need to think harder about establishing rules for multiplexed
> > > use of the process latch? I'm imagining some rule like "if
Hi,
On 2019-04-16 18:59:37 -0400, Robert Haas wrote:
> On Tue, Apr 16, 2019 at 6:45 PM Tom Lane wrote:
> > Do we need to think harder about establishing rules for multiplexed
> > use of the process latch? I'm imagining some rule like "if you are
> > not the outermost event loop of a process, you
On Tue, Apr 16, 2019 at 6:45 PM Tom Lane wrote:
> Do we need to think harder about establishing rules for multiplexed
> use of the process latch? I'm imagining some rule like "if you are
> not the outermost event loop of a process, you do not get to
> summarily clear MyLatch. Make sure to leave
On Sun, Apr 14, 2019 at 3:29 PM Tom Lane wrote:
> What I get for test cases like [1] is
>
> single-partition SELECT, hash partitioning:
>
> N tps, HEAD tps, patch
> 2 11426.24375411448.615193
> 8 11254.83326711374.278861
> 32 11288.32911411371.942425
> 128
Michael Paquier writes:
> The buildfarm has reported two similar failures when shutting down a
> node:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet&dt=2019-03-23%2022%3A28%3A59
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dragonet&dt=2019-04-16%2006%3A14%3A01
> I
On Tue, Apr 16, 2019 at 5:44 PM Stephen Frost wrote:
> > > I love the general idea of having additional facilities in core to
> > > support block-level incremental backups. I've long been unhappy that
> > > any such approach ends up being limited to a subset of the files which
> > > need to be in
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Apr 15, 2019 at 09:01:11AM -0400, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > Several companies, including EnterpriseDB, NTT, and Postgres Pro, have
> > > developed technology that permits a block-level
I wrote:
> I'm thinking that we really need to upgrade vacuum's reporting totals
> so that it accounts in some more-honest way for pre-existing dead
> line pointers. The patch as it stands has made the reporting even more
> confusing, rather than less so.
Here's a couple of ideas about that:
1.
Andres Freund writes:
> On 2019-04-16 14:31:25 -0400, Tom Lane wrote:
>> This can only work at all if an inaccurate map is very fail-soft,
>> which I'm not convinced it is
> I think it better needs to be fail-soft independent of this the no-fsm
> patch. Because the fsm is not WAL logged etc, it's
Hi,
On 2019-04-16 14:31:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm kinda thinking that this is the wrong architecture.
>
> The bits of that patch that I've looked at seemed like a mess
> to me too. AFAICT, it's trying to use a single global "map"
> for all relations (strike 1) wi
On Tue, Apr 16, 2019 at 12:00 PM Peter Geoghegan wrote:
> Can you be more specific? What was the cause of the corruption? I'm
> always very interested in hearing about cases that amcheck could have
> detected, but didn't.
FWIW, v4 indexes in Postgres 12 will support the new "rootdescend"
verifica
On Mon, Apr 15, 2019 at 7:30 PM Alexander Korotkov
wrote:
> Currently we amcheck supports lossy checking for missing parent
> downlinks. It collects bitmap of downlink hashes and use it to check
> subsequent tree level. We've experienced some large corrupted indexes
> which pass this check due t
Andres Freund writes:
> I'm kinda thinking that this is the wrong architecture.
The bits of that patch that I've looked at seemed like a mess
to me too. AFAICT, it's trying to use a single global "map"
for all relations (strike 1) without any clear tracking of
which relation the map currently de
Amit Langote writes:
>> I get that we want to get rid of the keep_* kludge in the long term, but
>> is it wrong to think, for example, that having keep_partdesc today allows
>> us today to keep the pointer to rd_partdesc as long as we're holding the
>> relation open or refcnt on the whole relation
Hi,
I'm somewhat unhappy in how much the no-fsm-for-small-rels exposed
complexity that looks like it should be purely in freespacemap.c to
callers.
extern Size GetRecordedFreeSpace(Relation rel, BlockNumber heapBlk);
-extern BlockNumber GetPageWithFreeSpace(Relation rel, Size spaceNeeded);
+ext
Amit Langote writes:
> On 2019/04/15 2:38, Tom Lane wrote:
>> To my mind there are only two trustworthy solutions to the problem of
>> wanting time-extended usage of a relcache subsidiary data structure: one
>> is to copy it, and the other is to reference-count it. I think that going
>> over to a
Dear Nikolay,
Many thanks for your efforts!
On Sat, Apr 6, 2019 at 2:29 PM Nikolay Shaplov wrote:
> В письме от воскресенье, 24 февраля 2019 г. 14:31:55 MSK пользователь
> Dmitry
> Belyavsky написал:
>
> Hi! Am back here again.
>
> I've been thinking about this patch a while... Come to some con
So after thinking about this a bit more ...
ISTM that what we have here is a race condition (ie, tuple changed state
since heap_page_prune), and that ideally we want the code to resolve it
as if no race had happened. That is, either of these behaviors would
be acceptable:
1. Delete the tuple, ju
On Mon, Apr 15, 2019 at 10:45:51PM -0700, Ashwin Agrawal wrote:
On Mon, Apr 15, 2019 at 12:50 PM Peter Geoghegan wrote:
On Mon, Apr 15, 2019 at 9:16 AM Ashwin Agrawal
wrote:
> Would like to know more specifics on this Peter. We may be having
different context on hybrid row/column design.
I'm
On Tue, Apr 16, 2019 at 10:48 AM Jamison, Kirk wrote:
>
> Hello Fujii-san,
>
> On April 18, 2018, Fujii Masao wrote:
>
> > On Fri, Mar 30, 2018 at 12:18 PM, Tsunakawa, Takayuki
> > wrote:
> >> Furthermore, TRUNCATE has a similar and worse issue. While DROP TABLE
> >> scans the shared buffers on
Hi,
On 2019-04-16 12:01:36 -0400, Tom Lane wrote:
> (BTW, I don't understand why that code will throw "found xmin %u from
> before relfrozenxid %u" if HeapTupleHeaderXminFrozen is true? Shouldn't
> the whole if-branch at lines 6113ff be skipped if xmin_frozen?)
I *think* that just looks odd, but
Robert Haas writes:
> On Mon, Apr 15, 2019 at 9:07 PM Tom Lane wrote:
>> If we're failing to remove it, and it's below the desired freeze
>> horizon, then we'd darn well better freeze it instead, no?
> I don't know that that's safe. IIRC, the freeze code doesn't cope
> nicely with being given a
Hi,
On 2019-04-16 11:38:01 -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Apr-16, Robert Haas wrote:
> >> On Mon, Apr 15, 2019 at 9:07 PM Tom Lane wrote:
> >>> If we're failing to remove it, and it's below the desired freeze
> >>> horizon, then we'd darn well better freeze it instea
Hi,
On 2019-04-16 10:54:34 -0400, Alvaro Herrera wrote:
> On 2019-Apr-16, Robert Haas wrote:
> > On Mon, Apr 15, 2019 at 9:07 PM Tom Lane wrote:
> > > > I'm not sure that's correct. If you do that, it'll end up in the
> > > > non-tupgone case, which might try to freeze a tuple that should've
> >
On Mon, Apr 15, 2019 at 3:32 PM Julien Rouhaud wrote:
>
> Sorry for late reply,
>
> On Sun, Apr 14, 2019 at 7:12 PM Magnus Hagander wrote:
> >
> > On Sat, Apr 13, 2019 at 8:46 PM Robert Treat wrote:
> >>
> >> On Fri, Apr 12, 2019 at 8:18 AM Magnus Hagander
> >> wrote:
> >> ISTM the argument he
Alvaro Herrera writes:
> On 2019-Apr-16, Robert Haas wrote:
>> On Mon, Apr 15, 2019 at 9:07 PM Tom Lane wrote:
>>> If we're failing to remove it, and it's below the desired freeze
>>> horizon, then we'd darn well better freeze it instead, no?
>> I don't know that that's safe. IIRC, the freeze c
On Tue, Apr 16, 2019 at 11:26 PM Robert Haas wrote:
>
> On Mon, Apr 15, 2019 at 9:07 PM Tom Lane wrote:
> > > I'm not sure that's correct. If you do that, it'll end up in the
> > > non-tupgone case, which might try to freeze a tuple that should've
> > > been removed. Or am I confused?
> >
> > I
Michael Paquier writes:
> Aren't extra ORDER BY clauses the usual response to tuple ordering? I
> really think that we should be more aggressive with that.
I'm not excited about that. The traditional argument against it
is that if we start testing ORDER BY queries exclusively (and it
would have
On 2019-Apr-16, Robert Haas wrote:
> On Mon, Apr 15, 2019 at 9:07 PM Tom Lane wrote:
> > > I'm not sure that's correct. If you do that, it'll end up in the
> > > non-tupgone case, which might try to freeze a tuple that should've
> > > been removed. Or am I confused?
> >
> > If we're failing to
Michael Paquier writes:
> In short, I tend to think that the attached is an acceptable cleanup.
> Thoughts?
WFM.
regards, tom lane
On Mon, Apr 15, 2019 at 9:07 PM Tom Lane wrote:
> > I'm not sure that's correct. If you do that, it'll end up in the
> > non-tupgone case, which might try to freeze a tuple that should've
> > been removed. Or am I confused?
>
> If we're failing to remove it, and it's below the desired freeze
> h
Magnus Hagander writes:
> On Tue, Apr 16, 2019 at 8:55 AM Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>> On 2019-04-16 08:47, Magnus Hagander wrote:
>>> Unless we want to go all the way and have said bot actualy close the CF
>>> entry. But the question is, do we?
>> I don't thin
> 9 апр. 2019 г., в 22:30, Tom Lane написал(а):
>
> The proposal is kind of cute, but I'll bet it's a net loss for
> small copy lengths --- likely we'd want some cutoff below which
> we do it with the dumb byte-at-a-time loop.
Ture.
I've made simple extension to compare decompression time on
On Mon, 15 Apr 2019 at 15:26, Alvaro Herrera wrote:
>
> On 2019-Apr-15, David Rowley wrote:
>
> > To be honest, if I'd done a better job of thinking through the
> > implications of this tablespace inheritance in ca4103025d, then I'd
> > probably have not bothered submitting a patch for it. We cou
On Tue, 16 Apr 2019 at 23:55, Yuzuko Hosoya wrote:
> postgres=# explain analyze select * from t1 where dt = current_date + 400;
> QUERY PLAN
> ---
> Append (cost=0.00..198.42
Hi all,
I found a runtime pruning test case which may be a problem as follows:
create table t1 (id int, dt date) partition by range(dt);
create table t1_1 partition of t1 for values from ('2019-01-01') to
('2019-04-01');
create table t1_2 partition of t1 for values from ('2019-04-01') to
(
On Fri, 5 Apr 2019 at 17:31, Pavan Deolasee wrote:
> IMV it makes sense to simply cap the lower limit of toast_tuple_target to the
> compile time default and update docs to reflect that. Otherwise, we need to
> deal with the possibility of dynamically creating the toast table if the
> relation
On Tue, Apr 16, 2019 at 2:45 PM Michael Paquier wrote:
>
> On Fri, Apr 12, 2019 at 10:06:41PM +0900, Masahiko Sawada wrote:
> > But I think that's not right, I've checked the code. If the startup
> > process failed in that function it raises a FATAL and recovery fails,
> > and if checkpointer proc
On Fri, Apr 12, 2019 at 11:05 PM Tom Lane wrote:
>
> Masahiko Sawada writes:
> > There are something like the following code in many places in PostgreSQL
> > code.
> > ...
> > Since we eventually call
> > pgstat_report_wait_end() in AbortTransaction(). I think that we don't
> > need to call pgst
On Tue, Apr 16, 2019 at 4:47 AM Tom Lane wrote:
>
> Robert Haas writes:
> > On Mon, Apr 15, 2019 at 1:13 PM Tom Lane wrote:
> >> I have a very strong feeling that this patch was not fully baked.
>
> > I think you're right, but I don't understand the comment in the
> > preceding paragraph. How d
On Tue, Apr 16, 2019 at 4:47 AM Eric Hanson wrote:
> We would probably be wise to learn from what has gone (so I hear) terribly
> wrong with the Node / NPM packaging system (and I'm sure many before it),
> namely versioning. What happens when two extensions require different
> versions of the sa
On Tue, Apr 16, 2019 at 4:24 AM Eric Hanson wrote:
>
>
> On Tue, Apr 16, 2019 at 12:47 AM Noah Misch wrote:
>
>> On Mon, Mar 18, 2019 at 09:38:19PM -0500, Eric Hanson wrote:
>> > I have heard talk of a way to write extensions so that they dynamically
>> > reference the schema of their dependenci
On Tue, Apr 16, 2019 at 12:47 AM Noah Misch wrote:
> On Mon, Mar 18, 2019 at 09:38:19PM -0500, Eric Hanson wrote:
> > I have heard talk of a way to write extensions so that they dynamically
> > reference the schema of their dependencies, but sure don't know how that
> > would work if it's possibl
Hi, hackers.
I'm trying to build 64-bit windows binaries with kerberos support.
I downloaded latest kerberos source package from here:
https://kerberos.org/dist/index.html
I followed the the instructions in src\windows\README, and executed the
following script in 64-bit Visual Studio Command Promp
Hi Horiguchi-san,
Thank you for your reviewing.
I updated patch. Please see my attached patch.
> +/* protocol message name */
> +static char *command_text_b[] = {
>
> Couldn't the name be more descriptive? The comment just above doesn't seem
> consistent with the variable. The tables are very
On Tue, Apr 16, 2019 at 8:55 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-04-16 08:47, Magnus Hagander wrote:
> > Unless we want to go all the way and have said bot actualy close the CF
> > entry. But the question is, do we?
>
> I don't think so. There are too many spe
Hi all,
This is a continuation of the following thread, but I prefer spawning
a new thread for clarity:
https://www.postgresql.org/message-id/20190416064512.gj2...@paquier.xyz
The buildfarm has reported two similar failures when shutting down a
node:
https://buildfarm.postgresql.org/cgi-bin/show_
62 matches
Mail list logo
