Re: [HACKERS] Does people favor to have matrix data type?

Hi 2016-05-25 4:52 GMT+02:00 Kouhei Kaigai : > In a few days, I'm working for a data type that represents matrix in > mathematical area. Does people favor to have this data type in the core, > not only my extension? > > Like oidvector or int2vector, it is one of array type

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Kyotaro HORIGUCHI writes: > Shouldn't archive_close_connection have an assertion (si->AHX != > NULL) instead of checking "if (si->AHX)" in each path? I thought about that but didn't see any really good argument for it. It'd be making that function dependent on

Re: [HACKERS] Parallel pg_dump's error reporting doesn't work worth squat

Hello, # Note for convenience for others: The commit fixing the original # issue is 1aa41e3eae3746e05d0e23286ac740a9a6cee7df. At Mon, 23 May 2016 13:40:30 -0400, Tom Lane wrote in <1336.1464025...@sss.pgh.pa.us> > I wrote: > >> ... the pg_dump process has crashed with a

Re: [HACKERS] Error during restore - dump taken with pg_dumpall -c option

Rushabh, * Rushabh Lathia (rushabh.lat...@gmail.com) wrote: > On Fri, May 13, 2016 at 7:27 PM, Stephen Frost wrote: > > > * Rushabh Lathia (rushabh.lat...@gmail.com) wrote: > > > On master branch when we do pg_dumpall with -c option, I can see that > > > it also dumping the

Re: [HACKERS] To-Do item: skip table scan for adding column with provable check constraints

On 25 May 2016 at 06:56, Tom Lane wrote: > ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > > Tom Lane writes: > >> ... and if the CHECK expression is immutable ... > > > Doesn't it have to be already? > > AFAIK we don't insist on

[HACKERS] Does people favor to have matrix data type?

In a few days, I'm working for a data type that represents matrix in mathematical area. Does people favor to have this data type in the core, not only my extension? Like oidvector or int2vector, it is one of array type with a few restrictions: - 2 dimensional only - never contains NULL -

Re: [HACKERS] Inheritance

On 24 May 2016 at 22:45, Konstantin Knizhnik wrote: > There is one aspect of inheritance support which was not mentioned: > polymorphic queries. > Actually polymorphism is the fundamental feature of OOP, without it there > is no behavioral inheritance and inheritance

Re: [HACKERS] Inheritance

On 24 May 2016 at 21:51, Jim Nasby wrote: > On 5/23/16 10:30 PM, Craig Ringer wrote: > >> I find it notable that no popular ORM has bothered adopting PostgreSQL's >> inheritance features, and instead just use big left joins or repeated >> SELECTs to implement

Re: [HACKERS] Is the unfair lwlock behavior intended?

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Alexander Korotkov I've already observed such behavior, see [1]. I think that now there is no consensus on how to fix that. For instance, Andres express opinion that this shouldn't be fixed from

Re: [HACKERS] Parallel safety tagging of extension functions

All, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Andreas Karlsson writes: > > On 05/25/2016 02:41 AM, Robert Haas wrote: > >> I'd rather extend see us ALTER AGGREGATE to do this. > > > Wouldn't that prevent this from going into 9.6? I do not think changing > > ALTER AGGREGATE

Re: [HACKERS] Parallel safety tagging of extension functions

Andreas Karlsson writes: > Ok, then I can avoid touching all functions which are only called by > operator classes, tsearch, pls, fdws, etc. Which also means that there > is no need to care about Tom's changes to the signatures of GIN and GiST > support functions. I think

Re: [HACKERS] Parallel safety tagging of extension functions

