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

On Thu, Mar 2, 2017 at 9:40 PM, Robert Haas wrote: > On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed > wrote: > > 3. Handling adding a new partition to a partitioned table > >with default partition. > >This will require moving tuples from

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

On Fri, Mar 03, 2017 at 08:10:52AM +0530, Robert Haas wrote: > On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed wrote: > > 3. Handling adding a new partition to a partitioned table > >with default partition. > >This will require moving tuples from existing default

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

On Wed, Mar 1, 2017 at 6:29 AM, Rahila Syed wrote: > 3. Handling adding a new partition to a partitioned table >with default partition. >This will require moving tuples from existing default partition to > newly created partition if they satisfy its partition

Re: [HACKERS] Hash support for grouping sets

> "Thom" == Thom Brown writes: Thom> This doesn't apply cleanly to latest master. Could you please Thom> post a rebased patch? Sure. -- Andrew (irc:RhodiumToad) diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c index c9e0a3e..480a07e 100644

Re: [HACKERS] Hash support for grouping sets

On 6 January 2017 at 03:48, Andrew Gierth wrote: > Herewith a patch for doing grouping sets via hashing or mixed hashing > and sorting. > > The principal objective is to pick whatever combination of grouping sets > has an estimated size that fits in work_mem, and

Re: [HACKERS] Json support for array pseudotypes

On 02/21/2017 06:01 PM, Tom Lane wrote: > Andrew Dunstan writes: >> The attached tiny patch lets the to_json(b) routines convert objects >> with array pseudotypes to json{b}. The main impetus for this came from >> my trying to convert the annyarray columns in

Re: [HACKERS] Json support for array pseudotypes

Andrew Dunstan writes: > The attached tiny patch lets the to_json(b) routines convert objects > with array pseudotypes to json{b}. The main impetus for this came from > my trying to convert the annyarray columns in pg_stats to json and > finding that they ended up

Re: [HACKERS] drop support for Python 2.3

On 2/21/17 10:18, Tom Lane wrote: > Based on some not-fun I had along the way to that, I think it would be > a good idea to do the Python version check a bit earlier than you have > here. The shlib search in PGAC_CHECK_PYTHON_EMBED_SETUP is pretty fragile > and version-dependent, which means that

Re: [HACKERS] drop support for Python 2.3

Peter Eisentraut writes: > On 2/19/17 23:33, Devrim Gündüz wrote: >> Thanks! Looks like buildfarm is green again. > Thank. I have committed the patch to drop Python 2.3 support. I spent some time last night building a (rather makeshift) python 2.4.1

Re: [HACKERS] drop support for Python 2.3

On 2/19/17 23:33, Devrim Gündüz wrote: > Thanks! Looks like buildfarm is green again. Thank. I have committed the patch to drop Python 2.3 support. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] drop support for Python 2.3

Hi, On Sun, 2017-02-19 at 16:20 -0500, Tom Lane wrote: > Well, that test is checking which week-of-the-year a Sunday midnight is > considered to fall into.  There could be an edge-case bug in Tcl itself, > or a problem with the time zone data, or maybe if you're setting LC_TIME > to tr_TR, that

Re: [HACKERS] drop support for Python 2.3

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > On Sun, 2017-02-19 at 13:48 -0500, Tom Lane wrote: >> Or conceivably it's timezone dependent? > FWIW, the timezone of the server is GMT+3, if that is what you are asking. Well, that test is checking which week-of-the-year a Sunday

Re: [HACKERS] drop support for Python 2.3

Hi Tom, On Sun, 2017-02-19 at 13:48 -0500, Tom Lane wrote: > Hmph.  I can't see any relevant-looking source changes between 8.4.13 > and 8.4.15, which I have laying about here and which works fine. > I wonder if Red Hat is carrying some distro-specific patch that > breaks this case?  Just

Re: [HACKERS] drop support for Python 2.3

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > On Sun, 2017-02-19 at 10:42 -0500, Tom Lane wrote: >> Relevant question: what version of tcl is installed on those? > 8.4.13 is installed. Hmph. I can't see any relevant-looking source changes between 8.4.13 and 8.4.15, which I

Re: [HACKERS] drop support for Python 2.3

Hi Tom, On Sun, 2017-02-19 at 10:42 -0500, Tom Lane wrote: > Relevant question: what version of tcl is installed on those? 8.4.13 is installed. Regards, -- Devrim Gündüz EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter:

