On Sun, Feb 10, 2019 at 2:37 AM Thomas Munro
wrote:
> ... but why would it do that? I can reproduce cases where (for
> example) FreePageManagerPutInternal() returns 179, and then
> FreePageManagerLargestContiguous() returns 179, but then after
> FreePageBtreeCleanup() it returns 178. At that
On Sun, Feb 10, 2019 at 1:55 AM Thomas Munro
wrote:
> Bleugh. Yeah. What I said before wasn't quite right. The value
> returned by FreePageManagerPutInternal() is actually correct at the
> moment it is returned, but it ceases to be correct immediately
> afterwards if the following call to
On 10.02.2019 3:25, Tomas Vondra wrote:
On 2/9/19 3:02 PM, Konstantin Knizhnik wrote:
On 09.02.2019 1:38, Tomas Vondra wrote:
On 2/8/19 11:10 PM, Konstantin Knizhnik wrote:
On 08.02.2019 21:57, Andres Freund wrote:
On 2019-02-08 12:15:58 +0300, Konstantin Knizhnik wrote:
Frankly
Hi,
On February 10, 2019 9:20:18 AM GMT+05:30, Tom Lane wrote:
>I've wondered for some time whether we couldn't make a useful
>reduction in the run time of the PG regression tests by looking
>for scripts that run significantly longer than others in their
>parallel groups, and making an effort to
On Sat, Feb 9, 2019 at 7:50 PM Tom Lane wrote:
> I've wondered for some time whether we couldn't make a useful
> reduction in the run time of the PG regression tests by looking
> for scripts that run significantly longer than others in their
> parallel groups, and making an effort to trim the
I've wondered for some time whether we couldn't make a useful
reduction in the run time of the PG regression tests by looking
for scripts that run significantly longer than others in their
parallel groups, and making an effort to trim the runtimes of
those particular scripts.
The first step in
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> Uh-huh. And what happens after DETACH PARTITION ... are you going to run
>> around and recreate these triggers?
> Yep, that's there too.
OK, then I guess it's fine.
regards, tom lane
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> Oh ... then why don't we go ahead and get rid of the constraint entry,
> >> too?
>
> > Because each partition has its own pg_constraint entry. (Otherwise
> > there's no place to put the column
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> Oh ... then why don't we go ahead and get rid of the constraint entry,
>> too?
> Because each partition has its own pg_constraint entry. (Otherwise
> there's no place to put the column numbers into -- they can differ from
> partition
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> Well, the question that's begged here is exactly why it's okay to
> >> remove the trigger and dependency link despite the fact that the
> >> constraint needs it. I suppose the answer is that we'll
On 2/9/19 3:02 PM, Konstantin Knizhnik wrote:
>
>
> On 09.02.2019 1:38, Tomas Vondra wrote:
>> On 2/8/19 11:10 PM, Konstantin Knizhnik wrote:
>>>
>>> On 08.02.2019 21:57, Andres Freund wrote:
On 2019-02-08 12:15:58 +0300, Konstantin Knizhnik wrote:
> Frankly speaking, I do not think
On Sun, Feb 10, 2019 at 12:31 AM Tom Lane wrote:
>
> Julien Rouhaud writes:
> > I just hit one of the asserts (in relation_open()) added in
> > b04aeb0a053. Here's a simple reproducer:
>
> Yeah, I think this is the same issue being discussed in
>
>
On 2/1/19 12:10 PM, Surafel Temesgen wrote:
> here is a rebased version of previous patch with planner
> comment included
>
It's really hard to say which comment is that ..
FWIW I find the changes in nodeLimit lacking sufficient comments. The
comments present are somewhat obvious - what we
Julien Rouhaud writes:
> I just hit one of the asserts (in relation_open()) added in
> b04aeb0a053. Here's a simple reproducer:
Yeah, I think this is the same issue being discussed in
https://www.postgresql.org/message-id/flat/19465.1541636036%40sss.pgh.pa.us
I imagine the patch David
Hi,
On Sun, Sep 30, 2018 at 7:18 PM Tom Lane wrote:
>
> I think that the call sites should ultimately look like
>
> Assert(CheckRelationLockedByMe(...));
>
> but for hunting down the places where the assertion currently fails,
> it's more convenient if it's just an elog(WARNING).
I just
On 1/30/19 7:07 AM, Surafel Temesgen wrote:
>
>
> On Mon, Jan 28, 2019 at 1:28 AM Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
>
>
> OK. Does that mean you agree the incremental approach is reasonable?
>
>
> there are no noticeable performance difference but i love
On Sun, Feb 10, 2019 at 7:24 AM Thomas Munro
wrote:
> On Sat, Feb 9, 2019 at 9:21 PM Robert Haas wrote:
> > On Fri, Feb 8, 2019 at 8:00 AM Thomas Munro
> > wrote:
> > > Sometimes FreeManagerPutInternal() returns a
> > > number-of-contiguous-pages-created-by-this-insertion that is too large
> >
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> After further reflection I really don't like Andrew's suggestion
> Tom> that we not document the rule that multiply-referenced CTEs won't
> Tom> be inlined by default. That would be giving up the principle that
> Tom> WITH calculations
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> Well, the question that's begged here is exactly why it's okay to remove
>> the trigger and dependency link despite the fact that the constraint needs
>> it. I suppose the answer is that we'll subsequently insert a new trigger
>>
On Sat, Feb 9, 2019 at 9:21 PM Robert Haas wrote:
> On Fri, Feb 8, 2019 at 8:00 AM Thomas Munro
> wrote:
> > Sometimes FreeManagerPutInternal() returns a
> > number-of-contiguous-pages-created-by-this-insertion that is too large
> > by one. [...]
>
> I spent a long time thinking about this and
On 2019-Feb-09, Alvaro Herrera wrote:
> I'll put this in the comment.
Attached.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
On 2/7/19 1:18 PM, Kyotaro HORIGUCHI wrote:
> At Thu, 07 Feb 2019 15:24:18 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20190207.152418.139132570.horiguchi.kyot...@lab.ntt.co.jp>
>> I'm going to retake numbers with search-only queries.
>
> Yeah, I was stupid.
>
> I made a
On Sun, Feb 10, 2019 at 2:13 AM Tom Lane wrote:
>
> Amit Langote writes:
> > Reading Tom's reply to my email, I wondered if performDeletion won't
> > do more than what the code is already doing (except calling the right
> > trigger deletion function which the current code doesn't), because the
>
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> I think you're doing it to get rid of the INTERNAL dependency so that
> >> deletion won't recurse across that, but why is that a good idea? Needs
> >> a comment at least.
>
> > Yeah, it's deleting
Amit Langote writes:
> Reading Tom's reply to my email, I wondered if performDeletion won't
> do more than what the code is already doing (except calling the right
> trigger deletion function which the current code doesn't), because the
> trigger in question is an internal trigger without any
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> I think you're doing it to get rid of the INTERNAL dependency so that
>> deletion won't recurse across that, but why is that a good idea? Needs
>> a comment at least.
> Yeah, it's deleting the INTERNAL dependency, because otherwise the
On Sun, Feb 10, 2019 at 1:50 AM Alvaro Herrera wrote:
> On 2019-Feb-09, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > On 2019-Feb-09, Tom Lane wrote:
> > >> No, that's still the back end of the deletion machinery, and in
> > >> particular
> > >> it would fail to clean pg_depend entries for
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> No, that's still the back end of the deletion machinery, and in particular
> >> it would fail to clean pg_depend entries for the trigger. Going in by the
> >> front door would use
On 2/9/19 3:14 PM, Andres Freund wrote:
> Hi,
>
> On 2019-02-08 23:38:12 +0100, Tomas Vondra wrote:
>> On 2/8/19 11:10 PM, Konstantin Knizhnik wrote:
>>> Does it mean that it is necessary to support multiple compression
>>> algorithms and make it possible to perform switch between them at
>>>
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> No, that's still the back end of the deletion machinery, and in particular
>> it would fail to clean pg_depend entries for the trigger. Going in by the
>> front door would use performDeletion(). (See deleteOneObject() to get
>> an idea
On 2019-Feb-09, Tom Lane wrote:
> Amit Langote writes:
> > On Sat, Feb 9, 2019 at 9:41 AM Tom Lane wrote:
> >> +1. The best solution would presumably be to go through the normal
> >> object deletion mechanism; though possibly there's a reason that
> >> won't work given you're already inside
Amit Kapila writes:
> It seems you would also like to see this back-patched. I am not sure
> if that is a good idea as there is some risk of breaking existing
> usage. Tom, do you have any opinion on this patch? It seems to me
> you were thinking to have a separate hook for partial paths, but
On 2019-Feb-07, Dmitry Dolgov wrote:
> Could there be a race condition somewhere? The idea and the code looks
> reasonable, but when I'm testing ALTER TABLE ... REPLICA IDENTITY with this
> patch and concurrent partition creation, I've got the following error on
> ATTACH
> PARTITION:
>
> ERROR:
Hi,
On 2019-02-08 23:38:12 +0100, Tomas Vondra wrote:
> On 2/8/19 11:10 PM, Konstantin Knizhnik wrote:
> > Does it mean that it is necessary to support multiple compression
> > algorithms and make it possible to perform switch between them at
> > runtime?
>
> IMHO the negotiation should happen
On 09.02.2019 1:38, Tomas Vondra wrote:
On 2/8/19 11:10 PM, Konstantin Knizhnik wrote:
On 08.02.2019 21:57, Andres Freund wrote:
On 2019-02-08 12:15:58 +0300, Konstantin Knizhnik wrote:
Frankly speaking, I do not think that such flexibility in choosing
compression algorithms is really
On Wed, Feb 6, 2019 at 10:35 AM Kohei KaiGai wrote:
>
> Hello,
> Let me remind the thread again.
> I'm waiting for the fix getting committed for a month...
>
It seems you would also like to see this back-patched. I am not sure
if that is a good idea as there is some risk of breaking existing
Hi,
On 2019-02-08 16:36:13 -0800, Alexandra Wang wrote:
> Current sequence of operations for drop database (dropdb())
> 1. Start Transaction
> 2. Make catalog changes
> 3. Drop database buffers
> 4. Forget database fsync requests
> 5. Checkpoint
> 6. Delete database directory
> 7. Commit
On Tue, Feb 5, 2019 at 12:14 PM Haribabu Kommi wrote:
>
>
> On Fri, Feb 1, 2019 at 8:19 AM Masahiko Sawada wrote:
>>
>>
>> The passing stats = NULL to amvacuumcleanup and ambulkdelete means the
>> first time execution. For example, btvacuumcleanup skips cleanup if
>> it's not NULL.In the normal
Current sequence of operations for drop database (dropdb())
1. Start Transaction
2. Make catalog changes
3. Drop database buffers
4. Forget database fsync requests
5. Checkpoint
6. Delete database directory
7. Commit Transaction
Problem
This sequence is unsafe from couple of fronts. Like if drop
On Tue, Feb 5, 2019 at 3:25 PM John Naylor wrote:
>
> On Tue, Feb 5, 2019 at 4:04 AM Amit Kapila wrote:
> >
> > On Mon, Feb 4, 2019 at 2:27 PM John Naylor
> > wrote:
> > >
> > > 1. Earlier, I had a test to ensure that free space towards the front
> > > of the relation was visible with no FSM.
Hi! Thanks for the next version!
> 8 февр. 2019 г., в 18:30, Alexey Kondratov
> написал(а):
>
> On 21.01.2019 23:50, a.kondra...@postgrespro.ru wrote:
>> Thank you for the review! I have updated the patch according to your
>> comments and remarks. Please, find new version attached.
>
> During
El 9/2/19 a las 4:19, Tom Lane escribió:
Please send comments/corrections by Sunday.
+ tuple deletion WAL record (Stas Kelvish)
-- a typo in his surname, should be Kelvich.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 2019-02-07 09:16:09 +0530, Amit Kapila wrote:
> On Wed, Feb 6, 2019 at 4:57 PM David Rowley
> wrote:
> >
> > On Wed, 6 Feb 2019 at 16:20, Amit Kapila wrote:
> > > I agree that the docs need to be updated and this patch should be
> > > backpatched as well. However, I think the older wording
On 2019-02-01 10:38:49 +0900, Michael Paquier wrote:
> On Thu, Jan 31, 2019 at 11:51:36PM +0300, Stas Kelvich wrote:
> > It seems that heapam.c:3082 calls XLogRegisterData() with an argument
> > allocated on stack, but following call to XLogInsert() happens after
> > end of context for that
Hi,
On 2019-02-06 03:39:19 -0800, Andres Freund wrote:
> On 2019-02-06 10:25:56 +, Andrew Gierth wrote:
> > > "Andres" == Andres Freund writes:
> >
> > >> Cool. Here's the patch that I, after some commit message polishing,
> > >> plan to commit to 11 and master to fix the issue at
Hi,
On 2019-02-05 22:44:38 -0300, Alvaro Herrera wrote:
> On 2019-Feb-05, Andres Freund wrote:
>
> > @@ -82,7 +80,7 @@ static Datum getmissingattr(TupleDesc tupleDesc, int
> > attnum, bool *isnull);
> > /*
> > * Return the missing value of an attribute, or NULL if there isn't one.
> > */
>
On Fri, Feb 8, 2019 at 8:00 AM Thomas Munro
wrote:
> Sometimes FreeManagerPutInternal() returns a
> number-of-contiguous-pages-created-by-this-insertion that is too large
> by one. If this happens to be a new max-number-of-contiguous-pages,
> it causes trouble some arbitrary time later because
On Fri, Feb 8, 2019 at 11:59 PM Tom Lane wrote:
> To the extent that this works at all, OIDs in the 9000 range ought
> to be enough of a flag already, I think.
A "flag" that isn't documented anywhere outside of a mailing list
discussion and that isn't checked by any code anywhere is not much of
48 matches
Mail list logo
