Re: [HACKERS] UPDATE of partition key

On Fri, Jun 2, 2017 at 4:37 PM, Amit Khandekar wrote: > On 2 June 2017 at 01:17, Robert Haas wrote: >> On Thu, Jun 1, 2017 at 7:41 AM, Amit Khandekar >> wrote: Regarding the trigger issue, I can't claim to have a

Re: [HACKERS] proposal psql \gdesc

Hi 2017-06-04 10:47 GMT+02:00 Fabien COELHO : > > Hello Brent, > > Regarding the error message earlier >> > > 'No columns or command has no result', >> > > it might be clearer with the slightly longer >> > > 'The result has no columns or the command has no result'. >> > > I

Re: [HACKERS] BEFORE trigger can cause undetected partition constraint violation

On 2017/06/03 1:56, Robert Haas wrote: > On Fri, Jun 2, 2017 at 12:51 AM, Amit Langote > wrote: >> Attached patch makes InitResultRelInfo() *always* initialize the >> partition's constraint, that is, regardless of whether insert/copy is >> through the parent or

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

Hi Michael, >You should add that to the next commit fest: >https://commitfest.postgresql.org/14/ Thanks your mention. I will do that. Regards, Jing Wang Fujitsu Australia

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

Amit Kapila writes: > On Mon, Jun 5, 2017 at 4:00 AM, Tom Lane wrote: >> I took a quick look at this, and it seems rather beside the point. > What I understood from the randomization shm allocation behavior due > to ASLR is that when we try to

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

On Mon, Jun 5, 2017 at 4:00 AM, Tom Lane wrote: > Amit Kapila writes: >> Okay, I have added the comment to explain the same. I have also >> modified the patch to adjust the looping as per your suggestion. > > I took a quick look at this, and it seems

[HACKERS] Fix a typo in README.dependencies

Hi, I found below formula to compute selectivities, but I think the last Probability 'P(b=?)' should be 'P(c=?)'. P(a=?,b=?,c=?) = P(a=?,b=?) * (d + (1-d)*P(b=?)) Attached patch fixes it, and it also adds some spaces following another formula which is on line 86 and computes P(a=?, b=?).

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

On 03/06/17 16:12, Jeff Janes wrote: > > On Fri, Jun 2, 2017 at 4:10 PM, Petr Jelinek > > wrote: > > > While I was testing something for different thread I noticed that I > manage transactions incorrectly in this patch.

Re: [HACKERS] sketchy partcollation handling

On 2017/06/03 1:31, Robert Haas wrote: > If you create a partitioned table in the obvious way, partcollation ends up 0: > > rhaas=# create table foo (a int, b text) partition by list (a); > CREATE TABLE > rhaas=# select * from pg_partitioned_table; > partrelid | partstrat | partnatts | partattrs

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

On 05/06/17 13:08, Mark Kirkwood wrote: On 05/06/17 00:04, Erik Rijkers wrote: On 2017-05-31 16:20, Erik Rijkers wrote: 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.

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

Hi, On 2017-06-05 10:31:12 +0900, Michael Paquier wrote: > On Mon, Jun 5, 2017 at 10:29 AM, Andres Freund wrote: > > Michael, Peter, Fujii, is either of you planning to review this? I'm > > planning to commit this tomorrow morning PST, unless somebody protest > > till then. >

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On Mon, Jun 5, 2017 at 10:29 AM, Andres Freund wrote: > Michael, Peter, Fujii, is either of you planning to review this? I'm > planning to commit this tomorrow morning PST, unless somebody protest > till then. Yes, I am. It would be nice if you could let me 24 hours to look

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

On Mon, Jun 5, 2017 at 10:09 AM, Jing Wang wrote: > By using the patch the CURRENT_DATABASE as a keyword can be used in the > following SQL commands: > > 1. COMMENT ON DATABASE CURRENT_DATABASE is ... > 2. ALTER DATABASE CURRENT_DATABASE OWNER to ... > 3. ALTER

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On 2017-06-02 17:20:23 -0700, Andres Freund wrote: > Attached is a *preliminary* patch series implementing this. I've first > reverted the previous patch, as otherwise backpatchable versions of the > necessary patches would get too complicated, due to the signals used and > such. I went again

[HACKERS] Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog

On Mon, Jun 5, 2017 at 7:24 AM, Noah Misch wrote: > [Action required within three days. This is a generic notification.] > > The above-described topic is currently a PostgreSQL 10 open item. Simon, > since you committed the patch believed to have created it, you own this open

[HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

Hi all, The attached patch is to support the feature "COMMENT ON DATABASE CURRENT_DATABASE". The solution is based on the previous discussion in [2] . Can't find the previous link in my email history list so create a new topic here. By using the patch the CURRENT_DATABASE as a keyword can be

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

On 05/06/17 00:04, Erik Rijkers wrote: On 2017-05-31 16:20, Erik Rijkers wrote: 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]

Re: [HACKERS] Should we standardize on a type for signal handler flags?

Andres Freund writes: > On 2017-06-04 19:14:06 -0400, Tom Lane wrote: >> sig_atomic_t is more standards-conforming, I should think. I'm not sure >> if there are any current platforms where a store to a char variable >> wouldn't be atomic, but why live dangerously? > Well, we

Re: [HACKERS] Should we standardize on a type for signal handler flags?

On 2017-06-04 19:14:06 -0400, Tom Lane wrote: > Andres Freund writes: > > At the moment a number of flag variables set in signal handlers have > > 'volatile bool' as type, others have 'volatile sig_atomic_t'. That's > > kinda confusing. I think either is safe, but I think

Re: [HACKERS] Should we standardize on a type for signal handler flags?

Andres Freund writes: > At the moment a number of flag variables set in signal handlers have > 'volatile bool' as type, others have 'volatile sig_atomic_t'. That's > kinda confusing. I think either is safe, but I think we should > standardize one of them. sig_atomic_t is

Re: [HACKERS] Should we standardize on a type for signal handler flags?

On Mon, Jun 5, 2017 at 8:00 AM, Andres Freund wrote: > At the moment a number of flag variables set in signal handlers have > 'volatile bool' as type, others have 'volatile sig_atomic_t'. That's > kinda confusing. I think either is safe, but I think we should > standardize

[HACKERS] Should we standardize on a type for signal handler flags?

Hi, At the moment a number of flag variables set in signal handlers have 'volatile bool' as type, others have 'volatile sig_atomic_t'. That's kinda confusing. I think either is safe, but I think we should standardize one of them. Opinions? - Andres -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Server ignores contents of SASLInitialResponse

On Fri, Jun 02, 2017 at 09:58:40PM -0700, Noah Misch wrote: > On Tue, May 30, 2017 at 03:04:47AM +, Noah Misch wrote: > > On Thu, May 25, 2017 at 10:52:23AM -0400, Michael Paquier wrote: > > > On Thu, May 25, 2017 at 9:32 AM, Michael Paquier > > > wrote: > > > > On

[HACKERS] Re: Error while creating subscription when server is running in single user mode

On Fri, Jun 02, 2017 at 11:06:52PM -0400, Peter Eisentraut wrote: > On 6/2/17 15:41, Tom Lane wrote: > > It's certainly plausible that we could have the latch code just ignore > > WL_POSTMASTER_DEATH if not IsUnderPostmaster. I think that the original > > reasoning for not doing that was that the

Re: [HACKERS] BUG #14682: row level security not work with partitioned table

On Fri, Jun 02, 2017 at 09:28:16AM +0900, Michael Paquier wrote: > On Thu, Jun 1, 2017 at 11:13 AM, Mike Palmiotto > wrote: > > This is indeed a bug. fireRIRrules is currently skipping the RLS > > policy check when relkind == PARTITIONED_TABLES, so RLS policies are

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

Amit Kapila writes: > Okay, I have added the comment to explain the same. I have also > modified the patch to adjust the looping as per your suggestion. I took a quick look at this, and it seems rather beside the point. You can't just loop inside an already-forked

[HACKERS] Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog

On Thu, Jun 01, 2017 at 01:07:53AM -0700, Michael Paquier wrote: > On Wed, May 31, 2017 at 12:30 PM, Michael Paquier > wrote: > > On Wed, May 31, 2017 at 6:57 AM, Tom Lane wrote: > >> wangchuant...@huawei.com writes: > >>> startup process on standby

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 4, 2017, at 2:19 PM, Andres Freund wrote: > > On 2017-06-04 14:16:14 -0700, Mark Dilger wrote: >> Sorry, I was not clear. What I meant to get at was that if you remove from >> the >> executor all support for SRFs inside case statements, you might foreclose >> the

