Re: [HACKERS] `array_position...()` causes SIGSEGV

On Fri, Dec 9, 2016 at 3:14 PM, Junseok Yang wrote: > I met SIGSEGV when using `array_position()` with record type > arguments, so I've written a patch which corrects this problem. It > seems that `array_position...()` sets wrong memory context for the > cached function (in

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 9, 2016 at 3:23 PM, Michael Paquier wrote: > This basically means that if the latch is set, we don't wait at all > and drop the ball. I am wondering: isn't that a problem even if > WL_LATCH_SET is *not* set? If I read this code correctly, even if > caller

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Fri, Dec 9, 2016 at 3:02 PM, vinayak wrote: > On 2016/12/05 14:42, Ashutosh Bapat wrote: >> >> On Mon, Dec 5, 2016 at 11:04 AM, Haribabu Kommi >> wrote: >> >> >> On Fri, Nov 11, 2016 at 5:38 PM, Masahiko Sawada

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 9, 2016 at 2:38 AM, Ashutosh Sharma wrote: > Well, we are currently passing INFINITE timeout value to > WaitForMultipleObjects() API which is hanging. I thought of changing this > INIFINTE timeout interval to some finite value like say 1 sec and could not >

Re: [HACKERS] Declarative partitioning - another take

Hi, I am testing the partitioning feature from the latest master and got the following error while loading the data - db01=# create table orders_y1993 PARTITION OF orders FOR VALUES FROM ('1993-01-01') TO ('1993-12-31'); CREATE TABLE db01=# copy orders from '/data/orders-1993.csv' delimiter

[HACKERS] `array_position...()` causes SIGSEGV

Hello hackers, I met SIGSEGV when using `array_position()` with record type arguments, so I've written a patch which corrects this problem. It seems that `array_position...()` sets wrong memory context for the cached function (in this case `record_eq()`) which is used to find a matching element.

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On 2016/12/05 14:42, Ashutosh Bapat wrote: On Mon, Dec 5, 2016 at 11:04 AM, Haribabu Kommi wrote: On Fri, Nov 11, 2016 at 5:38 PM, Masahiko Sawada wrote: 2PC is a basic building block to support the atomic commit and there are some

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/09 0:25, Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:42 PM, Michael Paquier > wrote: >>> Congrats to everyone working on this! This is a large step forward. >> >> Congratulations to all! It was a long way to this result. > > Yes. The last effort in this

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Thu, Dec 8, 2016 at 10:05 PM, Michael Paquier wrote: > On Thu, Dec 8, 2016 at 5:55 PM, Heikki Linnakangas wrote: >> On 12/08/2016 10:18 AM, Michael Paquier wrote: >>> Hmmm. How do we handle the case where the user name does not match >>> then? The

Re: [HACKERS] Declarative partitioning - another take

Hi Stephen, On 2016/12/08 22:35, Stephen Frost wrote: >>> * The fact that there's no implementation of row movement should be >>> documented as a limitation. We should also look at removing that >>> limitation. >> >> Yes, something to improve. By the way, since we currently mention INSERT >>

Re: [HACKERS] Declarative partitioning - another take

From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > On 2016/12/09 10:09, Tsunakawa, Takayuki wrote: > > Another requirement was subpartitioning. Will this be possible with the > current infrastructure, or does this need drastic change? > > It does support sub-partitioning, although the

Re: [HACKERS] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

