Re: [HACKERS] Latest Data::Dumper breaks hstore_plperl regression test

Andrew Dunstan writes: > Here's a patch along those lines. Looks sane in a quick once-over. Note this needs to be back-patched. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Latest Data::Dumper breaks hstore_plperl regression test

On 05/14/2017 12:04 AM, Andrew Dunstan wrote: > > On 05/13/2017 11:32 PM, Robert Haas wrote: >> On Sat, May 13, 2017 at 6:22 PM, Tom Lane wrote: >>> Or at least, that's what I surmise from the fact that buildfarm critter >>> caiman has been failing that test for the last day

Re: [HACKERS] Latest Data::Dumper breaks hstore_plperl regression test

Andrew Dunstan writes: > On 05/13/2017 11:32 PM, Robert Haas wrote: >> Depending on the precise details of how Data::Dumper prints things >> doesn't seem like a particularly good idea. > I'd be inclined to set $Data::Dumper::Indent to 0 which would suppress > all

Re: [HACKERS] Hash Functions

On Sat, May 13, 2017 at 11:47 PM, Andres Freund wrote: > It'll be differently sized on different platforms. So everyone will have to > write hash functions that look at each member individually, rather than > hashing the entire struct at once. And for each member you'll

Re: [HACKERS] Hash Functions

On Sat, May 13, 2017 at 1:57 PM, Tom Lane wrote: > Basically, this is simply saying that you're willing to ignore the > hard cases, which reduces the problem to one of documenting the > portability limitations. You might as well not even bother with > worrying about the

Re: [HACKERS] Latest Data::Dumper breaks hstore_plperl regression test

On 05/13/2017 11:32 PM, Robert Haas wrote: > On Sat, May 13, 2017 at 6:22 PM, Tom Lane wrote: >> Or at least, that's what I surmise from the fact that buildfarm critter >> caiman has been failing that test for the last day or so, with symptoms >> indicating whitespace

Re: [HACKERS] Latest Data::Dumper breaks hstore_plperl regression test

On 05/13/2017 11:43 PM, Craig Ringer wrote: > > > On 14 May 2017 11:33, "Robert Haas" > wrote: > > On Sat, May 13, 2017 at 6:22 PM, Tom Lane > wrote: > > Or at least, that's what I

Re: [HACKERS] Hash Functions

On May 13, 2017 8:44:22 PM PDT, Robert Haas wrote: >On Sat, May 13, 2017 at 7:08 PM, Andres Freund >wrote: >> I seriously doubt that's true. A lot of more complex types have >> internal alignment padding and such. > >True, but I believe we require

Re: [HACKERS] Hash Functions

On Sat, May 13, 2017 at 7:08 PM, Andres Freund wrote: > I seriously doubt that's true. A lot of more complex types have > internal alignment padding and such. True, but I believe we require those padding bytes to be zero. If we didn't, then hstore_hash would be broken

Re: [HACKERS] Latest Data::Dumper breaks hstore_plperl regression test

On 14 May 2017 11:33, "Robert Haas" wrote: On Sat, May 13, 2017 at 6:22 PM, Tom Lane wrote: > Or at least, that's what I surmise from the fact that buildfarm critter > caiman has been failing that test for the last day or so, with symptoms > indicating

Re: [HACKERS] Latest Data::Dumper breaks hstore_plperl regression test

On Sat, May 13, 2017 at 6:22 PM, Tom Lane wrote: > Or at least, that's what I surmise from the fact that buildfarm critter > caiman has been failing that test for the last day or so, with symptoms > indicating whitespace changes in Data::Dumper output. Some poking into > the

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

2017-05-13 22:20 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > I am working on migration large Oracle application to Postgres. When I > > started migration procedures with OUT parameters I found following limit > > > "record or row variable cannot

[HACKERS] Event triggers + table partitioning cause server crash in current master

Hackers, I discovered a reproducible crash using event triggers in the current development version, 29c7d5e483acaa74a0d06dd6c70b320bb315. I was getting a crash before this version, and cloned a fresh copy of the sources to be sure I was up to date, so I don't think the bug can be attributed

Re: [HACKERS] Hash Functions

On 2017-05-13 10:29:09 -0400, Robert Haas wrote: > On Sat, May 13, 2017 at 12:52 AM, Amit Kapila wrote: > > Can we think of defining separate portable hash functions which can be > > used for the purpose of hash partitioning? > > I think that would be a good idea. I

Re: [HACKERS] Hash Functions

On Fri, May 12, 2017 at 12:38 PM, Robert Haas wrote: > That is a good question. I think it basically amounts to this > question: is hash partitioning useful, and if so, for what? Two words: parallel query. To get parallelism, one of the best approaches is dividing the

Re: [HACKERS] walsender & parallelism

On 2017-04-25 11:18:35 -0400, Robert Haas wrote: > On Thu, Apr 20, 2017 at 9:40 PM, Andres Freund wrote: > > This'd be easier to look at if the fairly separate facility of allowing > > walsender to execute SQL commands had been committed separately, rather > > than as part of

Re: [HACKERS] logical decoding of two-phase transactions

On 13 May 2017 at 22:22, Tom Lane wrote: > > Apparently you are not testing against current HEAD. That's been there > since d10c626de (a whole two days now ;-)) Indeed, I was working on a more than two-day old antiquity. Unfortunately, it's even more complicated to apply

