On Fri, Apr 26, 2019 at 11:52 AM Amit Kapila wrote:
>
> On Thu, Apr 25, 2019 at 12:39 PM John Naylor
> wrote:
> >
> > On Wed, Apr 24, 2019 at 1:58 PM Amit Kapila wrote:
> > >
> >
> > Sorry for not noticing earlier, but this patch causes a regression
> > test failure for me (attached)
> >
>
>
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.
I took a stab at untying the free space code from any knowledge about
heaps, and
Amit-san,
(2019/04/26 13:20), Amit Langote wrote:
On 2019/04/25 22:17, Etsuro Fujita wrote:
(2019/04/24 22:04), Laurenz Albe wrote:
Before PostgreSQL v11, a foreign data wrapper could be certain that
BeginForeignModify is always called before ExecForeignInsert.
This is no longer
Fujita-san,
On 2019/04/25 22:17, Etsuro Fujita wrote:
> (2019/04/24 22:04), Laurenz Albe wrote:
>> Before PostgreSQL v11, a foreign data wrapper could be certain that
>> BeginForeignModify is always called before ExecForeignInsert.
>> This is no longer true.
>
> OK, how about something
Hi,
I couldn't find old discussions or source code comments about this, but
has someone encountered the following error and wondered whether it's
working that way for a reason?
select a::text, b from foo order by 1, 2 collate "C";
ERROR: collations are not supported by type integer
LINE 1:
Hi Kirk,
Thank you for your reviewing.
> Docs:
> It would be better to have reference to the documentations of Frontend/Backend
> Protocol's "Message Format".
I added a link to "Protocol's Message Formats" and little explanation to
PQtrace() documentation.
> Code:
> There are some protocol
On Thu, Apr 25, 2019 at 12:39 PM John Naylor
wrote:
>
> On Wed, Apr 24, 2019 at 1:58 PM Amit Kapila wrote:
> >
>
> Sorry for not noticing earlier, but this patch causes a regression
> test failure for me (attached)
>
Can you please try to finish the remaining work of the patch (I am bit
tied
On 2019/04/25 19:02, Amit Langote wrote:
> On 2019/04/25 11:21, Amit Langote wrote:
>> On 2019/04/25 8:27, Tom Lane wrote:
>>> BTW, I hadn't ever looked closely at what the index reuse code
>>> does, and now that I have, my heart just sinks. I think that
>>> logic needs to be nuked from orbit.
On Thu, Apr 25, 2019 at 03:08:36PM -0400, Alvaro Herrera wrote:
> On 2019-Apr-26, Fujii Masao wrote:
>> I did that arrangement because the format of PREPARE TRANSACTION record,
>> i.e., that struct, also needs to be accessed in backend and frontend.
>> But, of course, if there is smarter way, I'm
On Thu, Apr 25, 2019 at 11:32:21AM -0400, Tom Lane wrote:
> What you have to do to get it to crash is to ensure that
> RelationSetNewRelfilenode's update of pg_class will be a non-HOT
> update. You can try to set that up with "vacuum full pg_class"
> but it turns out that that tends to leave the
On Thu, Apr 25, 2019 at 01:34:41PM -0700, Peter Geoghegan wrote:
> The documentation has a section called "Routine Reindexing", which
> explains how to simulate REINDEX CONCURRENTLY with a sequence of
> creation and replacement steps. This should be updated to reference
> the REINDEX CONCURRENTLY
On Thu, Apr 25, 2019 at 12:54:06PM -0700, Andres Freund wrote:
> I think that'd make sense. The rest of the RMT probably isn't awake
> however, so I think it'd be good to give them 24h to object.
It would be nice to clean all that now, so +1 from me to apply the
patch.
--
Michael
signature.asc
On Thu, Apr 25, 2019 at 7:23 PM Alvaro Herrera wrote:
> Maybe it takes more than -O0 in cflags to disable those, but as I said,
> the compile lines do show the -O0.
Apparently, GCC does perform some optimizations at -O0, which is
barely acknowledged by its documentation:
On 2019-Apr-25, Peter Geoghegan wrote:
> On Fri, Apr 12, 2019 at 10:24 AM Alvaro Herrera
> wrote:
> > Hmm, it's odd, because
> > https://coverage.postgresql.org/src/backend/access/nbtree/nbtutils.c.gcov.html
> > still shows that function doing that. pg_config shows:
> >
> > $ ./pg_config
Hi,
On 2019-04-25 17:12:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-04-25 16:02:03 -0400, Tom Lane wrote:
> >> That could work. The important API spec is then that the relcache entry
> >> reflects the *previous* state of the relation, and is not to be modified
> >> by the
On Wed. Apr. 24, 2019 at 11:40 PM Masao, Fujii
wrote:
Thank you for the comment.
I understand about REPLICATION privilege and notice my unecessary words.
I update the patch.
Regards
Ryo Matsumura
pg_logical_emit_message_doc_v1_2.patch
Description: pg_logical_emit_message_doc_v1_2.patch
On Fri, Apr 12, 2019 at 10:24 AM Alvaro Herrera
wrote:
> Hmm, it's odd, because
> https://coverage.postgresql.org/src/backend/access/nbtree/nbtutils.c.gcov.html
> still shows that function doing that. pg_config shows:
>
> $ ./pg_config --configure
> '--enable-depend' '--enable-coverage'
On Tue, Apr 16, 2019 at 12:00 PM Peter Geoghegan wrote:
> 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
On Mon, Apr 22, 2019 at 5:22 AM Andrey Borodin wrote:
> > 21 апр. 2019 г., в 17:32, 梦旅人 написал(а):
> >I want to add a feature in PostgreSQL, and I need use map structure and
> > set structure(like STL in C++). Do PostgreSQL have realized these
> > structures? Where can I find the
Hi Heikki, Ashwin, Tom,
On 2019-04-23 15:52:01 -0700, Andres Freund wrote:
> On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
> > index_update_stats() calls RelationGetNumberOfBlocks(). If the AM
> > doesn't use normal data files, that won't work. I bumped into that with my
> > toy
Hi,
On 2019-04-25 17:12:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > My point was that given the current coding the code in
> > ATExecSetTableSpace() would make changes to the *old* relfilenode, after
> > having already copied the contents to the new relfilenode. Which means
> > that if
On Wed, Apr 24, 2019 at 06:04:41PM -0400, Tom Lane wrote:
Peter Geoghegan writes:
On Wed, Apr 24, 2019 at 2:15 PM Joe Conway wrote:
Has anyone ever (or recently) measured the impact on performance to have
this enabled? Is it that generically useful for debugging of production
instances of
On Thu, Apr 25, 2019 at 09:25:03AM +0900, Michael Paquier wrote:
On Wed, Apr 24, 2019 at 05:18:08PM -0700, Andres Freund wrote:
Just so it's guaranteed that it'll never happen? :)
Items get done, from time to time... b0eaa4c is one rare example :p
/me runs and hides.
IMO this is one of
Andres Freund writes:
> On 2019-04-25 16:02:03 -0400, Tom Lane wrote:
>> That could work. The important API spec is then that the relcache entry
>> reflects the *previous* state of the relation, and is not to be modified
>> by the tableam call.
> Right.
> I was wondering if we should just pass
Hi,
On 2019-04-25 16:02:03 -0400, Tom Lane wrote:
> > Currently the only thing that table_relation_set_new_filenode() accesses
> > that already is updated is the RelFileNode. I wonder if we shouldn't
> > change the API so that table_relation_set_new_filenode() will get a
> > relcache entry
On Thu, Apr 25, 2019 at 1:56 PM Tom Lane wrote:
> Well, I was suggesting that we ought to consider the alternative of
> making it *not* always compiled, and Jeff was pushing back on that.
Right. Sorry.
--
Peter Geoghegan
Alvaro Herrera writes:
> On 2019-Apr-25, Jeff Janes wrote:
>> I've had people use it to get some insight into the operation and memory
>> usage of Aggregate nodes, since those nodes offer nothing useful via
>> EXPLAIN ANALYZE. It would be a shame to lose that ability on
>> package-installed
On Thu, Apr 25, 2019 at 1:52 PM Alvaro Herrera wrote:
> But the proposal is not to remove the _code_. The proposal is just to
> remove that "#ifdef" lines that would make it conditionally compilable,
> *if* the symbol that they test weren't always enabled. In other words,
> turn it from "always
On 2019-Apr-25, Jeff Janes wrote:
> I've had people use it to get some insight into the operation and memory
> usage of Aggregate nodes, since those nodes offer nothing useful via
> EXPLAIN ANALYZE. It would be a shame to lose that ability on
> package-installed PostgreSQL unless we fix
I wrote:
> Well, that's just coincidental for the case where the problem fdw_expr is
> a Param. I haven't tried to figure out exactly what upper-path generation
> thinks it should put into fdw_exprs, but is it really only Params?
Oh, this is interesting:
regression=# explain verbose
select
The documentation has a section called "Routine Reindexing", which
explains how to simulate REINDEX CONCURRENTLY with a sequence of
creation and replacement steps. This should be updated to reference
the REINDEX CONCURRENTLY command.
--
Peter Geoghegan
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On Thu, Apr 25, 2019 at 8:24 PM Tom Lane wrote:
>> The proximate cause of the crash is that we have {PARAM 1}
>> (representing the output of the InitPlan) in the path's fdw_exprs, and
>> also the identical expression in fdw_scan_tlist, and that
> On Thu, Apr 25, 2019 at 8:24 PM Tom Lane wrote:
>
> The proximate cause of the crash is that we have {PARAM 1}
> (representing the output of the InitPlan) in the path's fdw_exprs, and
> also the identical expression in fdw_scan_tlist, and that means that when
> setrefs.c processes the
Andres Freund writes:
> On 2019-04-25 14:50:09 -0400, Tom Lane wrote:
>> As far as I can see, there is no API restriction on what parts of the
>> relcache entry it may presume are valid. It *certainly* thinks that
>> rd_rel is valid, which is rather at odds with the fact that this has
>> to be
Hi,
On 2019-04-25 15:05:47 -0400, Alvaro Herrera wrote:
> On 2019-Mar-10, Dmitry Dolgov wrote:
>
> > Then I guess we need to add the attached patch on top of a pg_dump support
> > for
> > table am. It contains changes to use NULL as a default value for owner /
> > defn /
> > dropStmt (exactly
Alexander Korotkov writes:
> I'm going to commit these adjustments if no objections.
Sorry for not getting to this sooner. Looking quickly at the v2 patch,
it seems like you didn't entirely take to heart the idea of preferring
a useful primary error message over a boilerplate primary with
On 2019-Apr-26, Fujii Masao wrote:
> On Fri, Apr 26, 2019 at 1:04 AM Alvaro Herrera
> wrote:
> > I also wonder if
> > defining the structs in the way you do is the most sensible arrangement.
>
> I did that arrangement because the format of PREPARE TRANSACTION record,
> i.e., that struct,
On 2019-Mar-10, Dmitry Dolgov wrote:
> Then I guess we need to add the attached patch on top of a pg_dump support for
> table am. It contains changes to use NULL as a default value for owner / defn
> /
> dropStmt (exactly what we've changed back in 19455c9f56), and doesn't crash,
> since K_VERS
PG Bug reporting form writes:
> [ this crashes if ft4 is a postgres_fdw foreign table: ]
> select exists(select c1 from ft4), avg(c1) from ft4 where c1 = (select
> max(c1) from ft4);
Hm, the max() subquery isn't necessary, this is sufficient:
select exists(select c1 from ft4), avg(c1) from ft4
On Fri, Apr 26, 2019 at 1:04 AM Alvaro Herrera wrote:
>
> On 2019-Apr-26, Fujii Masao wrote:
>
> > Hi,
> >
> > pg_waldump report no detail information about PREPARE TRANSACTION record,
> > as follows.
> >
> > rmgr: Transaction len (rec/tot):250/ 250, tx:485,
> > lsn: 0/02A8,
On 2019-Apr-06, Tom Lane wrote:
> BTW, I just stumbled across a different bug in v11 by trying to run
> HEAD's test script on it ... not sure if that's a known problem or not:
>
> (gdb) f 3
> #3 0x0063949c in ExecSetupPartitionTupleRouting (
> mtstate=, rel=0x7f343e4f4170) at
Hi,
On 2019-04-25 12:29:16 -0400, Tom Lane wrote:
> I wrote:
> > The problem here is that RelationSetNewRelfilenode is aggressively
> > changing the index's relcache entry before it's written out the
> > updated tuple, so that the tuple update tries to make an index
> > entry in the new storage
On Wed, Apr 24, 2019 at 9:03 PM Alexander Korotkov
wrote:
> On Mon, Apr 22, 2019 at 1:39 AM Tom Lane wrote:
> > Alexander Korotkov writes:
> > >> On Wed, Apr 17, 2019 at 8:43 PM Tom Lane wrote:
> > >>> Yeah, I'd noticed that one too :-(. I think the whole jsonpath patch
> > >>> needs a sweep
On Thu, Apr 25, 2019 at 9:45 AM Tom Lane wrote:
> However, by that argument we should change all 3 of these functions to
> set up the data. If we're eating the layering violation to the extent
> of letting OpenTemporaryFile call into commands/tablespace, then there's
> little reason for the
On Thu, Apr 25, 2019 at 7:15 AM Dilip Kumar wrote:
> > +static UndoBuffers def_buffers[MAX_UNDO_BUFFERS];
> > +static int buffer_idx;
> >
> > This is a file-global variable with a very generic name that is very
> > similar to a local variable name used by multiple functions within the
> > file
On Thu, Apr 25, 2019 at 9:19 AM Ashwin Agrawal wrote:
> Just to provide my opinion, since we are at intersection and can go
> either way on this. Second approach (just adding assert) only helps
> if the code path for ALL future callers gets excersied and test exist for
> the
> same, to expose
Ashwin Agrawal writes:
> On Wed, Apr 24, 2019 at 5:48 PM Peter Geoghegan wrote:
>> Like you, I find it hard to prefer one of the approaches over the
>> other, though I don't really know how to assess this layering
>> business. I'm glad that either approach will prevent oversights,
>> though.
>
Hello,
Oleksii Kliukin wrote:
> Tom Lane wrote:
>
>
>> I don't know how to make this better, but I wish we'd take a step
>> back and think about it rather than just accreting more and more
>> complexity.
>
> I am willing to do the refactoring when necessary, any particular place in
> the
I wrote:
> The problem here is that RelationSetNewRelfilenode is aggressively
> changing the index's relcache entry before it's written out the
> updated tuple, so that the tuple update tries to make an index
> entry in the new storage which isn't filled yet. I think we can
> fix it by *not*
On Wed, Apr 24, 2019 at 5:48 PM Peter Geoghegan wrote:
> On Wed, Apr 24, 2019 at 12:17 PM Tom Lane wrote:
> > After a bit more thought it seemed like another answer would be to
> > make all three of those functions assert that the caller did the
> > right thing, as per attached. This addresses
On 2019-Apr-26, Fujii Masao wrote:
> Hi,
>
> pg_waldump report no detail information about PREPARE TRANSACTION record,
> as follows.
>
> rmgr: Transaction len (rec/tot):250/ 250, tx:485,
> lsn: 0/02A8, prev 0/0260, desc: PREPARE
>
> I'd like to modify pg_waldump,
On Wed, Apr 24, 2019 at 6:04 PM Tom Lane wrote:
> Peter Geoghegan writes:
>
> > In
> > any case the current status quo is that it's built by default. I have
> > used it in production, though not very often. It's easy to turn it on
> > and off.
>
> Would any non-wizard really have a use for it?
Hi,
pg_waldump report no detail information about PREPARE TRANSACTION record,
as follows.
rmgr: Transaction len (rec/tot):250/ 250, tx:485,
lsn: 0/02A8, prev 0/0260, desc: PREPARE
I'd like to modify pg_waldump, i.e., xact_desc(), so that it reports
detail information
Michael Paquier writes:
> On Tue, Apr 23, 2019 at 08:03:37PM -0400, Tom Lane wrote:
>> Oh! One gets you ten it "works" as long as the pg_class update is a
>> HOT update, so that we don't actually end up touching the indexes.
> I have been able to spend a bit more time testing and looking at the
On Tue, Apr 23, 2019 at 7:09 AM Masahiko Sawada wrote:
> For the second issue, I've changed lazy vacuum so that it reports both
> the number of kilobytes we freed and the number of kilobytes can be
> freed after index cleanup.
I am not very convinced that this reporting is in any useful to
On 2019-Apr-25, Michael Paquier wrote:
> 2) Bisecting between the merge base points of REL9_4_STABLE/master and
> REL9_5_STABLE/master, I am being pointed to the introduction of
> replication origins:
> commit: 5aa2350426c4fdb3d04568b65aadac397012bbcb
> author: Andres Freund
> date: Wed, 29 Apr
On Thu, Apr 25, 2019 at 6:51 PM Kyotaro HORIGUCHI
wrote:
>
> Hello.
>
> I happened to find that several symbols renamed in 3eb77eba5a are
> left in comments. Please find the attached.
Thanks for the patch! Committed.
Regards,
--
Fujii Masao
On Thu, Apr 25, 2019 at 10:46 PM Alvaro Herrera
wrote:
> Haven't read the patch, but I tried applying it on top of my tablespace
> fixing patch ... and my first report is that this query in regress fails
> (three times):
>
> select conname, obj_description(oid, 'pg_constraint') from
I have pushed this now, after putting back a few of the tests I had
proposed earlier, as well as a couple of sentences in the docs to
hopefully make it clearer how it works.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
On Thu, 2019-04-25 at 22:17 +0900, Etsuro Fujita wrote:
> > The documentation of ExecForeignInsert should mention something like:
> >
> >ExecForeignInsert is called for INSERT statements as well
> >as for COPY FROM and tuples that are inserted into a foreign table
> >because it is a
Paul Guo writes:
> On Wed, Apr 24, 2019 at 10:36 PM Tom Lane wrote:
>> Alvaro Herrera writes:
>>> But the pgstat.c patch seems reasonable to me.
>> Nah, I don't buy that one either. Nobody has any business creating any
>> non-Postgres files in the stats directory ... and if somebody does want
Haven't read the patch, but I tried applying it on top of my tablespace
fixing patch ... and my first report is that this query in regress fails
(three times):
select conname, obj_description(oid, 'pg_constraint') from pg_constraint where
conname = 'c_chk' order by 1, 2;
conname |
(2019/04/24 22:04), Laurenz Albe wrote:
On Wed, 2019-04-24 at 20:54 +0900, Etsuro Fujita wrote:
How about adding to the documentation for BeginForeignInsert a mention
that if an FDW doesn't support COPY FROM and/or routable foreign tables,
it must throw an error in BeginForeignInsert
On Tue, Apr 23, 2019 at 08:03:37PM -0400, Tom Lane wrote:
> Oh! One gets you ten it "works" as long as the pg_class update is a
> HOT update, so that we don't actually end up touching the indexes.
> This explains why the crash is less likely to happen in a database
> where one's done some work
Kyotaro HORIGUCHI wrote:
> Hello. As mentioned before [1], read_page callback in
> XLogReaderState is a cause of headaches. Adding another
> remote-controlling stuff to xlog readers makes things messier [2].
The patch I posted in thread [2] tries to solve another problem: it tries to
merge
On Wed, Apr 24, 2019 at 12:57 PM Stephen Frost wrote:
> So, I had a thought about that when I was composing the last email and
> while I'm still unsure about it, maybe it'd be useful to mention it
> here- do we really need a list of every *file*, or could we reduce that
> down to a list of
On Wed, Apr 24, 2019 at 7:55 AM Tom Lane wrote:
> Michael Paquier writes:
> > On Tue, Apr 23, 2019 at 04:47:19PM -0400, Tom Lane wrote:
> >> Is there some precondition you're not mentioning?
>
> > Hm. In my own init scripts, I create a new database just after
> > starting the instance.
>
> Ah,
On 2019/04/25 11:21, Amit Langote wrote:
> On 2019/04/25 8:27, Tom Lane wrote:
>> BTW, I hadn't ever looked closely at what the index reuse code
>> does, and now that I have, my heart just sinks. I think that
>> logic needs to be nuked from orbit. RelationPreserveStorage was
>> never meant to be
Hello.
I happened to find that several symbols renamed in 3eb77eba5a are
left in comments. Please find the attached.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git a/src/backend/postmaster/checkpointer.c b/src/backend/postmaster/checkpointer.c
index
At Wed, 24 Apr 2019 09:30:12 -0700, Andres Freund wrote in
<20190424163012.7wzdl6j2v73cu...@alap3.anarazel.de>
> Hi,
>
> On 2019-04-24 17:02:28 +0900, Kyotaro HORIGUCHI wrote:
> > +/*
> > + * Check if the path is in the data directory strictly.
> > + */
> > +static bool
> >
On Wed, Apr 24, 2019 at 1:58 PM Amit Kapila wrote:
>
Sorry for not noticing earlier, but this patch causes a regression
test failure for me (attached)
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 15/04/2019 22:32, Peter Geoghegan wrote:
On Mon, Apr 15, 2019 at 12:19 PM Tom Lane wrote:
Perhaps, but we won't know if we don't try. I think we should try,
and be willing to add hooks and flexibility to core as needed to make
it possible.
We could approach it without taking a firm
72 matches
Mail list logo
