Re: [HACKERS] patch to fix unused variable warning on windows build

On Sat, Nov 9, 2013 at 7:29 PM, Amit Kapila wrote: > On Thu, Nov 7, 2013 at 11:43 AM, David Rowley > wrote: > > Attached is a small patch which fixes the unused variable warning in the > > visual studios build. Seems like VS does not support > > __attribute__((unused)) but looks like all other p

Re: [HACKERS] UTF8 national character data type support WIP patch and list of open issues.

From: "Robert Haas" On Tue, Nov 5, 2013 at 5:15 PM, Peter Eisentraut wrote: On 11/5/13, 1:04 AM, Arulappan, Arul Shaji wrote: Implements NCHAR/NVARCHAR as distinct data types, not as synonyms If, per SQL standard, NCHAR(x) is equivalent to CHAR(x) CHARACTER SET "cs", then for some "cs", NCH

[HACKERS] information schema parameter_default implementation

On 15 September 2013 01:35, Peter Eisentraut wrote: > > Here is an updated patch which fixes the bug you have pointed out. > > On Thu, 2013-01-31 at 18:59 +0500, Ali Dar wrote: > > > I checked our your patch. There seems to be an issue when we have OUT > > parameters after the DEFAULT values. > >

Re: [HACKERS] patch to fix unused variable warning on windows build

On Thu, Nov 7, 2013 at 11:43 AM, David Rowley wrote: > Attached is a small patch which fixes the unused variable warning in the > visual studios build. Seems like VS does not support > __attribute__((unused)) but looks like all other places we must assign to > the variable. I have raised same iss

[HACKERS] "Fix pg_isolation_regress to work outside its build directory" compiler warning

Commit 9b4d52f2095be96ca238ce41f6963ec56376491f introduced a new compiler warning to the windows visual studios build "D:\Postgres\b\pgsql.sln" (default target) (1) -> "D:\Postgres\b\pg_regress_ecpg.vcxproj" (default target) (88) -> (ClCompile target) -> src\interfaces\ecpg\test\pg_regress_ecpg.

Re: [HACKERS] TODO: Split out pg_resetxlog output into pre- and post-sections

On Fri, Nov 8, 2013 at 10:37 AM, Rajeev rastogi wrote: > On Fri, 08 November 2013 09:47 > >> On Tue, Nov 5, 2013 at 3:20 PM, Rajeev rastogi >> wrote: >> > On execution of pg_resetxlog using the option -n >> > >> > Please provide your opinion or expectation out of this patch. >> >> Your approach i

Re: [HACKERS] unaccent module - two params function should be immutable

Bruce Momjian writes: > [ mark unaccent functions immutable ] > Applied. This patch is flat out wrong and needs to be reverted. The functions were correctly marked (by you!) in commit c0577c92a84cc477a88fe6868c16c4a7e3348b11 on the basis of the discussion of bug #5781, http://www.postgresql.org

Re: [HACKERS] Suggestion: Issue warning when calling SET TRANSACTION outside transaction block

