On Tue, Dec 5, 2017 at 8:49 PM, Thomas Munro
wrote:
> On Tue, Dec 5, 2017 at 6:39 PM, Amit Kapila wrote:
>> I have one another observation in the somewhat related area. From the
>> code, it looks like we might have some problem with displaying sort
>> info for workers for rescans. I think the p
>> - Modified HeapTupleSatisfiesVacuum to return HEAPTUPLE_RECENTLY_DEAD
>> if the transaction id is newer than OldestXmin. Doing this only for
>> CATALOG tables (htup->t_tableOid < (Oid) FirstNormalObjectId).
>
>
> Because logical decoding supports user-catalog relations, we need to use the
> same
Hi!
On Tue, Dec 5, 2017 at 6:19 AM, Amit Kapila wrote:
> Currently, txid_current and friends export a 64-bit format of
> transaction id that is extended with an “epoch” counter so that it
> will not wrap around during the life of an installation. The epoch
> value it uses is based on the epoch
On 5 December 2017 at 16:00, Nikhil Sontakke
wrote:
>
> We disallow rewrites on user_catalog_tables, so they cannot change
> underneath. Yes, DML can be carried out on them inside a 2PC
> transaction which then gets ROLLBACK'ed. But if it's getting aborted,
> then we are not interested in that d
Hello Tom,
1. A patch that adds an integer version of pow() but not a double version
2. A patch that adds a double version of pow() but not an integer version
3. A patch that adds both an integer version of pow() and a double
version of pow(), with the two versions having different names
It
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
I've read the updated patch and see my concerns addressed.
I'm looking f
On Tue, Dec 5, 2017 at 2:49 PM, Alexander Korotkov
wrote:
> On Tue, Dec 5, 2017 at 6:19 AM, Amit Kapila wrote:
>>
>> Currently, txid_current and friends export a 64-bit format of
>> transaction id that is extended with an “epoch” counter so that it
>> will not wrap around during the life of an in
On Tue, Dec 5, 2017 at 1:29 PM, Thomas Munro
wrote:
> On Tue, Dec 5, 2017 at 8:49 PM, Thomas Munro
> wrote:
>> On Tue, Dec 5, 2017 at 6:39 PM, Amit Kapila wrote:
>>> I have one another observation in the somewhat related area. From the
>>> code, it looks like we might have some problem with dis
On Thu, Jun 22, 2017 at 7:19 PM, Thomas Munro
wrote:
> I don't plan to resubmit this patch myself, but I was doing some
> spring cleaning and rebasing today and I figured it might be worth
> quietly leaving a working patch here just in case anyone from the
> various BSD communities is interested i
On Tue, Dec 5, 2017 at 6:45 AM, Thomas Munro
wrote:
> On Thu, Nov 30, 2017 at 11:19 PM, Thomas Munro
> wrote:
>> On Thu, Nov 30, 2017 at 4:01 AM, Robert Haas wrote:
>>>
>>> In v10 we might need to go with a solution like what you've sketched
>>> here, because Tom will complain about breaking bin
Hi all,
I've been giving a thought about this and I think we could reach the
compromise
of having a single function with 2 overloads:
* pow(double, double) -> double: Uses C pow().
* pow(int, int) -> double: Uses ipow() for positive exponents, and pow()
for negative exponents.
In both cases we'd
I've been giving a thought about this and I think we could reach the
compromise
of having a single function with 2 overloads:
* pow(double, double) -> double: Uses C pow().
* pow(int, int) -> double: Uses ipow() for positive exponents, and pow()
for negative exponents.
In both cases we'd return
On Mon, Dec 4, 2017 at 9:20 PM, Robert Haas wrote:
> On Sun, Dec 3, 2017 at 10:30 PM, Amit Kapila
> wrote:
> > I thought there are some cases (though less) where we want to Shutdown
> > the nodes (ExecShutdownNode) earlier and release the resources sooner.
> > However, if you are not completely
As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
zero-downtime upgrades. After the usual discussion of using logical
replication, Slony, and perhaps having the server be able to read old
and new system catalogs, we discussed speeding up pg_upgrade.
There are clusters that
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> zero-downtime upgrades. After the usual discussion of using logical
> replication, Slony, and perhaps having the server be able to read old
> and new system catalogs, we d
Hi
On Tue, Dec 5, 2017 at 11:01 PM, Bruce Momjian wrote:
> As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> zero-downtime upgrades. After the usual discussion of using logical
> replication, Slony, and perhaps having the server be able to read old
> and new system cata
On Tue, Dec 5, 2017 at 09:16:02AM -0500, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> > zero-downtime upgrades. After the usual discussion of using logical
> > replication, Slony, and pe
On Tue, Dec 5, 2017 at 11:16:26PM +0900, Dave Page wrote:
> Hi
>
> On Tue, Dec 5, 2017 at 11:01 PM, Bruce Momjian wrote:
>
> As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> zero-downtime upgrades. After the usual discussion of using logical
> replication,
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
> On Tue, Dec 5, 2017 at 11:01 PM, Bruce Momjian wrote:
> > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> > zero-downtime upgrades. After the usual discussion of using logical
> > replication, Slony, and perhaps having the
On Tue, Dec 5, 2017 at 09:23:49AM -0500, Stephen Frost wrote:
> Dave,
>
> * Dave Page (dp...@pgadmin.org) wrote:
> > On Tue, Dec 5, 2017 at 11:01 PM, Bruce Momjian wrote:
> > > As part of PGConf.Asia 2017 in Tokyo, we had an unconference topic about
> > > zero-downtime upgrades. After the usual
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Dec 5, 2017 at 09:16:02AM -0500, Stephen Frost wrote:
> > > There are clusters that take a long time to dump the schema from the old
> > > cluster and recreate it in the new cluster. One idea of speeding up
> > > pg_upgrade would be to a
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> > In any case, of course, if we're able to move part of what pg_upgrade
> > does to be while the old server is online then that takes whatever the
> > cost of that is out of the downtime window. The question is if that's a
> > 5% improvement in t
On 11/29/17 13:49, Andres Freund wrote:
On 2017-11-27 22:53:41 -0500, Tom Lane wrote:
Tomas Vondra writes:
I'm a bit puzzled by this code in SH_COMPUTE_PARAMETERS:
if (tb->size == SH_MAX_SIZE)
tb->sizemask = 0;
else
tb->sizemask = tb->size - 1;
Doesn't that me
On Mon, Dec 4, 2017 at 8:48 PM, Peter Geoghegan wrote:
> On Mon, Dec 4, 2017 at 5:41 PM, Noah Misch wrote:
>>> I don't think we quite have an established protocol for this. I
>>> personally, but I'm biased in this specific case, is that we should
>>> adopt a position that PGDLLIMPORTs should basi
On Mon, Dec 4, 2017 at 6:57 PM, David Rowley
wrote:
> On 2 December 2017 at 03:39, Robert Haas wrote:
>> On Thu, Nov 30, 2017 at 11:39 PM, David Rowley
>> wrote:
>>> I feel like we could do better here with little extra effort. The
>>> DETACH index feature does not really seem required for this
On Mon, Dec 4, 2017 at 5:57 PM, Ashutosh Bapat
wrote:
> I think the real behaviour can be described as something like this:
>
> "Only superusers may connect to foreign servers without password
> authentication, so always specify the password
> option for user mappings that may be used by non-super
Robert, Ashutosh,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Dec 4, 2017 at 5:57 PM, Ashutosh Bapat
> wrote:
> > I think the real behaviour can be described as something like this:
> >
> > "Only superusers may connect to foreign servers without password
> > authentication, so always s
2017-12-03 23:48 GMT+01:00 Michael Paquier :
> On Sun, Dec 3, 2017 at 3:21 PM, Pavel Stehule
> wrote:
> > I am not sure if user postgres should be removed, so it is probably bug
> >
> > pg_dumpall -r -c | grep postgres
> >
> > DROP ROLE postgres;
> > CREATE ROLE postgres;
>
> You are looking for
On Tue, Dec 5, 2017 at 6:49 AM, Robert Haas wrote:
>> RecentGlobalXmin -- This is only PGDLLIMPORT on Postgres 10+,
>> following commit 56018bf2. I'd like to get that back to 9.4, although
>> there is no reason to not include 9.3.
>>
>> TransactionXmin -- This is needed for the newer heap-matches-
On Tue, Dec 5, 2017 at 9:09 AM, Peter Geoghegan wrote:
>> Committed with these additions. Please check that I haven't messed anything
>> up.
>
> Thanks, but you modified RecentGlobalDataXmin, not RecentGlobalXmin.
> Can you fix it, please?
I was looking at the wrong branch. Forget it.
Thanks
-
Hackers,
I'm getting the error in $subject and am only posting here because (a) the
comments
in src/backend/utils/mmgr/dsa.c circa line 720 suggest that this is a bug, and
(b) the
DSA code appears to be fairly new to the postgresql project, and perhaps not
fully
debugged.
I am running against
On 2017-12-05 16:21:27 +0530, Amit Kapila wrote:
> On Tue, Dec 5, 2017 at 2:49 PM, Alexander Korotkov
> wrote:
> > On Tue, Dec 5, 2017 at 6:19 AM, Amit Kapila wrote:
> >>
> >> Currently, txid_current and friends export a 64-bit format of
> >> transaction id that is extended with an “epoch” counte
On 12/5/17 09:23, Stephen Frost wrote:
> Right, but that doesn't really answer the question as to which part of
> the pg_upgrade process is taking up the time.
Yeah, that should be measured before we do anything.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-12-05 16:21:27 +0530, Amit Kapila wrote:
> > On Tue, Dec 5, 2017 at 2:49 PM, Alexander Korotkov
> > wrote:
> > > On Tue, Dec 5, 2017 at 6:19 AM, Amit Kapila
> > > wrote:
> > >>
> > >> Currently, txid_current and friends export a 64-b
On Wed, Nov 29, 2017 at 12:11 AM, Michael Paquier
wrote:
> On Fri, Oct 27, 2017 at 9:54 PM, Amit Kapila wrote:
>> The patch still applies (with some hunks). I have added it in CF [1]
>> to avoid losing track.
>>
>> [1] - https://commitfest.postgresql.org/15/1341/
>
> This did not get reviews and
On December 5, 2017 10:01:43 AM PST, Stephen Frost wrote:
>Andres,
>
>* Andres Freund (and...@anarazel.de) wrote:
>> I think it makes a fair bit of sense to not do the current crufty
>> tracking of xid epochs. I don't really how we got there, but it
>doesn't
>> make terribly much sense. Don't th
On 12/1/17 15:28, Robert Haas wrote:
> This feature doesn't have many tests. I think it should have a lot
> more of them. It's tinkering with the transaction control machinery
> of the system in a fairly fundamental way, and that could break
> things.
Thank you, these are great ideas.
> I sugge
On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut
wrote:
> I think ROLLBACK in a cursor loop might not make sense, because the
> cursor query itself could have side effects, so a rollback would have to
> roll back the entire loop. That might need more refined analysis before
> it could be allowed.
On Tue, Dec 5, 2017 at 2:49 AM, Thomas Munro
wrote:
> As for how to aggregate the information, isn't it reasonable to show
> data from the last loop on the basis that it's representative?
> Summing wouldn't make too much sense, because you didn't use that much
> memory all at once.
Sorts can be r
Stephen Frost writes:
> * Andres Freund (and...@anarazel.de) wrote:
>> I kinda wonder if we shouldn't just track nextXid as a 64bit integer
>> internally, instead of bothering with tracking the epoch
>> separately. Then we can "just" truncate it in the cases where it's
>> stored in space constrain
On Wed, Dec 6, 2017 at 6:17 AM, Mark Dilger wrote:
> I'm not asking for help configuring my system. If this is a run of the mill
> out of memory
> type error, I'll deal with it myself. But if this indicates a bug, I'll be
> happy to try to distill
> what I'm doing to a test case that I can sha
On Tue, Dec 5, 2017 at 12:39 AM, Amit Kapila wrote:
> Yeah, that sounds better, so modified the patch accordingly.
I committed this to master and REL_10_STABLE, but it conflicts all
over the place on 9.6.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Dec 5, 2017 at 7:24 AM, Amit Kapila wrote:
> + EState *estate = gatherstate->ps.state;
> +
> + /* Install our DSA area while executing the plan. */
> + estate->es_query_dsa = gatherstate->pei->area;
> outerTupleSlot = ExecProcNode(outerPlan);
> + estate->es_query_dsa = NULL;
>
> Won't th
On Tue, Dec 5, 2017 at 7:44 AM, Raúl Marín Rodríguez
wrote:
> I've been giving a thought about this and I think we could reach the
> compromise
> of having a single function with 2 overloads:
> * pow(double, double) -> double: Uses C pow().
> * pow(int, int) -> double: Uses ipow() for positive exp
On Mon, Dec 4, 2017 at 10:59 PM, Craig Ringer wrote:
> To me it looks like it's time to get this committed, marking as such.
This version has noticeably more code rearrangement than before, and
I'm not sure that is actually buying us anything. Why not keep the
changes minimal?
Also, TBH, this d
> On Dec 5, 2017, at 11:25 AM, Thomas Munro
> wrote:
>
> On Wed, Dec 6, 2017 at 6:17 AM, Mark Dilger wrote:
>> I'm not asking for help configuring my system. If this is a run of the mill
>> out of memory
>> type error, I'll deal with it myself. But if this indicates a bug, I'll be
>> happy
On 6 December 2017 at 04:29, Robert Haas wrote:
> On Mon, Dec 4, 2017 at 6:57 PM, David Rowley
>> I proposed that this worked a different way in [1]. I think the way I
>> mention is cleaner as it means there's no extra reason for a
>> partitioned index to be indisvalid=false than there is for any
David Rowley wrote:
> On 6 December 2017 at 04:29, Robert Haas wrote:
> > On Mon, Dec 4, 2017 at 6:57 PM, David Rowley
> >> I proposed that this worked a different way in [1]. I think the way I
> >> mention is cleaner as it means there's no extra reason for a
> >> partitioned index to be indisvali
On Tue, Dec 5, 2017 at 1:14 PM, Darafei Praliaskouski wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: not tested
> Implements feature: not tested
> Spec compliant: not tested
> Documentation:tested, passed
>
On Wed, Dec 6, 2017 at 12:02 AM, Amit Kapila wrote:
> On Tue, Dec 5, 2017 at 1:29 PM, Thomas Munro
> wrote:
>> Or would it be an option to change the time
>> ExecXXXRetrieveInstrumentation() is called so it is run only once?
>
> To me, that doesn't sound like a bad option. I think if do so, then
On Tue, Nov 28, 2017 at 6:02 AM, amul sul wrote:
> Here are the changes I did on v21 patch to handle crash reported by
> Rajkumar[1]:
>
> diff --git a/src/backend/executor/nodeAppend.c
> b/src/backend/executor/nodeAppend.c
> index e3b17cf0e2..e0ee918808 100644
> --- a/src/backend/executor/nodeApp
On Tue, Dec 5, 2017 at 3:53 PM, David Rowley
wrote:
> I'm not hugely concerned about that. It's not a new problem and it's
> not a problem that I recall seeing anyone complain about, at least not
> to the extent that we've ever bothered to fix it.
>
> The existing problem is with FOREIGN KEY const
On 6 December 2017 at 09:58, Alvaro Herrera wrote:
> David Rowley wrote:
>> On 6 December 2017 at 04:29, Robert Haas wrote:
>> > How does that proposal keep pg_dump from latching onto the wrong
>> > index, if there's more than one index on the same columns?
>>
>> I'm not hugely concerned about th
On 2017-11-27 17:55, Oliver Ford wrote:
Cheers here's v4 with the correct docs.
This email just to link related thread "Add GROUPS option to the Window
Functions":
https://www.postgresql.org/message-id/CAGMVOdtWkb9X7dUh7vjaCaiH34UGFg88unXYTEOub0Rk0swSXw%40mail.gmail.com
On Wed, Dec 6, 2017 at 9:35 AM, Mark Dilger wrote:
>> On Dec 5, 2017, at 11:25 AM, Thomas Munro
>> wrote:
>> Does the plan have multiple Gather nodes with Parallel Bitmap Heap Scan?
>
> This was encountered and logged by a java client. The only data I got was:
>
> org.postgresql.util.PSQLExcept
On 6 December 2017 at 04:07, Robert Haas wrote:
> On Mon, Dec 4, 2017 at 10:59 PM, Craig Ringer
> wrote:
> > To me it looks like it's time to get this committed, marking as such.
>
> This version has noticeably more code rearrangement than before, and
> I'm not sure that is actually buying us an
On 6 December 2017 at 11:35, Robert Haas wrote:
> What are we giving up by explicitly attaching
> the correct index?
The part I don't like about the ATTACH and DETACH of partitioned index
is that it seems to be trying to just follow the syntax we use to
remove a partition from a partitioned table
> On Dec 5, 2017, at 4:07 PM, Thomas Munro
> wrote:
>
> On Wed, Dec 6, 2017 at 9:35 AM, Mark Dilger wrote:
>>> On Dec 5, 2017, at 11:25 AM, Thomas Munro
>>> wrote:
>>> Does the plan have multiple Gather nodes with Parallel Bitmap Heap Scan?
>>
>> This was encountered and logged by a java cl
On Wed, Dec 6, 2017 at 9:42 AM, David Rowley
wrote:
> On 6 December 2017 at 11:35, Robert Haas wrote:
>> What are we giving up by explicitly attaching
>> the correct index?
>
> The part I don't like about the ATTACH and DETACH of partitioned index
> is that it seems to be trying to just follow th
On 6 December 2017 at 13:42, David Rowley wrote:
> On 6 December 2017 at 11:35, Robert Haas wrote:
>> What are we giving up by explicitly attaching
>> the correct index?
>
> The part I don't like about the ATTACH and DETACH of partitioned index
> is that it seems to be trying to just follow the s
In both cases we'd return a double but we use the fast ipow if it's
possible (which can be 20x faster), so at the cost of an extra cast if
you need an int, we'd have a consistent API. Would this be acceptable?
It seems OK to me.
Computing as an int, casting to double and back to int8 can ge
On Wed, Dec 6, 2017 at 12:18 AM, Robert Haas wrote:
> On Tue, Dec 5, 2017 at 2:49 AM, Thomas Munro
> wrote:
>> As for how to aggregate the information, isn't it reasonable to show
>> data from the last loop on the basis that it's representative?
>> Summing wouldn't make too much sense, because yo
On Wed, Dec 6, 2017 at 1:10 AM, Robert Haas wrote:
> On Tue, Dec 5, 2017 at 12:39 AM, Amit Kapila wrote:
>> Yeah, that sounds better, so modified the patch accordingly.
>
> I committed this to master and REL_10_STABLE, but it conflicts all
> over the place on 9.6.
>
I will try to prepare the pat
Hi,
I am trying to bundle a script file with my extension. Script has event
triggers and trigger function does a select query on
pg_event_trigger_ddl_commands .
While executing "create extension" following error is thrown :
ERROR: pg_event_trigger_ddl_commands() can only be called in an even
On Tue, Dec 5, 2017 at 11:34 PM, Robert Haas wrote:
> On Wed, Nov 29, 2017 at 12:11 AM, Michael Paquier
> wrote:
>> On Fri, Oct 27, 2017 at 9:54 PM, Amit Kapila wrote:
>>> The patch still applies (with some hunks). I have added it in CF [1]
>>> to avoid losing track.
>>>
>>> [1] - https://commi
On Wed, Dec 6, 2017 at 3:36 PM, sanyam jain wrote:
> I couldn't understand much from the above thread but like to solve this
> problem.
Not sure that people are much motivated in solving this problem either
as the use-case is very narrow. Based on my memories of the moment
where I looked at this
On 2 December 2017 at 08:04, Robert Haas wrote:
> On Fri, Dec 1, 2017 at 6:20 AM, Beena Emerson wrote:
>> David Q1:
>> postgres=# explain analyse execute ab_q1 (3,3); --const
>>QUERY PLAN
>> -
67 matches
Mail list logo