On Fri, Dec 9, 2016 at 1:11 AM, Asif Naeem wrote: > It make sense. I would like to share more comments as following i.e. > >> static int >> bf_check_supported_key_len(void) >> { >> ... >> /* encrypt with 448bits key and verify output */ >> evp_ctx =

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/09 10:09, Tsunakawa, Takayuki wrote: > Another requirement was subpartitioning. Will this be possible with the > current infrastructure, or does this need drastic change? It does support sub-partitioning, although the syntax is a bit different. Thanks, Amit -- Sent via

Re: [HACKERS] Declarative partitioning - another take

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Alexander > Korotkov > Yes. Getting at least some of this features committed to v10 would be great > and improve partitioning usability a lot. I'm sorry for not contributing to the real

Re: [HACKERS] Unlogged tables cleanup

On Fri, Dec 9, 2016 at 4:54 AM, Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:20 PM, Michael Paquier > wrote: >> OK, I rewrote a bit the patch as attached. What do you think? > > Committed and back-patched all the way back to 9.2. Thanks! >>>

Re: [HACKERS] Proposal for changes to recovery.conf API

On Fri, Dec 9, 2016 at 9:34 AM, Josh Berkus wrote: > On 12/08/2016 04:16 PM, Tom Lane wrote: >> Josh Berkus writes: >>> On 12/01/2016 05:58 PM, Magnus Hagander wrote: And in fairness, having such a "guide to changes" chapter in each release

Re: [HACKERS] Proposal for changes to recovery.conf API

On 12/08/2016 04:16 PM, Tom Lane wrote: > Josh Berkus writes: >> On 12/01/2016 05:58 PM, Magnus Hagander wrote: >>> And in fairness, having such a "guide to changes" chapter in each >>> release probably *would* be a good idea. But it would take resources to >>> make that. The

Re: [HACKERS] Proposal for changes to recovery.conf API

Josh Berkus writes: > On 12/01/2016 05:58 PM, Magnus Hagander wrote: >> And in fairness, having such a "guide to changes" chapter in each >> release probably *would* be a good idea. But it would take resources to >> make that. The release notes are good, but having a more

Re: [HACKERS] Proposal for changes to recovery.conf API

On 12/01/2016 05:58 PM, Magnus Hagander wrote: > >> * Add docs: "Guide to changes in recovery.conf in 10.0" > > > > Hmm, we don't usually write the docs in terms of how things are > > different from a previous version. Might seem strange in 5 years. > > Not sure what's best,

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2016-12-08 18:03:04 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-12-08 17:38:38 -0500, Tom Lane wrote: > >> The habit of zero-initializing Datums has got exactly nothing to do with > >> V0 functions; it's about ensuring consistent results and avoiding > >>

Re: [HACKERS] Time to drop old-style (V0) functions?

Andres Freund writes: > On 2016-12-08 17:38:38 -0500, Tom Lane wrote: >> The habit of zero-initializing Datums has got exactly nothing to do with >> V0 functions; it's about ensuring consistent results and avoiding >> heisenbugs from use of uninitialized memory. I do not

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2016-12-08 14:53:58 -0800, Andres Freund wrote: > On 2016-12-08 17:38:38 -0500, Tom Lane wrote: > > The habit of zero-initializing Datums has got exactly nothing to do with > > V0 functions; it's about ensuring consistent results and avoiding > > heisenbugs from use of uninitialized memory. I

Re: [HACKERS] Time to drop old-style (V0) functions?

On 2016-12-08 17:38:38 -0500, Tom Lane wrote: > Andres Freund writes: > > I'm wondering if it's not time for $subject: > > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > > forgotten > > - They have us keep weird hacks around just for the sake of testing

Re: [HACKERS] Changed SRF in targetlist handling

Robert Haas writes: > Tom, it's been about 3.5 months since you wrote this. I think it > would be really valuable if you could get to this RSN because the > large patch set posted on the "Changed SRF in targetlist handling" > thread is backed up behind this -- and I think

Re: [HACKERS] Time to drop old-style (V0) functions?

Andres Freund writes: > I'm wondering if it's not time for $subject: > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > forgotten > - They have us keep weird hacks around just for the sake of testing V0 > - they actually cost performance, because we have

Re: [HACKERS] Performance degradation in Bitmapscan (commit 75ae538bc3168bf44475240d4e0487ee2f3bb376)

On Wed, Nov 23, 2016 at 3:33 AM, Andres Freund wrote: > On 2016-11-18 08:00:40 -0500, Robert Haas wrote: >> On Tue, Nov 15, 2016 at 2:28 PM, Andres Freund wrote: >> > I've a working fix for this, and for a similar issue Robert found. I'm >> > still playing

Re: [HACKERS] pg_dump vs. TRANSFORMs

Stephen Frost writes: > That's a good point, we might be doing things wrong in other places in > the code by using FirstNormalObjectId on pre-8.1 servers. > What I suggest then is an independent patch which uses a different > variable than FirstNormalObjectId and sets it

Re: [HACKERS] Changed SRF in targetlist handling

On Mon, Aug 22, 2016 at 4:20 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-08-17 17:41:28 -0700, Andres Freund wrote: >>> Tom, do you think this is roughly going in the right direction? > > I've not had time to look at this patch, I'm afraid. If

Re: [HACKERS] Time to drop old-style (V0) functions?

Andres, all, * Andres Freund (and...@anarazel.de) wrote: > I'm wondering if it's not time for $subject: > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was > forgotten > - They have us keep weird hacks around just for the sake of testing V0 > - they actually cost performance,

Re: [HACKERS] pg_dump vs. TRANSFORMs

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> (Actually, the most likely way in which this would break things is if > >> it started causing built-in casts to get dumped ... have you checked?) > > > So, this is

Re: [HACKERS] pg_dump vs. TRANSFORMs

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Ok, thinking a bit more on this and testing, it looks like we record the > > initdb-defined casts as 'pinned' in pg_depend all the way back to 7.3. > > Therefore, we could use that as the gating factor

Re: [HACKERS] pg_dump vs. TRANSFORMs

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> (Actually, the most likely way in which this would break things is if >> it started causing built-in casts to get dumped ... have you checked?) > So, this is fun. Apparently casts had OIDs >

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Thu, 8 Dec 2016 11:27:34 -0500 Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:02 PM, Karl O. Pinc wrote: > > I read this and knew that I hadn't finished review, but didn't > > immediately respond because I thought the patch had to be > > marked "ready

[HACKERS] Time to drop old-style (V0) functions?

Hi, I'm wondering if it's not time for $subject: - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was forgotten - They have us keep weird hacks around just for the sake of testing V0 - they actually cost performance, because we have to zero initialize Datums, even if the

Re: [HACKERS] Logical Replication WIP

On 08/12/16 20:16, Peter Eisentraut wrote: > On 12/6/16 11:58 AM, Peter Eisentraut wrote: >> On 12/5/16 6:24 PM, Petr Jelinek wrote: >>> I think that the removal of changes to ReplicationSlotAcquire() that you >>> did will result in making it impossible to reacquire temporary slot once >>> you

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

Peter Geoghegan writes: > On Wed, Dec 7, 2016 at 11:55 PM, Heikki Linnakangas wrote: >> Should we be worried about breaking the API of tuplesort_get* functions? >> They might be used by extensions. I think that's OK, but wanted to bring it >> up. This would be

Re: [HACKERS] pg_dump vs. TRANSFORMs

Stephen Frost writes: > Ok, thinking a bit more on this and testing, it looks like we record the > initdb-defined casts as 'pinned' in pg_depend all the way back to 7.3. > Therefore, we could use that as the gating factor for getFuncs() instead > of FirstNormalObjectId and

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

I've pushed the previous patch to HEAD. Attached is a proposed patch (against 9.6) that we could use for the back branches; it takes the brute force approach of just computing the correct value on-demand in the two functions at issue. The key question of course is whether this is acceptable from

Re: [HACKERS] pg_dump vs. TRANSFORMs

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> I have a vague feeling that the code for dumping casts and/or transforms > >> may have some assumptions that the underlying function is also being > >> dumped.

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

On Wed, Dec 7, 2016 at 11:55 PM, Heikki Linnakangas wrote: > Should we be worried about breaking the API of tuplesort_get* functions? > They might be used by extensions. I think that's OK, but wanted to bring it > up. This would be only for master, of course, and any breakage

Re: [HACKERS] Parallel execution and prepared statements

On Wed, Dec 7, 2016 at 9:23 PM, Amit Kapila wrote: > Attached patch changes the comment based on above suggestions. Thanks. Committed and back-patched to 9.6. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Dec 8, 2016 at 2:11 PM, Stephen Frost wrote: > > Yes, that makes the compiler warning go away. > > Great, pushed. Awesome, thanks! > > ... your compiler knows that key->partnatts will always be >= 1? > > :-) > > I

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Thu, Dec 8, 2016 at 2:11 PM, Stephen Frost wrote: > Yes, that makes the compiler warning go away. Great, pushed. > ... your compiler knows that key->partnatts will always be >= 1? :-) I think my compiler is too dumb to notice that int x; printf("%d", x); is a reference