Re: [HACKERS] drop support for Python 2.3

I wrote: > Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: >> arapaima(x86) and aholehole(x86_64) are the new animals. They are running the >> buildfarm script now. > ... and failing. I wonder what is wrong with tcl_date_week()? > Will look for the explanation in a bit. Relevant

Re: [HACKERS] drop support for Python 2.3

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > arapaima(x86) and aholehole(x86_64) are the new animals. They are running the > buildfarm script now. ... and failing. I wonder what is wrong with tcl_date_week()? Will look for the explanation in a bit.

Re: [HACKERS] drop support for Python 2.3

Hi, On Thu, 2017-02-16 at 08:21 -0500, Peter Eisentraut wrote: > I will wait for that before proceeding. Sorry for the delay, I also had to build a newer flex RPM before proceeding. arapaima(x86) and aholehole(x86_64) are the new animals. They are running the buildfarm script now. Regards, --

Re: [HACKERS] drop support for Python 2.3

Hi Peter, On Thu, 2017-02-16 at 08:21 -0500, Peter Eisentraut wrote: > > I have CentOS 5 instances running on buildfarm. I'll register them via > > buildfarm.pg.org soon. > > I will wait for that before proceeding. Sorry for the delay. Machines are ready, I think I can prepare the buildfarm

Re: [HACKERS] drop support for Python 2.3

On 2/8/17 10:35, Devrim Gündüz wrote: > On Wed, 2017-02-08 at 09:16 -0500, Peter Eisentraut wrote: >> It appears that we don't have anything running 2.4. A RHEL/CentOS 5 >> system with standard components would be a good addition to the build farm. > > I have CentOS 5 instances running on

Re: [HACKERS] drop support for Python 2.3

On 2/7/17 10:49 PM, Tom Lane wrote: Peter Eisentraut writes: I would like to propose that we drop support for Python 2.3. ... We do have buildfarm coverage on prairiedog. However, that runs a >10 year old operating system, so I think it is not representing

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/28/17 1:33 PM, Fabrízio de Royes Mello wrote: > I did what you suggested making CURRENT_DATABASE reserved but I got the > following error during the bootstrap: current_database is also used as a function name, so you need to do some parser work to get it working in all the right ways. Hard

Re: [HACKERS] drop support for Python 2.3

On 02/07/2017 11:49 PM, Tom Lane wrote: > Peter Eisentraut writes: >> I would like to propose that we drop support for Python 2.3. >> ... >> We do have buildfarm coverage on prairiedog. However, that runs a >10 >> year old operating system, so I think it is

Re: [HACKERS] drop support for Python 2.3

Hi, On Wed, 2017-02-08 at 09:16 -0500, Peter Eisentraut wrote: > It appears that we don't have anything running 2.4.  A RHEL/CentOS 5 > system with standard components would be a good addition to the build farm. I have CentOS 5 instances running on buildfarm. I'll register them via

Re: [HACKERS] drop support for Python 2.3

On 2/7/17 11:49 PM, Tom Lane wrote: > Hm, is there anything running 2.4 in the buildfarm? If we're going to > claim support for 2.4, we'd be well advised to test it. It appears that we don't have anything running 2.4. A RHEL/CentOS 5 system with standard components would be a good addition to

Re: [HACKERS] drop support for Python 2.3

Peter Eisentraut writes: > I would like to propose that we drop support for Python 2.3. > ... > We do have buildfarm coverage on prairiedog. However, that runs a >10 > year old operating system, so I think it is not representing real usage. I have no particular

Re: [HACKERS] Microvacuum support for Hash Index

On Sat, Jan 28, 2017 at 8:02 PM, Amit Kapila wrote: > On Fri, Jan 27, 2017 at 5:15 PM, Ashutosh Sharma > wrote: >>> >>> Don't you think we should try to identify the reason of the deadlock >>> error reported by you up thread [1]? I know that you

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Sun, Jan 29, 2017 at 3:33 AM, Fabrízio de Royes Mello wrote: > On Sat, Jan 28, 2017 at 4:26 PM, Fabrízio de Royes Mello > wrote: >> On Fri, Jan 27, 2017 at 8:53 PM, Peter Eisentraut >> wrote: >> > >> > On

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Sat, Jan 28, 2017 at 4:26 PM, Fabrízio de Royes Mello < fabriziome...@gmail.com> wrote: > > > > On Fri, Jan 27, 2017 at 8:53 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > > > On 1/26/17 1:20 PM, Fabrízio de Royes Mello wrote: > > > Ok, but doing in that way the syntax

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Fri, Jan 27, 2017 at 8:53 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > On 1/26/17 1:20 PM, Fabrízio de Royes Mello wrote: > > Ok, but doing in that way the syntax would be: > > > > COMMENT ON DATABASE CURRENT_DATABASE IS 'comment'; > > Yes, that's right. We also have