[ I'm so far behind ... ] Bruce Momjian writes: > Applied. Thank you for all your suggestions. I thought the suggestion had been to issue a *warning*. How did that become an error? This patch seems likely to break applications that may have just been harmlessly sloppy about when they were iss

Re: [HACKERS] logical changeset generation v6.5

On 11/8/13, 3:03 PM, Robert Haas wrote: > On Fri, Nov 8, 2013 at 12:38 PM, Robert Haas wrote: >> On Tue, Nov 5, 2013 at 10:21 AM, Andres Freund >> wrote: >>> Attached to this mail and in the xlog-decoding-rebasing-remapping branch >>> in my git[1] repository you can find the next version of the

Re: [HACKERS] backup.sgml-cmd-v003.patch

On 11/08/2013 03:42:56 PM, Joshua D. Drake wrote: > > On 11/08/2013 12:18 PM, Karl O. Pinc wrote: > > > > On 11/08/2013 02:12:56 PM, Robert Haas wrote: > >> On Fri, Nov 8, 2013 at 1:33 PM, Joshua D. Drake > >> > >> wrote: > Should I go ahead and apply that portion, then? > >>> I am certainl

Re: [HACKERS] backup.sgml-cmd-v003.patch

On 11/08/2013 12:18 PM, Karl O. Pinc wrote: On 11/08/2013 02:12:56 PM, Robert Haas wrote: On Fri, Nov 8, 2013 at 1:33 PM, Joshua D. Drake wrote: superuser privileges; it's the selective-dump case where you can often get by without them. I've attached a proposed patch along these lines f

Re: [HACKERS] ERROR during end-of-xact/FATAL

On Wed, Nov 06, 2013 at 10:14:53AM +0530, Amit Kapila wrote: > On Thu, Oct 31, 2013 at 8:22 PM, Noah Misch wrote: > > If the original AbortTransaction() pertained to a FATAL, the situation is > > worse. errfinish() promotes the ERROR thrown from AbortTransaction() to > > another FATAL, > > isn't

Re: [HACKERS] Minmax indexes

Alvaro Herrera escribió: > I have been playing with having the revmap in the main fork of the index > rather than a separate one. ... > This is not complete yet; although I have a proof-of-concept working, I > still need to write XLog support code and update the pageinspect code to > match. Just

Re: [HACKERS] Minmax indexes

Robert Haas escribió: > On Wed, Sep 25, 2013 at 4:34 PM, Alvaro Herrera > wrote: > > Here's an updated version of this patch, with fixes to all the bugs > > reported so far. Thanks to Thom Brown, Jaime Casanova, Erik Rijkers and > > Amit Kapila for the reports. > > I'm not very happy with the us

Re: [HACKERS] Gin page deletion bug

On 08.11.2013 19:14, Tom Lane wrote: Heikki Linnakangas writes: I came up with the attached fix. In a nutshell, when walking along a right-link, the new page is locked before releasing the lock on the old one. Also, never delete the leftmost branch of a posting tree. I believe these changes are

Re: [HACKERS] regclass error reports improperly downcased

Jim Nasby writes: > Ahh, duh. Hrm... I ran across this because someone here got confused by this: > SELECT pg_total_relation_size( schema_name || '.' || relname ) FROM > pg_stat_all_tables > ERROR: relation "moo" does not exist Personally I'd do that like select pg_total_relation_si

Re: [HACKERS] backup.sgml-cmd-v003.patch

On 11/08/2013 02:12:56 PM, Robert Haas wrote: > On Fri, Nov 8, 2013 at 1:33 PM, Joshua D. Drake > > wrote: > superuser privileges; it's the selective-dump case where you can > often > get by without them. I've attached a proposed patch along these > lines > for your consideration.

Re: [HACKERS] regclass error reports improperly downcased

On 11/7/13 6:41 PM, Tom Lane wrote: Jim Nasby writes: decibel@decina.cashnetusa=# SELECT 'Moo'::regclass; ERROR: relation "moo" does not exist at character 8 That's doing what it's supposed to. Compare regression=# select 'Moo'::regclass; ERROR: relation "moo" does not exist LINE 1: selec

Re: [HACKERS] backup.sgml-cmd-v003.patch

On Fri, Nov 8, 2013 at 1:33 PM, Joshua D. Drake wrote: superuser privileges; it's the selective-dump case where you can often get by without them. I've attached a proposed patch along these lines for your consideration. >>> That's fair. >> Should I go ahead and apply that portion,

Re: [HACKERS] logical changeset generation v6.5

On Fri, Nov 8, 2013 at 12:38 PM, Robert Haas wrote: > On Tue, Nov 5, 2013 at 10:21 AM, Andres Freund wrote: >> Attached to this mail and in the xlog-decoding-rebasing-remapping branch >> in my git[1] repository you can find the next version of the patchset that: > > I have pushed patches #1 and #

Re: [HACKERS] Protocol forced to V2 in low-memory conditions?

On Fri, Nov 8, 2013 at 2:23 PM, Tom Lane wrote: > [ still catching up on old email ] > > I wrote: >> Andrew Dunstan writes: >>> On 09/11/2013 02:30 PM, Robert Haas wrote: On Tue, Sep 10, 2013 at 9:53 AM, Tom Lane wrote: > Note that I was proposing removing libpq's support for V2 connect

Re: [HACKERS] Protocol forced to V2 in low-memory conditions?

[ still catching up on old email ] I wrote: > Andrew Dunstan writes: >> On 09/11/2013 02:30 PM, Robert Haas wrote: >>> On Tue, Sep 10, 2013 at 9:53 AM, Tom Lane wrote: Note that I was proposing removing libpq's support for V2 connections. Not the backend's. >>> I vote against this. I

Re: [HACKERS] Fix picksplit with nan values

Alexander Korotkov writes: > I wrote attached patch by following principles: > 1) NaN coordinates shouldn't crash or hang GiST. > 2) NaN coordinates should be processed in GiST index scan like in > sequential scan. > 3) NaN coordinates shouldn't lead to significant slowdown. I looked at this patc

