On Mon, Jun 13, 2016 at 10:44:06PM -0400, Noah Misch wrote:
> On Fri, Jun 10, 2016 at 03:10:40AM -0400, Noah Misch wrote:
> > On Tue, Jun 07, 2016 at 06:05:10PM -0400, Tom Lane wrote:
> > > Jean-Pierre Pelletier writes:
> > > > I wanted to test if phraseto_tsquery(), new with 9.6 could be used for
Amit Kapila writes:
> Right, so I have moved "Failed assertion in parallel worker
> (ExecInitSubPlan)" item to CLOSE_WAIT state as I don't think there is any
> known pending issue in that item. I have moved it to CLOSE_WAIT state
> because we have derived our queries to reproduce the problem base
On Wed, Jun 15, 2016 at 11:43 AM, Thomas Munro
wrote:
> On Wed, Jun 15, 2016 at 12:44 AM, Robert Haas wrote:
>> On Tue, Jun 14, 2016 at 8:11 AM, Robert Haas wrote:
> I noticed that the tuples that it reported were always offset 1 in a
> page, and that the page always had a maxoff over a
On Wed, Jun 15, 2016 at 11:50:33AM +0530, Amit Kapila wrote:
> In short, this test doesn't serve it's purpose which is to generate an
> error from worker.
That's bad. Thanks for figuring out the problem.
> do $$begin
> Perform stringu1::int2 from tenk1 where unique1 = 1;
> end$$;
>
> ERROR:
On Wed, Jun 15, 2016 at 1:42 AM, Robert Haas wrote:
>
> On Tue, Jun 14, 2016 at 1:14 PM, Tom Lane wrote:
> >
> > I have not dug into the code enough to find out exactly what's happening
> > in Peter's complaint, but it seems like it would be a good idea to find
> > that out before arguing along t
Sorry, I'm confused about the minRecoveryPoint.
Reconsidered a bit.
At Tue, 14 Jun 2016 20:31:11 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160614.203111.229211034.horiguchi.kyot...@lab.ntt.co.jp>
> > > After looking more closely, I found that the minRecoveryPoint
> > > tends t
Ioseph Kim writes:
> 2016ë
06ì 15ì¼ 01:56ì Tom Lane ì´(ê°) ì´ ê¸:
>> I take it from the vast silence that nobody particularly cares one way
>> or the other. On reflection I think that this would be a good change
>> to make, so I'll go do so unless I hear complaints soon. regards, tom
2016년 06월 15일 01:56에 Tom Lane 이(가) 쓴 글:
I take it from the vast silence that nobody particularly cares one way
or the other. On reflection I think that this would be a good change
to make, so I'll go do so unless I hear complaints soon. regards, tom
lane
I propose to change from asctime()
On 06/14/2016 05:08 PM, Cat wrote:
We have the capability to provide (semi-)structured data. Might be an idea
to make greater use of it.
postgres=# SELECT * from
to_json(row(current_setting('server_version_num'))) as version;
Sincerely,
jD
--
Command Prompt, Inc. http:/
On 15/06/16 02:08, Cat wrote:
> is it possible to introduce a JSONB output to it.
No thanks.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On 2016/06/15 0:50, Robert Haas wrote:
> On Tue, Jun 14, 2016 at 4:06 AM, Amit Langote wrote:
>> You're right. It indeed should be possible to push down ft1-ft2 join.
>> However it could not be done without also modifying
>> build_tlist_to_deparse() a little (as Ashutosh proposed [1] to do
>> upth
On Tue, Jun 14, 2016 at 01:38:44PM -0700, Joshua D. Drake wrote:
> On 06/14/2016 12:46 PM, Jim Nasby wrote:
>
> >Any ideas on naming for such a function? version_detail()? I suppose
> >while we're at this we might as well provide the compile details as well.
>
> version(detail) or version(verbose
On Wed, Jun 15, 2016 at 12:44 AM, Robert Haas wrote:
> On Tue, Jun 14, 2016 at 8:11 AM, Robert Haas wrote:
I noticed that the tuples that it reported were always offset 1 in a
page, and that the page always had a maxoff over a couple of hundred,
and that we called record_corrupt_it
On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure wrote:
> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby
> wrote:
> > On 6/14/16 3:56 PM, Tom Lane wrote:
> >>
> >> Jim Nasby writes:
> >>>
> >>> On 6/14/16 3:01 PM, Robert Haas wrote:
>
> This seems kind of silly, because anybody who is writ
On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby wrote:
> On 6/14/16 3:56 PM, Tom Lane wrote:
>>
>> Jim Nasby writes:
>>>
>>> On 6/14/16 3:01 PM, Robert Haas wrote:
This seems kind of silly, because anybody who is writing code that
might have to run against an existing version of the dat
On 6/14/16 3:56 PM, Tom Lane wrote:
Jim Nasby writes:
On 6/14/16 3:01 PM, Robert Haas wrote:
This seems kind of silly, because anybody who is writing code that
might have to run against an existing version of the database won't be
able to use it. The one thing that absolutely has to be cross-
On Tue, Jun 14, 2016 at 03:24:12PM -0500, Jim Nasby wrote:
> On 6/8/16 4:36 PM, Bruce Momjian wrote:
> >Just a follow-up, but even with a randomized correlation order, it seems
> >25% restrictivity generates a Bitmap Index Scan:
>
> AFAIK we do the bitmap heap scan in heap order, thereby eliminati
On 6/14/16 3:38 PM, Joshua D. Drake wrote:
On 06/14/2016 12:46 PM, Jim Nasby wrote:
Any ideas on naming for such a function? version_detail()? I suppose
while we're at this we might as well provide the compile details as well.
version(detail) or version(verbose)
I don't think that makes as
Digging through the sqlsmith logging db, I noticed the following errors:
ERROR: cannot update SecondarySnapshot during a parallel operation
ERROR: cannot assign XIDs during a parallel operation
Queries raising the first one always contain calls to currtid() or
currtid2(). Queries raisi
Jim Nasby writes:
> On 6/14/16 3:01 PM, Robert Haas wrote:
>> This seems kind of silly, because anybody who is writing code that
>> might have to run against an existing version of the database won't be
>> able to use it. The one thing that absolutely has to be cross-version
>> is the method of d
On 6/14/16 3:01 PM, Robert Haas wrote:
D) Add a version function to 10.0 that returns both parts separately.
>
> My vote is D. Parsing version() output is a wart, but coming out with a
> split output version of that in 9.6 that still has to support 3 numbers
> would also be a wart. We've lived wi
On 6/8/16 4:36 PM, Bruce Momjian wrote:
Just a follow-up, but even with a randomized correlation order, it seems
25% restrictivity generates a Bitmap Index Scan:
AFAIK we do the bitmap heap scan in heap order, thereby eliminating the
effect of correlation?
--
Jim Nasby, Data Architect, Blue T
On 06/14/2016 12:46 PM, Jim Nasby wrote:
Any ideas on naming for such a function? version_detail()? I suppose
while we're at this we might as well provide the compile details as well.
version(detail) or version(verbose)
JD
--
Command Prompt, Inc. http://the.postgres.company/
On 6/8/16 9:56 AM, Tom Lane wrote:
Thom Brown writes:
On 15 May 2014 at 19:56, Bruce Momjian wrote:
On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote:
A recent question from Tim Kane prompted me to measure the overhead
costs of EXPLAIN ANALYZE, which I'd not checked in awhile. Things
On Tue, Jun 14, 2016 at 08:20:12AM -0400, ''br...@momjian.us' *EXTERN*' wrote:
> > This has caused confussion in the past, see
> > https://www.postgresql.org/message-id/flat/561E749D.4090301%40socialserve.com#561e749d.4090...@socialserve.com
> >
> > > Right. Updated patch attached.
> >
> > I am
On Tue, Jun 14, 2016 at 1:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 14, 2016 at 12:51 PM, Tom Lane wrote:
>>> FWIW, I follow all of your reasoning except this. If we believe that the
>>> parallel worker context line is useful, then it is a bug that plpgsql
>>> suppresses it.
On Tue, Jun 14, 2016 at 3:46 PM, Jim Nasby wrote:
> On 6/13/16 2:12 PM, Merlin Moncure wrote:
>>
>> A) make a variant of version() that returns major/minor/bugfix as
>> separate fields with minor being set to 0 for all released versions
>> 10.0 and beyond. We could then add a NOTE to the version
On 6/12/16 2:13 AM, Ants Aasma wrote:
On Fri, Jun 10, 2016 at 5:23 AM, Haribabu Kommi
wrote:
> 1. Instead of doing the entire database files encryption, how about
> providing user an option to protect only some particular tables that
> wants the encryption at table/tablespace level. This not on
On Tue, Jun 14, 2016 at 1:51 PM, Robert Haas wrote:
> On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson wrote:
>> I have rebased all my patches on the current master now (and skipped the
>> extensions I previously listed).
>
> Thanks, this is really helpful. It was starting to get hard to keep
>
On 6/13/16 2:12 PM, Merlin Moncure wrote:
A) make a variant of version() that returns major/minor/bugfix as
separate fields with minor being set to 0 for all released versions
10.0 and beyond. We could then add a NOTE to the version function and
other places suggesting to use that instead for 9.
On Tue, Jun 14, 2016 at 6:37 AM, Andreas Karlsson wrote:
> I have rebased all my patches on the current master now (and skipped the
> extensions I previously listed).
Thanks, this is really helpful. It was starting to get hard to keep
track of what hadn't been applied yet. I decided to prioriti
Robert Haas writes:
> On Tue, Jun 14, 2016 at 12:51 PM, Tom Lane wrote:
>> FWIW, I follow all of your reasoning except this. If we believe that the
>> parallel worker context line is useful, then it is a bug that plpgsql
>> suppresses it. If we don't believe it's useful, then we should get
>> r
On Tue, Jun 14, 2016 at 12:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> Of course, it would be nice if we could make these counters 64-bit
>> integers, but we can't, because we don't rely on 64-bit reads and
>> writes to be atomic on all platforms. So instead they'll have to be
>> uint32. Th
On Tue, Jun 14, 2016 at 12:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jun 10, 2016 at 4:12 PM, Robert Haas wrote:
>>> On Fri, Jun 10, 2016 at 1:49 PM, Peter Eisentraut
>>> wrote:
Elsewhere in this thread I suggested getting rid of the parallel worker
context by default (e
I wrote:
> Robert Haas writes:
>> On Sun, Jun 12, 2016 at 10:55 AM, Ioseph Kim wrote:
>>> Increase size of this title, please.
>>> 50 bytes is so small for multi language.
>>> And. I suggest that date string might be local language,
>>> or current_timestamp string.
>> This was already changed in
Robert Haas writes:
> On Fri, Jun 10, 2016 at 4:12 PM, Robert Haas wrote:
>> On Fri, Jun 10, 2016 at 1:49 PM, Peter Eisentraut
>> wrote:
>>> Elsewhere in this thread I suggested getting rid of the parallel worker
>>> context by default (except for debugging), but if we do want to keep it,
>>> th
On Fri, Jun 10, 2016 at 4:12 PM, Robert Haas wrote:
> On Fri, Jun 10, 2016 at 1:49 PM, Peter Eisentraut
> wrote:
>> Regarding the patch that ended up being committed, I wonder if it is
>> intentional that PL/pgSQL overwrites the context from the parallel worker.
>> Shouldn't the context effective
Amit Kapila writes:
> On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane wrote:
>> ... I got a core dump in the window.sql test:
>> which I think may be another manifestation of the failure-to-apply-proper-
>> pathtarget issue we're looking at in this thread. Or maybe it's just
>> an unjustified assumpt
Robert Haas writes:
> Of course, it would be nice if we could make these counters 64-bit
> integers, but we can't, because we don't rely on 64-bit reads and
> writes to be atomic on all platforms. So instead they'll have to be
> uint32. That means they could wrap (if you really work at it) but
>
Robert Haas writes:
> On Mon, Jun 13, 2016 at 6:21 PM, Tom Lane wrote:
>> I think this is bad because it forces any external creators of
>> UPPERREL_GROUP_AGG to duplicate that code --- and heaven help everybody
>> if anyone is out of sync on whether to set the flag. So I'd rather keep
>> set_gr
On Tue, Jun 14, 2016 at 4:06 AM, Amit Langote
wrote:
> On 2016/06/14 6:51, Robert Haas wrote:
>> On Fri, Jun 10, 2016 at 4:14 PM, Robert Haas wrote:
>>> Although I have done a bit of review of this patch, it needs more
>>> thought than I have so far had time to give it. I will update again
>>> b
On Mon, Jun 13, 2016 at 10:36 PM, Tom Lane wrote:
>
> Robert Haas writes:
> > On Mon, Jun 13, 2016 at 11:02 AM, Tom Lane wrote:
> >> BTW, decent regression tests could be written without the need to
create
> >> enormous tables if the minimum rel size in create_plain_partial_paths()
> >> could be
David Rowley writes:
> Do you think it's worth also applying the attached so as to have
> ressortgroupref set to NULL more consistently, instead of sometimes
> NULL and other times allocated to memory wastefully filled with zeros?
Meh --- that seems to add complication without buying a whole lot.
Andreas Karlsson writes:
> I do not think that extension SQL scripts should be using CREATE OR
> REPLACE FUNCTION like bloom--1.0.sql currently does. I suspect that this
> might just be a typo.
It's definitely a bug. Grepping around found another instance in
sslinfo, and I also noticed the lac
Bernd Helmle writes:
> --On 14. Juni 2016 10:32:13 + Albe Laurenz
> wrote:
>> I first thought of using the internal ROWID column that's probably
>> similar to your case, but that wouldn't fit into a tid's 6 bytes, and I
>> found that I could only add resjunk columns for existing columns of th
A very quick and dirty hack I did in src/backend/optimizer/plan/initsplan.c (in
9.5.3):
--- initsplan.c.orig2016-06-14 19:08:27.0 +0600
+++ initsplan.c 2016-06-14 19:10:55.0 +0600
@@ -185,9 +185,12 @@
if (IsA(node, Var))
{
On Tue, Jun 14, 2016 at 2:16 AM, Tom Lane wrote:
>
> Robert Haas writes:
> > In practice, we don't yet have the ability for
> > parallel-safe paths from subqueries to affect planning at higher query
> > levels, but that's because the pathification stuff landed too late in
> > the cycle for me to
--On 14. Juni 2016 10:32:13 + Albe Laurenz
wrote:
> I first thought of using the internal ROWID column that's probably
> similar to your case, but that wouldn't fit into a tid's 6 bytes, and I
> found that I could only add resjunk columns for existing columns of the
> table.
> Making the in
On Tue, Jun 14, 2016 at 8:11 AM, Robert Haas wrote:
>>> I noticed that the tuples that it reported were always offset 1 in a
>>> page, and that the page always had a maxoff over a couple of hundred,
>>> and that we called record_corrupt_item because VM_ALL_VISIBLE returned
>>> true but HeapTupleSa
On Tue, Jun 14, 2016 at 8:31 PM, Kyotaro HORIGUCHI
wrote:
>> +# Take a second backup of the standby while the master is offline.
>> +$node_master->stop;
>> +$node_standby_1->backup('my_backup_2');
>> +$node_master->start;
>
> I'm not sure that adding the test case for a particular bug like
> this
On Tue, Jun 14, 2016 at 08:37:12AM +, Albe Laurenz wrote:
> Bruce Momjian wrote:
> > However, for the wire protocol prepare/execute, how do you do EXPLAIN?
> > The only way I can see doing it is to put the EXPLAIN in the prepare
> > query, but I wasn't sure that works. So, I just wrote and tes
On Tue, Jun 14, 2016 at 8:08 AM, Robert Haas wrote:
> On Tue, Jun 14, 2016 at 2:53 AM, Thomas Munro
> wrote:
>> On Tue, Jun 14, 2016 at 4:02 AM, Robert Haas wrote:
>>> On Sat, Jun 11, 2016 at 5:00 PM, Robert Haas wrote:
> How about changing the return tuple of heap_prepare_freeze_tuple to
>
On Tue, Jun 14, 2016 at 2:53 AM, Thomas Munro
wrote:
> On Tue, Jun 14, 2016 at 4:02 AM, Robert Haas wrote:
>> On Sat, Jun 11, 2016 at 5:00 PM, Robert Haas wrote:
How about changing the return tuple of heap_prepare_freeze_tuple to
a bitmap? Two flags: "Freeze [not] done" and "[No] more
Hello, thank you for looking this.
At Fri, 10 Jun 2016 17:39:59 +0900, Michael Paquier
wrote in
> On Thu, Jun 9, 2016 at 9:55 PM, Kyotaro HORIGUCHI
> wrote:
> > Hello, I found that pg_basebackup from a replication standby
> > fails after the following steps, on 9.3 and the master.
> >
> > - st
On Mon, Jun 13, 2016 at 8:11 PM, Tom Lane wrote:
>
> Amit Kapila writes:
> > On Mon, Jun 13, 2016 at 7:51 PM, Tom Lane wrote:
> >> I think the real question here is why the code removed by 04ae11f62
> >> was wrong. It was unsafe to use apply_projection_to_path, certainly,
> >> but using create_
On 14/06/2016 04:09, Robert Haas wrote:
> On Mon, Jun 13, 2016 at 5:42 AM, Julien Rouhaud
> wrote:
>> Agreed, and fixed in attached v3.
>
> I don't entirely like the new logic in
> RegisterDynamicBackgroundWorker.
I'm not that happy with it too. We can avoid iterating over every slots
if the fea
Hi,
I do not think that extension SQL scripts should be using CREATE OR
REPLACE FUNCTION like bloom--1.0.sql currently does. I suspect that this
might just be a typo.
I have attached the tiny patch which fixes this.
Andreas
diff --git a/contrib/bloom/bloom--1.0.sql b/contrib/bloom/bloom--1.0
On 06/07/2016 05:54 PM, Andreas Karlsson wrote:
On 06/07/2016 05:44 PM, Robert Haas wrote:
cube: I think we need a new extension version.
hstore: Does not apply for me.
intarray: Does not apply for me.
Those three and ltree, pg_trgm, and seg depend on my patch with fixes
for the GiST/GIN funct
Aleksey Demakov wrote:
> I have a data store where tuples have unique identities that normally are not
> visible.
> I also have a FDW to work with this data store. As per the docs to implement
> updates
> for this data store I have AddForeignUpdateTargets() function that adds an
> artificial
> c
Hi all,
I have a data store where tuples have unique identities that normally are not
visible.
I also have a FDW to work with this data store. As per the docs to implement
updates
for this data store I have AddForeignUpdateTargets() function that adds an
artificial
column to the target list.
I
On 14 June 2016 at 04:07, Tom Lane wrote:
> Just as an experiment to see what would happen, I did
>
> - int parallel_threshold = 1000;
> + int parallel_threshold = 1;
>
> and ran the regression tests. I got a core dump in the win
Bruce Momjian wrote:
> However, for the wire protocol prepare/execute, how do you do EXPLAIN?
> The only way I can see doing it is to put the EXPLAIN in the prepare
> query, but I wasn't sure that works. So, I just wrote and tested the
> attached C program and it properly output the explain inform
On 2016/06/14 6:51, Robert Haas wrote:
> On Fri, Jun 10, 2016 at 4:14 PM, Robert Haas wrote:
>> Although I have done a bit of review of this patch, it needs more
>> thought than I have so far had time to give it. I will update again
>> by Tuesday.
>
> I've reviewed this a bit further and have di
On Thu, Apr 9, 2015 at 7:05 PM, Antonin Houska wrote:
> While playing with xlogreader, I was lucky enough to see one of the many
> record validations to fail. After having some fun with gdb, I found out that
> in some cases the reader does not enforce enough data to be in state->readBuf
> before c
64 matches
Mail list logo