Re: [HACKERS] Microvacuum support for Hash Index

On Fri, Jan 27, 2017 at 5:15 PM, Ashutosh Sharma wrote: >> >> Don't you think we should try to identify the reason of the deadlock >> error reported by you up thread [1]? I know that you and Ashutosh are >> not able to reproduce it, but still I feel some investigation is

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/26/17 1:20 PM, Fabrízio de Royes Mello wrote: > Ok, but doing in that way the syntax would be: > > COMMENT ON DATABASE CURRENT_DATABASE IS 'comment'; Yes, that's right. We also have ALTER USER CURRENT_USER already. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Microvacuum support for Hash Index

>>> I have done some more testing with this, and have moved to the patch >>> back to 'Needs Review' pending Amit's comments. >>> >> >> Moved to "Ready for Committer". >> > > Don't you think we should try to identify the reason of the deadlock > error reported by you up thread [1]? I know that you

Re: [HACKERS] Microvacuum support for Hash Index

On Thu, Jan 26, 2017 at 6:38 PM, Jesper Pedersen wrote: > On 01/23/2017 02:53 PM, Jesper Pedersen wrote: >> >> I have done some more testing with this, and have moved to the patch >> back to 'Needs Review' pending Amit's comments. >> > > Moved to "Ready for Committer".

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Mon, Jan 9, 2017 at 6:14 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > On 1/9/17 1:34 PM, Robert Haas wrote: > > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut > > wrote: > >> On 1/3/17 11:52 PM, Ashutosh Bapat wrote: > >>> We will need

Re: [HACKERS] Microvacuum support for Hash Index

On 01/23/2017 02:53 PM, Jesper Pedersen wrote: I have done some more testing with this, and have moved to the patch back to 'Needs Review' pending Amit's comments. Moved to "Ready for Committer". Best regards, Jesper -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/20/2017 03:24 PM, Jesper Pedersen wrote: Yeah, those are the steps; just with a Skylake laptop. However, I restarted with a fresh master, with WAL v8 and MV v5, and can't reproduce the issue. I have done some more testing with this, and have moved to the patch back to

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/20/2017 04:18 AM, Ashutosh Sharma wrote: okay, Thanks for confirming that. I would like to update you that I am not able to reproduce this issue at my end. I suspect that the steps i am following might be slightly different than your's. Could you please have a look at steps

Re: [HACKERS] Microvacuum support for Hash Index

Hi Jesper, > I'm not seeing this deadlock with just the WAL v8 patch applied. > okay, Thanks for confirming that. I would like to update you that I am not able to reproduce this issue at my end. I suspect that the steps i am following might be slightly different than your's. Could you please

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/10/2017 08:40 AM, Jesper Pedersen wrote: On 01/10/2017 05:24 AM, Ashutosh Sharma wrote: Thanks for reporting this problem. It is basically coming because i forgot to unpin the bucketbuf in hash_xlog_vacuum_one_page(). Please find the attached v5 patch that fixes the issue.

Re: [HACKERS] Hash support for grouping sets

On Mon, Jan 16, 2017 at 10:59 AM, Finnerty, Jim wrote: > The ability to exploit hashed aggregation within sorted groups, when the > order of the input stream can be exploited this way, is potentially a useful > way to improve aggregation performance more generally. This

Re: [HACKERS] Hash support for grouping sets

The ability to exploit hashed aggregation within sorted groups, when the order of the input stream can be exploited this way, is potentially a useful way to improve aggregation performance more generally. This would potentially be beneficial when the input size is expected to be larger than

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Mon, Jan 9, 2017 at 3:14 PM, Peter Eisentraut wrote: > To achieve consistent support for specifying the current database, we > would need to change the grammar for every command involving databases. I wouldn't have thought there would be all that many of

Re: [HACKERS] Hash support for grouping sets

