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
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
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.
>
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);
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
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
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
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 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
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
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
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,
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 @@
+/*--
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.
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 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: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, 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 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
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 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
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
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/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
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/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
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/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: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 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
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 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
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/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, 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 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, 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 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 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 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 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 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
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
44 matches
Mail list logo
