Re: [HACKERS] [PATCH] Generalized JSON output functions

> Yes, but I think the plugin is the right place to do it. What is more, this won't actually prevent you completely from producing non-ECMAScript compliant JSON, since json or jsonb values containing offending numerics won't be caught, AIUI. Ah, that's a good catch indeed. > But a fairly simple t

Re: [HACKERS] TABLESAMPLE doesn't actually satisfy the SQL spec, does it?

On 12 July 2015 at 18:50, Tom Lane wrote: > Robert Haas writes: > > On Sun, Jul 12, 2015 at 12:02 PM, Tom Lane wrote: > >> As best I can tell (evidence below), the SQL standard requires that if a > >> single query reads a table with a TABLESAMPLE clause multiple times > (say, > >> because it's

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

On Mon, Jul 13, 2015 at 06:19:49PM -0400, Andrew Dunstan wrote: > >>>On 7/13/2015 5:36 PM, Andrew Dunstan wrote: > hstore_plpython.o: In function `hstore_to_plpython': > /home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35: > undefined reference to `PLyUnicode_

Re: [HACKERS] Forensic recovery deleted pgdump custom format file

On Tue, Jul 14, 2015 at 11:20 AM, David Guimaraes wrote: > Yeah bingo Hm. While there is a magic-code header for the custom format, by looking at the code I am not seeing any traces of a similar thing at the end of the dump file (_CloseArchive in pg_backup_custom.c), and I don't recall wither tha

Re: [HACKERS] Forensic recovery deleted pgdump custom format file

Yeah bingo Em 13/07/2015 22:11, "Michael Paquier" escreveu: > On Tue, Jul 14, 2015 at 10:58 AM, David Guimaraes > wrote: > > The backups were deleted. I need them to use pg_restore. > > So what you mean is that you are looking at your disk at FS level to > find traces of those deleted backups by

Re: [HACKERS] Forensic recovery deleted pgdump custom format file

On Tue, Jul 14, 2015 at 10:58 AM, David Guimaraes wrote: > The backups were deleted. I need them to use pg_restore. So what you mean is that you are looking at your disk at FS level to find traces of those deleted backups by analyzing their binary format... Am I missing something? -- Michael -

Re: [HACKERS] Forensic recovery deleted pgdump custom format file

The backups were deleted. I need them to use pg_restore. Em 13/07/2015 21:18, "Michael Paquier" escreveu: > On Tue, Jul 14, 2015 at 9:28 AM, David Guimaraes > wrote: > > So I decided to try to understand the file format generated by > > pgdump. Analyzing the source code of pgdump/recovery, i con

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

On Tue, Jul 14, 2015 at 9:00 AM, Michael Paquier wrote: > On Mon, Jul 13, 2015 at 10:34 PM, Fujii Masao wrote: >> On Fri, Jul 10, 2015 at 10:06 PM, Beena Emerson wrote: >>> On Tue, Jul 7, 2015 at 2:19 PM, Michael Paquier wrote: >>> Something like pg_syncinfo/ coupled with a LW lock, we alread

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

On 07/13/2015 07:55 PM, Michael Paquier wrote: On Tue, Jul 14, 2015 at 8:49 AM, Andrew Dunstan wrote: On 07/13/2015 07:33 PM, Tom Lane wrote: Andrew Dunstan writes: Not AFAICT. Here is the contrib build: Hm ... what does -DUSE_DL_IMPORT do? NFI - I tried building with that but it made no

Re: [HACKERS] Forensic recovery deleted pgdump custom format file

On Tue, Jul 14, 2015 at 9:28 AM, David Guimaraes wrote: > So I decided to try to understand the file format generated by > pgdump. Analyzing the source code of pgdump/recovery, i concluded a few > things: > > The header of the file always starts with "PGDMP" followed by pgdump version > number use

[HACKERS] Forensic recovery deleted pgdump custom format file

Hello. I need some help. I have the following situation. My client deleted a number of old backups from a drive disc made by PGDUMP with custom flag activated. I could not find any program to recover backup files made by PGDUMP of customized / binary form. So I decided to try to understand the fil

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

On Mon, Jul 13, 2015 at 10:34 PM, Fujii Masao wrote: > On Fri, Jul 10, 2015 at 10:06 PM, Beena Emerson wrote: >> On Tue, Jul 7, 2015 at 2:19 PM, Michael Paquier wrote: >> >>> Something like pg_syncinfo/ coupled with a LW lock, we already do >>> something similar for replication slots with pg_replsl

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

On Tue, Jul 14, 2015 at 8:49 AM, Andrew Dunstan wrote: > > On 07/13/2015 07:33 PM, Tom Lane wrote: >> >> Andrew Dunstan writes: >>> >>> Not AFAICT. Here is the contrib build: >> >> Hm ... what does -DUSE_DL_IMPORT do? > > NFI - I tried building with that but it made no difference. Is your python

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

On 07/13/2015 07:33 PM, Tom Lane wrote: Andrew Dunstan writes: Not AFAICT. Here is the contrib build: Hm ... what does -DUSE_DL_IMPORT do? NFI - I tried building with that but it made no difference. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

Andrew Dunstan writes: > Not AFAICT. Here is the contrib build: Hm ... what does -DUSE_DL_IMPORT do? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-h

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

On 13 July 2015 at 17:00, Tom Lane wrote: > I wrote: > > TBH, I think the right thing to do at this point is to revert the entire > > patch and send it back for ground-up rework. I think the high-level > > design is wrong in many ways and I have about zero confidence in most > > of the code deta

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

On 07/13/2015 05:18 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/13/2015 11:53 AM, Marco Atzeri wrote: On 7/13/2015 5:36 PM, Andrew Dunstan wrote: hstore_plpython.o: In function `hstore_to_plpython': /home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35: undefine

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

Andrew Dunstan writes: > On 07/13/2015 11:53 AM, Marco Atzeri wrote: >> On 7/13/2015 5:36 PM, Andrew Dunstan wrote: >>> hstore_plpython.o: In function `hstore_to_plpython': >>> /home/andrew/bf64/root/HEAD/pgsql/contrib/hstore_plpython/hstore_plpython.c:35: >>> >>> undefined reference to `PLyUnic

Re: [HACKERS] [DESIGN] Incremental checksums

On 2015-07-13 15:50:44 -0500, Jim Nasby wrote: > Another possibility is some kind of a page-level indicator of what binary > format is in use on a given page. For checksums maybe a single bit would > suffice (indicating that you should verify the page checksum). Another use > case is using this to

Re: [HACKERS] [PATCH] SQL function to report log message

Jim Nasby writes: > On 7/13/15 3:39 PM, dinesh kumar wrote: >> Ah. It's' my bad interpretation. Let me work on it, and will send a new >> patch as a wrapper sql function for ereport. > You might want to present a plan for that; it's not as trivial as it > sounds due to how ereport works. In part

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

On 07/13/2015 11:53 AM, Marco Atzeri wrote: On 7/13/2015 5:36 PM, Andrew Dunstan wrote: On 07/12/2015 05:06 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/04/2015 11:02 AM, Tom Lane wrote: It's not apparent to me how that works at all. BTW, the .a files being linked to above are not lik

Re: [HACKERS] [DESIGN] Incremental checksums

> On Jul 13, 2015, at 3:50 PM, Jim Nasby wrote: > > On 7/13/15 3:26 PM, David Christensen wrote: >> * Incremental Checksums >> >> PostgreSQL users should have a way up upgrading their cluster to use data >> checksums without having to do a costly pg_dump/pg_restore; in particular, >> checksum

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 1:56 PM, Jim Nasby wrote: > On 7/13/15 3:39 PM, dinesh kumar wrote: > >> I don't really see the point of what you're describing here. Just do >> something like RAISE WARNING which should normally be high enough to >> make it into the logs. Or use a pl language

Re: [HACKERS] [PATCH] SQL function to report log message

On 7/13/15 3:39 PM, dinesh kumar wrote: I don't really see the point of what you're describing here. Just do something like RAISE WARNING which should normally be high enough to make it into the logs. Or use a pl language that will let you write your own logfile on the server (ie:

Re: [HACKERS] [DESIGN] Incremental checksums

On 7/13/15 3:26 PM, David Christensen wrote: * Incremental Checksums PostgreSQL users should have a way up upgrading their cluster to use data checksums without having to do a costly pg_dump/pg_restore; in particular, checksums should be able to be enabled/disabled at will, with the database

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 1:29 PM, Jim Nasby wrote: > On 7/13/15 12:39 PM, dinesh kumar wrote: > >> > As of now, we don't have an SQL function to write >> custom/application >> > messages to log destination. We have "RAISE" clause which is >> controlled by >> > log_ parameters. If w

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Tue, Jul 7, 2015 at 6:28 AM, Kyotaro HORIGUCHI wrote: > Please forgive me to resend this message for some too-sad > misspellings. > > # "Waiting for heavy weight locks" is somewhat confusing to spell.. > > === > Hello, > > At Tue, 7 Jul 2015 16:27:38 +0900, Fujii Masao wrote > in >> Each bac

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Jul 6, 2015 at 10:48 AM, Fujii Masao wrote: > According to his patch, the wait events that he was thinking to add were: > > + typedef enum PgCondition > + { > + PGCOND_UNUSED= 0,/* unused */ > + > + /* 1 - CPU */ > + PGCOND_CPU= 1

Re: [HACKERS] [PATCH] SQL function to report log message

On 7/13/15 12:39 PM, dinesh kumar wrote: > As of now, we don't have an SQL function to write custom/application > messages to log destination. We have "RAISE" clause which is controlled by > log_ parameters. If we have an SQL function which works irrespective of log > setting

[HACKERS] [DESIGN] Incremental checksums

pgsql-hackers, So I’ve put some time into a design for the incremental checksum feature and wanted to get some feedback from the group: * Incremental Checksums PostgreSQL users should have a way up upgrading their cluster to use data checksums without having to do a costly pg_dump/pg_restore;

Re: [HACKERS] A little RLS oversight?

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 oversight of RLS. Even if a policy is > defined to prevent a user

Re: [HACKERS] pg_upgrade + Extensions

On 07/13/2015 01:12 PM, Smitha Pamujula wrote: Yes. I have checked that the extension didn't exist in any of the databases. I used \dx to see if there was json_build was listed and i didnt see any. Is that sufficient to check its existence. I am about to do another testing in a few minutes on

Re: [HACKERS] Default Roles (was: Additional role attributes)

Fujii, * Fujii Masao (masao.fu...@gmail.com) wrote: > he documents of the functions which the corresponding default roles > are added by this patch need to be updated. For example, the description > of pg_xlog_replay_pause() says "Pauses recovery immediately (restricted > to superusers).". I think

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 1:11 AM, Michael Paquier wrote: > On Mon, Jul 13, 2015 at 4:54 PM, dinesh kumar > wrote: > > Would like to discuss on below feature here. > > > > Feature: > > Having an SQL function, to write messages to log destination. > > > > Justification: > > As of now, we do

Re: [HACKERS] pg_upgrade + Extensions

Yes. I have checked that the extension didn't exist in any of the databases. I used \dx to see if there was json_build was listed and i didnt see any. Is that sufficient to check its existence. I am about to do another testing in a few minutes on a different machine. I will capture before/after sho

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

On 11 July 2015 at 21:28, Tom Lane wrote: > What are we going to do about this? > I will address the points you raise, one by one. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] intarray planning/exeuction problem with multiple operators

Jeff Janes writes: > I've found an interesting performance problem in the intarray extension > module. It doesn't seem to be version dependent, I've verified it in 9.4.4 > and 9.6devel. Seems like this isn't specifically an issue for intarray, but rather one with the core GIN code not being smar

Re: [HACKERS] [BUGS] BUG #13126: table constraint loses its comment

On 07/08/2015 08:12 AM, Michael Paquier wrote: On Tue, Jul 7, 2015 at 6:24 PM, Petr Jelinek wrote: On 2015-07-04 13:45, Michael Paquier wrote: On Fri, Jul 3, 2015 at 11:59 PM, Petr Jelinek wrote: Well for indexes you don't really need to add the new AT command, as IndexStmt has char *idxcom

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

I wrote: > TBH, I think the right thing to do at this point is to revert the entire > patch and send it back for ground-up rework. I think the high-level > design is wrong in many ways and I have about zero confidence in most > of the code details as well. > I'll send a separate message about hig

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

On 7/13/2015 5:36 PM, Andrew Dunstan wrote: On 07/12/2015 05:06 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/04/2015 11:02 AM, Tom Lane wrote: It's not apparent to me how that works at all. BTW, the .a files being linked to above are not like Unix .a static archives - they are import li

Re: [HACKERS] PostgreSQL 9.5 Alpha 1 build fail with perl 5.22

On 07/12/2015 05:06 PM, Tom Lane wrote: Andrew Dunstan writes: On 07/04/2015 11:02 AM, Tom Lane wrote: It's not apparent to me how that works at all. BTW, the .a files being linked to above are not like Unix .a static archives - they are import library files, which I think they are only used

Re: [HACKERS] dead assignment src/bin/scripts/print.c line 421

On 07/13/2015 04:56 PM, Laurent Laborde wrote: Friendly greetings ! in file src/bin/scripts/print.c line 421 : need_recordsep = false; then set to true line 424. Now i'm pretty sure it's a meaningless "bug" without any consequence (the commit that introduced it is 15 years old). There is a lot

Re: [HACKERS] dead assignment src/bin/scripts/print.c line 421

Should have been sent to the bugs ML sorry :-/ On Mon, Jul 13, 2015 at 3:56 PM, Laurent Laborde wrote: > Friendly greetings ! > > in file src/bin/scripts/print.c line 421 : > need_recordsep = false; > then set to true line 424. > > Now i'm pretty sure it's a meaningless "bug" without any consequ

Re: [HACKERS] Freeze avoidance of very large table.

On 2015-07-13 23:48:02 +0900, Sawada Masahiko wrote: > But please image the case where old cluster has table which is very > large, read-only and vacuum freeze is done. > In this case, the all-frozen bit of such table in new cluster will not > set, unless we do vacuum freeze again. > The informatio

Re: [HACKERS] Freeze avoidance of very large table.

On 13 July 2015 at 15:48, Sawada Masahiko wrote: > On Mon, Jul 13, 2015 at 9:22 PM, Andres Freund wrote: > > On 2015-07-13 21:03:07 +0900, Sawada Masahiko wrote: > >> Even If we implement rewriting tool for vm into pg_upgrade, it will > >> take time as much as revacuum because it need whole scan

Re: [HACKERS] [PATCH] Generalized JSON output functions

On 07/13/2015 10:46 AM, Ryan Pedela wrote: On Mon, Jul 13, 2015 at 1:30 AM, Shulgin, Oleksandr mailto:oleksandr.shul...@zalando.de>> wrote: To reiterate: for my problem, that is escaping numerics that can potentially overflow[1] under ECMAScript standard, I want to be able to ove

Re: [HACKERS] [PATCH] Generalized JSON output functions

On 07/13/2015 05:41 AM, Shulgin, Oleksandr wrote: On Mon, Jul 13, 2015 at 9:44 AM, Pavel Stehule mailto:pavel.steh...@gmail.com>> wrote: To reiterate: for my problem, that is escaping numerics that can potentially overflow[1] under ECMAScript standard, I want to be abl

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Jul 13, 2015 at 9:22 PM, Andres Freund wrote: > On 2015-07-13 21:03:07 +0900, Sawada Masahiko wrote: >> Even If we implement rewriting tool for vm into pg_upgrade, it will >> take time as much as revacuum because it need whole scanning table. > > Why would it? Sure, you can only set allvis

Re: [HACKERS] [PATCH] Generalized JSON output functions

On Mon, Jul 13, 2015 at 1:30 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > > To reiterate: for my problem, that is escaping numerics that can > potentially overflow[1] under ECMAScript standard, I want to be able to > override the code that outputs the numeric converted to strin

Re: [HACKERS] Default Roles (was: Additional role attributes)

On Wed, May 13, 2015 at 12:07 PM, Stephen Frost wrote: > All, > > This patch gets smaller and smaller. > > Upon reflection I realized that, with default roles, it's entirely > unnecssary to change how the permission checks happen today- we can > simply add checks to them to be looking at role memb

[HACKERS] dead assignment src/bin/scripts/print.c line 421

Friendly greetings ! in file src/bin/scripts/print.c line 421 : need_recordsep = false; then set to true line 424. Now i'm pretty sure it's a meaningless "bug" without any consequence (the commit that introduced it is 15 years old). There is a lot of (apparently) dead assignment here and there b

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

Michael Paquier writes: > Regarding the fact that those two contrib modules can be part of a > -contrib package and could be installed, nuking those two extensions > from the tree and preventing the creating of custom tablesample > methods looks like a correct course of things to do for 9.5. TBH,

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

On Fri, Jul 10, 2015 at 10:06 PM, Beena Emerson wrote: > Hello, > > Tue, Jul 7, 2015 at 02:56 AM, Josh Berkus wrote: >> pro-JSON: >> >> * standard syntax which is recognizable to sysadmins and devops. >> * can use JSON/JSONB functions with ALTER SYSTEM SET to easily make >> additions/deletions fro

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Jul 13, 2015 at 9:19 PM, Ildus Kurbangaliev wrote: > On 07/13/2015 01:36 PM, Amit Kapila wrote: > > Other problem of pg_stat_activity that we can not see all processes there > (checkpointer for example). So we anyway need separate view for monitoring > purposes. +1 When there are many wa

Re: [HACKERS] WIP: Enhanced ALTER OPERATOR

Hello hackers. Attached is a new version of patch: * port syntax from NULL to truth NONE * fix documentation (thanks Heikki) * rebase to master Thanks. -- Uriy Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Companydiff --git a/doc/src/sgml/ref/alter_operator

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

On Mon, Jul 13, 2015 at 9:22 PM, Sawada Masahiko wrote: > I might missing something but, these functions will generate WAL? > If they does, we will face the situation where we need to wait > forever, Fujii-san pointed out. No, those functions are here to manipulate the metadata defining the quoru

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Jul 13, 2015 at 9:03 PM, Sawada Masahiko wrote: > On Mon, Jul 13, 2015 at 7:46 PM, Amit Kapila wrote: >> On Mon, Jul 13, 2015 at 3:39 PM, Sawada Masahiko >> wrote: >>> >>> On Tue, Jul 7, 2015 at 9:07 PM, Simon Riggs wrote: >>> > On 6 July 2015 at 17:28, Simon Riggs wrote: >>> > >>> >>

Re: [HACKERS] Freeze avoidance of very large table.

On 2015-07-13 21:03:07 +0900, Sawada Masahiko wrote: > Even If we implement rewriting tool for vm into pg_upgrade, it will > take time as much as revacuum because it need whole scanning table. Why would it? Sure, you can only set allvisible and not the frozen bit, but that's fine. That way the cos

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

On Fri, Jul 10, 2015 at 10:06 PM, Beena Emerson wrote: > Hello, > > Tue, Jul 7, 2015 at 02:56 AM, Josh Berkus wrote: >> pro-JSON: >> >> * standard syntax which is recognizable to sysadmins and devops. >> * can use JSON/JSONB functions with ALTER SYSTEM SET to easily make >> additions/deletions fro

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On 07/13/2015 01:36 PM, Amit Kapila wrote: I have already proposed something very similar in this thread [1] (where instead of class, I have used wait_event_type) to which Robert doesn't agree, so here I think before writing code, it seems prudent to get an agreement about what kind of User-Inter

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Jul 13, 2015 at 7:46 PM, Amit Kapila wrote: > On Mon, Jul 13, 2015 at 3:39 PM, Sawada Masahiko > wrote: >> >> On Tue, Jul 7, 2015 at 9:07 PM, Simon Riggs wrote: >> > On 6 July 2015 at 17:28, Simon Riggs wrote: >> > >> >> I think we need something for pg_upgrade to rewrite existing VMs.

Re: [HACKERS] intarray planning/exeuction problem with multiple operators

On Sunday 12 July 2015 23:12:41 Jeff Janes wrote: > I've found an interesting performance problem in the intarray extension > module. It doesn't seem to be version dependent, I've verified it in 9.4.4 > and 9.6devel. Hello. Look at my patch. Maybe he solves this problem. https://commitfest.postgr

Re: [HACKERS] Freeze avoidance of very large table.

On Mon, Jul 13, 2015 at 3:39 PM, Sawada Masahiko wrote: > > On Tue, Jul 7, 2015 at 9:07 PM, Simon Riggs wrote: > > On 6 July 2015 at 17:28, Simon Riggs wrote: > > > >> I think we need something for pg_upgrade to rewrite existing VMs. > >> Otherwise a large read only database would suddenly requi

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Mon, Jul 13, 2015 at 3:26 PM, Ildus Kurbangaliev < i.kurbangal...@postgrespro.ru> wrote: > > On 07/12/2015 06:53 AM, Amit Kapila wrote: > > For having duration, I think you need to use gettimeofday or some > similar call to calculate the wait time, now it will be okay for the > cases where wai

Re: [HACKERS] Freeze avoidance of very large table.

On Tue, Jul 7, 2015 at 9:07 PM, Simon Riggs wrote: > On 6 July 2015 at 17:28, Simon Riggs wrote: > >> I think we need something for pg_upgrade to rewrite existing VMs. >> Otherwise a large read only database would suddenly require a massive >> revacuum after upgrade, which seems bad. That can wai

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On 07/12/2015 06:53 AM, Amit Kapila wrote: On Fri, Jul 10, 2015 at 10:03 PM, Alexander Korotkov mailto:a.korot...@postgrespro.ru>> wrote: > > On Fri, Jun 26, 2015 at 6:39 AM, Robert Haas > wrote: >> >> On Thu, Jun 25, 2015 at 9:23 AM, Peter Eisentraut

Re: [HACKERS] [PATCH] Generalized JSON output functions

On Mon, Jul 13, 2015 at 9:44 AM, Pavel Stehule wrote: > > To reiterate: for my problem, that is escaping numerics that can >> potentially overflow[1] under ECMAScript standard, I want to be able to >> override the code that outputs the numeric converted to string. There is >> no way in current i

Re: [HACKERS] multivariate statistics / patch v7

Hi, Thanks for the detailed explaination. I misunderstood the code (more honest speaking, din't look so close there). Then I looked it closer. At Wed, 08 Jul 2015 03:03:16 +0200, Tomas Vondra wrote in <559c76d4.2030...@2ndquadrant.com> > FWIW this was a stupid bug in update_match_bitmap_histogr

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

On Mon, Jul 13, 2015 at 7:36 AM, Tom Lane wrote: > I wrote: >> The two contrib modules this patch added are nowhere near fit for public >> consumption. They cannot clean up after themselves when dropped: >> ... >> Raw inserts into system catalogs just >> aren't a sane thing to do in extensions. >

Re: [HACKERS] [PATCH] SQL function to report log message

On Mon, Jul 13, 2015 at 4:54 PM, dinesh kumar wrote: > Would like to discuss on below feature here. > > Feature: > Having an SQL function, to write messages to log destination. > > Justification: > As of now, we don't have an SQL function to write custom/application > messages to log desti

[HACKERS] [PATCH] SQL function to report log message

Hi All, Greetings for the day. Would like to discuss on below feature here. Feature: Having an SQL function, to write messages to log destination. Justification: As of now, we don't have an SQL function to write custom/application messages to log destination. We have "RAISE" clause whic

Re: [HACKERS] [PATCH] Generalized JSON output functions

2015-07-13 9:30 GMT+02:00 Shulgin, Oleksandr : > On Sun, Jul 12, 2015 at 8:39 PM, Pavel Stehule > wrote: > >> The thing is - it's not only about whitespace, otherwise I would probably >>> not bother with the generic interface. For my original problem, there is >>> simply no way to do this correct

Re: [HACKERS] [PATCH] Generalized JSON output functions

On Sun, Jul 12, 2015 at 8:39 PM, Pavel Stehule wrote: > The thing is - it's not only about whitespace, otherwise I would probably >> not bother with the generic interface. For my original problem, there is >> simply no way to do this correctly in an extension w/o copying over all of >> the logic

Re: [HACKERS] optimizing vacuum truncation scans

On Mon, Jul 13, 2015 at 12:06 PM, Haribabu Kommi wrote: > On Thu, Jul 9, 2015 at 5:36 PM, Haribabu Kommi > wrote: >> >> I will do some performance tests and send you the results. > > Here are the performance results tested on my machine. > > > Head vm patch