Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Thu, Feb 2, 2017 at 6:14 PM, Amit Kapila wrote: > > /* > + * If the index list was invalidated, we better also invalidate the index > + * attribute list (which should automatically invalidate other attributes > + * such as primary key and replica identity) > + */ >

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 12:57 AM, Fabien COELHO wrote: > > Hello Corey, > > Glad you like the barking. I'm happy to let the prompt issue rest for now, >> we can always add it later. >> >> If we DID want it, however, I don't think it'll be hard to add a special >> prompt

Re: [HACKERS] Packages: Again

2017-02-03 7:34 GMT+01:00 Craig Ringer : > On 3 February 2017 at 14:27, Pavel Stehule > wrote: > > > > > > 2017-01-20 17:01 GMT+01:00 Joshua D. Drake : > >> > >> On 01/17/2017 09:26 AM, Robert Haas wrote: > >>> > >>> On Fri,

Re: [HACKERS] proposal: session server side variables

2017-02-03 7:25 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > The @1 area is partially solved by psql session variables or by pgAdmin >> scripting functionality. @2 is partially solved by GUC but without >> possibility to set a access rights. >> >> I didn't found any

Re: [HACKERS] Packages: Again

On 3 February 2017 at 14:27, Pavel Stehule wrote: > > > 2017-01-20 17:01 GMT+01:00 Joshua D. Drake : >> >> On 01/17/2017 09:26 AM, Robert Haas wrote: >>> >>> On Fri, Jan 13, 2017 at 7:24 PM, Peter Geoghegan wrote: MERGE

Re: [HACKERS] Packages: Again

2017-01-20 17:01 GMT+01:00 Joshua D. Drake : > On 01/17/2017 09:26 AM, Robert Haas wrote: > >> On Fri, Jan 13, 2017 at 7:24 PM, Peter Geoghegan wrote: >> >>> MERGE isn't UPSERT, and isn't even in competition with UPSERT as a >>> feature. I've written

Re: [HACKERS] proposal: session server side variables

Hello Pavel, The @1 area is partially solved by psql session variables or by pgAdmin scripting functionality. @2 is partially solved by GUC but without possibility to set a access rights. I didn't found any implementation of XA variables [...] I did: GUCs in PostgreSQL are an implementation

Re: [HACKERS] proposal: session server side variables

On Fri, Feb 3, 2017 at 2:56 PM, Pavel Stehule wrote: > My patch was marked as "returned with feedback". Personally, I had not a > idea what can be next step and what is preferred design, if some preferred > design exists. I don't know what I have to change on my

Re: [HACKERS] proposal: session server side variables

There is a link - comparation Oracle package variables and DB2 global variables https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/ Regards Pavel

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello Corey, Glad you like the barking. I'm happy to let the prompt issue rest for now, we can always add it later. If we DID want it, however, I don't think it'll be hard to add a special prompt (Thinking %T or %Y because they both look like branches, heh), Ah!:-) T may stand for Tree, but

Re: [HACKERS] proposal: session server side variables

2017-02-01 6:42 GMT+01:00 Pavel Stehule : > > > 2017-02-01 6:05 GMT+01:00 Michael Paquier : > >> On Wed, Jan 11, 2017 at 10:42 PM, Craig Ringer >> wrote: >> > There is no code yet. Code review and testing is where things

Re: [HACKERS] Logical Replication and Character encoding

On 3 Feb. 2017 15:47, "Kyotaro HORIGUCHI" wrote: Hello, At Fri, 3 Feb 2017 09:16:47 +0800, Craig Ringer wrote in > On 2 February 2017 at 11:45, Euler Taveira

Re: [HACKERS] Radix tree for character conversion

Tnanks to that Heikki have pushed the first two patches and a part of the third, only one patch is remaining now. # Sorry for not separating KOI8 stuffs. At Tue, 31 Jan 2017 19:06:09 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in

Re: [HACKERS] pageinspect: Hash index support