Andreas Karlsson writes: > On 05/25/2016 02:41 AM, Robert Haas wrote: >> I'd rather extend see us ALTER AGGREGATE to do this. > Wouldn't that prevent this from going into 9.6? I do not think changing > ALTER AGGREGATE is 9.6 materials. Well, it's debatable --- but if the

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 03:09 AM, Robert Haas wrote: On Tue, May 24, 2016 at 8:41 PM, Robert Haas wrote: - Do you think we should add PARALLEL UNSAFE to the functions which we know are unsafe to make it obvious that it is intentional? That seems likely unnecessary churn from

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 02:41 AM, Robert Haas wrote: On Thu, May 19, 2016 at 5:50 PM, Andreas Karlsson wrote: - How should we modify the aggregate functions when upgrading extensions? ALTER AGGREGATE cannot change COMBINEFUNC or PARALLEL. My current patch updates the system catalogs

Re: [HACKERS] Parallel safety tagging of extension functions

On 05/25/2016 02:34 AM, Robert Haas wrote: On Fri, May 20, 2016 at 11:45 PM, Michael Paquier wrote: Sounds to me that this is part of the cleanup of a 9.6 feature and should be in that release. Yes, I agree. By the way, the patch completely ignores the fact that

Re: [HACKERS] Parallel safety tagging of extension functions

On Tue, May 24, 2016 at 8:41 PM, Robert Haas wrote: >> - Do you think we should add PARALLEL UNSAFE to the functions which we know >> are unsafe to make it obvious that it is intentional? > > That seems likely unnecessary churn from here. A general point here is that

[HACKERS] Re: new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump)

On Tue, May 24, 2016 at 08:19:20PM -0400, Robert Haas wrote: > On Sun, May 22, 2016 at 11:22 PM, Noah Misch wrote: > > Some or even most of the other tests would qualify under "closely related to > > ... a feature that is new in 9.6". Your 9.6 pg_dump changes affected object >

[HACKERS] RLS related docs

Please see attached two proposed patches for the docs related to RLS: 1) Correction to pg_restore 2) Additional mentions that "COPY FROM" does not allow RLS to be enabled Comments? Related question: I believe COPY tbl TO ... is internally converted to COPY (select * FROM tbl) TO ...

Re: [HACKERS] Is the unfair lwlock behavior intended?

On Tue, May 24, 2016 at 3:50 PM, Andres Freund wrote: >> Jim Gray's paper on the "Convoy phenomenon" remains relevant, decades later: >> >> http://www.msr-waypoint.com/en-us/um/people/gray/papers/Convoy%20Phenomenon%20RJ%202516.pdf >> >> I could believe that there's a case to

Re: [HACKERS] Parallel safety tagging of extension functions

On Thu, May 19, 2016 at 5:50 PM, Andreas Karlsson wrote: > - How should we modify the aggregate functions when upgrading extensions? > ALTER AGGREGATE cannot change COMBINEFUNC or PARALLEL. My current patch > updates the system catalogs directly, which should be safe in this

Re: [HACKERS] Parallel safety tagging of extension functions

On Sat, May 21, 2016 at 1:01 PM, Andreas Karlsson wrote: > Another question which I thought of is what we should do with functions like > pg_file_write() in adminpack. > > While it is perfectly fine to modify files from the parallel workers, a user > could get race conditions

Re: [HACKERS] Parallel safety tagging of extension functions

On Fri, May 20, 2016 at 11:45 PM, Michael Paquier wrote: >> Sounds to me that this is part of the cleanup of a 9.6 feature and should be >> in that release. > > Yes, I agree. By the way, the patch completely ignores the fact that > some of the modules already had a

Re: [HACKERS] [BUGS] BUG #14155: bloom index error with unlogged table

Moving my griping to -hackers only On Tue, May 24, 2016 at 8:08 PM, Tom Lane wrote: > dig...@126.com writes: > > postgres=# create unlogged table u_tbl (id int); > > CREATE TABLE > > postgres=# create index idx_u_tbl on u_tbl using bloom (id); > > ERROR: index "idx_u_tbl"

Re: [HACKERS] new tests post-feature freeze (was pgsql: Add TAP tests for pg_dump)

On Sun, May 22, 2016 at 11:22 PM, Noah Misch wrote: > Some or even most of the other tests would qualify under "closely related to > ... a feature that is new in 9.6". Your 9.6 pg_dump changes affected object > selection and catalog extraction for most object types, so I think

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