Re: [HACKERS] Unlogged tables cleanup

On Wed, Dec 7, 2016 at 11:20 PM, Michael Paquier wrote: > OK, I rewrote a bit the patch as attached. What do you think? Committed and back-patched all the way back to 9.2. >> Right (I think). If we set and clear delayChkpt around this work, we >> don't need the

Re: [HACKERS] Proposal for changes to recovery.conf API

On 12/04/2016 07:21 PM, Michael Paquier wrote: > On Mon, Dec 5, 2016 at 11:34 AM, Haribabu Kommi > wrote: >> As there was a feedback from others related to the patch and doesn't find >> any >> update from author. >> >> Closed in 2016-11 commitfest with "returned with

Re: [HACKERS] Logical Replication WIP

On 12/6/16 11:58 AM, Peter Eisentraut wrote: > On 12/5/16 6:24 PM, Petr Jelinek wrote: >> I think that the removal of changes to ReplicationSlotAcquire() that you >> did will result in making it impossible to reacquire temporary slot once >> you switched to different one in the session as the if

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Dec 8, 2016 at 1:49 PM, Stephen Frost wrote: > > * Robert Haas (rh...@postgresql.org) wrote: > >> Implement table partitioning. > > > > My compiler apparently doesn't care for this: > > > >

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On Thu, Dec 8, 2016 at 1:49 PM, Stephen Frost wrote: > * Robert Haas (rh...@postgresql.org) wrote: >> Implement table partitioning. > > My compiler apparently doesn't care for this: > > .../src/backend/catalog/partition.c: In function ‘partition_rbound_cmp’: >

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

