On Thu, Aug 6, 2020 at 12:20 AM Etsuro Fujita wrote:
> Will push the patch tomorrow.
Done. (I didn't have time for this, because I was terribly busy with
other stuff.)
Best regards,
Etsuro Fujita
On Thu, 6 Aug 2020 at 22:35, Tom Lane wrote:
> Robert Haas writes:
> > ... how
> > important is stability to ANALYZE? If you *either* retake your MVCC
> > snapshots periodically as you re-scan the table *or* use a non-MVCC
> > snapshot for the scan, you can get those same kinds of artifacts:
On Fri, Aug 7, 2020 at 1:21 PM Justin Pryzby wrote:
> On Fri, Aug 07, 2020 at 01:13:51PM +0900, Amit Langote wrote:
> > On Fri, Aug 7, 2020 at 1:05 PM Justin Pryzby wrote:
> > > On Fri, Aug 07, 2020 at 12:16:11PM +0900, Amit Langote wrote:
> > > > Curiously, Justin mentioned upthread that the
On Fri, Aug 07, 2020 at 01:13:51PM +0900, Amit Langote wrote:
> On Fri, Aug 7, 2020 at 1:05 PM Justin Pryzby wrote:
> > On Fri, Aug 07, 2020 at 12:16:11PM +0900, Amit Langote wrote:
> > > Curiously, Justin mentioned upthread that the crash occurred during
> > > BIND of a prepared query, so it
On Fri, Aug 7, 2020 at 1:05 PM Justin Pryzby wrote:
>
> On Fri, Aug 07, 2020 at 12:16:11PM +0900, Amit Langote wrote:
> > Curiously, Justin mentioned upthread that the crash occurred during
> > BIND of a prepared query, so it better had been that a custom plan was
> > being executed, because a
On Fri, Aug 07, 2020 at 12:16:11PM +0900, Amit Langote wrote:
> Curiously, Justin mentioned upthread that the crash occurred during
> BIND of a prepared query, so it better had been that a custom plan was
> being executed, because a generic one based on fewer partitions would
> be thrown away due
On Fri, Aug 7, 2020 at 8:10 AM Masahiko Sawada
wrote:
>
> On Fri, 7 Aug 2020 at 10:49, Amit Kapila wrote:
> >
> > On Thu, Aug 6, 2020 at 7:51 PM Justin Pryzby wrote:
> > >
> > > On Thu, Aug 06, 2020 at 07:39:21PM +0530, Amit Kapila wrote:
> > > > On Wed, Jul 29, 2020 at 1:09 AM Justin Pryzby
Amit Kapila writes:
> On Sat, Aug 1, 2020 at 1:53 AM Andres Freund wrote:
>> We could also just use pg_class.relpages. It'll probably mostly be
>> accurate enough?
> Don't we need the accurate 'number of blocks' if we want to invalidate
> all the buffers? Basically, I think we need to perform
On Sat, Aug 1, 2020 at 1:53 AM Andres Freund wrote:
>
> Hi,
>
> On 2020-07-31 15:50:04 -0400, Tom Lane wrote:
> > Andres Freund writes:
>
> > > Wonder if the temporary fix is just to do explicit hashtable probes for
> > > all pages iff the size of the relation is < s_b / 500 or so. That'll
> > >
On Fri, Aug 7, 2020 at 3:03 AM Tomas Vondra
wrote:
>
> >But I understand the sentiment on the added overhead on BufferAlloc.
> >Regarding the case where the patch would potentially affect workloads
> >that fit into RAM but not into shared buffers, could one of Andres'
> >suggested idea/s above
On Thu, Aug 6, 2020 at 11:51 PM Robert Haas wrote:
>
> On Thu, Jul 30, 2020 at 8:11 AM Robert Haas wrote:
> > Unless somebody complains pretty soon, I'm going to go ahead and do
> > what is described above.
>
> Done.
>
Thanks!
I have one more request to make: since we are of the opinion to not
On Thu, Aug 6, 2020 at 6:53 AM k.jami...@fujitsu.com
wrote:
>
> On Saturday, August 1, 2020 5:24 AM, Andres Freund wrote:
>
> Hi,
> Thank you for your constructive review and comments.
> Sorry for the late reply.
>
> > Hi,
> >
> > On 2020-07-31 15:50:04 -0400, Tom Lane wrote:
> > > Andres Freund
On Fri, Aug 07, 2020 at 12:16:11PM +0900, Amit Langote wrote:
> Curiously, Justin mentioned upthread that the crash occurred during
> BIND of a prepared query, so it better had been that a custom plan was
> being executed,
I'm looking at how to check that ... can you give a hint ?
--
Justin
Amit Langote writes:
> On Fri, Aug 7, 2020 at 9:32 AM Tom Lane wrote:
>> ... Amit's recipe for reproducing the bug works because there are
>> other relation lock acquisitions (and hence AcceptInvalidationMessages
>> calls) later in planning than where he asked us to wait. So this
>>
On Fri, Aug 7, 2020 at 9:32 AM Tom Lane wrote:
> Andy Fan writes:
> > Attached is the v2 patch.
Thanks Andy and Tom for this.
> Forgot to mention that I'd envisioned adding this as a src/test/modules/
> module; contrib/ is for things that we intend to expose to users, which
> I think this
On Mon, Aug 03, 2020 at 11:22:48AM -0400, Bruce Momjian wrote:
> On Sun, Aug 2, 2020 at 11:30:50PM -0700, Noah Misch wrote:
> > On Fri, Mar 23, 2018 at 07:47:39PM -0700, Noah Misch wrote:
> > > In light of the mixed reception, I am withdrawing this proposal.
> >
> > I'd like to reopen this.
Andy Fan writes:
> I am not sure if we need to limit the scope to "between parsing and
> execution",
Yeah, there might be reason to add similar functionality in other
places later. I'm not sure where yet --- but that idea does make
me slightly unhappy with the "delay_execution" moniker. I
On Fri, 7 Aug 2020 at 10:49, Amit Kapila wrote:
>
> On Thu, Aug 6, 2020 at 7:51 PM Justin Pryzby wrote:
> >
> > On Thu, Aug 06, 2020 at 07:39:21PM +0530, Amit Kapila wrote:
> > > On Wed, Jul 29, 2020 at 1:09 AM Justin Pryzby
> > > wrote:
> > > >
> > > >
> > > > lazy_check_needs_freeze iterates
On Fri, Aug 7, 2020 at 8:32 AM Tom Lane wrote:
> Andy Fan writes:
> > Attached is the v2 patch.
>
> Forgot to mention that I'd envisioned adding this as a src/test/modules/
> module; contrib/ is for things that we intend to expose to users, which
> I think this isn't.
>
> I played around with
On Thu, Aug 6, 2020 at 6:08 PM Tom Lane wrote:
> +1 for making this more like what happens in original execution ("on the
> primary", to use your wording). Perhaps what you suggest here is still
> not enough like the original execution, but it sounds closer.
It won't be the same as the original
On Thu, Aug 6, 2020 at 7:51 PM Justin Pryzby wrote:
>
> On Thu, Aug 06, 2020 at 07:39:21PM +0530, Amit Kapila wrote:
> > On Wed, Jul 29, 2020 at 1:09 AM Justin Pryzby wrote:
> > >
> > >
> > > lazy_check_needs_freeze iterates over blocks and this patch changes it to
> > > update vacrelstats. I
Hello,
On Fri, Aug 5, 2020 at 10:57:56 +, Michael Paquier
wrote:
> Yeah, that's a known problem. One way to counter that is for example
> to grab the path of pg_regress from pg_config --libdir and set
> $ENV{PG_REGRESS} to it, but that's hacky. So I agree that it would be
> good to do
Peter Geoghegan writes:
> I'm starting to think that we should bite the bullet and not release
> all same-level locks within btree_xlog_split() until the very end,
> along with the existing right sibling page whose left link we need to
> update.
+1 for making this more like what happens in
Andy Fan writes:
> Attached is the v2 patch.
Forgot to mention that I'd envisioned adding this as a src/test/modules/
module; contrib/ is for things that we intend to expose to users, which
I think this isn't.
I played around with this and got the isolation test I'd experimented
with yesterday
While reviewing an amcheck patch of Andrey Borodin's, I noticed that
it had a problem that I tied back to btree_xlog_split()'s loose
approach to locking buffers compared to the primary [1] (i.e. compared
to _bt_split()). This created a problem the proposed new check that is
not unlike the problem
Ashutosh Bapat noticed that WalSndWaitForWal() is setting
waiting_for_ping_response after sending a keepalive that does *not*
request a reply. The bad consequence is that other callers that do
require a reply end up in not sending a keepalive, because they think it
was already sent previously.
On Fri, 7 Aug 2020 at 00:44, David Rowley wrote:
> Just coming back to this. I'd like to push it soon, but it's currently
> late here. I'll look at pushing it in my morning in about 8 hours
> time.
Pushed.
David
Andres Freund writes:
> In fact using conceptually like a new snapshot for each sample tuple
> actually seems like it'd be somewhat of an improvement over using a
> single snapshot.
Dunno, that feels like a fairly bad idea to me. It seems like it would
overemphasize the behavior of whatever
Hi,
On 2020-08-06 16:22:23 -0400, Robert Haas wrote:
> On Thu, Aug 6, 2020 at 3:11 PM Tom Lane wrote:
> > (1) Without a snapshot it's hard to make any non-bogus decisions about
> > which tuples are live and which are dead. Admittedly, with Simon's
> > proposal the final totals would be spongy
Robert Haas writes:
> ... how
> important is stability to ANALYZE? If you *either* retake your MVCC
> snapshots periodically as you re-scan the table *or* use a non-MVCC
> snapshot for the scan, you can get those same kinds of artifacts: you
> might see two copies of a just-updated row, or none.
On Wed, May 27, 2020 at 10:11 AM Grigory Kryachko wrote:
> Here is the patch which I (with Andrey as my advisor) built on the top of the
> last patch from this thread: https://commitfest.postgresql.org/25/1800/ .
> It adds an ability to verify validity of GIN index. It is not polished yet,
>
On Thu, Aug 06, 2020 at 01:23:31AM +, k.jami...@fujitsu.com wrote:
On Saturday, August 1, 2020 5:24 AM, Andres Freund wrote:
Hi,
Thank you for your constructive review and comments.
Sorry for the late reply.
Hi,
On 2020-07-31 15:50:04 -0400, Tom Lane wrote:
> Andres Freund writes:
> >
Hi,
On 2020-08-06 14:48:52 -0400, Robert Haas wrote:
> On Thu, Aug 6, 2020 at 2:37 PM Tom Lane wrote:
> > +1 for removal. It's not clear to me that we'd ever put it back.
> > Long-running ANALYZE snapshots are indeed a problem, but Simon's proposal
> > upthread to just take a new one every so
Hi,
On 7/13/20 12:53 PM, Jonathan S. Katz wrote:
> Hi,
>
> The PostgreSQL 13 Release Management Team is pleased to announce the
> release date of PostgreSQL 13 Beta 3 is set to 2020-08-13, which is the
> same day as the cumulative update release[1]. Please be sure to have
> your patches
On Thu, Aug 6, 2020 at 3:11 PM Tom Lane wrote:
> (1) Without a snapshot it's hard to make any non-bogus decisions about
> which tuples are live and which are dead. Admittedly, with Simon's
> proposal the final totals would be spongy anyhow, but at least the
> individual decisions produce
On Mon, Jul 13, 2020 at 6:18 PM Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> On Mon, Jul 13, 2020 at 5:05 PM Andrew Dunstan <
> andrew.duns...@2ndquadrant.com> wrote:
> >
> >
> > On 7/13/20 2:46 PM, Fabrízio de Royes Mello wrote:
> > >
> > >
> > > >
> > > > yeah, that's the fix I
On Tue, Jul 28, 2020 at 5:35 AM Bharath Rupireddy
wrote:
> The v4 patch looks good to me. Hang is not seen, make check and make
> check-world passes. I moved this to the committer for further review
> in https://commitfest.postgresql.org/29/2636/.
I don't think I agree with this approach. In
I got the first draft of $SUBJECT done a little earlier than usual.
See
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a2e0cf45c21afbcbc544d1aca8d51d90004aa5d9
There seemed to be more than the usual quota of commits that I decided
not to document because they seemed
Robert Haas writes:
> Not to get too far from the proposal on the table of just removing
> something that's been unused for a really long time, which stands on
> its own merits, but if a particular ANALYZE doesn't invoke any
> user-defined functions and isn't run inside a transaction, could we
>
On Thu, Aug 6, 2020 at 2:37 PM Tom Lane wrote:
> +1 for removal. It's not clear to me that we'd ever put it back.
> Long-running ANALYZE snapshots are indeed a problem, but Simon's proposal
> upthread to just take a new one every so often seems like a much cleaner
> and simpler answer than
Robert Haas writes:
> On Wed, Aug 5, 2020 at 9:07 PM Andres Freund wrote:
>> Only mildly against because it'd not be hard to reintroduce once we need
>> it.
> I think we should nuke it. It's trivial to reintroduce the flag if we
> need it later, if and when somebody's willing to do the
On Wed, Aug 5, 2020 at 9:07 PM Andres Freund wrote:
> I'm mildly against that, because I'd really like to start making use of
> the flag. Not so much for cancellations, but to avoid the drastic impact
> analyze has on bloat. In OLTP workloads with big tables, and without
> disabled cost limiting
On Thu, Jul 30, 2020 at 8:11 AM Robert Haas wrote:
> Unless somebody complains pretty soon, I'm going to go ahead and do
> what is described above.
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Heikki Linnakangas writes:
> On 06/08/2020 18:42, Tom Lane wrote:
>> I'm looking at this commit in connection with writing release notes
>> for next week's releases. Am I right in thinking that this bug leads
>> to indefinite bloat of the pendingOps hash table when fsync is off?
>> If so, that
On 06/08/2020 18:42, Tom Lane wrote:
Heikki Linnakangas writes:
On 09/05/2020 02:53, Thomas Munro wrote:
On Sat, May 9, 2020 at 9:21 AM Heikki Linnakangas wrote:
I noticed that commit 3eb77eba5a changed the logic in
ProcessSyncRequests() (formerly mdsync()) so that if you have fsync=off,
On Wed, Aug 5, 2020 at 4:36 PM Peter Geoghegan wrote:
> Right, but the professional exterminator can be expected to use expert
> level tools, where a great deal of technical sophistication is
> required to interpret what's going on sensibly. An amatuer can only
> use them to determine if
On Wed, Aug 5, 2020 at 9:50 PM Andrey M. Borodin wrote:
> Sounds great! Thanks!
I'm afraid that there is another problem, this time with
btree_xlog_split(). It's possible to get false positives when running
the new test continually on a standby. You can see this by running
verification on a
On Thu, Aug 6, 2020 at 10:42 PM Tom Lane wrote:
> Andy Fan writes:
> > On Thu, Aug 6, 2020 at 12:02 PM Tom Lane wrote:
> >> See my straw-man proposal downthread.
>
> > Thanks for your explanation, I checked it again and it looks a very clean
> > method. The attached is a draft patch based on
On Thu, Aug 6, 2020 at 2:11 AM Ashutosh Sharma wrote:
> Okay, If you want I can remove the restriction on a toast table, but,
> then that means a user can directly remove the data chunks from the
> toast table without changing anything in the main table. This means we
> won't be able to query the
Heikki Linnakangas writes:
> On 09/05/2020 02:53, Thomas Munro wrote:
>> On Sat, May 9, 2020 at 9:21 AM Heikki Linnakangas wrote:
>>> I noticed that commit 3eb77eba5a changed the logic in
>>> ProcessSyncRequests() (formerly mdsync()) so that if you have fsync=off,
>>> the entries are not removed
Andy Fan writes:
> On Thu, Aug 6, 2020 at 12:02 PM Tom Lane wrote:
>> See my straw-man proposal downthread.
> Thanks for your explanation, I checked it again and it looks a very clean
> method. The attached is a draft patch based on my understanding. Hope
> I didn't misunderstand you..
Ah,
On Thu, Aug 06, 2020 at 07:39:21PM +0530, Amit Kapila wrote:
> On Wed, Jul 29, 2020 at 1:09 AM Justin Pryzby wrote:
> >
> > On Wed, Jul 29, 2020 at 12:35:17AM +0530, Mahendra Singh Thalor wrote:
> > > Apart from these, I fixed comments given by Sawada and Michael in the
> > > latest patch.
On Wed, Aug 5, 2020 at 12:47 AM Mahendra Singh Thalor
wrote:
>
> Apart from these, I fixed Justin's comment of extra brackets(That was
> due to "patch -p 1 < file", as 002_fix was not applying directly). I
> haven't updated the document for this(Sawada's comment). I will try in
> the next patch.
On Wed, Jul 29, 2020 at 1:09 AM Justin Pryzby wrote:
>
> On Wed, Jul 29, 2020 at 12:35:17AM +0530, Mahendra Singh Thalor wrote:
> > Apart from these, I fixed comments given by Sawada and Michael in the
> > latest patch. Attaching v2 patch for review.
>
> Thanks.
>
> lazy_check_needs_freeze
On Thu, Aug 6, 2020 at 12:02 PM Tom Lane wrote:
> Andy Fan writes:
> > On Thu, Aug 6, 2020 at 2:22 AM Tom Lane wrote:
> >> In the longer term, it's annoying that we have no test methodology
> >> for this other than "manually set a breakpoint here".
>
> > One of the methods I see is we can just
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Mon, Aug 3, 2020 at 5:26 PM Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > I'd like to reopen this. Reception was mixed, but more in favor than
> > against.
> > > Also, variations on the idea trade some
Attached v4 patch fixes the latest comments from Robert and Masahiko-san.
Changes:
1) Let heap_force_kill and freeze functions to be used with toast tables.
2) Replace "int nskippedItems" with "bool did_modify_page" flag to
know if any modification happened in the page or not.
3) Declare some of
The function pg_sequence_last_value() was added to underlie the
pg_sequences view, and it's the only way I'm aware of from userspace
to directly get the last value of a sequence globally (i.e., not
within the current session like currval()/lastval()). Obviously you
can join to the pg_sequences
On Wed, 5 Aug 2020 at 17:25, David Rowley wrote:
>
> On Wed, 5 Aug 2020 at 14:27, David Rowley wrote:
> > So maybe Hash Agg should be doing something similar. Additionally,
> > maybe it should not show the leader details if the leader didn't help.
>
> Here's what I had in mind.
Just coming
On Thu, 6 Aug 2020 at 05:44, Andres Freund wrote:
> > Andres, or anyone, any objections to me pushing 0002?
>
> I think it'd be good to add a warning that, unless one is very careful,
> no other hashtable modifications are allowed between lookup and
> modification. E.g. something like
> a =
On Mon, Aug 3, 2020 at 5:26 PM Stephen Frost wrote:
>
> * Noah Misch (n...@leadboat.com) wrote:
> > I'd like to reopen this. Reception was mixed, but more in favor than
> against.
> > Also, variations on the idea trade some problems for others and may be
> more
> > attractive. The taxonomy of
On Thu, Aug 06, 2020 at 02:58:44PM +1200, Thomas Munro wrote:
On Tue, Aug 4, 2020 at 3:47 AM Tomas Vondra
wrote:
On Thu, Jul 02, 2020 at 03:09:29PM +1200, Thomas Munro wrote:
>FYI I am still trying to reproduce and understand the problem Tomas
>reported; more soon.
Any luck trying to
On Thu, Aug 6, 2020 at 12:17 PM Drouvot, Bertrand
wrote:
> Hi,
> On 7/27/20 4:57 PM, Dave Page wrote:
>
> *CAUTION*: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
> Hi
>
> On
On Thu, 6 Aug 2020 at 18:05, Ashutosh Sharma wrote:
>
> Hello Masahiko-san,
>
> Thanks for looking into the patch. Please find my comments inline below:
>
> On Thu, Aug 6, 2020 at 1:42 PM Masahiko Sawada
> wrote:
> >
> > On Wed, 5 Aug 2020 at 22:42, Ashutosh Sharma wrote:
> > > Please check the
Hello Masahiko-san,
Thanks for looking into the patch. Please find my comments inline below:
On Thu, Aug 6, 2020 at 1:42 PM Masahiko Sawada
wrote:
>
> On Wed, 5 Aug 2020 at 22:42, Ashutosh Sharma wrote:
> > Please check the attached patch for the changes.
>
> I also looked at this version
I have been doing some user-level testing of this feature, apart from
sanity test for extension and it's functions
I have tried to corrupt tuples and then able to fix it using
heap_force_freeze/kill functions.
--corrupt relfrozenxid, cause vacuum failed.
update pg_class set relfrozenxid =
On Thu, 6 Aug 2020 at 02:07, Andres Freund wrote:
>
> On 2020-08-05 19:55:49 -0400, Alvaro Herrera wrote:
> > ... which means the flag I had added two days earlier has never been
> > used for anything. We've carried the flag forward to this day for
> > almost 13 years, dutifully turning it on
On Wed, 5 Aug 2020 at 22:42, Ashutosh Sharma wrote:
>
> Hi Robert,
>
> Thanks for the review. Please find my comments inline:
>
> On Sat, Aug 1, 2020 at 12:18 AM Robert Haas wrote:
> >
> > On Fri, Jul 31, 2020 at 8:52 AM Ashutosh Sharma
> > wrote:
> > > Attached is the new version of patch
On Wednesday, August 5, 2020 9:43 AM I wrote:
> I'll report the result before the end of August .
I test v2-0001-build-partdesc-memcxt.patch at 9a9db08ae4 and it is ok.
Firstly, I execute ALTER TABLE ADD CONSTRAINT FOREIGN KEY on the table which
has 8k tables.
This query execution completes in
Hi all,
As $subject says, pg_test_fsync and pg_test_timing don't really check
the range of option values specified. It is possible for example to
make pg_test_fsync run an infinite amount of time, and pg_test_timing
does not handle overflows with --duration at all.
These are far from being
On Thu, Aug 6, 2020 at 1:29 AM Robert Haas wrote:
>
> On Wed, Aug 5, 2020 at 9:42 AM Ashutosh Sharma wrote:
> > Yeah, it's being tested on the main table, not on a toast table. I've
> > removed this test-case and also restricted direct access to the toast
> > table using heap_force_kill/freeze
On Thu, Aug 6, 2020 at 1:04 AM Robert Haas wrote:
>
> On Mon, Aug 3, 2020 at 12:13 PM Ashutosh Sharma wrote:
> > If the above path is taken that means none of the items in the page
> > got changed.
>
> Oops. I didn't realize that, sorry. Maybe it would be a little more
> clear if instead of "int
72 matches
Mail list logo