On Thu, Jan 5, 2017 at 10:48 PM, Andrew Gierth wrote: > Herewith a patch for doing grouping sets via hashing or mixed hashing > and sorting. Cool. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/10/2017 05:24 AM, Ashutosh Sharma wrote: Thanks for reporting this problem. It is basically coming because i forgot to unpin the bucketbuf in hash_xlog_vacuum_one_page(). Please find the attached v5 patch that fixes the issue. The crash is now fixed, but the --- test.sql

Re: [HACKERS] Microvacuum support for Hash Index

Hi Jesper, > However (master / WAL v7 / MV v4), > > --- ddl.sql --- > CREATE TABLE test AS SELECT generate_series(1, 10) AS id, 0 AS val; > CREATE INDEX IF NOT EXISTS idx_id ON test USING hash (id); > CREATE INDEX IF NOT EXISTS idx_val ON test USING hash (val); > ANALYZE; > --- ddl.sql --- > >

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/9/17 2:52 PM, Alvaro Herrera wrote: > CURRENT_USER is a standards-mandated keyword, but CURRENT_DATABASE is > not. The closest thing SQL has is CURRENT_CATALOG, which is the string > that identifies the "current default catalog". This would lead us to > COMMENT ON DATABASE

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Mon, Jan 9, 2017 at 04:52:46PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote: > > > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut > > > wrote: > > > > On 1/3/17 11:52 PM, Ashutosh Bapat

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/9/17 1:34 PM, Robert Haas wrote: > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut > wrote: >> On 1/3/17 11:52 PM, Ashutosh Bapat wrote: >>> We will need to make CURRENT_DATABASE a reserved keyword. But I like >>> this idea more than COMMENT ON CURRENT

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

Bruce Momjian wrote: > On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote: > > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut > > wrote: > > > On 1/3/17 11:52 PM, Ashutosh Bapat wrote: > > >> We will need to make CURRENT_DATABASE a reserved keyword.

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote: > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut > wrote: > > On 1/3/17 11:52 PM, Ashutosh Bapat wrote: > >> We will need to make CURRENT_DATABASE a reserved keyword. But I like > >> this idea more

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut wrote: > On 1/3/17 11:52 PM, Ashutosh Bapat wrote: >> We will need to make CURRENT_DATABASE a reserved keyword. But I like >> this idea more than COMMENT ON CURRENT DATABASE. > > We already have the reserved key

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/06/2017 12:54 AM, Ashutosh Sharma wrote: using pgbench -M prepared -c 10 -j 10 -T 600 -f test.sql test crashes after a few minutes with TRAP: FailedAssertion("!(LWLockHeldByMeInMode(((LWLock*) (&(bufHdr)->content_lock)), LW_EXCLUSIVE))", File: "bufmgr.c", Line: 3781)

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

Jim Nasby writes: > On 1/6/17 2:45 PM, Tom Lane wrote: >> While I was checking the patch to verify that it didn't change any >> behavior, I noticed that it did, and there's a pre-existing bug here: >> pltcl_build_tuple_result is applying utf_e2u to the Tcl_GetString

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

On 1/6/17 2:45 PM, Tom Lane wrote: The only thing that seems significant is that we'd change the SQLSTATE for the "odd number of list items" error: pltcl_trigger_handler has (errcode(ERRCODE_E_R_I_E_TRIGGER_PROTOCOL_VIOLATED), errmsg("trigger's return list must have

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/3/17 11:52 PM, Ashutosh Bapat wrote: > We will need to make CURRENT_DATABASE a reserved keyword. But I like > this idea more than COMMENT ON CURRENT DATABASE. We already have the reserved key word CURRENT_CATALOG, which is the standard spelling. But I wouldn't be bothered if we made

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

Jim Nasby writes: > On 11/8/16 8:33 AM, Tom Lane wrote: >> As things stand in HEAD, the behavior is about the same, but the error >> messages are not --- in one case they mention triggers and of course the >> other doesn't. There are a couple of other minor things in

Re: [HACKERS] Microvacuum support for Hash Index