* Robert Haas (rh...@postgresql.org) wrote: > Implement table partitioning. My compiler apparently doesn't care for this: .../src/backend/catalog/partition.c: In function ‘partition_rbound_cmp’: .../src/backend/catalog/partition.c:1787:13: warning: ‘cmpval’ may be used uninitialized in this

Re: [HACKERS] postgres_fdw bug in 9.6

Robert Haas writes: > Maybe it would help for Jeff to use elog_node_display() to the nodes > that are causing the problem - e.g. outerpathkeys and innerpathkeys > and best_path->path_mergeclauses, or just best_path - at the point > where the error is thrown. That might give

Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code

Tom, Geoff, Thanks for your feedback! Here is version 2 of this patch. > You could just change it to > if (str[strspn(str, " \t\n\r\f")] == '\0') > to mitigate calling strlen. It's safe to do so because strspn will > only return values from 0 to strlen(str). > [...] I have serious doubts that

Re: [HACKERS] postgres_fdw bug in 9.6

On Thu, Dec 8, 2016 at 12:50 PM, Tom Lane wrote: > Jeff Janes writes: >> I have a DML statement which triggers the error: >> ERROR: XX000: outer pathkeys do not match mergeclauses >> LOCATION: create_mergejoin_plan, createplan.c:3722 > > Hmm. > >> Any

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On Thu, Dec 8, 2016 at 12:40 PM, Tom Lane wrote: > Ah-hah, thanks for the insight. I can now reproduce it, and I confirm > that aside from removing the semaphores, our POSIX shmem segment(s) > are removed from /dev/shm. They presumably still are attached to whatever >

Re: [HACKERS] postgres_fdw bug in 9.6

