Re: [HACKERS] Support for N synchronous standby servers - take 2

On Mon, Jul 20, 2015 at 9:59 PM, Beena Emerson wrote: > Simon Riggs wrote: > >> The choice between formats is not >> solely predicated on whether we have multi-line support. > >> I still think writing down some actual use cases would help bring the >> discussion to a conclusion. Inventing a genera

Re: [HACKERS] security labels on databases are bad for dump & restore

On Mon, Jul 20, 2015 at 07:01:14PM -0400, Adam Brightwell wrote: > > Consistency with existing practice would indeed have pg_dump ignore > > pg_shseclabel and have pg_dumpall reproduce its entries. > > I think that makes sense, but what about other DATABASE level info > such as COMMENT? Should th

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

On Tue, Jul 21, 2015 at 2:39 PM, Michael Paquier wrote: > On Tue, Jul 21, 2015 at 6:17 AM, Tom Lane wrote: >> Andrew Dunstan writes: >>> Somewhere along the way some changes to the way we do "make check" have >>> caused a significant deterioration in the buildfarm's logging. Compare >>> these tw

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

On Tue, Jul 21, 2015 at 6:17 AM, Tom Lane wrote: > Andrew Dunstan writes: >> Somewhere along the way some changes to the way we do "make check" have >> caused a significant deterioration in the buildfarm's logging. Compare >> these two from animal crake, which happens to be my test instance: >> <

Re: [HACKERS] A little RLS oversight?

On Tue, Jul 14, 2015 at 4:01 AM, Stephen Frost wrote: > Michael, > > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> On Sun, Jul 12, 2015 at 5:59 PM, Yaroslav wrote: >> > I can still see all statistics for 'test' in pg_stats under unprivileged >> > user. >> >> Indeed, this looks like an ov

Re: [HACKERS] creating extension including dependencies

On Mon, Jul 20, 2015 at 10:20 PM, Petr Jelinek wrote: > On 2015-07-19 17:16, Michael Paquier wrote: >> >> On Sat, Jul 18, 2015 at 8:00 AM, Petr Jelinek >> wrote: >>> >>> On 2015-07-15 06:07, Michael Paquier wrote: On Fri, Jul 10, 2015 at 11:28 PM, Tom Lane wrote: > > >

Re: [HACKERS] Unnecessary #include in objectaddress.h?

> I wondered whether to bother about this kind of thing for a while. It > doesn't have any practical impact immediately, because obviously > pg_list.h is still included indirectly by objectaddress.h (via lock.h in > this case IIRC). If we made some restructuring that caused the other > header not

Re: [HACKERS] security labels on databases are bad for dump & restore

> Consistency with existing practice would indeed have pg_dump ignore > pg_shseclabel and have pg_dumpall reproduce its entries. I think that makes sense, but what about other DATABASE level info such as COMMENT? Should that also be ignored by pg_dump as well? I'm specifically thinking of the di

Re: [HACKERS] Unnecessary #include in objectaddress.h?

Adam Brightwell wrote: > All, > > While looking at the include dependency graph for objectaddress.h: > > http://doxygen.postgresql.org/objectaddress_8h.html > > I saw that pg_list.h is both included and inherited (through multiple > paths) by objectaddress.h. Perhaps this doesn't matter, but I

Re: [HACKERS] "make check" changes have caused buildfarm deterioration.

Andrew Dunstan writes: > Somewhere along the way some changes to the way we do "make check" have > caused a significant deterioration in the buildfarm's logging. Compare > these two from animal crake, which happens to be my test instance: >

[HACKERS] Unnecessary #include in objectaddress.h?

All, While looking at the include dependency graph for objectaddress.h: http://doxygen.postgresql.org/objectaddress_8h.html I saw that pg_list.h is both included and inherited (through multiple paths) by objectaddress.h. Perhaps this doesn't matter, but I thought I would at least bring it up an

[HACKERS] "make check" changes have caused buildfarm deterioration.

Somewhere along the way some changes to the way we do "make check" have caused a significant deterioration in the buildfarm's logging. Compare these two from animal crake, which happens to be my test instance:

Re: [HACKERS] All-zero page in GIN index causes assertion failure

On 07/20/2015 07:11 PM, Alvaro Herrera wrote: Heikki Linnakangas wrote: Looking closer, heap vacuum does a similar thing, but there are two mitigating factors that make it safe in practice, I think: 1. An empty heap page is all-zeroes except for the small page header in the beginning of the pa

Re: [HACKERS] First Aggregate Funtion?

On Mon, Jul 20, 2015 at 10:06 AM, Paul A Jungwirth wrote: >> The above implementation of "first" aggregate returns the first non-NULL item >> value. > > I'm curious what advantages this approach has over these FIRST/LAST > functions from the Wiki?: > > https://wiki.postgresql.org/wiki/First/la

Re: [BUGS] [HACKERS] object_classes array is broken, again

I wrote: > +1 to this patch, in fact I think we could remove MAX_OCLASS altogether > which would be very nice for switch purposes. Oh, wait, I forgot that the patch itself introduces another reference to MAX_OCLASS. I wonder though if we should get rid of that as an enum value in favor of #define

Re: [BUGS] [HACKERS] object_classes array is broken, again

Alvaro Herrera writes: > Tom Lane wrote: >> What about adding StaticAsserts that lengthof() the relevant constant >> arrays is equal to MAX_OCLASS? (Or other similar ways of checking >> that they have the right number of entries.) > Well, the array itself is declared like this: > static co

Re: [HACKERS] Dead code in Create/RenameRole() after RoleSpec changes related to CURRENT/SESSION_USER

Jeevan Chalke wrote: > I found some dead code in CREATE/RENAME ROLE code path. > > We have introduced RoleSpec and handled public and none role names in > grammar > itself. We do have these handling in CreateRole() and RenameRole() > which is NO more valid now. Right. > Attached patch to remov

Re: [HACKERS] Typo in comment in setrefs.c

Etsuro Fujita wrote: > I ran into a typo in a comment in setrefs.c. Patch attached. Fixed by Heikki in 7845db2aa. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsq

Re: [BUGS] [HACKERS] object_classes array is broken, again

Tom Lane wrote: > Alvaro Herrera writes: > > Any opinions on this idea? I don't like it all that much, but it's > > plenty effective. > > I don't like it much either. > > What about adding StaticAsserts that lengthof() the relevant constant > arrays is equal to MAX_OCLASS? (Or other similar wa

Re: [HACKERS] All-zero page in GIN index causes assertion failure

Heikki Linnakangas wrote: > Looking closer, heap vacuum does a similar thing, but there are two > mitigating factors that make it safe in practice, I think: > > 1. An empty heap page is all-zeroes except for the small page header in the > beginning of the page. For a torn page to matter, the page

Re: [HACKERS] First Aggregate Funtion?

On 7/20/15 6:02 PM, Corey Huinker wrote: By using only(a.name_of_the_thing) we'd have a bit more clarity that the author expected all of those values to be the same across the aggregate window, and discovering otherwise was reason enough to fail the query. *IF* we're considering adding these to

Re: [HACKERS] First Aggregate Funtion?

On Mon, Jul 20, 2015 at 11:06 AM, Paul A Jungwirth < p...@illuminatedcomputing.com> wrote: > > The above implementation of "first" aggregate returns the first non-NULL > item > > value. > > I'm curious what advantages this approach has over these FIRST/LAST > functions from the Wiki?: > > http

Re: [HACKERS] TABLESAMPLE patch is really in pretty sad shape

>> to handle DROP dependency behaviors properly. (On reflection, maybe >> better if it's "bernoulli(internal) returns tablesample_handler", >> so as to guarantee that such a function doesn't create a conflict with >> any user-defined function of the same name.) > > The probability of conflict seem

Re: [HACKERS] TABLESAMPLE patch is really in pretty sad shape

Petr Jelinek writes: > On 2015-07-19 22:56, Tom Lane wrote: >> * I specified that omitting NextSampleBlock is allowed and causes the >> core code to do a standard seqscan, including syncscan support, which >> is a behavior that's impossible with the current API. If we fix >> the bernoulli code to

Re: [HACKERS] patch: enhanced DROP POLICY tab complete

Thank you very much Pavel 2015-07-20 15:39 GMT+02:00 Alvaro Herrera : > Pavel Stehule wrote: > > Hi > > > > I am sending trivial patch, that enforce more precious tab complete for > > DROP POLICY statement > > Thanks, pushed and preciousified. > > -- > Álvaro Herrerahttp://www.2n

Re: [HACKERS] First Aggregate Funtion?

> The above implementation of "first" aggregate returns the first non-NULL item > value. I'm curious what advantages this approach has over these FIRST/LAST functions from the Wiki?: https://wiki.postgresql.org/wiki/First/last_%28aggregate%29 Also to get the "first non-null value" you can ap

Re: [HACKERS] First Aggregate Funtion?

On Mon, Jul 20, 2015 at 8:40 AM, sudalai wrote: > >>I don't think so, because arrays can contain duplicates. > >I just add two element to the array. One for INITCOND value NULL, second > for first row value. > So Array size is always 2. So no duplicates. > >>rhaas=# select coalesce(first(x.c

Re: [HACKERS] pg_trgm version 1.2

On Wed, Jul 15, 2015 at 12:31 AM, Jeff Janes wrote: > On Tue, Jul 7, 2015 at 6:33 AM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> >> >> See Tom Lane's comment about downgrade scripts. I think just remove it is >> a right solution. >> > > The new patch removes the downgrade path

Re: [HACKERS] All-zero page in GIN index causes assertion failure

On 07/20/2015 11:14 AM, Heikki Linnakangas wrote: ISTM ginvacuumcleanup should check for PageIsNew, and put the page to the FSM. That's what btvacuumpage() gistvacuumcleanup() do. spgvacuumpage() seems to also check for PageIsNew(), but it seems broken in a different way: it initializes the page

Re: [BUGS] [HACKERS] object_classes array is broken, again

Alvaro Herrera writes: > Any opinions on this idea? I don't like it all that much, but it's > plenty effective. I don't like it much either. What about adding StaticAsserts that lengthof() the relevant constant arrays is equal to MAX_OCLASS? (Or other similar ways of checking that they have th

Re: [HACKERS] First Aggregate Funtion?

>I don't think so, because arrays can contain duplicates. I just add two element to the array. One for INITCOND value NULL, second for first row value. So Array size is always 2. So no duplicates. >rhaas=# select coalesce(first(x.column1), 'wrong') from (values >(null), ('correct')) x; >c

Re: [HACKERS] patch: enhanced DROP POLICY tab complete

Pavel Stehule wrote: > Hi > > I am sending trivial patch, that enforce more precious tab complete for > DROP POLICY statement Thanks, pushed and preciousified. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --

Re: [HACKERS] creating extension including dependencies

On 2015-07-19 17:16, Michael Paquier wrote: On Sat, Jul 18, 2015 at 8:00 AM, Petr Jelinek wrote: On 2015-07-15 06:07, Michael Paquier wrote: On Fri, Jul 10, 2015 at 11:28 PM, Tom Lane wrote: Andres Freund writes: On July 10, 2015 4:16:59 PM GMT+02:00, Tom Lane wrote: Would that propa

Re: [HACKERS] Support for N synchronous standby servers - take 2

Simon Riggs wrote: > The choice between formats is not > solely predicated on whether we have multi-line support. > I still think writing down some actual use cases would help bring the > discussion to a conclusion. Inventing a general facility is hard without > some clear goals about what we nee

Re: [HACKERS] Implementation of global temporary tables?

> > Just to be clear, the idea of a global temp table is that the table def > is available to all users, but the data is private to each session? The table def is visible to all sessions and persistent, but the data is private to each session and temporary. Thanks, Zhaomo

Re: [HACKERS] [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace

On Mon, Jul 20, 2015 at 4:31 PM, Marti Raudsepp wrote: > On Mon, Jun 22, 2015 at 9:20 PM, Robert Haas wrote: >> On Fri, Jun 19, 2015 at 12:10 PM, Marti Raudsepp wrote: >>> One of my databases failed to upgrade successfully and produced this error >>> in the copying phase: >>> >>> error while cop

[HACKERS] Use pg_rewind when target timeline was switched

Hackers, attached patch allows pg_rewind to work when target timeline was switched. Actually, this patch fixes TODO from pg_rewind comments. /* * Trace the history backwards, until we hit the target timeline. * * TODO: This assumes that there are no timeline switches on the target *

Re: [HACKERS] TABLESAMPLE patch is really in pretty sad shape

On 2015-07-20 12:18, Petr Jelinek wrote: On 2015-07-19 22:56, Tom Lane wrote: * You might have expected me to move the tsmseqscan and tsmpagemode flags into the TsmRoutine struct, but instead this API puts equivalent flags into the SampleScanState struct. The reason for that is that it lets th

Re: [HACKERS] [COMMITTERS] pgsql: Improve BRIN documentation somewhat

Alvaro Herrera wrote: > Improve BRIN documentation somewhat > > This removes some info about support procedures being used, which was > obsoleted by commit db5f98ab4f, as well as add some more documentation > on how to create new opclasses using the Minmax infrastructure. > (Hopefully we can get s

Re: [HACKERS] TABLESAMPLE patch is really in pretty sad shape

On 2015-07-19 22:56, Tom Lane wrote: Since I'm not observing any movement on the key question of redesigning the tablesample method API, and I think that's something that's absolutely necessary to fix for 9.5, attached is an attempt to respecify the API. Sorry, I got something similar to what

Re: [HACKERS] Grouping Sets: Fix unrecognized node type bug

On Sat, Jul 18, 2015 at 12:27 AM, Andrew Gierth wrote: > > "Kyotaro" == Kyotaro HORIGUCHI > writes: > > Kyotaro> Hello, this looks to be a kind of thinko. The attached patch > Kyotaro> fixes it. > > No, that's still wrong. Just knowing that there is a List is not enough > to tell whether t

Re: [HACKERS] object_classes array is broken, again

Any opinions on this idea? I don't like it all that much, but it's plenty effective. Alvaro Herrera wrote: > The problem is that there aren't enough callers of add_object_address: > there are many indexes of that array that aren't ever accessed and so > it's not obvious when the array is broken

Re: [HACKERS] Implementation of global temporary tables?

2015-07-20 11:07 GMT+02:00 Alvaro Herrera : > Pavel Stehule wrote: > > 2015-07-20 5:33 GMT+02:00 Gavin Flower : > > > > > Would it be difficult to add the ability for one user to share the > > > contents with a list of named other users (roles)? > > > > Probably it is possible, but not for tempora

Re: [HACKERS] Re: [COMMITTERS] pgsql: Retain comments on indexes and constraints at ALTER TABLE ... TY

On 2015-07-17 21:40:45 +0300, Heikki Linnakangas wrote: > Hmm, that function is pretty fragile, it will segfault on any AT_* type that > it doesn't recognize. Thankfully you get that compiler warning, but we have > added AT_* type codes before in minor releases. For in-core code that is supposed t

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, >Does this actually handle multiple indexes? It doesn't appear so, which I'd >think is a significant problem... :/ Please find v2 attached which does this. >I'm also not seeing how this will deal with exhausting maintenance_work_mem. >ISTM that when that happens you'd definitely want a bet

Re: [HACKERS] Re: [COMMITTERS] pgsql: Retain comments on indexes and constraints at ALTER TABLE ... TY

Alvaro Herrera wrote: > Heikki Linnakangas wrote: > > On 07/18/2015 04:15 PM, Alvaro Herrera wrote: > > >Heikki Linnakangas wrote: > > >>If it's there just to so you can run the regression tests that come > > >>with it, it might make sense to just add a "default" case to that > > >>switch to handle

Re: [HACKERS] Implementation of global temporary tables?

On 2015-07-20 15:33:32 +1200, Gavin Flower wrote: > Would it be difficult to add the ability for one user to share the contents > with a list of named other users (roles)? No need. That feature is called unlogged tables and grants. Doing this for temporary tables would be horrible. They live in p

Re: [HACKERS] Implementation of global temporary tables?

Pavel Stehule wrote: > 2015-07-20 5:33 GMT+02:00 Gavin Flower : > > > Would it be difficult to add the ability for one user to share the > > contents with a list of named other users (roles)? > > Probably it is possible, but not for temporary data - short data are in > process memory, so it are n

[HACKERS] Re: [COMMITTERS] pgsql: Retain comments on indexes and constraints at ALTER TABLE ... TY

Heikki Linnakangas wrote: > On 07/18/2015 04:15 PM, Alvaro Herrera wrote: > >Heikki Linnakangas wrote: > >>If it's there just to so you can run the regression tests that come > >>with it, it might make sense to just add a "default" case to that > >>switch to handle any unrecognized commands, and pe

[HACKERS] All-zero page in GIN index causes assertion failure

This is a continuation of the discussion at http://www.postgresql.org/message-id/CAMkU=1zUc=h0oczntajaqqw7gxxvxcwsyq8dd2t7ohgsgve...@mail.gmail.com, I'm starting a new thread as this is a separate issue than the original LWLock bug. On Thu, Jul 16, 2015 at 12:03 AM, Jeff Janes wrote: On We

Re: [HACKERS] Parallel Seq Scan

On Mon, Jul 20, 2015 at 3:31 PM, Amit Kapila wrote: > On Fri, Jul 17, 2015 at 1:22 PM, Haribabu Kommi > wrote: >> >> On Thu, Jul 16, 2015 at 1:10 PM, Amit Kapila >> wrote: >> > Thanks, I will fix this in next version of patch. >> > >> >> I am posting in this thread as I am not sure, whether it n

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 20 July 2015 at 08:18, Beena Emerson wrote: > Simon Riggs wrote: > > >synchronous_standby_name= is already 25 characters, so that leaves 115 > characters - are they always single byte chars? > > I am sorry, I did not get why there is a 140 byte limit. Can you please > explain? > Hmm, sorry,

[HACKERS] Re: [COMMITTERS] pgsql: Retain comments on indexes and constraints at ALTER TABLE ... TY

On 07/18/2015 04:15 PM, Alvaro Herrera wrote: Heikki Linnakangas wrote: If it's there just to so you can run the regression tests that come with it, it might make sense to just add a "default" case to that switch to handle any unrecognized commands, and perhaps even remove the cases for the curr

Re: [HACKERS] [PATCH] pg_upgrade fails when postgres/template1 isn't in default tablespace

On Mon, Jun 22, 2015 at 9:20 PM, Robert Haas wrote: > On Fri, Jun 19, 2015 at 12:10 PM, Marti Raudsepp wrote: >> One of my databases failed to upgrade successfully and produced this error >> in the copying phase: >> >> error while copying relation "pg_catalog.pg_largeobject" >> ("/srv/ssd/PG_9.3_

Re: [HACKERS] Support for N synchronous standby servers - take 2

Simon Riggs wrote: >synchronous_standby_name= is already 25 characters, so that leaves 115 characters - are they always single byte chars? I am sorry, I did not get why there is a 140 byte limit. Can you please explain? - Beena Emerson -- View this message in context: http://postgresq

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

Hi Hanada-san, I have reviewed usermapping patch and here are some comments. The patch applies cleanly on Head and compiles without problem. The make check in regression folder does not show any failure. In find_user_mapping(), if the first cache search returns a valid tuple, it is checked twice