[HACKERS] Make ANALYZE more selective about what is a "most common value"?

I've been thinking about the behavior discussed in https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org and it seems to me that there are a couple of things we ought to do about it. First, I think we need a larger hard floor on the number of occurrences

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

On 2017-06-04 14:16:14 -0700, Mark Dilger wrote: > Sorry, I was not clear. What I meant to get at was that if you remove from > the > executor all support for SRFs inside case statements, you might foreclose the > option > of extending the syntax at some later date to allow aggregates over >

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 4, 2017, at 12:35 PM, Andres Freund wrote: > > Hi Mark, > > On 2017-06-04 11:55:03 -0700, Mark Dilger wrote: >>> Yea, I'm not a big fan of the either the pre v10 or the v10 behaviour of >>> SRFs inside coalesce/case. Neither is really resonable imo - I'm not >>>

Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check

On Tue, Apr 18, 2017 at 09:59:26PM +0900, Michael Paquier wrote: > On Tue, Apr 18, 2017 at 9:35 PM, Andrew Dunstan > wrote: > > On 04/18/2017 08:23 AM, Michael Paquier wrote: > >> Increasing wal_sender_timeout and wal_receiver_timeout can help in > >> reducing the

Re: [HACKERS] Default Partition for Range

Hello, On Sun, Jun 4, 2017 at 9:26 AM, Rafia Sabih wrote: > On Fri, Jun 2, 2017 at 5:48 PM, Robert Haas wrote: >> On Fri, Jun 2, 2017 at 8:09 AM, Amit Kapila wrote: >>> I think if you have found spelling mistakes

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

Hi Mark, On 2017-06-04 11:55:03 -0700, Mark Dilger wrote: > > Yea, I'm not a big fan of the either the pre v10 or the v10 behaviour of > > SRFs inside coalesce/case. Neither is really resonable imo - I'm not > > sure a reasonable behaviour even exists. IIRC I'd argued in the > > original SRF

Re: [HACKERS] pg_upgrade and missing loadable libraries

On Sun, Jun 4, 2017 at 02:30:58PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I didn't want to optimize for it --- I wanted a way to detect when DROP > > EXTENSION has no hope of working, and give more details. I assume the > > problem with that is the the object names

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 4, 2017, at 11:55 AM, Mark Dilger wrote: > > SELECT x, CASE WHEN y THEN SUM(generate_series(1,z)) ELSE 5 END > FROM table_with_columns_x_and_y; Sorry, this table is supposed to be the same as the previous one, table_with_columns_x_and_y_and_z --

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 2, 2017, at 8:11 PM, Andres Freund wrote: > > Hi, > > > On 2017-06-02 22:53:00 -0400, Tom Lane wrote: >> I think you've got enough on your plate. I can take care of whatever >> we decide to do here. > > Thanks. > > >> Andres Freund writes:

Re: [HACKERS] Adding support for Default partition in partitioning

On Mon, Jun 5, 2017 at 12:14 AM, Jeevan Ladhe wrote: > > >> >> What is the reason the new patch does not mention of violating rows >> when a new partition overlaps with default? >> Is it because more than one row could be violating the condition? > > > This is

Re: [HACKERS] Adding support for Default partition in partitioning

> What is the reason the new patch does not mention of violating rows > when a new partition overlaps with default? > Is it because more than one row could be violating the condition? > This is because, for reporting the violating error, I had to function ExecBuildSlotValueDescription() public.

Re: [HACKERS] Adding support for Default partition in partitioning

Hello, On Fri, Jun 2, 2017 at 1:05 AM, Jeevan Ladhe wrote: > Hi, > > I have addressed Ashutosh's and Amit's comments in the attached patch. > > Please let me know if I have missed anything and any further comments. > > PFA. > > Regards, > Jeevan Ladhe > What is

Re: [HACKERS] pg_upgrade and missing loadable libraries

Bruce Momjian writes: > I didn't want to optimize for it --- I wanted a way to detect when DROP > EXTENSION has no hope of working, and give more details. I assume the > problem with that is the the object names are inside SQL scripts that > cannot be easily interrogated. Are

Re: [HACKERS] pg_upgrade and missing loadable libraries