Jeff Janes writes: > I have a DML statement which triggers the error: > ERROR: XX000: outer pathkeys do not match mergeclauses > LOCATION: create_mergejoin_plan, createplan.c:3722 Hmm. > Any tips on investigating this further in situ? Or is the best option just > to

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

Peter Eisentraut writes: > On 12/7/16 9:28 PM, Alex Hunsaker wrote: >> Hrm, the following incantation seems to break for me on a fresh Fedora >> 25 system: >> 1) As root su to $USER and start postgres. >> 2) ssh in as $USER and then logout >> 3) # psql localhost

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

Well, we are currently passing INFINITE timeout value to WaitForMultipleObjects() API which is hanging. I thought of changing this INIFINTE timeout interval to some finite value like say 1 sec and could not reproduce the issue. But, having said that i checked the older code where this issue does

[HACKERS] postgres_fdw bug in 9.6

I have a setup where a 9.6.1 server uses postgres_fdw to connect to a 9.4.9 hot standby server. I have a DML statement which triggers the error: ERROR: XX000: outer pathkeys do not match mergeclauses LOCATION: create_mergejoin_plan, createplan.c:3722 The error first starts appearing with this

Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code

Aleksander Alekseev writes: > How about rewriting such a code like this? > if (pg_str_containsonly(str, " \t\n\r\f")) Function name seems weirdly spelled. Also, I believe that in nearly all use-cases the number of data characters that would typically be examined is

Re: [HACKERS] Declarative partitioning - another take

On Thu, Dec 8, 2016 at 11:44 AM, Dmitry Ivanov wrote: >> That would be fantastic. I and my colleagues at EnterpriseDB can >> surely help review; of course, maybe you and some of your colleagues >> would like to help review our patches, too. > > Certainly, I'll start

Re: [HACKERS] Declarative partitioning - another take

On Thu, Dec 8, 2016 at 11:43 AM, Alexander Korotkov wrote: > Great! And it is very cool that we have basic infrastructure already > committed. Thanks a lot to you and everybody involved. Thanks. >> of course, maybe you and some of your colleagues >> would like to

Re: [HACKERS] Declarative partitioning - another take

That would be fantastic. I and my colleagues at EnterpriseDB can surely help review; of course, maybe you and some of your colleagues would like to help review our patches, too. Certainly, I'll start reviewing as soon as I get familiar with the code. Do you think this is likely to be

Re: [HACKERS] Declarative partitioning - another take

On Thu, Dec 8, 2016 at 7:29 PM, Robert Haas wrote: > On Thu, Dec 8, 2016 at 11:13 AM, Dmitry Ivanov > wrote: > > We (PostgresPro) have been working on pg_pathman for quite a while, and > > since it's obviously going to become the thing of the

Re: [HACKERS] Declarative partitioning - another take

On Thu, Dec 8, 2016 at 11:13 AM, Dmitry Ivanov wrote: > We (PostgresPro) have been working on pg_pathman for quite a while, and > since it's obviously going to become the thing of the past, it would be a > wasted effort if we didn't try to participate. > > For starters,

Re: [HACKERS] Patch to implement pg_current_logfile() function

On Wed, Dec 7, 2016 at 11:02 PM, Karl O. Pinc wrote: > I read this and knew that I hadn't finished review, but didn't > immediately respond because I thought the patch had to be > marked "ready for committer" on commitfest.postgresql.org > before the committers would spend a lot of

Re: [HACKERS] Declarative partitioning - another take

Hi everyone, Of course, this is the beginning, not the end. I've been thinking about next steps -- here's an expanded list: - more efficient plan-time partition pruning (constraint exclusion is too slow) - run-time partition pruning - try to reduce lock levels ... We (PostgresPro) have

Re: [HACKERS] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