>> I think it's OK to check hash_bitmap_info() or any other functions >> with different page types at least once. >> >> [1]- >> https://www.postgresql.org/message-id/CA%2BTgmoZUjrVy52TUU3b_Q5L6jcrt7w5R4qFwMXdeCuKQBmYWqQ%40mail.gmail.com > > Sure, I just don't know if we need to test them 4 or 5

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

At Thu, 2 Feb 2017 15:34:33 +0900, Michael Paquier wrote in > On Thu, Feb 2, 2017 at 1:26 AM, Fujii Masao wrote: > > I'm afraid that many WAL segments would start with a

Re: [HACKERS] Logical Replication and Character encoding

Hello, At Fri, 3 Feb 2017 09:16:47 +0800, Craig Ringer wrote in > On 2 February 2017 at 11:45, Euler Taveira wrote: > > > I don't think storage without conversion is an acceptable

Re: [HACKERS] Declarative partitioning - another take

On 2017/01/31 6:42, Peter Eisentraut wrote: > On 1/25/17 12:54 AM, Ashutosh Bapat wrote: >> The documentation available at >> https://www.postgresql.org/docs/devel/static/sql-createtable.html, >> does not make it clear that the lower bound of a range partition is >> always inclusive and the higher

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > > On reflection, it seems fairly improbable to me that people would use > \if and friends interactively. They're certainly useful for scripting, > but would you really type commands that you know are going to be ignored? > I'm thinking the one use-case is where a person is debugging a

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao wrote in

Re: [HACKERS] Constraint exclusion failed to prune partition in case of partition expression involves function call

On 2017/02/02 21:09, amul sul wrote: > Hi, > > In following case, constraint exclusion not able prune partition (even > if function is immutable), is this know behaviour? Yes. The where condition in your example query does not specify the partition key column, so constraint exclusion won't

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker writes: >> As it is, I've added interactive mode psql_error notifications about the >> resulting branching state of any branching commands, and any attempt to >> send non-branching commands or queries while in an inactive branch will >> generate a psql_error

Re: [HACKERS] Logical Replication and Character encoding

On 2 February 2017 at 11:45, Euler Taveira wrote: > I don't think storage without conversion is an acceptable approach. We > should provide options to users such as ignore tuple or NULL for > column(s) with conversion problem. I wouldn't consider storage data > without

Re: [HACKERS] pageinspect: Hash index support

On Fri, Feb 3, 2017 at 4:28 AM, Jesper Pedersen wrote: > On 02/02/2017 02:24 PM, Robert Haas wrote: >> >> So, committed. Wow, I wish every patch had this many reviewers. >> > > Thanks Robert ! 9 people in total per the commit message. Yes that's rare, and thanks for

Re: [HACKERS] Deadlock in XLogInsert at AIX

On Wed, Feb 01, 2017 at 02:39:25PM +0200, Heikki Linnakangas wrote: > On 02/01/2017 01:07 PM, Konstantin Knizhnik wrote: > >Attached please find my patch for XLC/AIX. > >The most critical fix is adding __sync to pg_atomic_fetch_add_u32_impl. > >The comment in this file says that: > > > > *

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

On 3 February 2017 at 03:34, Robert Haas wrote: > On Wed, Feb 1, 2017 at 4:35 PM, Craig Ringer wrote: >> Right. Per my comments uothread I don't see why we need to add anything more >> to WAL here. >> >> Stas was concerned about what happens in

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Fri, Feb 3, 2017 at 8:50 AM, Daniel Verite wrote: > What if we look at the change from the pessimistic angle? > An example of confusion that the change would create: > a lot of users currently choose pg_wal for the destination > directory of their archive command.

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Peter Eisentraut wrote: > You really have (at least) three options here: > > 1. Rename nothing > 2. Rename directory only > 3. Rename everything I vote for 1) as I believe the renaming will create more confusion than it's worth, not even considering the renaming of functions and views.

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > > All, > As it is, I've added interactive mode psql_error notifications about the > resulting branching state of any branching commands, and any attempt to > send non-branching commands or queries while in an inactive branch will > generate a psql_error saying that the command was ignored.

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Wed, Feb 1, 2017 at 4:58 PM, Jim Nasby wrote: > I think the issue here is that the original case for this is a user > accidentally getting into an \if and then having no clue what's going on. > That's similar to what happens when you miss a quote or a semicolon. We >

Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)

