Hi,
On 2017-07-17 12:54:31 -0700, Mark Dilger wrote:
> These types provide a 4-byte datatype for storing real-world second
> precision timestamps, as occur in many log files.
These seem to be getting less common IME, most products have higher
resolution these days. If this were nicely written, m
On 2017/12/13 15:59, Ali Akbar wrote:
> 2017-12-13 9:10 GMT+07:00 Michael Paquier :
>
>>
>> It is not the first time that this topic shows up. See for example
>> this thread from myself's version of last year:
>> https://www.postgresql.org/message-id/CAB7nPqTPXgX9HiyhhtAgpW7jbA1is
>> kmcsoqxpeeb_k
On Wed, Dec 13, 2017 at 4:30 PM, Andres Freund wrote:
> On 2017-12-13 16:02:45 +0900, Masahiko Sawada wrote:
>> When we add extra blocks on a relation do we access to the disk? I
>> guess we just call lseek and write and don't access to the disk. If so
>> the performance degradation regression mig
On Wed, Dec 13, 2017 at 12:55 PM, Rushabh Lathia
wrote:
> HI,
>
> Consider the below test:
>
> postgres@110311=#call sum(2+2);
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to th
On 12 December 2017 at 22:13, Amit Langote
wrote:
> Attached updated patches.
Thanks for sending the updated patches.
I don't have a complete review at the moment, but the following code
in set_append_rel_pathlist() should be removed.
/* append_rel_list contains all append rels; ignore others *
On 12/13/2017 01:54 AM, Robert Haas wrote:
> On Tue, Dec 12, 2017 at 5:07 PM, Tomas Vondra
> wrote:
>>> I definitely think there's a place for compression built right into
>>> the data type. I'm still happy about commit
>>> 145343534c153d1e6c3cff1fa1855787684d9a38 -- although really, more
>>> n
On Tue, Dec 12, 2017 at 2:33 PM, Teodor Sigaev wrote:
> 0002-pg-trgm-strict_word-similarity.patch – implementation of
>> strict_word_similarity() with comments, docs and tests.
>>
> After some looking in
>
> 1)
> repeated piece of code:
> + if (strategy == SimilarityStrategyNumber)
> +
On 4 December 2017 at 15:35, Konstantin Knizhnik
wrote:
> On 30.11.2017 05:02, Michael Paquier wrote:
>>
>> On Wed, Sep 27, 2017 at 4:07 PM, Simon Riggs
>> wrote:
>>>
>>> On 15 September 2017 at 16:34, Konstantin Knizhnik
>>> wrote:
>>>
Attached please find yet another version of the patch.
On Tue, 12 Dec 2017 15:52:01 -0500
Robert Haas wrote:
>
> Yes. I wonder if \d or \d+ can show it somehow.
>
Yes, in current version of the patch, \d+ shows current compression.
It can be extended to show a list of current compression methods.
Since we agreed on ALTER syntax, i want to clear
On 12/12/17 8:48 PM, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (and...@anarazel.de) wrote:
>> On 2017-12-12 18:04:44 -0500, David Steele wrote:
>>> If the forks are written out of order (i.e. main before init), which is
>>> definitely possible, then I think worst case is some files will b
On Tue, Dec 12, 2017 at 3:43 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Here are review comments for 0009
>
Thank you, Ashutosh for the detailed review so far.
I am working on your reviews but since parallel Append is now committed,
I need to re-base my changes over it and ne
> On 12 September 2017 at 15:29, Tom Lane wrote:
>
> This patch no longer applies cleanly on HEAD, so here's a rebased version
> (no substantive changes). As before, I think the most useful review task
> would be to quantify whether it makes planning noticeably slower.
I tried to experiment a bi
David,
* David Steele (da...@pgmasters.net) wrote:
> On 12/12/17 8:48 PM, Stephen Frost wrote:
> > I don't think there is, because, as David points out, the unlogged
> > tables are cleaned up first and then WAL replay happens during recovery,
> > so the init fork will cause the relation to be over
> On Dec 13, 2017, at 12:07 AM, Andres Freund wrote:
>
> Hi,
>
> On 2017-07-17 12:54:31 -0700, Mark Dilger wrote:
>> These types provide a 4-byte datatype for storing real-world second
>> precision timestamps, as occur in many log files.
>
> These seem to be getting less common IME, most produ
On 12/13/17 04:46, Ashutosh Bapat wrote:
> I think it shouldn't reach this code. Like a normal function
> invocation, an aggregate invocation should not be allowed in a CALL
> statement. Here's patch to fix it. I thought that window function
> invocations and casts had similar problem, but they are
On 12/13/17 10:04 AM, Stephen Frost wrote:
Just to be clear- the new base backup code doesn't actually *do* the
non-init fork removal, it simply doesn't include the non-init fork in
the backup when there is an init fork, right?
It does *not* do the unlogged non-init fork removal. The code I
On 12/13/17 04:06, John Naylor wrote:
> There doesn't seem to be any interest in bootstrap data at the moment,
> but rather than give up just yet, I've added a couple features to make
> a data migration more compelling:
I took a brief look at your patches, and there appear to be a number of
good c
On 12/11/17 9:41 PM, Chapman Flack wrote:
I have, more or less, this classic question:
https://www.postgresql.org/message-id/4667C403.1070807%40t3go.de
However, when you stat a file with a POSIX ACL, you get shown the
ACL's 'mask' entry (essentially the ceiling of all the 'extra' ACL
entrie
Tomas Vondra wrote:
> On 12/13/2017 01:54 AM, Robert Haas wrote:
> > 3. Compression is only applied to large-ish values. If you are just
> > making the data type representation more compact, you probably want to
> > apply the new representation to all values. If you are compressing in
> > the s
On 12/12/17 22:59, Michael Paquier wrote:
> Attached is what I have some up with, based on Peter's v2.
This has been committed. Thanks!
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Thank you for review.
On 13.12.2017 14:29, Simon Riggs wrote:
On 4 December 2017 at 15:35, Konstantin Knizhnik
wrote:
On 30.11.2017 05:02, Michael Paquier wrote:
On Wed, Sep 27, 2017 at 4:07 PM, Simon Riggs
wrote:
On 15 September 2017 at 16:34, Konstantin Knizhnik
wrote:
Attached please
On 12/13/2017 05:55 PM, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> On 12/13/2017 01:54 AM, Robert Haas wrote:
>
>>> 3. Compression is only applied to large-ish values. If you are just
>>> making the data type representation more compact, you probably want to
>>> apply the new representat
On Mon, Dec 11, 2017 at 9:35 PM, Michael Paquier
wrote:
> + /*
> +* Generate random seed, or use caller's. Seed should always be a
> positive
> +* value less than or equal to PG_INT32_MAX, to ensure that any random
> seed
> +* can be recreated through callerseed if the need arises
Robert Haas writes:
> On Mon, Dec 11, 2017 at 3:52 PM, Tom Lane wrote:
>> Here's a quick hack at that. I guess the main question that needs to be
>> asked is whether we're happy with plpgsql getting so much chattier
>> (as per all the regression test changes).
> I confess to never having really
On Tue, Dec 12, 2017 at 9:37 PM, Amit Kapila wrote:
>> Uh, should I just revert that commit entirely first, and then we can
>> commit the new fix afterward?
>
> Yes. I have already extracted the test case of that commit to the new
> patch which is what we need from that commit.
OK, done.
--
Rob
On Wed, Dec 13, 2017 at 12:35 AM, Kuntal Ghosh
wrote:
> I've also verified the backward scan case with the query provided by
> Thomas. In standby,
> 2. explain analyze select * from t1 where a+1>a order by a desc; and
> the parallel workers hang.
> The patch fixes the issue.
Committed and back-pa
On Wed, Dec 13, 2017 at 1:41 AM, Amit Kapila wrote:
> I have tried to reproduce this situation by adding error case in
> worker (just before worker returns success ('X' message)) and by
> having breakpoint in WaitForParallelWorkersToFinish. What, I noticed
> is that worker is not allowed to exit
On Wed, Oct 18, 2017 at 12:45 PM, Peter Geoghegan wrote:
> Bringing it back to the concrete freeze-the-dead issue, and the
> question of an XID-cutoff for safely interrogating CLOG: I guess it
> will be possible to assess a HOT chain as a whole. We can probably do
> this safely while holding a sup
On Wed, Dec 13, 2017 at 1:46 AM, Thomas Munro
wrote:
> Hi hackers,
>
> The start-up cost of bounded (top-N) sorts is sensitive at the small
> end of N, and the
> comparison_cost * tuples * LOG2(2.0 * output_tuples) curve doesn't
> seem to correspond to reality. Here's a contrived example that com
On Tue, Dec 12, 2017 at 10:46 PM, Thomas Munro <
thomas.mu...@enterprisedb.com> wrote:
> Hi hackers,
>
> The start-up cost of bounded (top-N) sorts is sensitive at the small
> end of N, and the
> comparison_cost * tuples * LOG2(2.0 * output_tuples) curve doesn't
> seem to correspond to reality.
Hi,
Looking at the latest version of the tuplestore patch:
diff --git a/src/backend/utils/sort/sharedtuplestore.c
b/src/backend/utils/sort/sharedtuplestore.c
new file mode 100644
index 000..d1233221a58
--- /dev/null
+++ b/src/backend/utils/sort/sharedtuplestore.c
@@ -0,0 +1,583 @@
+/*--
Hi David.
On 2017/12/13 18:48, David Rowley wrote:
> On 12 December 2017 at 22:13, Amit Langote
> wrote:
>> Attached updated patches.
>
> Thanks for sending the updated patches.
>
> I don't have a complete review at the moment, but the following code
> in set_append_rel_pathlist() should be rem
Hi hackers,
I suppose that extensions are supposed to be allowed to use the
facilities in access/parallel.h. I noticed in passing when I wrote a
throwaway test harness that my Windows built drone complained:
test_sharedtuplestore.obj : error LNK2001: unresolved external symbol
ParallelWorkerNumb
2017-12-13 15:37 GMT+07:00 Amit Langote :
> On 2017/12/13 15:59, Ali Akbar wrote:
> >
> > Thanks for the link to those thread.
> >
> > Judging from the discussion there, it will be a long way to prevent DROP
> > NOT NULL.
>
> Yeah, I remembered that discussion when writing my email, but was for so
On Thu, Dec 14, 2017 at 2:32 AM, Robert Haas wrote:
> On Tue, Dec 12, 2017 at 9:37 PM, Amit Kapila wrote:
>>> Uh, should I just revert that commit entirely first, and then we can
>>> commit the new fix afterward?
>>
>> Yes. I have already extracted the test case of that commit to the new
>> patch
On Thu, Dec 14, 2017 at 2:51 AM, Robert Haas wrote:
> On Wed, Dec 13, 2017 at 12:35 AM, Kuntal Ghosh
> wrote:
>> I've also verified the backward scan case with the query provided by
>> Thomas. In standby,
>> 2. explain analyze select * from t1 where a+1>a order by a desc; and
>> the parallel work
Thanks for the updated patches, Amit.
Some review comments.
Forgot to remove the description of update_rri and num_update_rri in the
header comment of ExecSetupPartitionTupleRouting().
-
+extern void pull_child_partition_columns(Relation rel,
+ Relation parent,
+
On Thu, Dec 14, 2017 at 6:37 AM, Andres Freund wrote:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi&dt=2017-12-13%2018%3A00%3A18
>
> which seems half like a compiler bug to me. But either way, we gotta
> work around it. I suspect the reason configure test doesn't
> sufficie
At Fri, 1 Dec 2017 14:12:20 -0800, Andres Freund wrote in
<20171201221220.z5e6wtlpl264w...@alap3.anarazel.de>
> On 2017-12-01 17:03:28 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2017-12-01 16:40:23 -0500, Tom Lane wrote:
> > >> I have no faith in either of these proposals, because
Hi,
Currently if some one try to drop the PROCEDURE and
it don't have privilege or it's not an owner, than error message
still indicate object as FUNCTION.
Example:
postgres@37737=#drop procedure pro;
ERROR: must be owner of function pro
This doesn't look correct specially that now we have sep
Hi.
You may have guessed from $subject that the two don't work together.
create table p (a int) partition by list (a);
create table p1 partition of p for values in (1, 2) partition by list (a);
create table p11 partition of p1 for values in (1);
create table p12 partition of p1 for values in (2);
On Thu, Dec 14, 2017 at 08:51:06AM +0700, Ali Akbar wrote:
> 2017-12-13 15:37 GMT+07:00 Amit Langote :
>
> > On 2017/12/13 15:59, Ali Akbar wrote:
> > >
> > > Thanks for the link to those thread.
> > >
> > > Judging from the discussion there, it will be a long way to prevent DROP
> > > NOT NULL.
>
On 7 December 2017 at 01:22, Petr Jelinek
wrote:
> On 05/12/17 21:07, Robert Haas wrote:
> >
> > Generally we write if (a && b) { ... } not if (a) { if (b) .. }
> >
>
> It's rather ugly with && because one of the conditions is two line, but
> okay here you go. I am keeping the brackets even if no
Hi,
We allow a function to be invoked as part of PERFORM statement in plpgsql
do $$
begin perform pg_relation_size('t1'); end; $$ language plpgsql;
DO
But we do not allow a procedure to be invoked this way
create procedure dummy_proc(a int) as $$
begin null; end;
$$ language plpgsql;
CREATE PROCE
44 matches
Mail list logo