It make sense. I would like to share more comments as following i.e. static int > bf_check_supported_key_len(void) > { > ... > /* encrypt with 448bits key and verify output */ > evp_ctx = EVP_CIPHER_CTX_new(); > if (!evp_ctx) > return 1; > if

Re: [HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code

On 8 December 2016 at 15:54, Aleksander Alekseev wrote: > Hi. > > I noticed that there is a lot of repeating code like this: > > ``` > if (strspn(str, " \t\n\r\f") == strlen(str)) > ``` > > I personally don't find it particularly readable, not mentioning that >

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

On 12/08/2016 05:51 PM, Christoph Berg wrote: Re: Heikki Linnakangas 2016-10-17 <07ebd878-ff09-72d5-7df7-f7fde7b83...@iki.fi> Committed this patch now. Hi, I've just taken up work again on PG 10 on Debian unstable. With openssl 1.1.0c-2, pgcrypto errors out with: Yeah, sorry about that.

[HACKERS] [PATCH] Refactor "if(strspn(str, ...) == strlen(str)" code

Hi. I noticed that there is a lot of repeating code like this: ``` if (strspn(str, " \t\n\r\f") == strlen(str)) ``` I personally don't find it particularly readable, not mentioning that traversing a string twice doesn't look as a good idea (you can check using objdump that latest GCC 6.2

Re: [HACKERS] Use EVP API pgcrypto encryption, dropping support for OpenSSL 0.9.6 and older

Re: Heikki Linnakangas 2016-10-17 <07ebd878-ff09-72d5-7df7-f7fde7b83...@iki.fi> > Committed this patch now. Hi, I've just taken up work again on PG 10 on Debian unstable. With openssl 1.1.0c-2, pgcrypto errors out with: gcc -Wall -Wmissing-prototypes -Wpointer-arith

Re: [HACKERS] Declarative partitioning - another take

On Wed, Dec 7, 2016 at 11:42 PM, Michael Paquier wrote: >> Congrats to everyone working on this! This is a large step forward. > > Congratulations to all! It was a long way to this result. Yes. The last effort in this area which I can remember was by Itagaki Takahiro

Re: [HACKERS] pg_dump vs. TRANSFORMs

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> I have a vague feeling that the code for dumping casts and/or transforms > >> may have some assumptions that the underlying function is also being > >> dumped.

Re: [HACKERS] pg_dump vs. TRANSFORMs

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I have a vague feeling that the code for dumping casts and/or transforms >> may have some assumptions that the underlying function is also being >> dumped. Although maybe the assumption was really only what's

Re: [HACKERS] pg_dump vs. TRANSFORMs

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > As pointed out by Peter E, this also impacts CASTs. Attached is a patch > > which addresses both by simply also pulling any functions which are > > referenced from pg_cast or pg_transform when they have OIDs

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

2016-12-08 14:03 GMT+01:00 Alvaro Herrera : > Tom Lane wrote: > > Alvaro Herrera writes: > > > Tom Lane wrote: > > >> In HEAD, we could change the RTE data structure so that > > >> transformValuesClause could save the typmod information in the

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On 12/7/16 9:28 PM, Alex Hunsaker wrote: > Hrm, the following incantation seems to break for me on a fresh Fedora > 25 system: > 1) As root su to $USER and start postgres. > 2) ssh in as $USER and then logout > 3) # psql localhost > > FATAL: semctl(4980742, 3, SETVAL, 0) failed: Invalid argument

Re: [HACKERS] Declarative partitioning - another take

Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > Hmm, I had mixed feeling about what to do about that as well. So now, we > have the description of various new features buried into VI. Reference > section of the documentation, which is simply meant as a command > reference. I agree

Re: [HACKERS] Back-patch use of unnamed POSIX semaphores for Linux?

On 12/7/16 9:38 AM, Tom Lane wrote: >> Even with that change, dynamic shared memory is still vulnerable to be >> removed. > Really? I thought we concluded that it is safe because it is detectably > attached to running processes. The DSM implementation uses POSIX shared memory, which doesn't have

[HACKERS] PgConf.Russia 2017 Call for Papers