On 2017-02-02 22:44, Tom Lane wrote: Erik Rijkers writes: Something is broken in HEAD: Fixed, thanks for the report! Indeed, the complicated version of the script runs again as before. Thank you very much, Erik Rijkers -- Sent via pgsql-hackers mailing list

Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)

Erik Rijkers writes: > Something is broken in HEAD: Fixed, thanks for the report! regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] possible self-deadlock window after bad ProcessStartupPacket

Hello, There may possibly be a very small window for a double exit() self-deadlock during a forked backend process's ProcessStartupPacket returns and status is not STATUS_OK. The process will go into proc_exit and then a very well timed SIGQUIT will call startup_die for another proc_exit. If

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On 2 February 2017 at 18:48, Peter Eisentraut wrote: > On 2/2/17 8:32 AM, Simon Riggs wrote: >> I think we should remove the "replication" false database concept in >> pg_hba.conf altogether and allow any valid pg_hba rule to invoke a >> replication connection,

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2017-02-02 14:47:53 -0500, Robert Haas wrote: > I expect that increasing the maximum value of shared_buffers beyond > what can be stored by an integer could have a noticeable distributed > performance cost for the entire system. It might be a pretty small > cost, but then again maybe not; for

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2017-02-02 11:41:44 -0800, Jim Nasby wrote: > On 2/1/17 4:28 PM, Andres Freund wrote: > > On 2016-11-28 11:40:53 -0800, Jim Nasby wrote: > > > With current limits, the most bgwriter can do (with 8k pages) is 1000 > > > pages > > > * 100 times/sec = 780MB/s. It's not hard to exceed that with

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On Wed, Feb 1, 2017 at 9:47 PM, Jim Nasby wrote: > Before doing that the first thing to look at would be why the limit is > currently INT_MAX / 2 instead of INT_MAX. Generally the rationale for GUCs with limits of that sort is that there is or might be code someplace

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2/1/17 4:28 PM, Andres Freund wrote: On 2016-11-28 11:40:53 -0800, Jim Nasby wrote: With current limits, the most bgwriter can do (with 8k pages) is 1000 pages * 100 times/sec = 780MB/s. It's not hard to exceed that with modern hardware. Should we increase the limit on bgwriter_lru_maxpages?

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

On Wed, Feb 1, 2017 at 4:35 PM, Craig Ringer wrote: > Right. Per my comments uothread I don't see why we need to add anything more > to WAL here. > > Stas was concerned about what happens in logical decoding if we crash > between PREPSRE TRANSACTION and COMMIT PREPARED. But

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

On Wed, Feb 1, 2017 at 2:32 PM, Tom Lane wrote: > Robert Haas writes: >> Also, including the GID in the WAL for each COMMIT/ABORT PREPARED >> doesn't seem inordinately expensive to me. > > I'm confused ... isn't it there already? If not, how do we

Re: [HACKERS] pageinspect: Hash index support

On 02/02/2017 02:24 PM, Robert Haas wrote: So, committed. Wow, I wish every patch had this many reviewers. Thanks Robert ! Best regards, Jesper -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] pageinspect: Hash index support