[HACKERS] Latest Data::Dumper breaks hstore_plperl regression test

Or at least, that's what I surmise from the fact that buildfarm critter caiman has been failing that test for the last day or so, with symptoms indicating whitespace changes in Data::Dumper output. Some poking into the Fedora repo shows that rawhide updated perl-Data-Dumper from 2.161 to 2.167 on

Re: [HACKERS] snapbuild woes

On 2017-05-12 10:57:55 +0200, Petr Jelinek wrote: > Hmm, well it helps but actually now that we don't track individual > running transactions anymore it got much less effective (my version of > 0005 does as well). > > The example workload I test with is: > session 1: open transaction, do a write,

Re: [HACKERS] logical decoding of two-phase transactions

Dmitry Dolgov <9erthali...@gmail.com> writes: > Just a note about this patch. Of course time flies by and it needs rebase, > but also there are few failing tests right now: > ERROR: function pg_wal_lsn_diff(pg_lsn, unknown) does not exist Apparently you are not testing against current HEAD.

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

Pavel Stehule writes: > I am working on migration large Oracle application to Postgres. When I > started migration procedures with OUT parameters I found following limit > "record or row variable cannot be part of multiple-item INTO list" IIRC, the reason for

Re: [HACKERS] logical decoding of two-phase transactions

Hi > On 4 April 2017 at 19:13, Masahiko Sawada wrote: > > Other than that issue current patch still could not pass 'make check' > test of contrib/test_decoding. Just a note about this patch. Of course time flies by and it needs rebase, but also there are few failing tests

[HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

Hi I am working on migration large Oracle application to Postgres. When I started migration procedures with OUT parameters I found following limit "record or row variable cannot be part of multiple-item INTO list" I checked code and it looks so this limit is not necessary for ROW types (what is

Re: [HACKERS] Valgrind & tests for `numeric`

Dmitry Dolgov <9erthali...@gmail.com> writes: > Recently I noticed, that when I'm running the regression tests under > Valgrind 3.9.0, > one test for `numeric` is constantly failing: That seems very strange, especially since many PG developers use valgrind, and we even have one buildfarm animal

[HACKERS] Valgrind & tests for `numeric`

Hi Recently I noticed, that when I'm running the regression tests under Valgrind 3.9.0, one test for `numeric` is constantly failing: Here is what expected: ``` SELECT i as pow, round((-2.5 * 10 ^ i)::numeric, -i), round((-1.5 * 10 ^ i)::numeric, -i), round((-0.5 * 10 ^ i)::numeric, -i),

Re: [HACKERS] Hash Functions

On Fri, May 12, 2017 at 11:45 AM, Tom Lane wrote: > Forget hash partitioning. There's no law saying that that's a good > idea and we have to have it. With a different set of constraints, > maybe we could do it, but I think the existing design decisions have > basically

Re: [HACKERS] Hash Functions

Robert Haas writes: > On Sat, May 13, 2017 at 12:52 AM, Amit Kapila wrote: >> Can we think of defining separate portable hash functions which can be >> used for the purpose of hash partitioning? > I think that would be a good idea. I think it

Re: [HACKERS] Hash Functions

On Fri, May 12, 2017 at 10:34 AM, Tom Lane wrote: > Maintaining such a property for float8 (and the types that depend on it) > might be possible if you believe that nobody ever uses anything but IEEE > floats, but we've never allowed that as a hard assumption before. This is

[HACKERS] proposal - using names as primary names of plpgsql function parameters instead $ based names

Hi Now, I when I working on plpgsql_check, I have to check function parameters. I can use fn_vargargnos and out_param_varno for list of arguments and related varno(s). when I detect some issue, I am using refname. It is not too nice now, because these refnames are $ based. Long names are alias

Re: [HACKERS] multi-column range partition constraint

On Sat, May 13, 2017 at 12:42 AM, Amit Langote wrote: > Attached is the correct version. Thank you! I committed 0001 with a couple of cosmetic tweaks and with the change I previously suggested around partexprs_item. You argued that wouldn't work because the contents of

Re: [HACKERS] Hash Functions

On Sat, May 13, 2017 at 12:52 AM, Amit Kapila wrote: > Can we think of defining separate portable hash functions which can be > used for the purpose of hash partitioning? I think that would be a good idea. I think it shouldn't even be that hard. By data type: -

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

On Wed, May 10, 2017 at 10:10 PM, Remi Colinet wrote: > > Parallel queries can also be monitored. The same mecanism is used to monitor > child workers with a slight difference: the main worker requests the child > progression directly in order to dump the whole progress

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Fri, May 12, 2017 at 9:14 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada >> wrote: >>> ... I'd like to propose to change relation >>> extension lock management so that it works

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Thu, May 11, 2017 at 6:09 AM, Masahiko Sawada wrote: > This work would be helpful not only for existing workload but also > future works like some parallel utility commands, which is discussed > on other threads[1]. At least for parallel vacuum, this feature helps > to

Re: [HACKERS] [POC] hash partitioning

On Fri, May 12, 2017 at 6:08 PM, amul sul wrote: > Hi, > > Please find the following updated patches attached: I have done some testing with the new patch, most of the cases worked as per the expectation except below I expect the planner to select only "Seq Scan on t1"