On Tue, Mar 7, 2017 at 11:38 AM, Dilip Kumar wrote:
> On Tue, Mar 7, 2017 at 7:47 PM, Robert Haas wrote:
>> You're right to be confused, because that seems to be a bug in the
>> existing code. There seems to be no guarantee that the cheapest
>> parallel-safe path will be in the cheapest_paramete
On Wed, Mar 8, 2017 at 12:45 AM, Fujii Masao wrote:
> Hi,
>
> When I logged in PostgreSQL as non-superuser and ran
> ALTER PUBLICATION command, I got a segmentation fault.
> The code checking the owner of publication might have a bug.
>
> =# CREATE ROLE foo NOSUPERUSER LOGIN
> =# \c - foo
> => \dR
Vaishnavi Prabakaran wrote:
> Yes, I have created a new patch entry into the commitfest 2017-03 and
> attached the latest patch with this e-mail.
Please find attached a companion patch implementing the batch API in
pgbench, exposed as \beginbatch and \endbatch meta-commands
(without docum
On Tue, Mar 7, 2017 at 10:07 PM, Robert Haas wrote:
> It's not about speed. It's about not forgetting to prefetch. Suppose
> that worker 1 becomes the prefetch worker but then doesn't return to
> the Bitmap Heap Scan node for a long time because it's busy in some
> other part of the plan tree.
On Tue, Mar 7, 2017 at 11:39 AM, Peter Eisentraut
wrote:
> On 3/4/17 01:46, Robert Haas wrote:
>>> So I think we should do it, but it needs to be configurable, my original
>>> patch added GUC for it, Peter wanted it to be configurable per
>>> subscription. I guess we could add it as another option
On Sat, Mar 4, 2017 at 1:30 AM, Amit Kapila wrote:
>> While I can't see this explained anywhere, I'm
>> pretty sure that that's supposed to be impossible, which this patch
>> changes.
>>
>
> What makes you think that patch will allow pg_class.relfrozenxid to be
> advanced past opaque->btpo.xact wh
On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila wrote:
> I also think that commit didn't intend to change the behavior,
> however, the point is how sensible is it to keep such behavior after
> Parallel Append. I am not sure if this is the right time to consider
> it or shall we wait till Parallel Ap
On 3/4/17 01:46, Robert Haas wrote:
>> So I think we should do it, but it needs to be configurable, my original
>> patch added GUC for it, Peter wanted it to be configurable per
>> subscription. I guess we could add it as another option to the list of
>> WITH (...) options for CREATE and ALTER SUBS
On Tue, Mar 7, 2017 at 7:47 PM, Robert Haas wrote:
> You're right to be confused, because that seems to be a bug in the
> existing code. There seems to be no guarantee that the cheapest
> parallel-safe path will be in the cheapest_parameterized_paths list.
> I'll go fix that.
Okay, Done the simm
On Tue, Mar 7, 2017 at 11:27 AM, Dilip Kumar wrote:
> On Tue, Mar 7, 2017 at 9:44 PM, Robert Haas wrote:
>> I mean, IIUC, the call to PrefetchBuffer() is not done under any lock.
>> And that's the slow part. The tiny amount of time we spend updating
>> the prefetch information under the mutex sh
On Tue, Mar 7, 2017 at 1:43 AM, Amit Langote
wrote:
> On 2017/03/07 14:04, Tom Lane wrote:
>> Amit Langote writes:
>>> Also, I found out that alter_table.sql mistakenly forgot to drop
>>> partitioned table "p1". Patch 0002 takes care of that.
>>
>> While that might or might not have been intenti
On Thu, Mar 2, 2017 at 9:40 PM, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed
> wrote:
> > 3. Handling adding a new partition to a partitioned table
> >with default partition.
> >This will require moving tuples from existing default partition to
> > newly created par
On Tue, Mar 7, 2017 at 9:44 PM, Robert Haas wrote:
> I mean, IIUC, the call to PrefetchBuffer() is not done under any lock.
> And that's the slow part. The tiny amount of time we spend updating
> the prefetch information under the mutex should be insignificant
> compared to the cost of actually r
On Fri, Mar 03, 2017 at 08:10:52AM +0530, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed wrote:
> > 3. Handling adding a new partition to a partitioned table
> >with default partition.
> >This will require moving tuples from existing default partition to
> > newly creat
On Thu, Mar 2, 2017 at 8:02 PM, Amit Langote
wrote:
> Thanks. I noticed that 'and' is duplicated in a line added by the commit
> to analyze.sgml. Attached 0001 fixes that. 0002 and 0003 same as the
> last version.
Oh, rats. Thanks for noticing. Committed 0001.
--
Robert Haas
EnterpriseDB:
On Tue, Mar 7, 2017 at 11:08 AM, Peter Eisentraut
wrote:
> On 3/6/17 17:16, Robert Haas wrote:
>> What if we told pg_receivewal (or pg_receivexlog, whatever that is) a
>> maximum number of segments to retain before removing old ones? Like
>> pg_receivewal --limit-retained-segments=50GB, or someth
On Tue, Mar 7, 2017 at 11:09 AM, Dilip Kumar wrote:
> On Tue, Mar 7, 2017 at 9:34 PM, Robert Haas wrote:
>>
>> + if (DsaPointerIsValid(node->pstate->tbmiterator))
>> + tbm_free_shared_area(dsa, node->pstate->tbmiterator);
>> +
>> + if (DsaPointerI
(On Tue, Feb 28, 2017 at 10:48 AM, Dilip Kumar wrote:
> 0001- same as previous with some changes for freeing the shared memory stuff.
+if (--ptbase->refcount == 0)
+dsa_free(dsa, istate->pagetable);
+
+if (istate->spages)
+{
+ptpages = dsa_get_address(dsa, istate->spag
On 3/6/17 16:33, Tomas Vondra wrote:
>> I think it would be better not to maintain so much duplicate code
>> between bt_page_items(text, int) and bt_page_items(bytea). How about
>> just redefining bt_page_items(text, int) as an SQL-language function
>> calling bt_page_items(get_raw_page($1, $2))?
On Tue, Mar 7, 2017 at 9:34 PM, Robert Haas wrote:
>
> + if (DsaPointerIsValid(node->pstate->tbmiterator))
> + tbm_free_shared_area(dsa, node->pstate->tbmiterator);
> +
> + if (DsaPointerIsValid(node->pstate->prefetch_iterator))
> +
On 3/6/17 17:16, Robert Haas wrote:
> What if we told pg_receivewal (or pg_receivexlog, whatever that is) a
> maximum number of segments to retain before removing old ones? Like
> pg_receivewal --limit-retained-segments=50GB, or something like that.
That would be doable, but would it solve anyone
On Mon, Mar 6, 2017 at 12:35 AM, Dilip Kumar wrote:
> On Thu, Mar 2, 2017 at 6:52 PM, Robert Haas wrote:
>> 0002 wasn't quite careful enough about the placement of #ifdef
>> USE_PREFETCH, but otherwise looks OK. Committed after changing that
>> and getting rid of the local variable prefetch_iter
On Mon, Mar 6, 2017 at 9:45 AM, Rader, David wrote:
> Revised doc patch attached with various parameters.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
Ashutosh,
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> Here are patches for follwing
> 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as:
> SUMMARY when ON prints planning time. With ANALYZE ON, it also prints
> execution time. When user explicitly uses SUMMARY OFF, it
On Mon, Mar 6, 2017 at 10:01 PM, Andres Freund wrote:
> My benchmarking script first prewarms the whole database, then runs the
> tpch queries in sequence, repeated three times, and compares the shortes
> execution time:
Those numbers are stupendous.
--
Robert Haas
EnterpriseDB: http://www.ente
On Mon, Mar 6, 2017 at 9:09 PM, Amit Kapila wrote:
> Sure, if you think both Writes and Reads at OS level can have some
> chance of blocking in obscure cases, then we should add a wait event
> for them.
I think writes have a chance of blocking in cases even in cases that
are not very obscure at a
Hi,
When I logged in PostgreSQL as non-superuser and ran
ALTER PUBLICATION command, I got a segmentation fault.
The code checking the owner of publication might have a bug.
=# CREATE ROLE foo NOSUPERUSER LOGIN
=# \c - foo
=> \dRp
List of publications
Name | Owner | Inserts | Up
On 03/07/2017 07:58 AM, Simon Riggs wrote:
> On 7 March 2017 at 20:36, Alvaro Herrera wrote:
>
>> FWIW, +1 on improving matters here.
> +1 also.
>
> I don't see what's wrong with relying on buildfarm though; testing is
> exactly what its there for.
>
> If we had a two-stage process, where commit
I think we have consensus to go ahead with this, and the patches are
mostly mechanical, so I only have a few comments on style and one
possible bug below:
0001-Move-contrib-seg-to-only-use-V1-calling-conventions.patch
static int restore(char *s, float val, int n);
-
/*
On 03/07/2017 12:19 AM, Andres Freund wrote:
On 2017-03-02 22:51:09 +0100, Tomas Vondra wrote:
Attaches is the last part of the patch series, rebased to current master and
adopting the new chunk header approach.
Something seems to have gone awry while sending that - the attachement
is a whoppi
On Tue, Mar 7, 2017 at 5:16 AM, Dilip Kumar wrote:
> I am confused about whether to call
> "get_cheapest_parallel_safe_total_inner" with
> innerrel->cheapest_parameterized_paths like we do in case of
> hash_inner_and_outer or with
> innerrel->pathlist. The reason behind I am calling this with com
On Sun, Feb 26, 2017 at 7:09 PM, Robert Haas wrote:
>
> I think I see the problem that you're trying to solve, but I agree
> that this doesn't seem all that elegant. The reason why we have that
> numberTuples check is because we're afraid that we might be in a
> context like the extended-query pr
On Tue, Mar 7, 2017 at 9:36 PM, Heikki Linnakangas wrote:
> I've now committed the bulk of these patches. Many thanks to everyone
> involved, and especially you, Michael, for your persistence!
Thanks!
> There are a bunch of loose ends, like the SASLprep thing. But the core of
> this patch has be
* Daniel Verite (dan...@manitou-mail.org) wrote:
> Christoph Berg wrote:
>
> > Both fixed, thanks for the review! Version 3 attached.
>
> It looks good to me.
>
> Stephen Frost is also reviewer on the patch, so I'm moving the
> status back to "Needs review" at
> https://commitfest.postgres
Simon Riggs writes:
> On 7 March 2017 at 20:36, Alvaro Herrera wrote:
>
>> FWIW, +1 on improving matters here.
>
> +1 also.
>
> I don't see what's wrong with relying on buildfarm though; testing is
> exactly what its there for.
>
> If we had a two-stage process, where committers can issue "trial
On 24 January 2017 at 06:37, Craig Ringer wrote:
> Rebased series attached, on top of current master (which includes
> logical replicaiton).
>
> I'm inclined to think I should split out a few of the changes from
> 0005, roughly along the lines of the bullet points in its commit
> message. Anyone f
On 7 March 2017 at 20:36, Alvaro Herrera wrote:
> FWIW, +1 on improving matters here.
+1 also.
I don't see what's wrong with relying on buildfarm though; testing is
exactly what its there for.
If we had a two-stage process, where committers can issue "trial
commits" as a way of seeing if the b
On Tue, Mar 7, 2017 at 8:48 PM, Ivan Kartyshov
wrote:
> Rebase done.
Thank you for updating the patch.
>
> Meanwhile I made some more changes.
>
> Changes
> ===
> 1) WAITLSN is now implemented as an extension called "pg_waitlsn"
I've read the discussion so far but I didn't see the reason wh
Christoph Berg wrote:
> Both fixed, thanks for the review! Version 3 attached.
It looks good to me.
Stephen Frost is also reviewer on the patch, so I'm moving the
status back to "Needs review" at
https://commitfest.postgresql.org/13/973/
and let him proceed.
Best regards,
--
Daniel Vé
FWIW, +1 on improving matters here.
Andres Freund wrote:
> The best I can come up so far is a toplevel target that creates the temp
> install, starts a cluster and then runs the 'installcheck-or-check'
> target on all the subdirectories via recursion. Individual makefiles can
> either use the pre
On 28 February 2017 at 12:56, Alvaro Herrera wrote:
> Here's a small patch to make a BRIN page range unsummarized. This is
> useful if data has been deleted, and the heap pages are now used for
> completely different data.
We currently have a manual interface for summarize new values, so it
mak
On Tue, Mar 7, 2017 at 8:02 AM, David Rowley
wrote:
> On 7 March 2017 at 15:21, Amit Kapila wrote:
>> +1. How about changing the description of
>> max_parallel_workers_per_gather to "taken from max_worker_processes,
>> limited by max_parallel_workers"?
>
> Thanks for looking.
>
> Seems more accu
On 03/02/2017 08:50 AM, Michael Paquier wrote:
Attached is a new patch set. I have combined SASLprep with the rest
and fixed some conflicts. At the same time when going through NFKC
this morning I have noticed that the implementation was doing the
canonical decomposition and reordered the charact
Hi Amit,
Thanks for adding testcases. Overall the testcases look good.
The testcase is using ALTER TABLE to modify foreign table schema.
Though this works, I think a better option is to use ALTER FOREIGN
TABLE.
Something not related to this patch but
-- no attach partition validation occurs for f
On 7 March 2017 at 19:22, David Rowley wrote:
>>> That may need tweaking. Likely it could be smaller if we had some sort
>>> of bloom filter to mark if the transaction had obtained any AEL locks,
>>> that way it could skip. Initially I really didn't want to make the
>>> patch too complex. I had t
Rebase done.
Meanwhile I made some more changes.
Changes
===
1) WAITLSN is now implemented as an extension called "pg_waitlsn"
2) Call new hook "lsn_updated_hook" right after xact_redo_commit (xlog.c)
3) Corresponding functions:
pg_waitlsn('0/693FF800', 1) - wait 10 seconds
pg_waitlsn_
On 7 March 2017 at 23:20, Simon Riggs wrote:
> On 7 March 2017 at 10:01, David Rowley wrote:
>> On 2 March 2017 at 16:06, Amit Kapila wrote:
>>> On Wed, Mar 1, 2017 at 5:32 PM, David Rowley
>>> wrote:
Hackers,
I've attached a small patch which aims to improve the performance of
>
On 7 March 2017 at 17:31, David Rowley wrote:
> On 2 March 2017 at 16:06, Amit Kapila wrote:
>> Few comments on the patch:
>> 1.
>> +/*
>> + * Number of buckets to split RecoveryLockTable into.
>> + * This must be a power of two.
>> + */
>>
>> +#define RECOVERYLOCKTABLE_SIZE 1024
>>
>> On what ba
Hi,
2017-03-07 1:40 GMT+01:00 Tom Lane :
> > This is actually a problem if a new TSDictionary is created, in a
> different
> > schema specified by the dumped search_path setting.
>
> Just out of curiosity, do you have a concrete test case where it failed
> that way? AFAICS the emitted SQL would
On Sat, Mar 4, 2017 at 4:11 AM, Michael Meskes wrote:
> Dear Sawada-san,
>
>> This cause is that the "begin transaction" is issued automatically
>> before executing COMMIT PREPARED if we're not in auto commit. The
>> Commit 816b008eaf1a1ff1069f3bafff363a9a8bf04a21 fixed bug of
>> incorrect
>> stat
Hi Kuntal,
Patches apply and compile fine. Works as advertised.
Some minor comments on the patches themselves.
In 0001:
- * pgstat_bestart() -
+ * pgstat_procstart() -
+ *
+ * Initialize this process's entry in the PgBackendStatus array.
+ * Called from InitPostgres and AuxiliaryProcessMain.
On 7 March 2017 at 10:01, David Rowley wrote:
> On 2 March 2017 at 16:06, Amit Kapila wrote:
>> On Wed, Mar 1, 2017 at 5:32 PM, David Rowley
>> wrote:
>>> Hackers,
>>>
>>> I've attached a small patch which aims to improve the performance of
>>> AccessExclusiveLock when there are many AccessExclu
On 02/20/2017 01:51 PM, Aleksander Alekseev wrote:
Currently I don't see any significant flaws in these patches. However I
would like to verify that implemented algorithms are compatible with
algorithms implemented by third party.
Yes, that's very important.
For instance, for user 'eax' and p
On Tue, Mar 7, 2017 at 5:21 AM, Robert Haas wrote:
> +/* Can't do anything else if inner path needs to be unique'd */
> +if (save_jointype == JOIN_UNIQUE_INNER)
> +return;
>
> Right after this, you should try_partial_mergejoin_path() with the
> result of get_cheapest_parallel_safe_
On Fri, Mar 3, 2017 at 11:49 PM, David Steele wrote:
> Hi Oleg,
>
> On 2/28/17 2:55 PM, Pavel Stehule wrote:
> > 2017-02-28 20:08 GMT+01:00 Oleg Bartunov >
> > Attached patch is an implementation of SQL/JSON data model from
> > SQL-2016 standard (ISO/IEC 9075-2:2016(E)), which was publis
101 - 155 of 155 matches
Mail list logo