Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x

Christoph Berg writes: > Re: Tom Lane 2017-05-30 <1564.1496176...@sss.pgh.pa.us> >> It'd be interesting if people could gather similar numbers on other >> platforms of more real-world relevance, such as ppc64. But based on >> this small sample, I wouldn't object to just going to

Re: [HACKERS] pg_class.relpartbound definition overly brittle

On 2017-05-31 15:06:06 -0700, Mark Dilger wrote: > That's cold comfort, given that most users will be looking at the pg_class > table and not writing C code that compares Node objects. I wrote a bit of > regression test logic that checks, and sure enough the relpartbound field > shows up as

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 3:17 PM, Andres Freund wrote: > > On 2017-05-31 15:06:06 -0700, Mark Dilger wrote: >> That's cold comfort, given that most users will be looking at the pg_class >> table and not writing C code that compares Node objects. I wrote a bit of >> regression

Re: [HACKERS] pg_class.relpartbound definition overly brittle

On 2017-05-31 15:38:58 -0700, Mark Dilger wrote: > > Normal users aren't going to make sense of node trees in the first > > place. You should use pg_get_expr for it: > > postgres[3008][1]=# SELECT pg_get_expr(relpartbound, oid) FROM pg_class > > WHERE relpartbound IS NOT NULL; > >

Re: [HACKERS] logical replication - still unstable after all these months

On 2017-05-31 11:16, Petr Jelinek wrote: [...] Thanks to Mark's offer I was able to study the issue as it happened and found the cause of this. [0001-Improve-handover-logic-between-sync-and-apply-worker.patch] This looks good: -- out_20170531_1141.txt 100 -- pgbench -c 90 -j 8 -T 60 -P

Re: [HACKERS] pg_class.relpartbound definition overly brittle

Mark Dilger wrote: > Hackers, > > recent changes have introduced the :location field to the partboundspec > in pg_catalog.pg_class. This means that if two identical tables with > identical partitioning scheme are created, but one is done before a change > to gram.y, and the other after a change

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 2:49 PM, Alvaro Herrera wrote: > > Mark Dilger wrote: >> Hackers, >> >> recent changes have introduced the :location field to the partboundspec >> in pg_catalog.pg_class. This means that if two identical tables with >> identical partitioning

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 4:00 PM, Alvaro Herrera wrote: > > Mark Dilger wrote: > relpartbound

Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x

Re: Tom Lane 2017-05-31 <28752.1496238...@sss.pgh.pa.us> > OK, this looks good to me. Just to make sure everyone's on the > same page, what I propose to do is simplify all our platform-specific > Makefiles that use either -fpic or -fPIC to use -fPIC unconditionally. > This affects the netbsd,

Re: [HACKERS] POC: Sharing record typmods between backends

On Wed, May 31, 2017 at 11:16 AM, Dilip Kumar wrote: > I agree with you. But, if I understand the use case correctly we need > to store the TupleDesc for the RECORD in shared hash so that it can be > shared across multiple processes. I think this can be achieved with > the

Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x

Alvaro Herrera writes: > My vote would be to backpatch it all the way. That's my thought too. Otherwise it'll be five years before extension authors can stop worrying about this issue. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] TAP backpatching policy

Alvaro Herrera writes: > My main concern is how widely is the buildfarm going to test the new > test frameworks. If we backpatch PostgresNode-based tests to 9.2, are > buildfarm animals going to need to be reconfigured to use > --enable-tap-tests? Yes. The animals

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 2017-05-24 10:52:37 -0400, Robert Haas wrote: > On Wed, May 24, 2017 at 10:32 AM, Andres Freund wrote: > > Well, but then we should just remove minval/maxval if we can't rely on > > it. > > That seems like a drastic overreaction to me. Well, either they work, or they

Re: [HACKERS] UPDATE of partition key

On Mon, May 29, 2017 at 5:26 AM, Amit Kapila wrote: >> But I think, we can also take step-by-step approach even for v11. If >> we agree that it is ok to silently do the updates as long as we >> document the behaviour, we can go ahead and do this, and then as a >> second

[HACKERS] COPY (query) TO ... doesn't allow parallelism

Hi, At the moment $subject doesn't allow parallelism, because copy.c's pg_plan_query() invocation doesn't set the CURSOR_OPT_PARALLEL_OK flag. To me that appears to be an oversight rather than intentional. A somewhat annoying one at that, because it's not uncommong to use COPY to execute

Re: retry shm attach for windows (WAS: Re: [HACKERS] OK, so culicidae is *still* broken)

On Fri, May 26, 2017 at 10:51 AM, Magnus Hagander wrote: > I would definitely suggest putting it in HEAD (and thus, v10) for a while to > get some real world exposure before backpatching. But if it does work out > well in the end, then we can certainly consider backpatching

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 3:42 PM, Andres Freund wrote: > > On 2017-05-31 15:38:58 -0700, Mark Dilger wrote: >>> Normal users aren't going to make sense of node trees in the first >>> place. You should use pg_get_expr for it: >>> postgres[3008][1]=# SELECT

Re: [HACKERS] pg_class.relpartbound definition overly brittle

Mark Dilger wrote: > >> > >> relpartbound > >> | > >>

<    1   2