On Fri, Apr 19, 2019 at 11:23:04AM +0900, Michael Paquier wrote:
> The dependency is not strongly mandatory for the test coverage. I'll
> just go remove it if that's an annoyance.
And done.
--
Michael
signature.asc
Description: PGP signature
>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>Do you have any thoughts?
>
Hi, I updated my idea, hoping get some feedback.
[TL; DR]
The basic idea is following 4 points:
A. User can choose which database to put a cache (relation and catalog) on
shared memory and how much memory
fresh rebase
Regards
Pavel
schema-variables-20180419.patch.gz
Description: application/gzip
Hi, Hackers
pg_logical_emit_message() can be used by any user,
but the following document says that it can be used by only superuser.
> Table 9.88. Replication SQL Functions
> Use of these functions is restricted to superusers.
I think that pg_logicl_emit_message() should be used by any user.
Th
On 2019/04/19 14:39, Etsuro Fujita wrote:
> (2019/04/19 13:00), Amit Langote wrote:
>> On 2019/04/18 22:10, Etsuro Fujita wrote:
>>> * I kept all the changes in the previous patch, because otherwise
>>> postgres_fdw would fail to release resources for a foreign-insert
>>> operation created by postg
On April 18, 2019 7:53:58 PM PDT, Tom Lane wrote:
>Amit Kapila writes:
>> I am thinking that we should at least give it a try to move the map
>to
>> rel cache level to see how easy or difficult it is and also let's
>wait
>> for a day or two to see if Andres/Tom has to say anything about this
>
(2019/04/19 13:17), Amit Langote wrote:
OTOH, we don't mention at all in postgres-fdw.sgml
that postgres_fdw supports tuple routing. Maybe we should and list this
limitation or would it be too much burden to maintain?
I think it's better to add this limitation to postgres-fdw.sgml. Will
do.
(2019/04/19 13:00), Amit Langote wrote:
On 2019/04/18 22:10, Etsuro Fujita wrote:
On 2019/04/18 14:06, Amit Langote wrote:
On 2019/04/17 21:49, Etsuro Fujita wrote:
So what I'm thinking is to throw an error for cases like this.
(Though, I
think we should keep to allow rows to be moved from loc
Andrey Lepikhov writes:
> Can we include the CustomScan node in the list of nodes that do not
> support projection?
That seems like a pretty bad idea. Maybe it's a good thing for whatever
unspecified extension you have in mind right now, but it's likely to be
a net negative for many more. As a
On Wed, Apr 17, 2019 at 1:27 PM Paul Guo wrote:
>
> create db with tablespace
> drop database
> drop tablespace.
Essentially, that sequence of operations causes crash recovery to fail
if the "drop tablespace" transaction was committed before crashing.
This is a bug in crash recovery in general an
Can we include the CustomScan node in the list of nodes that do not
support projection?
Reason is that custom node can contain quite arbitrary logic that does
not guarantee projection support.
Secondly. If planner does not need a separate Result node, it just
assign tlist to subplan (i.e. change
On 2019/04/19 13:00, Amit Langote wrote:
> BTW, do you think we should update the docs regarding the newly
> established limitation of row movement involving foreign tables?
Ah, maybe not, because it's a postgres_fdw limitation, not of the core
tuple routing feature. OTOH, we don't mention at all
>>> Maybe what we should be looking for is "why doesn't the walreceiver
>>> shut down"? But the dragonet log you quote above shows the walreceiver
>>> exiting, or at least starting to exit. Tis a puzzlement.
huh ... take a look at this little stanza in PostmasterStateMachine:
if (pmState ==
Fujita-san,
On 2019/04/18 22:10, Etsuro Fujita wrote:
>> On 2019/04/18 14:06, Amit Langote wrote:
>>> On 2019/04/17 21:49, Etsuro Fujita wrote:
So what I'm thinking is to throw an error for cases like this.
(Though, I
think we should keep to allow rows to be moved from local partit
Thomas Munro writes:
> On Fri, Apr 19, 2019 at 10:22 AM Tom Lane wrote:
>> Maybe what we should be looking for is "why doesn't the walreceiver
>> shut down"? But the dragonet log you quote above shows the walreceiver
>> exiting, or at least starting to exit. Tis a puzzlement.
> ... Is there so
On Fri, Apr 19, 2019 at 10:22 AM Tom Lane wrote:
> Thomas Munro writes:
> > 2019-04-16 08:23:24.178 CEST [8393] FATAL: terminating walreceiver
> > process due to administrator command
> Maybe what we should be looking for is "why doesn't the walreceiver
> shut down"? But the dragonet log you q
Hi Michael,
I updated the patches as attached following previous discussions.
The two patches:
v2-0001-Extact-common-functions-from-pg_basebackup-into-s.patch
v2-0002-Add-option-to-write-recovery-configuration-inform.patch
1. 0001 does move those common functions & variables to two new files (on
On Thu, Apr 18, 2019 at 5:46 PM Michael Paquier wrote:
> Adding an open item is adapted, nice you found this issue. Testing on
> my laptop with v11, the non-NULL case takes 5s and the NULL case 6s.
> On HEAD, the non-NULL case takes 6s, and the NULL case takes... I
> just gave up and cancelled i
(2019/04/18 22:10), Etsuro Fujita wrote:
Notes:
* I kept all the changes in the previous patch, because otherwise
postgres_fdw would fail to release resources for a foreign-insert
operation created by postgresBeginForeignInsert() for a tuple-routable
foreign table (ie, a foreign-table subplan re
Thomas Munro writes:
> Interesting, but I'm not sure how that could be though. Perhaps, a
> bit like the other thing that cropped up in the build farm after that
> commit, removing ~200ms of needless sleeping around an earlier online
> CHECKPOINT made some other pre-existing race condition more l
Amit Kapila writes:
> I am thinking that we should at least give it a try to move the map to
> rel cache level to see how easy or difficult it is and also let's wait
> for a day or two to see if Andres/Tom has to say anything about this
> or on the response by me above to improve the current patch
Michael Paquier writes:
> On Thu, Apr 18, 2019 at 05:57:39PM -0400, Tom Lane wrote:
>> Anyway, this is *not* new in v12.
> Indeed. It seems to me that v12 makes the problem easier to appear
> though, and I got to wonder if c6c9474 is helping in that as more
> cases are popping up since mid-March
On Fri, Apr 19, 2019 at 2:30 PM Michael Paquier wrote:
> On Thu, Apr 18, 2019 at 05:57:39PM -0400, Tom Lane wrote:
> > Anyway, this is *not* new in v12.
>
> Indeed. It seems to me that v12 makes the problem easier to appear
> though, and I got to wonder if c6c9474 is helping in that as more
> cas
On Thu, Apr 18, 2019 at 2:10 PM John Naylor wrote:
>
> On Thu, Apr 18, 2019 at 2:48 PM Amit Kapila wrote:
> > I respect and will follow whatever will be the consensus after
> > discussion. However, I request you to wait for some time to let the
> > discussion conclude. If we can't get to an
> >
On Thu, Apr 18, 2019 at 05:57:39PM -0400, Tom Lane wrote:
> It's the latter. I searched the buildfarm database for failure logs
> including the string "server does not shut down" within the last three
> years, and got all of the hits attached. Not all of these look like
> the failure pattern Mich
On Thu, Apr 18, 2019 at 09:31:21PM -0400, Tom Lane wrote:
> If we think that depending on pageinspect is worthwhile here, the right
> thing to do is just to fix the README to say that you need it. I'm
> merely asking whether it's really worth the extra dependency.
The dependency is not strongly m
Hi,
On 2019-04-15 22:46:56 -0400, Tom Lane wrote:
> Using HEAD,
>
> create table t1 as select generate_series(1,4000) id;
> vacuum analyze t1;
> explain select * from t1, t1 t1b where t1.id = t1b.id;
> -- should indicate a hash join
> explain analyze select * from t1, t1 t1b where t1.id = t1b
Michael Paquier writes:
> I am wondering if it would be better to just install automatically all
> the paths listed in EXTRA_INSTALL when invoking installcheck.
Absolutely not! In the first place, "make installcheck" is supposed to
test the installed tree, not editorialize upon what's in it; and
On Wed, Apr 17, 2019 at 07:37:17PM -0700, Peter Geoghegan wrote:
> I'll create an open item for this, and begin work on a patch tomorrow.
Adding an open item is adapted, nice you found this issue. Testing on
my laptop with v11, the non-NULL case takes 5s and the NULL case 6s.
On HEAD, the non-NUL
On Thu, Apr 18, 2019 at 03:51:14PM -0400, Robert Haas wrote:
> I was thinking that a dedicated background worker would be a good
> option, but Stephen Frost seems concerned (over on the other thread)
> about how much load that would generate. That never really occurred
> to me as a serious issue a
Hi,
On 2019-04-18 17:30:20 -0700, Andres Freund wrote:
> For not the first time I was trying to remember why and when the whole
> nodeIndexscan.c:IndexNextWithReorder() business is needed. The comment
> about reordering
>
> *IndexNextWithReorder
> *
> *Like IndexNext, b
On Wed, Apr 17, 2019 at 7:37 PM Peter Geoghegan wrote:
> Tentatively, I think that the fix here is to not "itup_key->scantid =
> NULL" when a NULL value is involved (i.e. don't "itup_key->scantid =
> NULL" when we see IndexTupleHasNulls(itup) within _bt_doinsert()). We
> may also want to avoid cal
Hi,
For not the first time I was trying to remember why and when the whole
nodeIndexscan.c:IndexNextWithReorder() business is needed. The comment
about reordering
* IndexNextWithReorder
*
* Like IndexNext, but this version can also re-check ORDER BY
* ex
On Thu, Apr 18, 2019 at 01:45:45AM -0400, Tom Lane wrote:
> Is this extra dependency actually essential? I'm not really
> happy about increasing the number of moving parts in this test.
Hmmm. I don't actually object to removing the part depending on
pageinspect in the tests. Relying on the on-d
On Thu, Apr 18, 2019 at 03:16:17PM -0400, Robert Haas wrote:
> On Tue, Apr 16, 2019 at 2:45 AM Michael Paquier wrote:
>> I think that we have race conditions with checkpointing and shutdown
>> on HEAD.
>
> Any idea whether it's something newly-introduced or of long standing?
I would suggest to k
Greetings,
Ok, responding to the rest of this email.
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 17, 2019 at 6:43 PM Stephen Frost wrote:
> > Sadly, I haven't got any great ideas today. I do know that the WAL-G
> > folks have specifically mentioned issues with the visibility map
Thomas Munro writes:
> This is a curious thing from dragonet's log:
> 2019-04-16 08:23:24.178 CEST [8335] LOG: received fast shutdown request
> 2019-04-16 08:23:24.178 CEST [8335] LOG: aborting any active transactions
> 2019-04-16 08:23:24.178 CEST [8393] FATAL: terminating walreceiver
> proce
On Fri, Apr 19, 2019 at 2:53 AM Tom Lane wrote:
> Question is, what other theory has anybody got?
I wondered if there might be a way for PostmasterStateMachine() to be
reached with without signals blocked, in the case where we fork a
fresh checkpointers, and then it misses the SIGUSR2 that we
imm
Robert Haas wrote (in the other thread):
> Any idea whether it's something newly-introduced or of long standing?
It's the latter. I searched the buildfarm database for failure logs
including the string "server does not shut down" within the last three
years, and got all of the hits attached. No
On 2019-04-18 17:47:56 -0400, Bruce Momjian wrote:
> I can see a 1GB marker being used for that. It would prevent an
> incremental backup from being done until the first 1G modblock files was
> written, since until then there is no record of modified blocks, but
> that seems fine. A 1G marker wou
On 2019-Apr-17, Alvaro Herrera wrote:
> On 2019-Apr-17, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > 1. pg_dump now uses regular CREATE TABLE followed by ALTER TABLE / ATTACH
> > >PARTITION when creating partitions, rather than CREATE TABLE
> > >PARTITION OF. pg_dump --binary-upgr
On Thu, Apr 18, 2019 at 04:25:24PM -0400, Robert Haas wrote:
> On Thu, Apr 18, 2019 at 3:51 PM Bruce Momjian wrote:
> > How would you choose the STARTLSN/ENDLSN? If you could do it per
> > checkpoint, rather than per-WAL, I think that would be great.
>
> I thought of that too. It seems appealin
Greetings,
I wanted to respond to this point specifically as I feel like it'll
really help clear things up when it comes to the point of view I'm
seeing this from.
* Robert Haas (robertmh...@gmail.com) wrote:
> > Perhaps that's what we're both saying too and just talking past each
> > other, but
Andres Freund writes:
> My compromise suggestion would be to try to give John and Amit ~2 weeks
> to come up with a cleanup proposal, and then decide whether to 1) revert
> 2) apply the new patch, 3) decide to live with the warts for 12, and
> apply the patch in 13. As we would already have a patc
Hi,
On 2019-04-17 12:20:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-04-17 15:49:29 +0530, Amit Kapila wrote:
> >> OTOH, if we want to extend it later for whatever reason to a relation
> >> level cache, it shouldn't be that difficult as the implementation is
> >> mostly contained
Hi,
On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
> The comments for relation_set_new_relfilenode() callback say that the AM can
> set *freezeXid and *minmulti to invalid. But when I did that, VACUUM hits
> this assertion:
>
> TRAP: FailedAssertion("!(((classForm->relfrozenxid) >= ((Tra
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Apr 17, 2019 at 5:20 PM Stephen Frost wrote:
> > As I understand it, the problem is not with backing up an individual
> > database or cluster, but rather dealing with backing up thousands of
> > individual clusters with thousands o
On Thu, Apr 18, 2019 at 3:51 PM Bruce Momjian wrote:
> How would you choose the STARTLSN/ENDLSN? If you could do it per
> checkpoint, rather than per-WAL, I think that would be great.
I thought of that too. It seems appealing, because you probably only
really care whether a particular block was
On Thu, Apr 18, 2019 at 03:43:30PM -0400, Robert Haas wrote:
> You can make it kinda make sense by saying "the blocks modified by
> records *beginning in* segment XYZ" or alternatively "the blocks
> modified by records *ending in* segment XYZ", but that seems confusing
> to me. For example, suppos
On Mon, Apr 15, 2019 at 11:45 PM Michael Paquier wrote:
> On Mon, Apr 15, 2019 at 09:04:13PM -0400, Robert Haas wrote:
> > That is pretty much exactly what I was intending to propose.
>
> Any caller of XLogWrite() could switch to a new segment once the
> current one is done, and I am not sure that
I wrote:
> [ let's fix this by reverting ruleutils back to using Plans not PlanStates ]
BTW, while I suspect the above wouldn't be a huge patch, it doesn't
seem trivial either. Since the issue is (a) cosmetic and (b) not new
(v11 behaves the same way), I don't think we should consider it to be
an
On Mon, Apr 15, 2019 at 10:22 PM Bruce Momjian wrote:
> > > I am thinking tools could retain modblock files along with WAL, could
> > > pull full-page-writes from WAL, or from PGDATA. It avoids the need to
> > > scan 16MB WAL files, and the WAL files and modblock files could be
> > > expired inde
Amit Langote writes:
> On 2019/02/23 2:23, Tom Lane wrote:
>> Fix plan created for inherited UPDATE/DELETE with all tables excluded.
> I noticed that we may have forgotten to fix one more thing in this commit
> -- nominalRelation may refer to a range table entry that's not referenced
> elsewhere
čt 18. 4. 2019 v 21:12 odesílatel Alvaro Herrera
napsal:
> On 2019-Apr-18, Pavel Stehule wrote:
>
> > I don't know any about other cases. Other results in psql has tabular
> > format.
>
> What about EXPLAIN?
>
I forgot it, thank you
Pavel
> --
> Álvaro Herrerahttps://www.2ndQu
On Tue, Apr 16, 2019 at 2:45 AM Michael Paquier wrote:
> I think that we have race conditions with checkpointing and shutdown
> on HEAD.
Any idea whether it's something newly-introduced or of long standing?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compa
On 2019-Apr-18, Pavel Stehule wrote:
> I don't know any about other cases. Other results in psql has tabular
> format.
What about EXPLAIN?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Apr 17, 2019 at 11:55 PM Tom Lane wrote:
> * I'm not sure whether we want to try to back-patch this, or how
> far it should go. The misbehavior has been there a long time
> (at least back to 8.4, I didn't check further); so the lack of
> previous reports means people seldom try to do it.
Hi,
> > Wow. I have to admit that I feel completely opposite of that- I'd
> > *love* to have an independent tool (which ideally uses the same code
> > through the common library, or similar) that can be run to apply WAL.
> >
> > In other words, I don't agree that it's the server's problem at all
On Tue, Apr 16, 2019 at 10:49 PM Amit Langote
wrote:
> Maybe, not show them? That may be a bit inconsistent, because the point
> of VERBOSE is to the targetlist among other things, but maybe the users
> wouldn't mind not seeing it on such empty Append nodes. OTOH, they are
> more likely to think
On Wed, Apr 17, 2019 at 6:43 PM Stephen Frost wrote:
> Sadly, I haven't got any great ideas today. I do know that the WAL-G
> folks have specifically mentioned issues with the visibility map being
> large enough across enough of their systems that it kinda sucks to deal
> with. Perhaps we could
Amit Langote writes:
> On 2019/04/17 13:10, Tom Lane wrote:
>> No, the larger issue is that *any* plan node above the Append might
>> be recursing down to/through the Append to find out what to print for
>> a Var reference. We have to be able to support that.
> I wonder why the original targetli
On Thu, Apr 18, 2019 at 10:09 PM Tom Lane wrote:
> Andy Fan writes:
> > when I fetch from holdable cursor, I found the fact is more complex
> than I
> > expected.
> > ...
> > why the 3rd time is necessary and will the performance be bad due to this
> > design?
>
> If you read the whole cursor o
Hi,
On 2019-04-18 11:34:32 -0400, Bruce Momjian wrote:
> On Thu, Apr 18, 2019 at 05:32:57PM +0200, David Fetter wrote:
> > On Wed, Apr 17, 2019 at 11:57:35AM -0400, Bruce Momjian wrote:
> > > Also, instead of storing the file name and block number in the modblock
> > > file, using the database oid
On Wed, Apr 17, 2019 at 5:20 PM Stephen Frost wrote:
> As I understand it, the problem is not with backing up an individual
> database or cluster, but rather dealing with backing up thousands of
> individual clusters with thousands of tables in each, leading to an
> awful lot of tables with lots o
čt 18. 4. 2019 v 18:35 odesílatel Bruce Momjian napsal:
> On Thu, Apr 18, 2019 at 06:06:40PM +0200, Pavel Stehule wrote:
> >
> >
> > čt 18. 4. 2019 v 17:58 odesílatel Bruce Momjian
> napsal:
> >
> > On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
> > > čt 18. 4. 2019 v 15:
On Thu, Apr 18, 2019 at 06:06:40PM +0200, Pavel Stehule wrote:
>
>
> čt 18. 4. 2019 v 17:58 odesílatel Bruce Momjian napsal:
>
> On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
> > čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian
> napsal:
> > In testing pspg,
čt 18. 4. 2019 v 17:58 odesílatel Bruce Momjian napsal:
> On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
> > čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian
> napsal:
> > In testing pspg, it seems to work fine with tabular and
> \x-non-tabular
> > data. Are you asking fo
On Thu, Apr 18, 2019 at 05:45:24PM +0200, Pavel Stehule wrote:
> čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian napsal:
> In testing pspg, it seems to work fine with tabular and \x-non-tabular
> data. Are you asking for a pager option that is only used for non-\x
> display? What do
čt 18. 4. 2019 v 15:51 odesílatel Bruce Momjian napsal:
> On Thu, Apr 18, 2019 at 07:20:37AM +0200, Pavel Stehule wrote:
> > Hi
> >
> > I wrote a pspg pager https://github.com/okbob/pspg
> >
> > This pager is designed for tabular data. It can work in fallback mode as
> > classic pager, but it is
On Thu, Apr 18, 2019 at 05:32:57PM +0200, David Fetter wrote:
> On Wed, Apr 17, 2019 at 11:57:35AM -0400, Bruce Momjian wrote:
> > Also, instead of storing the file name and block number in the modblock
> > file, using the database oid, relfilenode, and block number (3 int32
> > values) should be s
On Wed, Apr 17, 2019 at 11:57:35AM -0400, Bruce Momjian wrote:
> On Tue, Apr 16, 2019 at 06:40:44PM -0400, Robert Haas wrote:
> > Yeah, I really hope we don't end up with dueling patches. I want to
> > come up with an approach that can be widely-endorsed and then have
> > everybody rowing in the s
Thomas Munro writes:
> On Wed, Apr 17, 2019 at 10:45 AM Tom Lane wrote:
>> I think what we need to look for is reasons why (1) the postmaster
>> never sends SIGUSR2 to the checkpointer, or (2) the checkpointer's
>> main loop doesn't get to noticing shutdown_requested.
>>
>> A rather scary point
Andy Fan writes:
> when I fetch from holdable cursor, I found the fact is more complex than I
> expected.
> ...
> why the 3rd time is necessary and will the performance be bad due to this
> design?
If you read the whole cursor output, then close the transaction and
persist the cursor, yes we'll
On Thu, Apr 18, 2019 at 07:20:37AM +0200, Pavel Stehule wrote:
> Hi
>
> I wrote a pspg pager https://github.com/okbob/pspg
>
> This pager is designed for tabular data. It can work in fallback mode as
> classic pager, but it is not designed for this purpose (and I don't plan do
> it). Can we enhan
Amit-san,
Thanks for the comments!
(2019/04/18 14:08), Amit Langote wrote:
On 2019/04/18 14:06, Amit Langote wrote:
On 2019/04/17 21:49, Etsuro Fujita wrote:
I think the reason for that is: the row routed to remp is incorrectly
fetched as a to-be-updated row when updating remp as a subplan
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].
I refactored XLOG reading functions so that we don't need the
callback. In short, ReadRecrod now calls XLogPageRead direc
when I fetch from holdable cursor, I found the fact is more complex than I
expected.
suppose we fetched 20 rows.
1). It will fill a PortalStore, the dest is not the client, it is the
DestTupleStore, called ExecutePlan once and receiveSlot will be call 20
times.
2). the portal for client then
On Thu, Apr 18, 2019 at 2:48 PM Amit Kapila wrote:
> I respect and will follow whatever will be the consensus after
> discussion. However, I request you to wait for some time to let the
> discussion conclude. If we can't get to an
> agreement or one of John or me can't implement what is decided,
On 2019-03-25 09:04, Peter Eisentraut wrote:
> So perhaps push the check down to GetRelationPublicationActions()
> instead. That way we don't have to patch up two places and everything
> "just works" even for possible other callers. See attached patch.
This has been committed and backpatched to
79 matches
Mail list logo