Alvaro Herrera writes: > How long does it take for you to reproduce this panic in the unpatched > code? Very long, I'm afraid. I only observed it once, and according to the logging database, about 4e9 random queries were generated since testing with 9.5 code. I could probably speed it up by

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

Andreas Seltenreich wrote: > There was one instance of this PANIC when testing with the regression db > of master at 50e5315. > > , > | WARNING: specified item offset is too large > | PANIC: failed to add BRIN tuple > | server closed the connection unexpectedly > ` > > It is

Re: [HACKERS] To-Do item: skip table scan for adding column with provable check constraints

ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes: > Tom Lane writes: >> ... and if the CHECK expression is immutable ... > Doesn't it have to be already? AFAIK we don't insist on that currently. You could imagine useful checks that are not, for example

Re: [HACKERS] statistics for shared catalogs not updated when autovacuum is off

Michael Paquier writes: > The problem is different I think. Since 9.3, database-related > statistics are located on separate files. And the statistics of shared > tables is visibly located in a file with database name set as > InvalidOid, leading to the presence of

Re: [HACKERS] Is the unfair lwlock behavior intended?

On 2016-05-24 15:34:31 -0700, Peter Geoghegan wrote: > On Tue, May 24, 2016 at 1:38 PM, Ants Aasma wrote: > >> I've already observed such behavior, see [1]. I think that now there is no > >> consensus on how to fix that. For instance, Andres express opinion that > >> this

Re: [HACKERS] Is the unfair lwlock behavior intended?

On Tue, May 24, 2016 at 1:38 PM, Ants Aasma wrote: >> I've already observed such behavior, see [1]. I think that now there is no >> consensus on how to fix that. For instance, Andres express opinion that >> this shouldn't be fixed from LWLock side [2]. >> FYI, I'm planning

Re: [HACKERS] Is the unfair lwlock behavior intended?

On 2016-05-24 17:20:48 -0400, Robert Haas wrote: > On Tue, May 24, 2016 at 4:39 PM, Ants Aasma wrote: > > On Tue, May 24, 2016 at 9:03 AM, Tsunakawa, Takayuki > > wrote: > >> I encountered a strange behavior of lightweight lock in PostgreSQL

Re: [HACKERS] effective_io_concurrency in 9.6beta

On Tue, May 24, 2016 at 11:34 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> Jeff Janes writes: >> > commit 1aba62ec made zero be an illegal value for effective_io_concurrency. >> > i think this was an accident. If not, then the sample

Re: [HACKERS] Allow COPY to use parameters

> "Merlin" == Merlin Moncure writes: Merlin> Hm, what's the use case preparing COPY? Preparing it isn't necessarily the point (and SQL-level PREPARE is not addressed in that patch). The point is to allow parameters, so that a client can do COPY (select blah from

Re: [HACKERS] To-Do item: skip table scan for adding column with provable check constraints

Tom Lane writes: > Robert Haas writes: >> Right. If there were a DEFAULT on the new column that would of course >> be different, and you can also do thinks like CHECK (a != b) here. >> However, if the CHECK constraint does not reference any column

Re: [HACKERS] Speaking of breaking compatibility...standard_conforming_strings

On Tue, May 24, 2016 at 4:07 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, May 24, 2016 at 3:57 PM, Tom Lane wrote: > >> "David G. Johnston" writes: >> > I just noticed this comment in scan.l: >> > /* >> > * GUC variables.

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-05-24 16:09:27 -0500, Kevin Grittner wrote: > On Tue, May 24, 2016 at 3:54 PM, Andres Freund wrote: > > > what about e.g. concurrent index builds? E.g. IndexBuildHeapRangeScan() > > doesn't > > seem to contain any checks against outdated blocks > > Why would it?

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, May 24, 2016 at 4:09 PM, Kevin Grittner wrote: > On Tue, May 24, 2016 at 3:54 PM, Andres Freund wrote: >> It appears that concurrent index builds are currently broken >> from a quick skim? > > Either you don't understand this feature very well, or

Re: [HACKERS] To-Do item: skip table scan for adding column with provable check constraints

Robert Haas writes: > Right. If there were a DEFAULT on the new column that would of course > be different, and you can also do thinks like CHECK (a != b) here. > However, if the CHECK constraint does not reference any column other > than the newly-added one, and if the

Re: [HACKERS] Allow COPY to use parameters

Merlin Moncure writes: > Hm, what's the use case preparing COPY? Note, the biggest pain point > I have with COPY is not being able to parameterize the filename > argument. Yeah. But putting a parameter symbol there (or anywhere in a utility statement that's not part of an

Re: [HACKERS] To-Do item: skip table scan for adding column with provable check constraints

On Thu, May 19, 2016 at 7:33 PM, Jeff Janes wrote: > I recently had to run something like: > > alter table pgbench_accounts add locked text check (locked != 'unlocked'); > > And was surprised that it took several minutes to complete as it > scanned the whole table. > > The

Re: [HACKERS] [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

Robert Haas wrote: > On Tue, May 24, 2016 at 10:12 AM, Nikolay Shaplov > wrote: > > While working on patch for attribute options for indexes (see > > http://www.postgresql.org/message-id/5213596.TqFRiqmCTe@nataraj-amd64 ) > > I found out that code for reloptions is not

Re: [HACKERS] [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

On Tue, May 24, 2016 at 10:12 AM, Nikolay Shaplov wrote: > While working on patch for attribute options for indexes (see > http://www.postgresql.org/message-id/5213596.TqFRiqmCTe@nataraj-amd64 ) > I found out that code for reloptions is not flexible at all. > > All

Re: [HACKERS] Is the unfair lwlock behavior intended?

On Tue, May 24, 2016 at 4:39 PM, Ants Aasma wrote: > On Tue, May 24, 2016 at 9:03 AM, Tsunakawa, Takayuki > wrote: >> I encountered a strange behavior of lightweight lock in PostgreSQL 9.2. >> That appears to apply to 9.6, too, as far as I

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, May 24, 2016 at 4:10 PM, Robert Haas wrote: > For purposes of > "snapshot too old", though, it will be important that a function in an > index which tries to read data from some other table which has been > pruned cancels itself when necessary. Hm. I'll try to

Re: [HACKERS] Possible regression regarding estimating relation width in FDWs

Ronan Dunklau writes: > While working on adapting the Multicorn FDW for 9.6, I noticed that there is > a > regression with regards to estimating the remote relation width. Hm. In the old code it was basically a chance artifact that this example happens to produce

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, May 24, 2016 at 3:48 PM, Kevin Grittner wrote: > On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote: >> On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote: >>> On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote: On Fri,

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, May 24, 2016 at 3:54 PM, Andres Freund wrote: > what about e.g. concurrent index builds? E.g. IndexBuildHeapRangeScan() > doesn't > seem to contain any checks against outdated blocks Why would it? We're talking about blocks where there were dead tuples, with the

Re: [HACKERS] Allow COPY to use parameters

On Tue, May 24, 2016 at 3:42 PM, David Fetter wrote: > On Tue, May 24, 2016 at 02:16:40PM -0400, Tom Lane wrote: >> David Fetter writes: >> > Per discussion on IRC and some test code, COPY can't take parameters >> > in a PREPARE, which feature would make it

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-05-24 14:48:35 -0500, Kevin Grittner wrote: > On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote: > > On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote: > >> On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote: > >>> On Fri, May 6, 2016 at 7:48

Re: [HACKERS] Allow COPY to use parameters

On Tue, May 24, 2016 at 02:16:40PM -0400, Tom Lane wrote: > David Fetter writes: > > Per discussion on IRC and some test code, COPY can't take parameters > > in a PREPARE, which feature would make it even more useful. > > Uh, what? > > regression=# prepare foo as copy c from

Re: [HACKERS] Is the unfair lwlock behavior intended?

On Tue, May 24, 2016 at 9:03 AM, Tsunakawa, Takayuki wrote: > I encountered a strange behavior of lightweight lock in PostgreSQL 9.2. That > appears to apply to 9.6, too, as far as I examine the code. Could you tell > me if the behavior is intended or needs

Re: [HACKERS] Is the unfair lwlock behavior intended?

On Tue, May 24, 2016 at 1:29 PM, Alexander Korotkov wrote: > On Tue, May 24, 2016 at 9:03 AM, Tsunakawa, Takayuki > wrote: >> Is this intentional, or should we make the later share-lockers if someone >> is in the wait queue? > > I've

Re: [HACKERS] Speaking of breaking compatibility...standard_conforming_strings

On Tue, May 24, 2016 at 3:57 PM, Tom Lane wrote: > "David G. Johnston" writes: > > I just noticed this comment in scan.l: > > /* > > * GUC variables. This is a DIRECT violation of the warning given at the > > * head of gram.y, ie flex/bison

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

Kevin Grittner wrote: > On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote: > > On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote: > >> On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote: > >>> On Fri, May 6, 2016 at 7:48 PM, Andres Freund

Re: [HACKERS] Speaking of breaking compatibility...standard_conforming_strings

"David G. Johnston" writes: > I just noticed this comment in scan.l: > /* > * GUC variables. This is a DIRECT violation of the warning given at the > * head of gram.y, ie flex/bison code must not depend on any GUC variables; > * as such, changing their values can

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote: > On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote: >> On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote: >>> On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote: >> That

Re: [HACKERS] Bug in intarray bench script

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested The patch changes the benchmark tool in a way that the explain output is

[HACKERS] Speaking of breaking compatibility...standard_conforming_strings

I just noticed this comment in scan.l: /* * GUC variables. This is a DIRECT violation of the warning given at the * head of gram.y, ie flex/bison code must not depend on any GUC variables; * as such, changing their values can induce very unintuitive behavior. * But we shall have to live with

Re: [HACKERS] Autovacuum to prevent wraparound tries to consume xid

Alexander Korotkov writes: > On Sun, May 22, 2016 at 12:39 PM, Amit Kapila > wrote: >> As per your latest patch, you are using ReadNewTransactionId() to get the >> nextXid which then is used to check if any database's frozenxid is already >>

Re: [HACKERS] effective_io_concurrency in 9.6beta

Tom Lane wrote: > Jeff Janes writes: > > commit 1aba62ec made zero be an illegal value for effective_io_concurrency. > > i think this was an accident. If not, then the sample postgresql.conf > > (at least) needs to be updated. > > It looks like the problem is that the new

Re: [HACKERS] effective_io_concurrency in 9.6beta

Jeff Janes writes: > commit 1aba62ec made zero be an illegal value for effective_io_concurrency. > i think this was an accident. If not, then the sample postgresql.conf > (at least) needs to be updated. It looks like the problem is that the new range check + /* This

[HACKERS] Allow COPY to use parameters

Folks, Per discussion on IRC and some test code, COPY can't take parameters in a PREPARE, which feature would make it even more useful. To make this work, we'd need to: - do parse analysis immediately - parameterize all the options This doesn't seem like a gigantic lift. What say? Cheers,

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-05-24 13:04:09 -0500, Kevin Grittner wrote: > On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote: > > > Analyze IIRC acquires a new snapshot when getting sample rows, > > I could not find anything like that, and a case-insensitive search > of analyze.c finds no

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

Kevin Grittner writes: > On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote: >> Analyze IIRC acquires a new snapshot when getting sample rows, > I could not find anything like that, and a case-insensitive search > of analyze.c finds no occurrences of

Re: [HACKERS] Allow COPY to use parameters

David Fetter writes: > Per discussion on IRC and some test code, COPY can't take parameters > in a PREPARE, which feature would make it even more useful. Uh, what? regression=# prepare foo as copy c from stdin; ERROR: syntax error at or near "copy" LINE 1: prepare foo as copy

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

Kevin Grittner wrote: > On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote: > > > Analyze IIRC acquires a new snapshot when getting sample rows, > > I could not find anything like that, and a case-insensitive search > of analyze.c finds no occurrences of "snap". Can you

[HACKERS] effective_io_concurrency in 9.6beta

commit 1aba62ec made zero be an illegal value for effective_io_concurrency. i think this was an accident. If not, then the sample postgresql.conf (at least) needs to be updated. Cheers, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Tue, May 24, 2016 at 12:00 PM, Andres Freund wrote: > Analyze IIRC acquires a new snapshot when getting sample rows, I could not find anything like that, and a case-insensitive search of analyze.c finds no occurrences of "snap". Can you remember where you think you saw

[HACKERS] Windows 7/8, Visual Studio 2013: Runtime error r6034 microsoft visual c++ runtime library(pgadmin3.exe)

I have been able to build PgAdmin3 after several days of hassle on creating PgAdmin3 installer. However, after installing the installer pgadmin3 msi, a generic and difficult runtime error to figure out appears when I try to open the pgadmin3.exe. To iterate, the following error appears: Runtime

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On 2016-05-24 11:24:44 -0500, Kevin Grittner wrote: > On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote: > > On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote: > > >> That comment reminds me of a question I had: Did you consider the effect > >> of

Re: [HACKERS] [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

Nikolay Shaplov writes: > If I read gram.y code for insert statement, I see that there is an optional > USING keyword before opclass name > opt_class: any_name{ $$ = $1; } > | USING any_name{ $$ = $2;

Re: [HACKERS] pg_dump -j against standbys

On Tue, May 24, 2016 at 7:02 AM, Jim Nasby wrote: > On 5/24/16 6:27 AM, Magnus Hagander wrote: >> >> pg_dump: Synchronized snapshots are not supported on standby servers. > > > Would it be that much harder to support this use case, perhaps by having the > replica request

Re: [HACKERS] LSN as a recovery target

On Tue, May 24, 2016 at 9:29 AM, Alvaro Herrera wrote: > Christoph Berg wrote: >> Re: Michael Paquier 2016-05-24 >>

Re: [HACKERS] LSN as a recovery target

Christoph Berg wrote: > Re: Michael Paquier 2016-05-24 >

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Fri, May 6, 2016 at 8:28 PM, Kevin Grittner wrote: > On Fri, May 6, 2016 at 7:48 PM, Andres Freund wrote: >> That comment reminds me of a question I had: Did you consider the effect >> of this patch on analyze? It uses a snapshot, and by memory you've

Re: [HACKERS] LSN as a recovery target

Re: Michael Paquier 2016-05-24

Re: [HACKERS] pg_dump -j against standbys

Magnus Hagander writes: > I think the cleanest way to do it is to just track if it's a standby in the > AH struct as written. > Comments? This patch will cause pg_dump to fail entirely against pre-9.0 servers. You need to execute the test conditionally. Also, in view of

Re: [HACKERS] Inheritance

There is one aspect of inheritance support which was not mentioned: polymorphic queries. Actually polymorphism is the fundamental feature of OOP, without it there is no behavioral inheritance and inheritance can be considered just as "syntax sugar" for sharing some common subset of attributes

Re: [HACKERS] BTREE_BUILD_STATS build is broken

Peter Geoghegan writes: > On Mon, May 23, 2016 at 8:09 PM, Tom Lane wrote: >> (More generally, is there a better answer for that problem?) > My unpublished parallel B-Tree index build patch will move everything > to do with index builds into nbtsort.c.

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On 5/16/16 2:36 AM, Bruce Momjian wrote: Right. I am thinking of writing some docs about how to avoid downtime for upgrades of various types. If there's some magic sauce to shrink pg_upgrade downtime to near 0 I think folks would be very interested in that. Outside of that scenario, I

[HACKERS] [PROPOSAL] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind

While working on patch for attribute options for indexes (see http://www.postgresql.org/message-id/5213596.TqFRiqmCTe@nataraj-amd64 ) I found out that code for reloptions is not flexible at all. All definitions of attoptons are stored in central catalog in

Re: [HACKERS] Calling json_* functions with JSONB data

On 5/23/16 4:45 PM, David G. Johnston wrote: On Mon, May 23, 2016 at 5:38 PM, Jim Nasby >wrote: On 5/23/16 11:55 AM, Peter van Hardenberg wrote: Fortunately, this seems quite easy to resolve by taking advantage of

[HACKERS] [PROPOSAL][PROTOTYPE] Individual options for each index column: Opclass options

Hi! There was an interesting idea. Now it is possible to add in runtime options for relation, when you are creating a new extension with new access method. But if you add a custom operator class, you have no tool to tune it's behavior. But in some cases it would be nice to have such tool.

Re: [HACKERS] pg_dump -j against standbys

On 5/24/16 6:27 AM, Magnus Hagander wrote: pg_dump: Synchronized snapshots are not supported on standby servers. Would it be that much harder to support this use case, perhaps by having the replica request the snapshot from the master on the client's behalf? It certainly doesn't surprise me

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 5/23/16 4:19 AM, Craig Ringer wrote: +Batching less useful when information from one operation is required by the SB "Batching is less useful". -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it

Re: [HACKERS] Inheritance

On 5/23/16 10:30 PM, Craig Ringer wrote: I find it notable that no popular ORM has bothered adopting PostgreSQL's inheritance features, and instead just use big left joins or repeated SELECTs to implement parent/child relationships, with foreign keys enforcing constraints. Since when do we

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

Amit Kapila writes: > On Mon, May 23, 2016 at 4:48 PM, Andreas Seltenreich > wrote: >> plan6 corresponds to this query: >> > Are you sure that the core dumps you are seeing are due to plan6? Each of the plans sent was harvested from a controlling process when the above

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

On Mon, May 23, 2016 at 4:48 PM, Andreas Seltenreich wrote: > > Amit Kapila writes: > > > Earlier problems were due to the reason that some unsafe/restricted > > expressions were pushed below Gather node as part of target list whereas in > > the plan6, it seems some unsafe

Re: [HACKERS] [PATCH] add missing "USING bloom" into bloom extension documentation

you should add "USING bloom" to the insert statement, in order make this example work. Patch in the attachment fixes an example. Please commit it ;-) Thank you, applied -- Teodor Sigaev E-mail: teo...@sigaev.ru

[HACKERS] [PATCH] add missing "USING bloom" into bloom extension documentation

In current bloom documentation an example CREATE INDEX bloomidx ON tbloom(i1,i2,i3) WITH (length=5, col1=2, col2=2, col3=4); does not work, as it does not actually create a bloom index you should add "USING bloom" to the insert statement, in order make this example work. Patch in the

[HACKERS] pg_dump -j against standbys

pg_dump -j against a standby server returns a pretty bad error message when pointed at a standby node: pg_dump: [archiver (db)] query failed: ERROR: cannot assign TransactionIds during recovery pg_dump: [archiver (db)] query was: SELECT pg_export_snapshot() That looks quite scary to the user,

Re: [HACKERS] Is the unfair lwlock behavior intended?

Hi! On Tue, May 24, 2016 at 9:03 AM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > I encountered a strange behavior of lightweight lock in PostgreSQL 9.2. > That appears to apply to 9.6, too, as far as I examine the code. Could you > tell me if the behavior is intended or needs

[HACKERS] Is the unfair lwlock behavior intended?

Hello, I encountered a strange behavior of lightweight lock in PostgreSQL 9.2. That appears to apply to 9.6, too, as far as I examine the code. Could you tell me if the behavior is intended or needs fix? Simply put, the unfair behavior is that waiters for exclusive mode are overtaken by