On Wed, Feb 20, 2019 at 1:00 PM Masahiko Sawada wrote:
>
> BTW, XLogRecPtrIsInvalid(copy_restart_lsn) || copy_restart_lsn <
> src_restart_lsn is redundant, the former should be removed.
>
So attached the updated version patch.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORAT
On Mon, Feb 25, 2019 at 7:56 AM Michael Paquier wrote:
>
> On Mon, Feb 25, 2019 at 02:38:05AM +, Tsunakawa, Takayuki wrote:
> > From: Julien Rouhaud [mailto:rjuju...@gmail.com]
> >> One last thing, I think we should at least add one regression test for
> >> this setting. The one you provided
Hi,
I did upgrade of my test pg. Part of this is pg_dump -Fd of each
database, then upgrade binaries, then initdb, and pg_restore.
But - I can't restore any database that has any data - I get segfaults.
For example, with gdb:
=$ gdb --args pg_restore -v -C -Fd
backup-20190225074600.10361-db
Hello Tom,
For quite some years now there's been dissatisfaction with our List
data structure implementation. Because it separately palloc's each
list cell, it chews up lots of memory, and it's none too cache-friendly
because the cells aren't necessarily adjacent. Moreover, our typical
usage
At Mon, 25 Feb 2019 15:23:22 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190225.152322.104148315.horiguchi.kyot...@lab.ntt.co.jp>
> I think the two parameters are to be tuned in the following
> steps.
>
> - If the default setting sutisfies you, leave it alone. (as a
> general s
Tom Lane wrote:
> Not sure what I think about your new proposed patch. What problem
> do you think it solves? Also, don't think I believe this:
>
> + * crosscheck_snapshot is actually used only for UPDATE / DELETE
> + * queries.
I wanted to clarify the meaning of cro
On Mon, Feb 25, 2019 at 3:56 PM Michael Paquier wrote:
>
> On Mon, Feb 25, 2019 at 02:38:05AM +, Tsunakawa, Takayuki wrote:
> > From: Julien Rouhaud [mailto:rjuju...@gmail.com]
> >> One last thing, I think we should at least add one regression test for
> >> this setting. The one you provided
On Mon, Feb 25, 2019 at 02:38:05AM +, Tsunakawa, Takayuki wrote:
> From: Julien Rouhaud [mailto:rjuju...@gmail.com]
>> One last thing, I think we should at least add one regression test for
>> this setting. The one you provided previously seems perfectly suited.
>
> Thanks, added.
+SELECT pg
On 2/25/19 12:35 AM, Christophe Pettus wrote:
On Feb 24, 2019, at 14:19, Stephen Frost wrote:
You say above that the new interface is unquestionably an improvement
and here say that we shouldn't deprecate the old one in favor of it
(even though we actually already have... but that's beside
hi,
I have researched buffer manager with postgresql9.4.18.
For exact result, I must change IO style to Direct IO.
Then I changed the align and O_DIRECT flags according to the version, and
set the options at compile time.
However, when I run postgres with the modified version, I get ERROR: could
On 2/24/19 11:36 PM, Stephen Frost wrote:
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
Stephen Frost wrote:
Yes, it *is* impossible to do safe backups with the existing API. There
is an unquestionable race condition where a system restart will cause
your system to not come back
At Wed, 20 Feb 2019 13:09:08 -0500, Robert Haas wrote
in
> On Tue, Feb 19, 2019 at 11:15 PM Kyotaro HORIGUCHI
> wrote:
> > Difference from v15:
> >
> > Removed AllocSet accounting stuff. We use approximate memory
> > size for catcache.
> >
> > Removed prune-by-number(or size) stuff.
> >
>
Hi Amit-san.
On Fri, Feb 22, 2019 at 5:55 PM, Amit Langote wrote:
>
> Please find attached updated patches. I've made a few updates in last
> couple of hours such as improving comments, fixing a few thinkos in
> inheritance_planner changes, etc.
Thanks for the patch.
While doing code review o
On Sun, Feb 24, 2019 at 9:42 PM David Rowley
wrote:
> The current default vacuum_cost_limit of 200 seems to be 15 years old
> and was added in f425b605f4e.
>
> Any supporters for raising the default?
I also think that the current default limit is far too conservative.
--
Peter Geoghegan
Hi,
I've had to do quite a bit of performance investigation work this year
and it seems that I only too often discover that the same problem is
repeating itself... A vacuum_cost_limit that is still set to the 200
default value along with all 3 auto-vacuum workers being flat chat
trying and failing
On Mon, Feb 25, 2019 at 02:28:23PM +0900, Michael Paquier wrote:
> Done. I have spent some time today looking at the performance of the
> patch, designing a worst-case scenario to see how much bloat this adds
> in COMMIT PREPARED by running across many sessions 2PC transactions
> taking SHARE lock
On Sat, Feb 23, 2019 at 08:44:43AM +0900, Michael Paquier wrote:
> Thanks. I am still looking at this patch an extra time, so this may
> take at most a couple of days from my side. For now I have committed
> the test portion, which is independently useful and caused recovery of
> multixact post-c
Hi, all.
Thank you for discussion.
I made documentation about socket_timeout and reflected Tsunakawa-san's comment
in the new patch.
# Mainly only fixing documentation...
The current documentation of socket_timeout is as follows:
socket_timeout
Controls the number of second of client's waiting ti
From: Michael Paquier [mailto:mich...@paquier.xyz]
> I don't think that we want to use a too generic name and it seems more natural
> to reflect the context where it is used in the parameter name.
> If we were to shrink with a similar option for other contexts, we would
> most likely use a differen
Hello hackers,
1. In a nearby thread, I misdiagnosed a problem reported[1] by Justin
Pryzby (though my misdiagnosis is probably still a thing to be fixed;
see next). I think I just spotted the real problem he saw: if you
execute a parallel query after a smart shutdown has been initiated,
you wai
Hi,
On 2019-02-24 14:35:04 -0800, Christophe Pettus wrote:
> > On Feb 24, 2019, at 14:19, Stephen Frost wrote:
> > You say above that the new interface is unquestionably an improvement
> > and here say that we shouldn't deprecate the old one in favor of it
> > (even though we actually already hav
Hi Hari-san,
I've reviewed all files. I think I'll proceed to testing when I've reviewed
the revised patch and the patch for target_server_type.
(1) patch 0001
CONNECTION_CHECK_WRITABLE, /* Check if we could make a writable
> On Feb 24, 2019, at 14:19, Stephen Frost wrote:
> You say above that the new interface is unquestionably an improvement
> and here say that we shouldn't deprecate the old one in favor of it
> (even though we actually already have... but that's beside the point I'm
> trying to make here), so w
Hi,
On 2019-02-24 17:19:22 -0500, Stephen Frost wrote:
> You say above that the new interface is unquestionably an improvement
FWIW, I think we didn't design it even remotely as well as we ought to
have. It was both a mistake to not offer a version of non-exclusive
backups that works with a clien
Greetings,
* Christophe Pettus (x...@thebuild.com) wrote:
> > On Feb 24, 2019, at 13:44, Stephen Frost wrote:
> > Right, and PG12 will be out for another *5* years beyond that, meaning
> > people will have had 8.5 years to move from the exclusive API to the
> > non-exclusive one.
>
> The thing i
> On Feb 24, 2019, at 13:44, Stephen Frost wrote:
>
> Right, and PG12 will be out for another *5* years beyond that, meaning
> people will have had 8.5 years to move from the exclusive API to the
> non-exclusive one.
The thing is that for 90% of installations, the clock will start ticking whe
Greetings,
* Christophe Pettus (x...@thebuild.com) wrote:
> > On Feb 24, 2019, at 13:00, Stephen Frost wrote:
> >
> > No, it *hasn't* been the only backup API for a long time- that was only
> > true up until 9.6 was released, since then we've had both, and it's made
> > everything a downright me
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> Stephen Frost wrote:
> > Yes, it *is* impossible to do safe backups with the existing API. There
> > is an unquestionable race condition where a system restart will cause
> > your system to not come back up without you going in and rem
> On Feb 24, 2019, at 13:00, Stephen Frost wrote:
>
> No, it *hasn't* been the only backup API for a long time- that was only
> true up until 9.6 was released, since then we've had both, and it's made
> everything a downright mess because of exactly these arguments.
9.6 has been out for about
Stephen Frost wrote:
> Yes, it *is* impossible to do safe backups with the existing API. There
> is an unquestionable race condition where a system restart will cause
> your system to not come back up without you going in and removing the
> backup_label file- and the only way you make that race wi
Andres Freund wrote:
> On 2019-02-24 11:52:54 -0800, Christophe Pettus wrote:
> > > On Feb 22, 2019, at 15:18, Stephen Frost wrote:
> > > Getting a solid and resiliant backup to work from a shell script is, imv
> > > anyway (though I might have a bit of experience, having tried numerous
> > > time
Greetings,
* Christophe Pettus (x...@thebuild.com) wrote:
> > On Feb 24, 2019, at 12:00, Stephen Frost wrote:
> >
> > Do they realize how that existing backup strategy is flawed?
>
> Undoubtedly, some do, some don't. However, given that it has been the *only*
> backup API for a very long time
> On Feb 24, 2019, at 12:00, Stephen Frost wrote:
>
> Do they realize how that existing backup strategy is flawed?
Undoubtedly, some do, some don't. However, given that it has been the *only*
backup API for a very long time, many organizations have spent a lot of time
closing all of the ho
Hi,,
On 2019-02-24 11:52:54 -0800, Christophe Pettus wrote:
> > On Feb 22, 2019, at 15:18, Stephen Frost wrote:
> > Getting a solid and resiliant backup to work from a shell script is, imv
> > anyway (though I might have a bit of experience, having tried numerous
> > times myself and then realizi
Greetings,
* Christophe Pettus (x...@thebuild.com) wrote:
> > On Feb 22, 2019, at 15:18, Stephen Frost wrote:
> > Getting a solid and resiliant backup to work from a shell script is, imv
> > anyway (though I might have a bit of experience, having tried numerous
> > times myself and then realizing
> On Feb 22, 2019, at 15:18, Stephen Frost wrote:
> Getting a solid and resiliant backup to work from a shell script is, imv
> anyway (though I might have a bit of experience, having tried numerous
> times myself and then realizing that it just isn't practical...), a
> downright fool's errand.
Michael Meskes writes:
>> Not seeing any motion on this, here's a draft patch to make these
>> scripts complain about missing semicolons. Against the current
>> gram.y (which contains 2 such errors, as Michael noted) you
>> get output like
> Thanks Tom for looking into this. Are we agreed then t
so 23. 2. 2019 v 20:23 odesílatel Chapman Flack
napsal:
> On 02/23/19 13:35, Pavel Stehule wrote:
> > please, see, attached patch
>
> It is getting close, for my purposes. There is still this:
>
> >> Can the sentence added to the doc be changed to "These functions support
> >> passing parameters
I've moved this to the hackers list, and added Teodor and Alexander of the
bloom extension, as I would like to hear their opinions on the costing.
On Tue, Feb 12, 2019 at 4:17 PM Tom Lane wrote:
>
> It's possible that a good cost model for bloom is so far outside
> genericcostestimate's ideas th
Hi!
Thanks for this detailed review!
>
> * Note that this "parent then child" lock order seems to not be
> consistent with the general rule for holding concurrent buffer locks
> that is described in the GiST README:
This is correct. I've changed locking order.
When we check target internal pag
On Sun, Feb 24, 2019 at 2:44 PM Tomas Vondra
wrote:
> On 2/24/19 10:03 AM, Alexander Korotkov wrote:
> > Attached is revised version of jsonpath. Assuming that jsonpath have
> > problem places, I decided to propose partial implementation.
> > Following functionality was cut from jsonpath:
> > 1)
Hi,
On 2/24/19 10:03 AM, Alexander Korotkov wrote:
> Hi!
>
> Attached is revised version of jsonpath. Assuming that jsonpath have
> problem places, I decided to propose partial implementation.
> Following functionality was cut from jsonpath:
> 1) Support of datetime datatypes. Besides error sup
Dear Nikolay,
On Wed, Feb 20, 2019 at 12:28 PM Nikolay Shaplov wrote:
> В письме от вторник, 29 января 2019 г. 20:43:07 MSK пользователь Dmitry
> Belyavsky написал:
> > Dear all,
> >
> > Please find attached the patch extending the sets of symbols allowed in
> > ltree labels. The patch introduce
On Fri, 22 Feb 2019 at 14:40, David Rowley wrote:
>
> On Tue, 19 Feb 2019 at 02:34, Surafel Temesgen wrote:
> > I see that there are already a test for zero column table in
> > test_fourth_table_zero_col
> > and if am not wrong table_index_stats is empty table
>
> Maybe Fabien would like to see
44 matches
Mail list logo