Re: [HACKERS] backup.sgml-cmd-v003.patch

On 11/08/2013 06:04 AM, Robert Haas wrote: On Thu, Nov 7, 2013 at 11:37 AM, Joshua D. Drake wrote: This isn't software, it is docs. It is ridiculous to suggest we break this up into 3-4 patches. This is a small doc patch to a single doc file (backup.sgml). I don't think it's ridiculous, but

Re: [HACKERS] Fix picksplit with nan values

Alexander Korotkov writes: >> Thanks, Andrew! Good spot. >> I didn't examine order by operators for work with NaNs. >> I think this time problem is in GiST itself rather than in opclass. I'm >> going to fix it in a separate patch. > Attached patch fixes knn GiST behaviour with NaN. It makes RB-tr

Re: [HACKERS] Changing pg_dump default file format

On 11/07/2013 08:35 PM, Craig Ringer wrote: > I've seen all sorts of combinations of client and server versions in the > wild. Ancient JDBC, ODBC, etc drivers are also common. There's a security compromise out there for the 8.1 JDBC driver which was discovered last year, and folks *keep* reporting

Re: [HACKERS] Changing pg_dump default file format

I don't want to hijack this thread any further, but Craig, thanks for your insight. -Harold On Thu, Nov 7, 2013 at 8:35 PM, Craig Ringer wrote: > On 11/08/2013 11:41 AM, Harold Giménez wrote: > > > > > > > > On Thu, Nov 7, 2013 at 7:01 PM, Craig Ringer > > wrote:

Re: [HACKERS] logical changeset generation v6.5

On Tue, Nov 5, 2013 at 10:21 AM, Andres Freund wrote: > Attached to this mail and in the xlog-decoding-rebasing-remapping branch > in my git[1] repository you can find the next version of the patchset that: I have pushed patches #1 and #2 from this series as a single commit, after some editing.

Re: [HACKERS] Gin page deletion bug

Heikki Linnakangas writes: > I came up with the attached fix. In a nutshell, when walking along a > right-link, the new page is locked before releasing the lock on the old > one. Also, never delete the leftmost branch of a posting tree. I believe > these changes are sufficient to fix the proble

Re: [HACKERS] stats for network traffic WIP

Also still to be tested: performance impact. __ *Mike Blackwell | Technical Analyst, Distribution Services/Rollout Management | RR Donnelley* 1750 Wallace Ave | St Charles, IL 60174-3401 Office: 630.313.7818 mike.black

Re: [HACKERS] stats for network traffic WIP

Patch applies and builds against git HEAD (as of 6790e738031089d5). "make check" runs cleanly as well. The new features appear to work as advertised as far as I've been able to check. The code looks good as far as I can see. Documentation patches are included for the new features. Still to be

Re: [HACKERS] FDW: possible resjunk columns in AddForeignUpdateTargets

Tom Lane wrote: > Albe Laurenz writes: >> What I would like to do is add a custom resjunk column >> (e.g. a bytea) in AddForeignUpdateTargets that carries a row identifier >> from the scan state to the modify state. >> Would that be possible? Can I have anything else than a Var >> in a resjunk col

Re: [HACKERS] Gin page deletion bug

On 07.11.2013 22:49, Heikki Linnakangas wrote: Gin page deletion fails to take into account that there might be a search in-flight to the page that is deleted. If the page is reused for something else, the search can get very confused. ... The regular b-tree code solves this by stamping deleted

Re: [HACKERS] UTF8 national character data type support WIP patch and list of open issues.

On Tue, Nov 5, 2013 at 5:15 PM, Peter Eisentraut wrote: > On 11/5/13, 1:04 AM, Arulappan, Arul Shaji wrote: >> Implements NCHAR/NVARCHAR as distinct data types, not as synonyms > > If, per SQL standard, NCHAR(x) is equivalent to CHAR(x) CHARACTER SET > "cs", then for some "cs", NCHAR(x) must be th

Re: [HACKERS] Row-security writer-side checks proposal