On Thu, Feb 2, 2017 at 6:29 AM, Ashutosh Sharma wrote: >> >> + ptr = (char *) itup + IndexInfoFindDataOffset(itup->t_info); >> + Assert(ptr <= uargs->page + BLCKSZ); >> >> I think this should be promoted to an ereport(); these functions can >>

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On 2/2/17 12:48 AM, Michael Paquier wrote: > +#define Query_for_list_of_subscriptions \ > +" SELECT pg_catalog.quote_ident(subname) "\ > +" FROM pg_catalog.pg_subscription "\ > +" WHERE substring(pg_catalog.quote_ident(subname),1,%d)='%s'" This query should also be qualified by current

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On 2/2/17 12:48 PM, Fujii Masao wrote: > +#define Query_for_list_of_subscriptions \ > +" SELECT pg_catalog.quote_ident(subname) "\ > +" FROM pg_catalog.pg_subscription "\ > +" WHERE substring(pg_catalog.quote_ident(subname),1,%d)='%s'" > > Since non-superuser is not allowed to access to

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On 2/2/17 8:32 AM, Simon Riggs wrote: > I think we should remove the "replication" false database concept in > pg_hba.conf altogether and allow any valid pg_hba rule to invoke a > replication connection, if one is requested. Roles would still need > the REPLICATION capability before this would be

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Feb 02, 2017 at 12:14:10PM -0500, Tom Lane wrote: > Also, somebody who wants a check like that isn't necessarily going to want > "no WHERE clause" training wheels. So you're going to need to think about > facilities to enable or disable different checks. WHERE-less-ness should be

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Thu, Feb 2, 2017 at 2:48 PM, Michael Paquier wrote: > Hi all, > > While testing a bit the logical replication facility, I have bumped on > the fast that psql's completion does not show the list of things > already created. Attached is a patch. +#define

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Feb 02, 2017 at 12:14:10PM -0500, Tom Lane wrote: > Alvaro Herrera writes: > > Pavel Stehule wrote: > >> Better to enhance this feature step by step. > > > Agreed -- IMO this is a reasonable first step, except that I would > > rename the proposed extension so

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

Alvaro Herrera writes: > Pavel Stehule wrote: >> Better to enhance this feature step by step. > Agreed -- IMO this is a reasonable first step, except that I would > rename the proposed extension so that it doesn't focus solely on the > first step. Quite. The patch

Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)

Andres Freund writes: > On 2017-02-01 23:27:36 -0500, Tom Lane wrote: >> I think the appropriate fix is that, once split_pathtarget_at_srfs() has >> computed a tentative list of SRFs it needs to evaluate, it has to make a >> second pass to see if any of them match expressions

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Pavan Deolasee wrote: > I can reproduce this entire scenario using gdb sessions. This also explains > why the patch I sent earlier helps to solve the problem. Ouch. Great detective work there. I think it's quite possible that this bug explains some index errors, such as primary keys (or unique

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

Pavel Stehule wrote: > Identification of unjoined tables should be very useful - but it is far to > original proposal - so it can be solved separately. > > This patch is simple - and usually we prefer more simple patches than one > bigger. > > Better to enhance this feature step by step.

Re: [HACKERS] Deadlock in XLogInsert at AIX

Hi Tony, On 02.02.2017 17:10, REIX, Tony wrote: Hi Konstantin I've discussed the "zombie/exit" issue with our expert here. - He does not think that AIX has anything special here - If the process is marked in ps, this is because the flag SEXIT is set, thus the process is blocked somewhere

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

2017-02-02 16:34 GMT+01:00 Bruce Momjian : > On Thu, Feb 2, 2017 at 07:18:45AM -0800, David Fetter wrote: > > On Thu, Feb 02, 2017 at 03:16:29PM +, Bruce Momjian wrote: > > > I just don't see this patch going in. I think it needs are larger > > > approach to the problems

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Feb 02, 2017 at 10:34:43AM -0500, Bruce Momjian wrote: > On Thu, Feb 2, 2017 at 07:18:45AM -0800, David Fetter wrote: > > On Thu, Feb 02, 2017 at 03:16:29PM +, Bruce Momjian wrote: > > > I just don't see this patch going in. I think it needs are > > > larger approach to the problems

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

On Thu, Feb 2, 2017 at 2:36 PM, Michael Paquier wrote: > On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane wrote: >> Kyotaro HORIGUCHI writes: >>> Then, the reason for the TRY-CATCH cluase is that I found that >>> some

Re: [HACKERS] Deadlock in XLogInsert at AIX

On 02.02.2017 18:20, REIX, Tony wrote: Hi Konstantin I have an issue with pgbench. Any idea ? Pgbench -s options specifies scale. Scale 1000 corresponds to 1000 million rows and requires about 16Gb at disk. # mkdir /tmp/PGS # chown pgstbf.staff /tmp/PGS # su pgstbf $