On Sun, Jun 4, 2017 at 02:04:37PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > The problem is that in some cases extensions are improperly removed or > > the extension has bugs that leaves pg_proc entries around that aren't > > dumped, but are seen by pg_upgrade and

Re: [HACKERS] pg_upgrade and missing loadable libraries

Bruce Momjian writes: > The problem is that in some cases extensions are improperly removed or > the extension has bugs that leaves pg_proc entries around that aren't > dumped, but are seen by pg_upgrade and generate an error. In these > cases, and I have seen a few recently,

Re: [HACKERS] pg_upgrade and missing loadable libraries

On Sun, Jun 4, 2017 at 01:55:01PM -0400, Tom Lane wrote: > > * should we print all the pg_proc.pronames that are involved, not just > > the unique library names > > * should we output a query helping people find the pg_proc entries > > > I think there are many cases where DROP EXTENSION XXX

Re: [HACKERS] pg_upgrade and missing loadable libraries

Bruce Momjian writes: > On Sun, Jun 4, 2017 at 01:20:12PM -0400, Alvaro Herrera wrote: >> I think it'd be better to be exhaustive about the report, i.e. report >> all problems in all databases, if possible. Doing repeated pg_upgrade >> attempts until you've nailed all the

Re: [HACKERS] pg_upgrade and missing loadable libraries

On Sun, Jun 4, 2017 at 01:20:12PM -0400, Alvaro Herrera wrote: > Bruce Momjian wrote: > > I have seen a few reports where people are getting this pg_upgrade > > error: > > > > Your installation references loadable libraries that are missing > > from the new installation. You can add

Re: [HACKERS] pg_upgrade and missing loadable libraries

Bruce Momjian wrote: > I have seen a few reports where people are getting this pg_upgrade > error: > > Your installation references loadable libraries that are missing > from the new installation. You can add these libraries to the > new installation, or remove the functions

Re: [HACKERS] pg_upgrade and missing loadable libraries

On 2017-06-04 13:06:25 -0400, Bruce Momjian wrote: > This seems to be one of the last pg_upgrade problems Famous last words. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] pg_upgrade and missing loadable libraries

I have seen a few reports where people are getting this pg_upgrade error: Your installation references loadable libraries that are missing from the new installation. You can add these libraries to the new installation, or remove the functions using them from the

Re: [HACKERS] Index created in BEFORE trigger not updated during INSERT

Michael Paquier writes: > The patch looks good to me, could you add a regression test? Done, thanks for the review. I stuck the test into triggers.sql, which is not completely on point since there are other ways to get to this error. But if we're thinking of it as a

Re: [HACKERS] Fix performance of generic atomics

Good day, every one. I'm just posting benchmark numbers for atomics patch. Hardware: 4 socket 72 core (144HT) x86_64 Centos 7.1 postgresql.conf tuning: shared_buffers = 32GB fsync = on synchronous_commit = on full_page_writes = off wal_buffers = 16MB wal_writer_flush_after = 16MB commit_delay =

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Robert, Thanks for your comments: > If DETACH PARTITION and DROP PARTITION require this, why not ATTACH > PARTITION and CREATE TABLE .. PARTITION OF? > > For CREATE and ATTACH parition the invalidation of default relation is taken care by the following clean-up part in

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

On 2017-05-31 16:20, Erik Rijkers wrote: 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: --

Re: [HACKERS] proposal psql \gdesc

Hello Brent, Regarding the error message earlier 'No columns or command has no result', it might be clearer with the slightly longer 'The result has no columns or the command has no result'. I agree that a better phrasing may be possible. I'm hesitating about this one because word

Re: [HACKERS] proposal psql \gdesc

Regarding the error message earlier 'No columns or command has no result', it might be clearer with the slightly longer 'The result has no columns or the command has no result'. I didn't read the patch though, just the email so that might not make sense in context. Brent On Sun, Jun 4, 2017 at

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Wed, May 31, 2017 at 10:18 PM, Robert Haas wrote: > + *contrib/autoprewarm.c > > Wrong. -- Oops Sorry fixed. > +Oiddatabase;/* database */ > +Oidspcnode;/* tablespace */ > +Oidfilenode;/*

Re: [HACKERS] proposal psql \gdesc

ok - look on new version, please The patch needs a rebase after Tom's reindentation of tab-complete. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers