Re: Problem while setting the fpw with SIGHUP

On Thu, Apr 12, 2018 at 10:34:30AM +0900, Kyotaro HORIGUCHI wrote: > Checkpointer never calls CreateCheckPoint while > RecoveryInProgress() == true. In other words, checkpointer is not > an updator of shared FPW at the time StartupXLOG calls > CreateCheckPoint for fallback_promote. I have been

Re: [HACKERS] Runtime Partition Pruning

On 11 April 2018 at 09:32, Alvaro Herrera wrote: > Robert Haas wrote: >> On Mon, Apr 9, 2018 at 2:28 PM, Alvaro Herrera >> wrote: > >> >> I don't get this. The executor surely had to (and did) open all of >> >> the relations somewhere even

Re: Boolean partitions syntax

Hello. At Wed, 11 Apr 2018 09:43:37 -0400, "Jonathan S. Katz" wrote in > case EXPR_KIND_PARTITION_BOUNDS: > ^~ .. > 2 errors generated. > > The

Re: relispartition for index partitions

On 2018/04/12 5:33, Alvaro Herrera wrote: > Amit Langote wrote: >> Hi. >> >> I noticed that relispartition isn't set for index's partitions. > > This patch should fix it. Thanks. I saw your commit 9e9befac4a22 and changes seem fine. Regards, Amit

Re: WIP: Covering + unique indexes.

On Tue, Apr 10, 2018 at 5:45 PM, Peter Geoghegan wrote: > I did find another problem, though. Looks like the idea to explicitly > represent the number of attributes directly has paid off already: > > pg@~[3711]=# create table covering_bug (f1 int, f2 int, f3 text); > create unique

Re: [HACKERS] path toward faster partition pruning

On 2018/04/11 21:35, Alvaro Herrera wrote: > Here's an idea. Why don't we move the function/opclass creation lines > to insert.sql, without the DROPs, and use the same functions/opclasses > in the three tests insert.sql, alter_table.sql, hash_part.sql and > partition_prune.sql, i.e. not recreate

Re: Native partitioning tablespace inheritance

On 12 April 2018 at 09:19, Keith Fiske wrote: > To me the current behavior is even more unintuitive. You tell it to put the > parent table in a specific tablespace and it completely ignores the option > and puts it in the default. Then when you go create children

Re: Problem while setting the fpw with SIGHUP

Hello. Thanks to Heikkit for picking this up and thanks for the commnet to Michael. # The attached is changed only in a comment, and rebased. At Thu, 12 Apr 2018 05:24:14 +0900, Michael Paquier wrote in <20180411202414.ga32...@paquier.xyz> > On Wed, Apr 11, 2018 at

Re: Bugs in TOAST handling, OID assignment and redo recovery

On 4/10/18 06:29, Pavan Deolasee wrote: > One of our 2ndQuadrant support customers recently reported a sudden rush > of TOAST errors post a crash recovery, nearly causing an outage. Most > errors read like this: > > ERROR: unexpected chunk number 0 (expected 1) for toast value While

Re: submake-errcodes

On Wed, Apr 11, 2018 at 10:16:24AM -0400, Tom Lane wrote: > That works for me: > > $ git clean -dfx > $ ./configure ... --with-python and other stuff ... > $ cd src/pl/plpython > $ make all > make -C ../../../src/backend generated-headers > make[1]: Entering directory

Re: Bugs in TOAST handling, OID assignment and redo recovery

Michael Paquier writes: > I have not really checked this thread in details, but one thing that > strikes me is that it would be rather easy to add a TAP test based on > the initial script that Pavan has sent. Would that be worth testing > cycles or not? I doubt it --- that

Re: pgsql: New files for MERGE

On Wed, Apr 11, 2018 at 10:28:10PM +0100, Simon Riggs wrote: > Requesting review so I don't cause multiple revert commits. I have gone through the code tree with your patch applied for some time, and it seems to me that there are no more traces of merge or any of its infrastructure. Tests are

Re: Bugs in TOAST handling, OID assignment and redo recovery

On Wed, Apr 11, 2018 at 04:28:33PM -0400, Tom Lane wrote: > I propose therefore that the right fix does not require an API change > for GetNewOidWithIndex: we can just make it use SnapshotAny all the > time. I have not really checked this thread in details, but one thing that strikes me is that

Re: Partitioned tables and covering indexes

That's the idea that I tried to express. The point is that we need to tell the user that there is no need to worry about it, rather than that they're wrong to ask about it. Though we should probably actually just throw an error. Or maybe it should be the collation of the underlying table

Re: Partitioned tables and covering indexes

Peter Geoghegan wrote: On Wed, Apr 11, 2018 at 2:29 PM, Peter Eisentraut wrote: But in this case it doesn't even do equality comparison, it just returns the value. That's the idea that I tried to express. The point is that we need to tell the user that

Re: Partitioned tables and covering indexes

On 4/11/18 17:38, Peter Geoghegan wrote: > On Wed, Apr 11, 2018 at 2:29 PM, Peter Eisentraut > wrote: >> But in this case it doesn't even do equality comparison, it just returns >> the value. > > That's the idea that I tried to express. The point is that we need

Re: Fix for pg_stat_activity putting client hostaddr into appname field

On Thu, Apr 12, 2018 at 12:01:29AM +0300, Heikki Linnakangas wrote: > Thanks for the debugging and the patch, Edmund! Thanks for the commit, Heikki. -- Michael signature.asc Description: PGP signature

Re: Creation of wiki page for open items of v11

> On Apr 11, 2018, at 4:58 PM, Peter Eisentraut > wrote: > > On 4/11/18 10:53, Tom Lane wrote: >> It's not that much work to move the items rather than remove them, > > Well, toward the end of the cycle, when the list of closed items is > quite long, then it

Re: Partitioned tables and covering indexes

On Wed, Apr 11, 2018 at 2:29 PM, Peter Eisentraut wrote: > But in this case it doesn't even do equality comparison, it just returns > the value. That's the idea that I tried to express. The point is that we need to tell the user that there is no need to worry

Re: Native partitioning tablespace inheritance

On 4/11/18 17:19, Keith Fiske wrote: > To me the current behavior is even more unintuitive. You tell it to put > the parent table in a specific tablespace and it completely ignores the > option and puts it in the default. Then when you go create children > without specifying a tablespace, you

Re: Partitioned tables and covering indexes

On 4/11/18 17:08, Peter Geoghegan wrote: >> However, I don't see any point in defining collations here, because >> INCLUDE attributes exist solely for index-only scans. So, index just >> can return value of INCLUDE attribute "as is", no point to do something >> with collation. >> >> So, I propose

Re: missing support of named convention for procedures

On 4/11/18 12:06, Andres Freund wrote: > On 2018-03-22 15:19:12 +0100, Pavel Stehule wrote: >> attached patch should to fix it > > This is still broken, and has been an open item for a bit. Peter, Could > you check whether Pavel's fix resolves the issue for you? Yes, I will work on this. --

Re: Native partitioning tablespace inheritance

On Wed, Apr 11, 2018 at 4:54 PM, Michael Paquier wrote: > On Wed, Apr 11, 2018 at 12:52:06PM -0400, Keith Fiske wrote: > > Any chance of this being an inheritable property that can simply be > > overridden if the TABLESPACE flag is set when creating a child table? If > >

Re: Partitioned tables and covering indexes

On Wed, Apr 11, 2018 at 1:58 PM, Alexander Korotkov wrote: > It appears that INCLUDE columns might have collation defined. > For instance, following query is working: > > create index t_s1_s2_idx on t (s1) include (s2 collate "en_US.UTF-8"); > > However, I don't see any

Re: Fix for pg_stat_activity putting client hostaddr into appname field

On 29/03/18 10:46, Michael Paquier wrote: On Tue, Mar 27, 2018 at 03:47:07PM +1300, Edmund Horner wrote: I considered whether aux processes really need those strings (especially st_clienthostname), but decided it was more consistent just to assume that they might. (It's an extra 3 kB... if we

Re: Creation of wiki page for open items of v11

On 4/11/18 10:53, Tom Lane wrote: > It's not that much work to move the items rather than remove them, Well, toward the end of the cycle, when the list of closed items is quite long, then it does become a bit of a burden to carefully cut and paste the item in the little browser window without

Re: Partitioned tables and covering indexes

On Wed, Apr 11, 2018 at 10:47 PM, Alvaro Herrera wrote: > Teodor Sigaev wrote: > > > Patch attached. > > I wonder why this is a problem in opfamilies but not collations. > If we don't compare collations, wouldn't it make more sense to break out > of the loop once the

Re: es_query_dsa is broken

On Thu, Apr 12, 2018 at 4:04 AM, Andres Freund wrote: > This is an open item for v11: > > Tidy up es_query_dsa and possibly ParallelWorkerContext? > Original commit: e13029a5ce353574516c64fd1ec9c50201e705fd (principal > author: Thomas Munro; owner: Robert Haas) >

Re: Native partitioning tablespace inheritance

On Wed, Apr 11, 2018 at 12:52:06PM -0400, Keith Fiske wrote: > Any chance of this being an inheritable property that can simply be > overridden if the TABLESPACE flag is set when creating a child table? If > it's not set, just set the tablespace to whatever was set for the parent. I am wondering

Re: Gotchas about pg_verify_checksums

On Wed, Apr 11, 2018 at 10:21:29PM +0200, Daniel Gustafsson wrote: > Right, I misunderstood your initial email but I see what you mean. Yes, you > are right and with that +1 on your patch. OK, no problem. > Naming it pg_checksums, with only verification as an option, seems to me to > imply

Re: relispartition for index partitions

Amit Langote wrote: > Hi. > > I noticed that relispartition isn't set for index's partitions. This patch should fix it. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services diff --git a/src/backend/catalog/index.c

Re: Bugs in TOAST handling, OID assignment and redo recovery

So while looking at this, it suddenly occurred to me that probing with SnapshotDirty isn't that safe for regular (non-TOAST) Oid assignment either. SnapshotDirty will consider a row dead the instant the deleting transaction has committed, but it may remain visible to other transactions for awhile

Re: Problem while setting the fpw with SIGHUP

On Wed, Apr 11, 2018 at 02:09:48PM +0300, Heikki Linnakangas wrote: > I think the new behavior where the GUC only takes effect at next checkpoint > is OK. It seems quite intuitive. > > > [rebased patch version] > > Looks good at a quick glance. Assuming no objections from others, I'll take > a

Re: Gotchas about pg_verify_checksums

> On 11 Apr 2018, at 01:53, Michael Paquier wrote: > > On Tue, Apr 10, 2018 at 10:27:19PM +0200, Daniel Gustafsson wrote: >>> On 10 Apr 2018, at 06:21, Michael Paquier wrote: >> Does it really imply that? Either way, the tool could potentially be

Re: Bugs in TOAST handling, OID assignment and redo recovery

On 11 April 2018 at 19:57, Tom Lane wrote: > Pavan Deolasee writes: >> Ok. I propose attached patches, more polished this time. > > I'll take these, unless some other committer is hot to do so? Please go ahead. -- Simon Riggs

Re: pgsql: New files for MERGE

On 7 April 2018 at 18:45, Tom Lane wrote: > Simon Riggs writes: >> On 6 April 2018 at 17:22, Bruce Momjian wrote: >>> My point was that people didn't ask you to work harder on fixing the >>> patch, but in reverting it. You can work

Re: lazy detoasting

> "Chapman" == Chapman Flack writes: Chapman> There's precedent for that kind of thing in PL/Java already Chapman> ... objects that Java considers alive as long as some code Chapman> holds a reference to them, but proxy for things in PG that may Chapman> only have

Re: Partitioned tables and covering indexes

Teodor Sigaev wrote: > Patch attached. I wonder why this is a problem in opfamilies but not collations. If we don't compare collations, wouldn't it make more sense to break out of the loop once the number of keys is reached? When this code was written, there was no question as to what length

Re: Partitioned tables and covering indexes

Actually, discovered bug is not related to patch except new test faces with it, problem is: CompareIndexInfo() checks rd_opfamily for equality for all attributes, not only for key attribute. Patch attached. But it seems to me, field's names of IndexInfo structure are a bit confused now:

Re: lazy detoasting

On 04/11/2018 03:04 PM, Tom Lane wrote: > Chapman Flack writes: >> that it might *not* be sufficient to find an applicable snapshot at >> the time of constructing the object, and register that snapshot >> on TopTransactionResourceOwner? > > The problem is to know which

Re: lazy detoasting

Chapman Flack writes: > But let me return to the earlier idea for a moment: are you saying > that it might *not* be sufficient to find an applicable snapshot at > the time of constructing the object, and register that snapshot > on TopTransactionResourceOwner? The problem

Re: Bugs in TOAST handling, OID assignment and redo recovery

Pavan Deolasee writes: > Ok. I propose attached patches, more polished this time. I'll take these, unless some other committer is hot to do so? regards, tom lane

Re: using index or check in ALTER TABLE SET NOT NULL

Hi I noticed new merge conflict, updated version attached. regards, Sergeidiff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml index bd22627..db98a98 100644 --- a/doc/src/sgml/ref/alter_table.sgml +++ b/doc/src/sgml/ref/alter_table.sgml @@ -215,8 +215,15 @@ WITH (

Re: Commit 4dba331cb3 broke ATTACH PARTITION behaviour.

Thanks for the discussion. Per your suggestions, I changed the check for default partition OID to an assert instead of the 'if' condition, and removed the code that attempted vainly to verify the constraint when attaching a foreign table as a partition. And pushed. I think we're done here, so

Re: Bugs in TOAST handling, OID assignment and redo recovery

On Wed, Apr 11, 2018 at 8:20 PM, Tom Lane wrote: > Pavan Deolasee writes: > > Or may be we simply err on the side of caution and scan the toast table > > with SnapshotAny while looking for a duplicate? That might prevent us > from > > reusing an OID

Re: lazy detoasting

On 04/11/2018 01:55 PM, Tom Lane wrote: > Chapman Flack writes: >> Well, the devilsAdvocate() function would stash the object >> in a static, then try to look at it some time in a later call >> in the same transaction. > > If you're worried about that, you should also

Re: WARNING in parallel index creation.

I wrote: > The WARNING seems to indicate that the error check in set_config_option > is too aggressive. I kind of wonder why it was placed there at all, > rather than in SQL-level operations like ExecSetVariableStmt. BTW, looking back at the thread, nobody seems to have posted an analysis of why

Re: lazy detoasting

Chapman Flack writes: > On 04/11/2018 11:33 AM, Tom Lane wrote: >> OK, but if this object only lives within a single function call, >> what's the problem? The underlying row must be visible to the >> calling query, and that condition won't change for the duration >> of the

Re: 'make check' fails

On Wed, Apr 11, 2018 at 01:04:56PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote: > >> We can fix this by making submake-generated-headers be a recursive > >> prerequisite for "check" as well as "all" and "install".

Re: lazy detoasting

On 04/11/2018 11:33 AM, Tom Lane wrote: > Chapman Flack writes: >> The mission is to implement java.sql.SQLXML, which has long been >> missing from PL/Java. >> This is the class of object your Java code can retrieve from a >> ResultSet row from a query with an XML column

Re: Creation of wiki page for open items of v11

On 04/11/2018 10:06 AM, Alvaro Herrera wrote: Andres Freund wrote: On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote: The other proposal was that we could have a simple web app to track open items. After all, we now know what we need from it. A wiki page seems more laborious. (The

Re: Creation of wiki page for open items of v11

Magnus Hagander wrote: > (And of course, if we want to go in *any* direction away from the wiki, > it's not going to happen in time for *this* release..) Absolutely. But if we never start, it'll never get done. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL

Re: Creation of wiki page for open items of v11

Andres Freund wrote: > On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote: > > The other proposal was that we could have a simple web app to track open > > items. After all, we now know what we need from it. A wiki page seems > > more laborious. (The commitfest app also sprung from a wiki

Re: 'make check' fails

Bruce Momjian writes: > On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote: >> We can fix this by making submake-generated-headers be a recursive >> prerequisite for "check" as well as "all" and "install". I wonder >> whether anybody is expecting any other shortcuts to

Re: Creation of wiki page for open items of v11

On Wed, Apr 11, 2018 at 6:57 PM, Andres Freund wrote: > On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote: > > The other proposal was that we could have a simple web app to track open > > items. After all, we now know what we need from it. A wiki page seems > > more

Re: Creation of wiki page for open items of v11

On 2018-04-11 13:54:34 -0300, Alvaro Herrera wrote: > The other proposal was that we could have a simple web app to track open > items. After all, we now know what we need from it. A wiki page seems > more laborious. (The commitfest app also sprung from a wiki page.) Growing a number of

Re: Creation of wiki page for open items of v11

Jonathan S. Katz wrote: > During some RMT discussions I had proposed formatting the open items > into a table on the Wiki page with some useful info to help track the status > and surface the necessary info to track down the open item. The other proposal was that we could have a simple web app

Native partitioning tablespace inheritance

Just had someone report that pg_partman wasn't handling tablespaces for native partitioning. https://github.com/keithf4/pg_partman/issues/212 I'd assumed that that was a property that was being inherited from the parent table, but apparently the TABLESPACE flag to CREATE TABLE is completely

Re: 'make check' fails

Alvaro Herrera writes: > Tom Lane wrote: >> We can fix this by making submake-generated-headers be a recursive >> prerequisite for "check" as well as "all" and "install". I wonder >> whether anybody is expecting any other shortcuts to work. > check-world certainly, but

Re: Creation of wiki page for open items of v11

> On Apr 11, 2018, at 11:54 AM, Tom Lane wrote: > > Robert Haas writes: >> On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane wrote: >>> What *does* take time is adding a link to the commit, so I'd happily >>> drop that step. As Peter

Re: Partitioned tables and covering indexes

Patch makes buildfarm almost red, patch is temporary reverted. Actually, discovered bug is not related to patch except new test faces with it, problem is: CompareIndexInfo() checks rd_opfamily for equality for all attributes, not only for key attribute. Obviously, CompareIndexInfo() needs

Re: 'make check' fails

Tom Lane wrote: > We can fix this by making submake-generated-headers be a recursive > prerequisite for "check" as well as "all" and "install". I wonder > whether anybody is expecting any other shortcuts to work. check-world certainly, but presumably that depends on check? -- Álvaro Herrera

Re: 'make check' fails

On Wed, Apr 11, 2018 at 12:35:41PM -0400, Tom Lane wrote: > Andrew Gierth writes: > > Tom> Please be more explicit about what state you're starting from. > > > This is consistently failing for me, on FreeBSD with GNU Make 4.2.1, > > clang 3.9.1, at commit

Re: 'make check' fails

Andrew Gierth writes: > Tom> Please be more explicit about what state you're starting from. > This is consistently failing for me, on FreeBSD with GNU Make 4.2.1, > clang 3.9.1, at commit 651cb90941: > git clean -dfx > ./configure

Re: WARNING in parallel index creation.

Andres Freund writes: > On 2018-03-12 20:44:01 -0700, Peter Geoghegan wrote: >> I wonder why DefineCustomStringVariable() does not set var->reset_val. >> We see that within DefineCustomEnumVariable(), >> DefineCustomRealVariable(), DefineCustomIntVariable(), etc. > Peter,

Re: 'make check' fails

> "Tom" == Tom Lane writes: Tom> No doubt this is related to the generated-headers changes I've Tom> been making, but I find your recipe confusing. "make clean" should Tom> not have removed the generated headers from the previous build. I Tom> can believe that if you

Re: relispartition for index partitions

Hello Andres Freund wrote: > On 2018-01-26 18:57:03 +0900, Amit Langote wrote: > > I noticed that relispartition isn't set for index's partitions. > > Is that intentional? > > This appears to be a question about >

Re: relispartition for index partitions

Hi, On 2018-01-26 18:57:03 +0900, Amit Langote wrote: > I noticed that relispartition isn't set for index's partitions. > > create table p (a int) partition by list (a); > create table p12 partition of p for values in (1, 2); > create index on p (a); > select relname, relkind from pg_class where

Re: 'make check' fails

On Wed, Apr 11, 2018 at 10:59:45AM -0400, Tom Lane wrote: > Bruce Momjian writes: > > I have discovered that: > > make clean; make check > > fails with: > > No doubt this is related to the generated-headers changes I've been > making, but I find your recipe confusing.

Re: missing support of named convention for procedures

Hi Peter, Pavel, On 2018-03-22 15:19:12 +0100, Pavel Stehule wrote: > attached patch should to fix it This is still broken, and has been an open item for a bit. Peter, Could you check whether Pavel's fix resolves the issue for you? Regards, Andres

Re: es_query_dsa is broken

Hi, On 2017-12-07 12:51:56 +1300, Thomas Munro wrote: > 1. Removing es_query_dsa and injecting the right context into the > executor tree as discussed. > > 2. Another idea mentioned by Robert in an off-list chat: We could > consolidate all DSM segments in a multi-gather plan into one. See

Re: WARNING in parallel index creation.

On 2018-03-12 20:44:01 -0700, Peter Geoghegan wrote: > On Sun, Mar 11, 2018 at 10:15 PM, Jeff Janes wrote: > > Then when I create in index, I get a warning: > > > > jjanes=# create index on pgbench_accounts (foobar(filler)); > > WARNING: cannot set parameters during a

Re: Creation of wiki page for open items of v11

Robert Haas writes: > On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane wrote: >> What *does* take time is adding a link to the commit, so I'd happily >> drop that step. As Peter says, you can usually look in the commit >> log if you care. > The trouble is

Re: lazy detoasting

Chapman Flack writes: > On 04/11/2018 10:41 AM, Tom Lane wrote: >> So maybe we need to take two steps back and talk about the semantics >> of what you're doing. > The mission is to implement java.sql.SQLXML, which has long been > missing from PL/Java. > This is the class

Re: lazy detoasting

On 04/11/2018 10:41 AM, Tom Lane wrote: > The core of the problem now is that in a READ COMMITTED transaction, we > may not be holding any snapshot at all between statements. So if you're > hanging onto a toast pointer across statements you're at risk. > > On the other hand, it's also arguable

Re: Creation of wiki page for open items of v11

On Wed, Apr 11, 2018 at 10:53 AM, Tom Lane wrote: > Ashutosh Bapat writes: >> On Wed, Apr 11, 2018 at 6:53 PM, Peter Eisentraut >> wrote: >>> Do people find it useful to move the resolved items to a separate

Re: 'make check' fails

Bruce Momjian writes: > I have discovered that: > make clean; make check > fails with: No doubt this is related to the generated-headers changes I've been making, but I find your recipe confusing. "make clean" should not have removed the generated headers from the

Re: Creation of wiki page for open items of v11

Ashutosh Bapat writes: > On Wed, Apr 11, 2018 at 6:53 PM, Peter Eisentraut > wrote: >> Do people find it useful to move the resolved items to a separate >> section on the page, instead of just removing them? I'm not sure that >>

Re: Bugs in TOAST handling, OID assignment and redo recovery

Pavan Deolasee writes: > Or may be we simply err on the side of caution and scan the toast table > with SnapshotAny while looking for a duplicate? That might prevent us from > reusing an OID for a known-dead tuple, but should save us a second index > scan and still work.

Re: lazy detoasting

Chapman Flack writes: > On 04/10/2018 10:17 PM, Jan Wieck wrote: >> If your session has a transaction snapshot that protects the old toast >> slices from being vacuumed away, you are fine. > That harks back to my earlier (naïve?) thought that, as long as > my lazy datum

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On Wed, 11 Apr 2018 07:29:09 -0700 Andres Freund wrote: > If that room can be found, I might be able to make it. Being in SF, I'm > probably the physically closest PG dev involved in the discussion. OK, I've dropped the PC a note; hopefully you'll be hearing from them. jon

Re: Transform for pl/perl

On 4/10/18 07:33, Dagfinn Ilmari Mannsåker wrote: > 1) both the jsonb_plperl and jsonb_plperlu extensions contain the SQL >functions jsonb_to_plperl and plperl_to_jsonb, so can't be installed >simultaneously > > 2) jsonb scalar values are passed to the plperl function wrapped in not >

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

Hi, On 2018-04-11 06:05:27 -0600, Jonathan Corbet wrote: > The event is April 23-25 in Park City, Utah. I bet that room could be > found for somebody from the postgresql community, should there be > somebody who would like to represent the group on this issue. Let me > know if an introduction

Re: lazy detoasting

On 04/10/2018 10:17 PM, Jan Wieck wrote: > If your session has a transaction snapshot that protects the old toast > slices from being vacuumed away, you are fine. That harks back to my earlier (naïve?) thought that, as long as my lazy datum doesn't have to outlive the transaction, lazy detoasting

Re: submake-errcodes

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes: > On Wed, 2018-04-11 at 09:38 -0400, Tom Lane wrote: >> *What* still doesn't work on current HEAD? I don't know what commands >> you are running to get this. > I think my build and Christoph's builds fail because of the same reason

Re: submake-errcodes

Hi, On Wed, 2018-04-11 at 09:38 -0400, Tom Lane wrote: > *What* still doesn't work on current HEAD? I don't know what commands > you are running to get this. I think my build and Christoph's builds fail because of the same reason again (the same as yesterday):

Re: WIP: Covering + unique indexes.

_bt_mark_page_halfdead() looked like it had a problem, but it now looks like I was wrong. I also verified every other BTreeInnerTupleGetDownLink() caller. It now looks like everything is good here. Right - it tries to find right page by conlsulting in parent page, by taking of next key. --

Re: Creation of wiki page for open items of v11

On Wed, Apr 11, 2018 at 6:53 PM, Peter Eisentraut wrote: > On 2/18/18 22:42, Michael Paquier wrote: >> Okay, I have created a skeleton of page here: >> https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items >> Feel free to add any bugs or issues related to v11

Re: Partitioned tables and covering indexes

Thank you, pushed Amit Langote wrote: Hi. On 2018/04/11 0:36, Teodor Sigaev wrote:     Does the attached fix look correct?  Haven't checked the fix with ATTACH     PARTITION though. Attached patch seems to fix the problem.  However, I would rather get rid of modifying stmt->indexParams. 

Re: Boolean partitions syntax

> On Apr 11, 2018, at 4:33 AM, Kyotaro HORIGUCHI > wrote: > > Thank you for the comments. > > At Wed, 11 Apr 2018 13:51:55 +0900, Amit Langote > wrote in > <3d0fda29-986c-d970-a22c-b4bd44f56...@lab.ntt.co.jp> >> Horiguchi-san,

Re: submake-errcodes

Christoph Berg writes: > It still doesn't work on current HEAD: *What* still doesn't work on current HEAD? I don't know what commands you are running to get this. regards, tom lane

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Mark Rofail wrote: > > In particular: it seemed to me that you decided to throw away the idea > > of the new GIN operator without sufficient evidence that it was > > unnecessary. > > I have to admit to that. But in my defence @> is also GIN indexable so the > only difference in performance

Re: lazy detoasting

On Wed, Apr 11, 2018 at 2:34 AM, Chapman Flack wrote: > On 04/10/2018 04:03 PM, Robert Haas wrote: > >> I suspect you want, or maybe need, to use the same snapshot as the >> scan that retrieved the tuple containing the toasted datum. > > I'm sure it's worth more than that,

Re: Creation of wiki page for open items of v11

On 2/18/18 22:42, Michael Paquier wrote: > Okay, I have created a skeleton of page here: > https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items > Feel free to add any bugs or issues related to v11 that need to be > tracked before the release. Do people find it useful to move the resolved

Re: segmentation fault in pg head with SQL function.

On 3/16/18 11:40, Tom Lane wrote: > Michael Paquier writes: >> On Fri, Mar 16, 2018 at 11:35:13AM +0530, Prabhat Sahu wrote: >>> postgres=# CREATE OR REPLACE FUNCTION func1() RETURNS VOID >>> LANGUAGE SQL >>> AS $$ >>> select 10; >>> $$; > >> Problem reproducible here, and

Re: [WIP] Document update for Logical Replication security

On 3/3/18 07:35, Shinoda, Noriyoshi wrote: > Hi, Hackers, > > The attached patch adds the following information to the document on Logical > Replication. > About the requirement of connection role of Logical Replication, written in > 31.7 of the manual is as follows. > -- > The role used for

Re: pgbench doc typos

On 3/30/18 03:30, Edmund Horner wrote: > On 30 March 2018 at 19:26, Fabien COELHO wrote: >> Thanks for the check. You might consider turning the patch as ready in the >> cf app. > > Ok, I have done so, since the patch is small and simple. > >>> Fixing the abs/hash

Re: [HACKERS] path toward faster partition pruning

Here's an idea. Why don't we move the function/opclass creation lines to insert.sql, without the DROPs, and use the same functions/opclasses in the three tests insert.sql, alter_table.sql, hash_part.sql and partition_prune.sql, i.e. not recreate what are essentially the same objects three times?

Re: User defined data types in Logical Replication

2018-04-11 10:16 GMT+09:00 Masahiko Sawada : > On Mon, Mar 19, 2018 at 7:57 PM, Masahiko Sawada > wrote: > > > > Attached an updated test patch added the above test(0002 patch). Since > > for this test case it's enough to use existing test functions

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On Tue, 10 Apr 2018 17:40:05 +0200 Anthony Iliopoulos wrote: > LSF/MM'18 is upcoming and it would > have been the perfect opportunity but it's past the CFP deadline. > It may still worth contacting the organizers to bring forward > the issue, and see if there is a chance to

  1   2   >