[HACKERS] Some patch triage from Brussels

The developer meeting in Brussels ran out of topics :), so we have spent some time going through the patches on the upcoming CF. We did manage to assign a couple of patches to people (and we also discussed but didn't actually assign all the patches that Robert has his hands in :P). And we found

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Feb 2, 2017 at 07:18:45AM -0800, David Fetter wrote: > On Thu, Feb 02, 2017 at 03:16:29PM +, Bruce Momjian wrote: > > I just don't see this patch going in. I think it needs are larger > > approach to the problems it is trying to solve. I think it then > > will be very useful. > >

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

I just don't see this patch going in. I think it needs are larger approach to the problems it is trying to solve. I think it then will be very useful. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Deadlock in XLogInsert at AIX

Hi Konstantin I have an issue with pgbench. Any idea ? # mkdir /tmp/PGS # chown pgstbf.staff /tmp/PGS # su pgstbf $ /opt/freeware/bin/initdb -D /tmp/PGS The files belonging to this database system will be owned by user "pgstbf". This user must also own the server prcess. The database

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Feb 02, 2017 at 03:16:29PM +, Bruce Momjian wrote: > I just don't see this patch going in. I think it needs are larger > approach to the problems it is trying to solve. I think it then > will be very useful. What problems that it's trying to solve are not addressed? Best, David. --

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Jan 30, 2017 at 7:20 PM, Pavan Deolasee wrote: > > Based on my investigation so far and the evidence that I've collected, > what probably happens is that after a relcache invalidation arrives at the > new transaction, it recomputes the rd_indexattr but based on

Re: [HACKERS] Non-deterministic behavior with floating point in parallel mode

Ruben Buchatskiy writes: > We have found that in parallel mode result of queries is non-deterministic > when the types of the attributes in table are double precision > (floating-point). Yeah ... > That is because floating-point addition is not necessarily associative. Right,

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On 02/02/17 14:32, Simon Riggs wrote: > On 23 January 2017 at 04:29, Michael Paquier > wrote: >> Hi all, >> >> As now wal_level = replica has become the default for Postgres 10, >> could we consider as well making replication connections enabled by >> default in

Re: [HACKERS] Deadlock in XLogInsert at AIX

Hi Konstantin I've discussed the "zombie/exit" issue with our expert here. - He does not think that AIX has anything special here - If the process is marked in ps, this is because the flag SEXIT is set, thus the process is blocked somewhere in the kexitx() syscall, waiting for something. -

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On 23 January 2017 at 04:29, Michael Paquier wrote: > Hi all, > > As now wal_level = replica has become the default for Postgres 10, > could we consider as well making replication connections enabled by > default in pg_hba.conf? Agreed > This requires just

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Pavan Deolasee wrote: > Do you think we should apply the patch to remove ItemPointerCopy()? I will > rework the HeapTupleHeaderGetNextTid() after that. Not that it depends on > removing ItemPointerCopy(), but decided to postpone it until we make a call > on that patch. My inclination is not to.

[HACKERS] patch: optimize information_schema.constraint_column_usage

Hello hackers, The view information_schema.constraint_column_usage becomes slow when the number of columns and constraints raise to substantial values. This is because of a join condition that allows only join filter to enforce. The patch is to optimize it. See many_constraints.sql file

[HACKERS] Non-deterministic behavior with floating point in parallel mode

Hi hackers, We have found that in parallel mode result of queries is non-deterministic when the types of the attributes in table are double precision (floating-point). Our example is based on TPC-H, but some NUMERIC columns type was changed to DOUBLE PRECISION; When running without parallelism

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On Thu, Feb 2, 2017 at 6:08 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 1/22/17 10:29 PM, Michael Paquier wrote: > > As now wal_level = replica has become the default for Postgres 10, > > could we consider as well making replication connections enabled by > > default in

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello, What do I need to do to get TAP tests running? I misunderstood. You need to configure with "--enable-tap-tests". There is a spurious empty line added at the very end of "mainloop.h": + #endif /* MAINLOOP_H */ Not in my diff, but that's been coming and going in your diff

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Mon, Jan 30, 2017 at 7:20 PM, Pavan Deolasee wrote: > Hello All, > > While stress testing WARM, I encountered a data consistency problem. It > happens when index is built concurrently. What I thought to be a WARM > induced bug and it took me significant amount of

Re: [HACKERS] What is "index returned tuples in wrong order" for recheck supposed to guard against?

I forgot to mention this.. At Thu, 02 Feb 2017 21:11:16 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170202.26.49572782.horiguchi.kyot...@lab.ntt.co.jp> > Hello, I digged this topic covered by a spiderweb.. > > # PostGIS requires so many

Re: [HACKERS] What is "index returned tuples in wrong order" for recheck supposed to guard against?

Hello, I digged this topic covered by a spiderweb.. # PostGIS requires so many libraries installed :( FIY, for the given test case, the following query hits the bug. | SELECT edge.geom AS geom | FROM (SELECT * FROM knn_recheck_geom) AS edge | ORDER BY

[HACKERS] Constraint exclusion failed to prune partition in case of partition expression involves function call

Hi, In following case, constraint exclusion not able prune partition (even if function is immutable), is this know behaviour? --CASE 1 : create table & insert data create table foo_list (a integer, b text) partition by list (abs(a)); create table foo_list1 partition of foo_list for values in

Re: [HACKERS] pageinspect: Hash index support

> > + ptr = (char *) itup + IndexInfoFindDataOffset(itup->t_info); > + Assert(ptr <= uargs->page + BLCKSZ); > > I think this should be promoted to an ereport(); these functions can > accept an arbitrary bytea. I think we had added 'ptr' variable initially just to dump

Re: [HACKERS] [PATCH] Add tab completion for DEALLOCATE

Tom Lane writes: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: >> While playing with prepared statements in psql, I noticed that EXECUTE >> tab-completes the list of active prepared statements, but DEALLOCATE >> does not. >> Attached is a patch to

Re: [HACKERS] Superowners

On 30 January 2017 at 16:34, Peter Eisentraut wrote: > On 1/30/17 9:04 AM, Simon Riggs wrote: >> all I want in this release is >> super-ownership. > > What exactly is super-ownership, and what problems does it solve? The problem is that there is no easy way for

Re: [HACKERS] Superowners

On 30 January 2017 at 16:43, Tom Lane wrote: > Simon Riggs writes: >> Agreed. Let me reiterate: all I want in this release is >> super-ownership. > > While I'm not entirely convinced whether super-ownership is a good idea > or not, I am pretty sure that

Re: [HACKERS] multivariate statistics (v19)

On 02/01/2017 11:52 PM, Alvaro Herrera wrote: Still looking at 0002. pg_ndistinct_in disallows input, claiming that pg_node_tree does the same thing. But pg_node_tree does it for security reasons: you could crash the backend if you supplied a malicious value. I don't think that applies to

Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)

On 02/02/2017 05:50 AM, David Rowley wrote: On 2 February 2017 at 00:13, Heikki Linnakangas wrote: Ok, I'll drop the second patch for now. I committed the first patch after fixing the things you and Michael pointed out. Thanks for the review! dbd69118 caused small compiler

Re: [HACKERS] Improvements in psql hooks for variables

On 02/01/2017 11:26 AM, Tom Lane wrote: > "Daniel Verite" writes: >> That works for me. I tested and read it and did not find anything >> unexpected or worth objecting. >> "\unset var" acting as "\set var off" makes sense considering >> that its opposite "\set var" is

Re: [HACKERS] Deadlock in XLogInsert at AIX

Last update on the issue with deadlock in XLogInsert. After almost one day of working, pgbench is once again not working normally:( There are no deadlock, there are no core files and no error messages in log. But TPS is almost zero: progress: 57446.0 s, 1.1 tps, lat 3840.265 ms stddev NaNQ