Hi! We are now accepting talk proposals for PgConf.Russia 2017. The Russian PostgreSQL conference will take place on 15-17 March 2017 in Moscow, at the Digital October venue, same as for PgConf.Russia 2015. The audience include a wide range of application and system developers, database

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Thu, Dec 8, 2016 at 5:55 PM, Heikki Linnakangas wrote: > On 12/08/2016 10:18 AM, Michael Paquier wrote: >> Hmmm. How do we handle the case where the user name does not match >> then? The spec gives an error message e= specifically for this case. > > Hmm, interesting. I wonder

Re: [HACKERS] Typmod associated with multi-row VALUES constructs

Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> In HEAD, we could change the RTE data structure so that > >> transformValuesClause could save the typmod information in the RTE, > >> keeping the lookups cheap. > > > Hmm, I think this would be useful for

Re: [HACKERS] varlena beyond 1GB and matrix

2016-12-08 16:11 GMT+09:00 Craig Ringer : > On 8 December 2016 at 12:01, Kohei KaiGai wrote: > >>> At a higher level, I don't understand exactly where such giant >>> ExpandedObjects would come from. (As you point out, there's certainly >>> no easy way

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/12/07 20:23, Etsuro Fujita wrote: On 2016/12/07 15:39, Ashutosh Bapat wrote: On 2016/11/22 18:28, Ashutosh Bapat wrote: I guess, the reason why you are doing it this way, is SELECT clause for the outermost query gets deparsed before FROM clause. For later we call

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/12/07 21:11, Ashutosh Bapat wrote: On Wed, Dec 7, 2016 at 4:51 PM, Etsuro Fujita wrote: On 2016/12/05 20:20, Ashutosh Bapat wrote: 3. Why is foreignrel variable changed to rel? -extern void deparseSelectStmtForRel(StringInfo buf, PlannerInfo *root, -

Re: [HACKERS] Major service downtime expected

On Thu, Dec 8, 2016 at 9:49 AM, Magnus Hagander wrote: > Hi! > > (Copying this one to -hackers as well, for git coverage) > > We were just notified by one of our hosting providers, MeetMe, that they > are about to start physically moving two of our servers to a different >

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Dec 8, 2016 at 4:39 PM, Michael Paquier wrote: > On Thu, Dec 8, 2016 at 9:07 AM, Robert Haas wrote: >> You could do that, but first I would code up the simplest, cleanest >> algorithm you can think of and see if it even shows up in a

Re: [HACKERS] Declarative partitioning - another take

On 2016/12/08 3:20, Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote: >>> My bad. The fix I sent last night for one of the cache flush issues >>> wasn't quite right. The attached seems to fix it. >> Yes, fixed here too. Thanks. > > Thanks for the report

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 12/08/2016 10:18 AM, Michael Paquier wrote: On Thu, Dec 8, 2016 at 5:54 AM, Heikki Linnakangas wrote: Attached those here, as add-on patches to your latest patch set. Thanks for looking at it! I'll continue reviewing, but a couple of things caught my eye that you may

[HACKERS] Effect of caching hash bucket size while costing

Dear PostgreSQL Hackers, I am working in PostgreSQL 9.4.* optimizer module. In costsize.c file and final_cost_hashjoin() function, the innerbucketsize is either: a) calculated using a cached copy OR b) calculated afresh using statistics

[HACKERS] Major service downtime expected

Hi! (Copying this one to -hackers as well, for git coverage) We were just notified by one of our hosting providers, MeetMe, that they are about to start physically moving two of our servers to a different datacenter. Unfortunately, we were only given about an hours warning on this, so we have

Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Wed, Dec 07, 2016 at 03:16:09PM +0530, Ashutosh Sharma wrote: > Problem Analysis: > - > Allthough i am very new to Windows, i tried debugging the issue and > could find that Backend is not receiving the query executed after > "SELECT pldbg_attach_to_port(2)" and is

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Thu, Dec 8, 2016 at 5:54 AM, Heikki Linnakangas wrote: > Attached those here, as add-on patches to your latest patch set. Thanks for looking at it! > I'll continue reviewing, but a couple of things caught my eye that you may > want > to jump on, in the meanwhile: > > On