Hi, > using pgbench -M prepared -c 10 -j 10 -T 600 -f test.sql test > > crashes after a few minutes with > > TRAP: FailedAssertion("!(LWLockHeldByMeInMode(((LWLock*) > (&(bufHdr)->content_lock)), LW_EXCLUSIVE))", File: "bufmgr.c", Line: 3781) Attached v4 patch fixes this assertion failure. >

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/04/2017 06:13 AM, Ashutosh Sharma wrote: Attached is the v3 patch rebased on postgreSQL HEAD and WAL v7 patch. It also takes care of all the previous comments from Jesper - [1]. With an --enable-cassert build (master / WAL v7 / MV v3) and -- ddl.sql -- CREATE TABLE test

Re: [HACKERS] Microvacuum support for Hash Index

Hi, > This can be rebased on the WAL v7 patch [1]. In addition to the previous > comments you need to take commit 7819ba into account. > Attached is the v3 patch rebased on postgreSQL HEAD and WAL v7 patch. It also takes care of all the previous comments from Jesper - [1]. Also, I have changed

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Tue, Jan 3, 2017 at 10:09 PM, Robert Haas wrote: > On Tue, Jan 3, 2017 at 12:06 AM, Ashutosh Bapat > wrote: >> Instead of changing get_object_address_unqualified(), >> get_object_address_unqualified() and pg_get_object_address(), should

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Tue, Jan 3, 2017 at 9:18 PM, Peter Eisentraut wrote: > On 12/30/16 9:28 PM, Fabrízio de Royes Mello wrote: >> The attached patch is reworked from a previous one [1] to better deal >> with get_object_address and pg_get_object_address. >> >> Regards, >> >> [1]

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Tue, Jan 3, 2017 at 6:40 PM, Fabrízio de Royes Mello wrote: > Hi Ashutosh, > > First of all thanks for your review. > > > On Tue, Jan 3, 2017 at 3:06 AM, Ashutosh Bapat > wrote: >> >> The patch has white space error >> git apply

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On Tue, Jan 3, 2017 at 12:06 AM, Ashutosh Bapat wrote: > Instead of changing get_object_address_unqualified(), > get_object_address_unqualified() and pg_get_object_address(), should > we just stick get_database_name(MyDatabaseId) as object name in > gram.y? No.

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 12/30/16 9:28 PM, Fabrízio de Royes Mello wrote: > The attached patch is reworked from a previous one [1] to better deal > with get_object_address and pg_get_object_address. > > Regards, > > [1] https://www.postgresql.org/message-id/20150317171836.gc10...@momjian.us The syntax we have used

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

Hi Ashutosh, First of all thanks for your review. On Tue, Jan 3, 2017 at 3:06 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > > The patch has white space error > git apply /mnt/hgfs/tmp/comment_on_current_database_v1.patch > /mnt/hgfs/tmp/comment_on_current_database_v1.patch:52:

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

The patch has white space error git apply /mnt/hgfs/tmp/comment_on_current_database_v1.patch /mnt/hgfs/tmp/comment_on_current_database_v1.patch:52: trailing whitespace. * schema-qualified or catalog-qualified. warning: 1 line adds whitespace errors. The patch compiles clean, regression is

Re: [HACKERS] Microvacuum support for Hash Index

On 11/11/2016 12:11 AM, Ashutosh Sharma wrote: Hi Jesper, Some initial comments. _hash_vacuum_one_page: + END_CRIT_SECTION(); + _hash_chgbufaccess(rel, metabuf, HASH_READ, HASH_NOLOCK); The _hash_chgbufaccess() needs a comment. You also need a place where you

Re: [HACKERS] Partitionning: support for Truncate Table WHERE

; ; De : Amit Langote <langote_amit...@lab.ntt.co.jp> Envoyé : mercredi 7 décembre 2016 06:58:03 À : Craig Ringer; legrand legrand Cc : pgsql-hackers@postgresql.org Objet : Re: [HACKERS] Partitionning: support for Truncate Table WHERE On 2016/12/07 15:26, Craig

Re: [HACKERS] Partitionning: support for Truncate Table WHERE

On 2016/12/07 15:26, Craig Ringer wrote: > On 7 December 2016 at 07:29, legrand legrand > wrote: > >> Working in a DSS environment, we often need to truncate table partitions >> regarding a WHERE condition and have to >> [...] >> Would be pleased to ear your feedback

Re: [HACKERS] Partitionning: support for Truncate Table WHERE

On 7 December 2016 at 07:29, legrand legrand wrote: > Working in a DSS environment, we often need to truncate table partitions > regarding a WHERE condition and have to > [...] > Would be pleased to ear your feedback regarding this. It sounds like something that'd

Re: [HACKERS] Add support for restrictive RLS policies

* Stephen Frost (sfr...@snowman.net) wrote: > Updated patch attached. Erp, actually attached this time. Thanks again! Stephen From 27e5fdac801cecc5ac33daccf979bbc59458dbbc Mon Sep 17 00:00:00 2001 From: Stephen Frost Date: Thu, 1 Sep 2016 02:11:30 -0400 Subject: [PATCH] Add

Re: [HACKERS] Add support for restrictive RLS policies

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > This note reads a little awkwardly to me. I think I would write it as: > > Note that ALTER POLICY only allows the set of roles > to which the policy applies and the USING and > WITH CHECK expressions to be modified. To change

Re: [HACKERS] Add support for restrictive RLS policies

Stephen, I looked through this in a little more detail and I found one other issue: the documentation for the system catalog table pg_policy and the view pg_policies needs to be updated to include the new columns that have been added. Other than that, it all looks good to me, subject to the

Re: [HACKERS] Add support for restrictive RLS policies

On Fri, Dec 2, 2016 at 2:09 AM, Stephen Frost wrote: > Dean, > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > > On 1 December 2016 at 14:38, Stephen Frost wrote: > > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > > >> In

Re: [HACKERS] Add support for restrictive RLS policies

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 1 December 2016 at 14:38, Stephen Frost wrote: > > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > >> In get_policies_for_relation() ... > >> ... I think it should sort the restrictive policies by name > > > >

Re: [HACKERS] Add support for restrictive RLS policies

On 1 December 2016 at 14:38, Stephen Frost wrote: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> In get_policies_for_relation() ... >> ... I think it should sort the restrictive policies by name > > Hmmm, is it really the case that the quals will always end up being >

Re: [HACKERS] Microvacuum support for Hash Index

On 11/11/2016 12:11 AM, Ashutosh Sharma wrote: Thanks for reviewing this patch. I would like to update you that this patch has got dependency on a patch for concurrent hash index and WAL log in hash index. So, till these two patches for hash index are not stable I won't be able to share you a

Re: [HACKERS] Add support for restrictive RLS policies

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 30 November 2016 at 21:54, Stephen Frost wrote: > > Unless there's further comments, I'll plan to push this sometime > > tomorrow. > > Sorry I didn't have time to look at this properly. I was intending to, > but my

Re: [HACKERS] Add support for restrictive RLS policies

On 30 November 2016 at 21:54, Stephen Frost wrote: > Unless there's further comments, I'll plan to push this sometime > tomorrow. > Sorry I didn't have time to look at this properly. I was intending to, but my day job just keeps getting in the way. I do have a couple of

Re: [HACKERS] Add support for restrictive RLS policies

* Stephen Frost (sfr...@snowman.net) wrote: > * Jeevan Chalke (jeevan.cha...@enterprisedb.com) wrote: > > 4. It will be good if we have an example for this in section > > "5.7. Row Security Policies" > > I haven't added one yet, but will plan to do so. I've now added and cleaned up the Row

Re: [HACKERS] GiST support for UUIDs

On Tue, Nov 29, 2016 at 1:13 PM, Tom Lane wrote: > Pushed with that change and some other mostly-cosmetic tweaking. Thank you for addressing all those issues, Tom! I tested some exclusion constraints that are interesting to me, and everything seems to be working well. --

Re: [HACKERS] GiST support for UUIDs

I wrote: > I'm kind of inclined to change uuid_parts_distance to just convert > a given pg_uuid_t to "double" and then apply penalty_num(), as is > done in gbt_macad_penalty. Pushed with that change and some other mostly-cosmetic tweaking. One not too cosmetic fix was that gbt_uuid_union was

Re: [HACKERS] GiST support for UUIDs

Chris Bandy writes: > [ btree_gist_uuid_8.patch ] Um ... is there a reason why the penalty logic in gbt_uuid_penalty() is completely unlike that for any other btree_gist module? As best I can tell from the (admittedly documentation-free) code elsewhere, the penalty ought

Re: [HACKERS] GiST support for UUIDs

On Mon, Nov 28, 2016 at 4:04 PM, Tom Lane wrote: > > What I would suggest is that you forget the union hack and just use > memcmp in all the comparison functions. It's not likely to be worth > the trouble to try to get those calls to be safely aligned. The > only place where

Re: [HACKERS] GiST support for UUIDs

