On Thu, Jun 9, 2016 at 9:41 PM, Robert Haas wrote:
>
>
>
> 2. The all-visible checks seemed to me to be incorrect and incomplete.
> I made the check match the logic in lazy_scan_heap.
>
Okay, I thought we just want to check for dead-tuples. If we want the
logic similar to lazy_scan_heap(), then
On 2016-06-10 11:58:26 +0530, Amit Kapila wrote:
> I have tried in multiple ways by running pgbench with read-write tests, but
> could not see any such behaviour.
It took over an hour of pgbench on a fast laptop till I saw it.
> I have tried by even crashing and
> restarting the server and then
On Fri, Jun 10, 2016 at 8:27 AM, Andres Freund wrote:
>
>
> On June 9, 2016 7:46:06 PM PDT, Amit Kapila
> wrote:
> >On Fri, Jun 10, 2016 at 8:08 AM, Andres Freund
> >wrote:
> >
> >> On 2016-06-09 19:33:52 -0700, Andres Freund wrote:
> >> > I played with it for a while, and besides
> >> > findin
On June 9, 2016 7:46:06 PM PDT, Amit Kapila wrote:
>On Fri, Jun 10, 2016 at 8:08 AM, Andres Freund
>wrote:
>
>> On 2016-06-09 19:33:52 -0700, Andres Freund wrote:
>> > I played with it for a while, and besides
>> > finding intentionally caused corruption, it didn't flag anything
>> > (besides c
On Fri, Jun 10, 2016 at 8:08 AM, Andres Freund wrote:
> On 2016-06-09 19:33:52 -0700, Andres Freund wrote:
> > I played with it for a while, and besides
> > finding intentionally caused corruption, it didn't flag anything
> > (besides crashing on a standby, as in 2)).
>
> Ugh. Just sends after I
On 2016-06-09 19:33:52 -0700, Andres Freund wrote:
> I played with it for a while, and besides
> finding intentionally caused corruption, it didn't flag anything
> (besides crashing on a standby, as in 2)).
Ugh. Just sends after I sent that email:
oid|t_ctid
---
Hi,
I found two, relatively minor, issues.
1) I think we should perform a relkind check in
collect_corrupt_items(). Atm we'll "gladly" run against an index. If
we actually entered the main portion of the loop in
collect_corrupt_items(), that could end up corrupting the table (via
Hea
On Tue, Jun 7, 2016 at 11:56 PM, Ants Aasma wrote:
> Hi all,
>
> I have been working on data-at-rest encryption support for PostgreSQL.
> In my experience this is a common request that customers make. The
> short of the feature is that all PostgreSQL data files are encrypted
> with a single master
On Fri, Jun 10, 2016 at 9:42 AM, Andres Freund wrote:
> On 2016-06-10 09:41:09 +0900, Michael Paquier wrote:
>> On Fri, Jun 10, 2016 at 9:37 AM, Andres Freund wrote:
>> > On 2016-06-10 09:34:33 +0900, Michael Paquier wrote:
>> >> On Fri, Jun 10, 2016 at 9:19 AM, Andres Freund wrote:
>> >> > On 2
On 2016-06-10 09:41:09 +0900, Michael Paquier wrote:
> On Fri, Jun 10, 2016 at 9:37 AM, Andres Freund wrote:
> > On 2016-06-10 09:34:33 +0900, Michael Paquier wrote:
> >> On Fri, Jun 10, 2016 at 9:19 AM, Andres Freund wrote:
> >> > On 2016-06-09 14:37:31 -0700, Andres Freund wrote:
> >> >> I'm wr
On Fri, Jun 10, 2016 at 9:37 AM, Andres Freund wrote:
> On 2016-06-10 09:34:33 +0900, Michael Paquier wrote:
>> On Fri, Jun 10, 2016 at 9:19 AM, Andres Freund wrote:
>> > On 2016-06-09 14:37:31 -0700, Andres Freund wrote:
>> >> I'm writing a patch right now, planning to post it later today, commi
On 2016-06-10 09:34:33 +0900, Michael Paquier wrote:
> On Fri, Jun 10, 2016 at 9:19 AM, Andres Freund wrote:
> > On 2016-06-09 14:37:31 -0700, Andres Freund wrote:
> >> I'm writing a patch right now, planning to post it later today, commit
> >> it tomorrow.
> >
> > Attached.
>
> -/* see b
On Fri, Jun 10, 2016 at 9:19 AM, Andres Freund wrote:
> On 2016-06-09 14:37:31 -0700, Andres Freund wrote:
>> I'm writing a patch right now, planning to post it later today, commit
>> it tomorrow.
>
> Attached.
-/* see bufmgr.h: OS dependent default */
-DEFAULT_BACKEND_FLUSH_AFTER
On 2016-06-09 14:37:31 -0700, Andres Freund wrote:
> I'm writing a patch right now, planning to post it later today, commit
> it tomorrow.
Attached.
>From d86fc0c966efe544b1926652196059539966b137 Mon Sep 17 00:00:00 2001
From: Andres Freund
Date: Thu, 9 Jun 2016 17:15:42 -0700
Subject: [PATCH] Ch
I wrote:
> Robert Haas writes:
>> There's one other related thing I'm concerned about, which is that the
>> code in namespace.c that manages pg_temp doesn't know anything about
>> parallelism. So it will interpret pg_temp to mean the pg_temp_NNN
>> schema for its own backend ID rather than the lea
> There appears to be a problem with how client encoding is handled in
> the communication from parallel workers.
Ouch.
> In a parallel worker, the
> client encoding setting is inherited from its creating process as part
> of the GUC setup. So any plain-text stuff the parallel worker sends
> to
On Thu, Jun 9, 2016 at 10:28 AM, Kevin Grittner wrote:
> [Thanks to Robert to stepping up to keep this moving while I was
> down yesterday with a minor injury. I'm back on it today.]
>> Generally, I think I see the hazard you're concerned about: I had
>> failed to realize, as you mentioned upthre
On Thu, Jun 9, 2016 at 6:09 PM, Peter Geoghegan wrote:
> On Thu, Jun 9, 2016 at 1:08 PM, Robert Haas wrote:
>>> I am in favor of having something similar to
>>> max_parallel_workers_per_gather for utility statements like CREATE
>>> INDEX. That will need a cost model, at least where the DBA isn't
On Thu, Jun 9, 2016 at 1:08 PM, Robert Haas wrote:
>> I am in favor of having something similar to
>> max_parallel_workers_per_gather for utility statements like CREATE
>> INDEX. That will need a cost model, at least where the DBA isn't
>> explicit about the number of workers to use.
>
> We may we
On Thu, Jun 9, 2016 at 5:45 PM, Andres Freund wrote:
> On 2016-06-09 17:40:24 -0400, Robert Haas wrote:
>> On Thu, Jun 9, 2016 at 4:48 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote:
>> >>> Yes, let's fix it. This will also take care of the
On Tue, Jun 7, 2016 at 11:44 AM, Robert Haas wrote:
> More later.
ltree: Skipped per your other email.
ltree_plpython: No point.
pageinspect: Committed.
pg_buffercache: Committed.
pgcrypto: Committed.
pg_freespacemap: Committed.
pg_prewarm: Committed.
pgrowlocks: Committed.
Still more to go.
--
On 2016-06-09 17:40:24 -0400, Robert Haas wrote:
> On Thu, Jun 9, 2016 at 4:48 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote:
> >>> Yes, let's fix it. This will also take care of the questions about
> >>> whether the GIN/GIST opclass tweaks I
On Thu, Jun 9, 2016 at 4:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote:
>>> Yes, let's fix it. This will also take care of the questions about
>>> whether the GIN/GIST opclass tweaks I made a few months ago require
>>> module version bumps.
>
>
On 2016-06-08 23:00:15 -0400, Noah Misch wrote:
> On Sun, May 29, 2016 at 01:26:03AM -0400, Noah Misch wrote:
> > On Thu, May 12, 2016 at 10:49:06AM -0400, Robert Haas wrote:
> > > On Thu, May 12, 2016 at 8:39 AM, Ashutosh Sharma
> > > wrote:
> > > > Please find the test results for the following
Robert Haas writes:
> On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote:
>> Yes, let's fix it. This will also take care of the questions about
>> whether the GIN/GIST opclass tweaks I made a few months ago require
>> module version bumps.
> Tom, there's a patch for this at
> https://www.postgres
On Thu, Jun 9, 2016 at 2:05 PM, Peter Geoghegan wrote:
> On Thu, Jun 9, 2016 at 7:04 AM, Robert Haas wrote:
>> OK, I pushed this after re-reviewing it and fixing a number of
>> oversights. There remains only the task of adding max_parallel_degree
>> as a system-wide limit (as opposed to max_para
On Thu, Jun 9, 2016 at 2:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane wrote:
>>> Well, yeah, you could remove it. It's inappropriate. The right place
>>> for such an error check is an attempt to actually access any data within
>>> a temp table, ie so
On Thu, Jun 9, 2016 at 1:47 PM, Tom Lane wrote:
>> Second, if you can't convert an error or notice message (or possibly a
>> notify message) from the server encoding to the client coding, you are
>> definitely going to fail, with or without parallel query, because that
>> conversion has to be done
Robert Haas writes:
> On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane wrote:
>> Well, yeah, you could remove it. It's inappropriate. The right place
>> for such an error check is an attempt to actually access any data within
>> a temp table, ie someplace in localbuf.c. There is no reason a worker
>>
On Thu, Jun 9, 2016 at 7:04 AM, Robert Haas wrote:
> OK, I pushed this after re-reviewing it and fixing a number of
> oversights. There remains only the task of adding max_parallel_degree
> as a system-wide limit (as opposed to max_parallel_degree now
> max_parallel_workers_per_gather which is a
On Thu, Jun 9, 2016 at 1:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote:
>>> Yes, let's fix it. This will also take care of the questions about
>>> whether the GIN/GIST opclass tweaks I made a few months ago require
>>> module version bumps.
>
>
On Thu, Jun 9, 2016 at 1:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane wrote:
>>> It seems like the only reason that we would need such a flag is that
>>> applying has_parallel_hazard() to a Var is a bit expensive thanks to
>>> the typeid_is_temp() test
Robert Haas writes:
> On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote:
>> Yes, let's fix it. This will also take care of the questions about
>> whether the GIN/GIST opclass tweaks I made a few months ago require
>> module version bumps.
> Tom, there's a patch for this at
> https://www.postgres
On Sat, May 21, 2016 at 11:45 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 5/20/16 7:37 PM, Robert Haas wrote:
>>> I guess my first question is whether we have consensus on the release
>>> into which we should put this. Some people (Noah, among others)
>>> thought it should wait because
Robert Haas writes:
> On Thu, Jun 9, 2016 at 1:14 PM, Tom Lane wrote:
>> The current code results in failures if any non-latin1 data has to be
>> transmitted from worker to leader, even though the query might not have
>> ever sent that data to the client, and therefore would work fine in
>> non-p
Robert Haas writes:
> On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane wrote:
>> It seems like the only reason that we would need such a flag is that
>> applying has_parallel_hazard() to a Var is a bit expensive thanks to
>> the typeid_is_temp() test --- but if you ask me, that test is stupid
>> and shou
On Thu, Jun 9, 2016 at 1:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
>> wrote:
>>> ... So this whole thing
>>> actually happens to work as long as round tripping is possible between the
>>> involved encodings.
>
>> Hmm. I didn't realize that
On Thu, Jun 9, 2016 at 1:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> Don't generate parallel paths for rels with parallel-restricted outputs.
>
> Surely this bit is wrong on its face:
>
> @@ -971,6 +980,7 @@ set_append_rel_size(PlannerInfo *root, RelOptInfo *rel,
> adjust_appendre
Robert Haas writes:
> On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
> wrote:
>> ... So this whole thing
>> actually happens to work as long as round tripping is possible between the
>> involved encodings.
> Hmm. I didn't realize that we had encodings where round-tripping
> wasn't possible.
On Thu, Jun 9, 2016 at 5:50 AM, Amit Langote
wrote:
> On 2016/06/08 23:16, Amit Langote wrote:
>> On Wed, Jun 8, 2016 at 9:27 PM, Robert Haas wrote:
>>> On Tue, Jun 7, 2016 at 10:41 PM, Noah Misch wrote:
[Action required within 72 hours. This is a generic notification.]
The above
On Mon, Jun 6, 2016 at 9:45 PM, Peter Eisentraut
wrote:
> There appears to be a problem with how client encoding is handled in the
> communication from parallel workers. In a parallel worker, the client
> encoding setting is inherited from its creating process as part of the GUC
> setup. So any
On Thu, Jun 9, 2016 at 10:44 AM, Amit Kapila wrote:
> No, I don't have a test case. I have tried a bit, but it seems even if
> there is a problem, one needs to spend quite some time to generate an exact
> test. I think the current patch fixes the reproducible problem [1], so lets
> go with it. W
Hi Robert, Amit,
thanks for working on this.
On 2016-06-09 12:11:15 -0400, Robert Haas wrote:
> 4. The tests as written were not safe under concurrency; they could
> return spurious results if the page changed between the time you
> checked the visibility map and the time you actually examined t
On Thu, Jun 9, 2016 at 5:48 AM, Amit Kapila wrote:
> Attached patch implements the above 2 functions. I have addressed the
> comments by Sawada San and you in latest patch and updated the documentation
> as well.
I made a number of changes to this patch. Here is the new version.
1. The algorit
On 6/6/16 9:45 PM, Peter Eisentraut wrote:
There appears to be a problem with how client encoding is handled in the
communication from parallel workers.
I have added this to the open items for now.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
On Thu, Jun 9, 2016 at 7:44 PM, Robert Haas wrote:
>
> On Thu, Jun 9, 2016 at 9:37 AM, Amit Kapila
wrote:
> > On Thu, Jun 9, 2016 at 8:47 AM, Robert Haas
wrote:
> >> On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila
> >> wrote:
> >> > That seems doable, as for such rels we can only have Vars and
> >>
[Thanks to Robert to stepping up to keep this moving while I was
down yesterday with a minor injury. I'm back on it today.]
On Wed, Jun 8, 2016 at 3:11 PM, Robert Haas wrote:
> On Wed, Jun 8, 2016 at 4:04 PM, Kevin Grittner wrote:
>> -- connection 1
>> drop table if exists t1;
>> create table
Robert Haas writes:
> So I really would like to get a pgindent run done. Any objections to
> doing it sometime RSN? It is of course possible that it might make
> something that we want to revert later harder to revert, but I think
> we should just accept that risk and move forward.
Now that we
On Tue, May 3, 2016 at 11:31 AM, Robert Haas wrote:
> On Tue, May 3, 2016 at 11:23 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> OK, I committed this. Barring objections, I'll go ahead and pgindent
>>> the whole tree tomorrow. If we're going to revert anything big then
>>> we might want to ho
On Thu, Jun 9, 2016 at 9:37 AM, Amit Kapila wrote:
> On Thu, Jun 9, 2016 at 8:47 AM, Robert Haas wrote:
>> On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila
>> wrote:
>> > That seems doable, as for such rels we can only have Vars and
>> > PlaceHolderVars in targetlist. Basically, whenever we are addi
On Wed, Jun 8, 2016 at 10:18 AM, Tom Lane wrote:
> Josh Berkus writes:
>> On 06/07/2016 11:01 PM, Robert Haas wrote:
>>> Here's a patch change max_parallel_degree to
>>> max_parallel_workers_per_gather, and also changing parallel_degree to
>>> parallel_workers. I haven't tackled adding a separat
On Thu, Jun 9, 2016 at 8:47 AM, Robert Haas wrote:
>
> On Mon, Jun 6, 2016 at 6:07 AM, Amit Kapila
wrote:
> > That seems doable, as for such rels we can only have Vars and
> > PlaceHolderVars in targetlist. Basically, whenever we are adding
> > PlaceHolderVars to a relation, just remember that i
Hello, I found that pg_basebackup from a replication standby
fails after the following steps, on 9.3 and the master.
- start a replication master
- start a replication standby
- stop the master in the mode other than immediate.
pg_basebackup to the standby will fail with the following error.
pg
On Wed, May 25, 2016 at 1:32 AM, Michael Paquier
wrote:
> On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera
> wrote:
>> Christoph Berg wrote:
>>> Re: Michael Paquier 2016-05-24
>>>
>>> > Yeah, that's really something that covers only a narrow case, though
>>> > if we don't have it when we need it
On 2016/06/08 23:16, Amit Langote wrote:
> On Wed, Jun 8, 2016 at 9:27 PM, Robert Haas wrote:
>> On Tue, Jun 7, 2016 at 10:41 PM, Noah Misch wrote:
>>> [Action required within 72 hours. This is a generic notification.]
>>>
>>> The above-described topic is currently a PostgreSQL 9.6 open item. R
On Thu, Jun 9, 2016 at 8:48 AM, Amit Kapila wrote:
>
> On Wed, Jun 8, 2016 at 6:31 PM, Robert Haas wrote:
> >
> >
> > Here's my proposal:
> >
> > 1. You already implemented a function to find non-frozen tuples on
> > supposedly all-frozen pages. Great.
> >
> > 2. Let's implement a second functio
On Thu, Jun 9, 2016 at 12:47 AM, Tom Lane wrote:
> Oleg Bartunov writes:
>> On Wed, Jun 8, 2016 at 8:12 PM, Tom Lane wrote:
>>> Another thing I noticed: if you test with tsvectors that don't contain
>>> position info, <-> seems to reduce to &, that is it doesn't enforce
>>> relative position:
>
57 matches
Mail list logo
