* Noah Misch wrote:
> On Wed, Nov 29, 2017 at 11:45:35PM -0500, Tom Lane wrote:
>> Oh, OK. In that case, we need to get some representatives of these
>> more modern builds into the buildfarm while we're at it.
>
> Yep. Among machines already in the buildfarm, the one running member
> woodlouse
[Replying to an old thread...]
> A customer of ours hit some very slow code while running the
> @>(polygon, polygon) operator with some big polygons. I'm not familiar
> with this stuff but I think the problem is that the algorithm converges
> too slowly to a solution and also has some pretty expe
Peter Geoghegan writes:
> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane wrote:
>> Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario,
>> although that number is a bit shaky since the run-to-run variation
>> is a few percent anyway.
> Is that with "-M prepared", too?
No, I didn't us
On 06/12/2017 17:26, Andreas Karlsson wrote:
An additional issue is that this could break a lot of extensions and
in a way that it is not apparent at compile time. This means we may
need to break all extensions to force extensions authors to check if
they are thread safe.
I do not like making
I noticed that since I put in commit 390d58135, buildfarm members
that use CLOBBER_CACHE_ALWAYS are failing the added test case
with diffs like
*** 5051,5057
NOTICE: y = 2
ERROR: record "r" is not assigned yet
DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
On Sun, Dec 10, 2017 at 12:36:13PM +, Christian Ullrich wrote:
> * Noah Misch wrote:
> > On Wed, Nov 29, 2017 at 11:45:35PM -0500, Tom Lane wrote:
> >> Oh, OK. In that case, we need to get some representatives of these
> >> more modern builds into the buildfarm while we're at it.
> >
> > Yep.
Emre Hasegeli writes:
> I believe there is a simple flaw on the algorithm that causes it loop
> endlessly. It should stop looking at the other segments of the
> polygon after finding the touching one. The attached patch fixes the
> issue for the query posted to this thread. I suggest backpackin
On 9 December 2017 at 06:05, Robert Haas wrote:
> On Thu, Dec 7, 2017 at 3:14 AM, David Rowley
> wrote:
>> The attached is my attempt at putting this right.
>
> I don't feel entirely right about the way this seems to treat
> inheritance and partitioning as two entirely separate features; that's
>
On 2017/12/08 23:34, Tom Lane wrote:
> Amit Langote writes:
>> I wonder if ScalarArrayOpExpr is not really meant for multi-dimensional
>> arrays appearing on the right hand side? Because:
>> # select array[1] = any (array[array[1], array[2]]);
>
>> ERROR: operator does not exist: integer[] = in
Hi hackers,
I heard a report of a 10.1 cluster hanging with several 'BtreePage'
wait_events showing in pg_stat_activity. The query plan involved
Parallel Index Only Scan, and the table is concurrently updated quite
heavily. I tried and failed to make a reproducer, but from the clues
available it
On Mon, Dec 11, 2017 at 3:51 PM, Thomas Munro
wrote:
> I heard a report of a 10.1 cluster hanging with several 'BtreePage'
> wait_events showing in pg_stat_activity.
I forgot to add, for bug reporter credit purposes: thanks to Patrick
Hemmer for the off-list report and backtrace. He's able to wo
Hello,
FYI
I collected Web resources to learn PostgreSQL internals in the Developer FAQ
page. I did this because I need to provide self-education materials for new
developers. Specifically, I modified "How is the source code organized?", and
added "What information is available to learn Postg
On Fri, Dec 8, 2017 at 9:45 PM, Robert Haas wrote:
> On Fri, Dec 8, 2017 at 4:56 AM, Amit Kapila wrote:
>> I think the optimization you are suggesting has a merit over what I
>> have done in the patch. However, one point to note is that we are
>> anyway going to call that function down in the pa
On Sat, Dec 2, 2017 at 6:16 AM, Bossart, Nathan wrote:
> On 12/1/17, 3:04 PM, "Robert Haas" wrote:
>> Seems entirely reasonable to me, provided that we only update the
>> extensible-options syntax:
>>
>> VACUUM [ ( option [, ...] ) ] [ table_and_columns [, ...] ]
>>
>> I don't want to add any mor
Thanks Tels for reviewing the patch.
On Fri, Dec 8, 2017 at 2:54 PM, Tels wrote:
> Hello Rushabh,
>
> On Fri, December 8, 2017 2:28 am, Rushabh Lathia wrote:
> > Thanks for review.
> >
> > On Fri, Dec 8, 2017 at 6:27 AM, Peter Geoghegan wrote:
> >
> >> On Thu, Dec 7, 2017 at 12:25 AM, Rushabh L
On Sat, Dec 9, 2017 at 2:00 AM, Robert Haas wrote:
> On Fri, Dec 8, 2017 at 3:20 AM, Masahiko Sawada wrote:
>>> The first hunk in monitoring.sgml looks unnecessary.
>>
>> You meant the following hunk?
>>
>> diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
>> index 8d461c8.
On Sat, Dec 9, 2017 at 1:25 AM, Peter Eisentraut
wrote:
> On 6/29/17 06:09, Masahiko Sawada wrote:
>> Thanks, I agree to use XLOG_BACKUP_END instead.
>>
>>> Worse, the current comment implies that
>>> minRecoveryPoint is incorrectly set if it is true. Bleh.
>>
>> Looking at the condition, we use m
On Sat, Dec 9, 2017 at 2:24 AM, Robert Haas wrote:
> On Fri, Dec 8, 2017 at 4:13 AM, Michael Paquier
> wrote:
>> On Fri, Dec 8, 2017 at 5:38 PM, Masahiko Sawada
>> wrote:
>>> After off-discussion with Fujii-san, I've updated the comment of why
>>> we should disallow interrupts before setting/cl
On Wed, Dec 6, 2017 at 1:52 AM, Bossart, Nathan wrote:
> 0001_fix_unparenthesized_vacuum_grammar_v1.patch
>
> One VacuumStmt grammar rule allows users to specify the VACOPT_ANALYZE
> option by including an AnalyzeStmt at the end of the command. This
> appears to have been added as part of the int
On Mon, Dec 11, 2017 at 2:03 PM, Masahiko Sawada wrote:
> On Sat, Dec 9, 2017 at 2:24 AM, Robert Haas wrote:
>> On Fri, Dec 8, 2017 at 4:13 AM, Michael Paquier
>> wrote:
>>> I would just write "To
>>> avoid calling CHECK_FOR_INTERRUPTS which can happen when releasing a
>>> LWLock" and be done wi
On 2017/12/09 3:46, Robert Haas wrote:
> On Fri, Dec 8, 2017 at 5:40 AM, Amit Langote
> wrote:
>> I noticed that if you partition using a array type column, partition
>> pruning using constraint exclusion fails to work due to a minor problem.
>>
>> Example:
>>
>> create table p (a int[]) partition
On Mon, Dec 11, 2017 at 8:43 AM, Tsunakawa, Takayuki
wrote:
> Hello,
>
> FYI
> I collected Web resources to learn PostgreSQL internals in the Developer FAQ
> page. I did this because I need to provide self-education materials for new
> developers. Specifically, I modified "How is the source co
On Mon, Dec 11, 2017 at 8:21 AM, Thomas Munro
wrote:
> Hi hackers,
>
>
> ... and then it called _bt_parallel_seize() itself, in violation of
> the rule (by my reading of the code) that you must call
> _bt_parallel_release() (via _bt_readpage()) or _bt_parallel_done()
> after seizing the scan. If
On Sun, Dec 10, 2017 at 6:02 AM, Noah Misch wrote:
> Two buildfarm runs[1][2] from the last 90 days have failed in
> src/test/authentication, like this:
>
> t/001_password.pl ..
> Failed 3/8 subtests
> t/002_saslprep.pl .. ok 1815 ms ( 0.00 usr 0.00 sys + 0.89 cusr 0.26
> csys = 1.1
(2017/12/09 5:53), Robert Haas wrote:
On Sun, Dec 3, 2017 at 2:56 PM, Tom Lane wrote:
Not sure where that leaves us for the patch at hand. It feels to me
like it's a temporary band-aid for code that we want to get rid of
in the not-too-long run. As such, it'd be okay if it were smaller,
but i
On Mon, Dec 11, 2017 at 04:19:52PM +0900, Michael Paquier wrote:
> On Sun, Dec 10, 2017 at 6:02 AM, Noah Misch wrote:
> If SIGPIPE is ignored then test output just stops after generating the
> FATAL message. Oops.
You mean "If SIGPIPE is not ignored ...", right?
> > To fix the actual failures,
26 matches
Mail list logo