Adam Brusselback writes: > [ btree_gist_uuid_7.patch ] I spent awhile looking at this. I have exactly no faith that it won't crash on alignment-picky hardware, because this declaration: union pg_uuid_t { unsigned char data[UUID_LEN]; uint64 v64[2]; };

Re: [HACKERS] GiST support for UUIDs

On Wed, Nov 2, 2016 at 3:49 AM, Adam Brusselback wrote: > So I apologize in advance if I didn't follow the processes exactly, I was > going to attempt to review this to move it along, but ran into issues > applying the patch cleanly to master. I fixed the issues I was

Re: [HACKERS] Microvacuum support for Hash Index

Hi Jesper, > Some initial comments. > > _hash_vacuum_one_page: > > + END_CRIT_SECTION(); > + _hash_chgbufaccess(rel, metabuf, HASH_READ, HASH_NOLOCK); > > The _hash_chgbufaccess() needs a comment. > > You also need a place where you call pfree for so->killedItems -

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

On 11/8/16 8:33 AM, Tom Lane wrote: As things stand in HEAD, the behavior is about the same, but the error messages are not --- in one case they mention triggers and of course the other doesn't. There are a couple of other minor things in the way of unifying the two hunks of code, so I

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

Jim Nasby writes: > Hrm, I completely spaced on the fact that composite returns are > essentially the same thing as trigger returns. ISTM we should be able to > use the same code for both. IIRC those magic elements could end up in > any SPI result, so that handling

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

On 11/6/16 12:15 PM, Tom Lane wrote: I wrote: I got the code to a state that I liked (attached), and started reviewing the docs, and then it occurred to me to wonder why you'd chosen to use Tcl lists to represent composite output values. The precedent established by input argument handling is

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

I wrote: > I got the code to a state that I liked (attached), and started reviewing > the docs, and then it occurred to me to wonder why you'd chosen to use > Tcl lists to represent composite output values. The precedent established > by input argument handling is that composites are transformed

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

2016-11-06 2:12 GMT+01:00 Tom Lane : > Jim Nasby writes: > > Attached is a patch that adds support for SRFs and returning composites > > from pl/tcl. This work was sponsored by Flight Aware. > > I spent a fair amount of time whacking this around,

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

Jim Nasby writes: > Attached is a patch that adds support for SRFs and returning composites > from pl/tcl. This work was sponsored by Flight Aware. I spent a fair amount of time whacking this around, because I did not like the fact that you were using the

Re: [HACKERS] Add support for SRF and returning composites to pl/tcl

Hi I checked this code, and it looks well 0. there are not any reason why we would not to implement this feature - more, the implementation is simple. 1. there was not problem with patching, compilation 2. the original patch is missing new expected result for regress tests, fixed in attached

Re: [HACKERS] Microvacuum support for Hash Index

Hi, On 11/02/2016 01:38 AM, Ashutosh Sharma wrote: While replaying the delete/vacuum record on standby, it can conflict with some already running queries. Basically the replay can remove some row which can be visible on standby. You need to resolve conflicts similar to what we do in btree

Re: [HACKERS] Microvacuum support for Hash Index

Hi, > While replaying the delete/vacuum record on standby, it can conflict > with some already running queries. Basically the replay can remove > some row which can be visible on standby. You need to resolve > conflicts similar to what we do in btree delete records (refer > btree_xlog_delete).

Re: [HACKERS] GiST support for UUIDs

So I apologize in advance if I didn't follow the processes exactly, I was going to attempt to review this to move it along, but ran into issues applying the patch cleanly to master. I fixed the issues I was having applying it, and created a new patch (attached). Managed to test it out after I

Re: [HACKERS] Microvacuum support for Hash Index

Hi Amit, Thanks for showing your interest and reviewing my patch. I have started looking into your review comments. I will share the updated patch in a day or two. With Regards, Ashutosh Sharma EnterpriseDB: http://www.enterprisedb.com On Fri, Oct 28, 2016 at 4:42 PM, Amit Kapila

Re: [HACKERS] Microvacuum support for Hash Index

On Mon, Oct 24, 2016 at 2:21 PM, Ashutosh Sharma wrote: > Hi All, > > I have added a microvacuum support for hash index access method and > attached is the v1 patch for the same. > This is an important functionality for hash index as we already do have same functionality

<    1   2   3   4   5   6   7   8   9   10   >