On Wed, Nov 6, 2013 at 2:27 AM, Craig Ringer wrote: > Separate "READ DELETE" etc would only be interesting if we wanted to let > someone DELETE rows they cannot SELECT. Since we have DELETE ... > RETURNING, and since users can write a predicate function for DELETE > that leaks the information even

Re: [HACKERS] stats for network traffic WIP

On Tue, Oct 29, 2013 at 11:26 AM, Nigel Heron wrote: >> >> So, for now, the counters only track sockets created from an inbound >> (client to server) connection. > > here's v3 of the patch (rebase and cleanup). > Hi, here's v4 of the patch. I added documentation and a new global view called "pg_s

Re: [HACKERS] FDW: possible resjunk columns in AddForeignUpdateTargets

Albe Laurenz writes: > What I would like to do is add a custom resjunk column > (e.g. a bytea) in AddForeignUpdateTargets that carries a row identifier > from the scan state to the modify state. > Would that be possible? Can I have anything else than a Var > in a resjunk column? [ thinks for awhi

Re: [HACKERS] FDW: possible resjunk columns in AddForeignUpdateTargets

Tom Lane wrote: > Albe Laurenz writes: >> I have a question concerning the Foreign Data Wrapper API: >> I find no mention of this in the documentation, but I remember that >> you can only add a resjunk column that matches an existing attribute >> of the foreign table and not one with an arbitrary

Re: [HACKERS] ERROR during end-of-xact/FATAL

On Wed, Nov 6, 2013 at 9:40 AM, Alvaro Herrera wrote: > Noah Misch wrote: >> Incomplete list: >> >> - If smgrDoPendingDeletes() finds files to delete, mdunlink() and its callee >> relpathbackend() call palloc(); this is true in all supported branches. In >> 9.3, due to commit 279628a0, smgrDo

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On 08-11-2013 05:07, Jan Lentfer wrote: > For the case where you have tables of varying size this would lead to > a reduced overall processing time as it prevents large (read: long > processing time) tables to be processed in the last step. While > processing large tables at first and filling up "p

Re: [HACKERS] backup.sgml-cmd-v003.patch

On Thu, Nov 7, 2013 at 11:37 AM, Joshua D. Drake wrote: > This isn't software, it is docs. It is ridiculous to suggest we break this > up into 3-4 patches. This is a small doc patch to a single doc file > (backup.sgml). I don't think it's ridiculous, but you can certainly disagree. >> superuser

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On 08 November 2013 13:38, Jan Lentfer > For this use case, would it make sense to queue work (tables) in order of > their size, starting on the largest one? > For the case where you have tables of varying size this would lead to a > reduced overall processing time as it prevents large (read:

Re: [HACKERS] TODO: Split out pg_resetxlog output into pre- and post-sections

On Fri, 08 November 2013 09:47 > On Tue, Nov 5, 2013 at 3:20 PM, Rajeev rastogi > wrote: > > On execution of pg_resetxlog using the option -n > > > > 1. It will display values in two section. > > > > 2. First section will be called as "Current > pg_control > > valu

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

On 08 November 2013 03:22, Euler Taveira Wrote > On 07-11-2013 09:42, Dilip kumar wrote: > > Dilip, this is on my TODO for 9.4. I've already had a half-backed patch > for it. Let's see what I can come up with. Ok, Let me know if I can contribute to this.. > > Is it required to move the common

Re: [HACKERS] Heavily modified big table bloat even in auto vacuum is running

On Fri, Nov 8, 2013 at 10:56 AM, Haribabu kommi wrote: > On 07 November 2013 09:42 Amit Kapila wrote: >> I am not sure whether the same calculation as done for new_rel_tuples >> works for new_dead_tuples, you can once check it. > > I didn't find any way to calculate new_dead_tuples like new_rel_tu

[HACKERS] Improve code in tidbitmap.c

Hi, ISTM the code in tidbitmap.c should be improved. Patch attached. I think this patch increases the efficiency a bit. Thanks, Best regards, Etsuro Fujita diff --git a/src/backend/nodes/tidbitmap.c b/src/backend/nodes/tidbitmap.c index 3ef0112..43628ac 100644 --- a/src/backend/node

Re: [HACKERS] TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

Am 07.11.2013 12:42, schrieb Dilip kumar: > This patch implementing the following TODO item > > Allow parallel cores to be used by vacuumdb > > http://www.postgresql.org/message-id/4f10a728.7090...@agliodbs.com [1] > > Like Parallel pg_dump, vacuumdb is provided with the option to run th