Re: [HACKERS] four minor proposals for 9.5

2014-03-20 5:36 GMT+01:00 Amit Kapila : > On Wed, Mar 19, 2014 at 9:04 PM, Pavel Stehule > wrote: > > Hello > > > > I wrote a few patches, that we use in our production. These patches are > > small, but I hope, so its can be interesting for upstream: > > > > 1. cancel time - we log a execution ti

Re: [HACKERS] Archive recovery won't be completed on some situation.

Hello, > On 03/19/2014 10:28 AM, Kyotaro HORIGUCHI wrote: > > The*problematic* operation sequence I saw was performed by > > pgsql-RA/Pacemaker. It stops a server already with immediate mode > > and starts the Master as a Standby at first, then > > promote. Focusing on this situation, there would

Re: [HACKERS] Archive recovery won't be completed on some situation.

Hello, At Wed, 19 Mar 2014 19:34:10 +0900, Fujii Masao wrote > > Agreed. Attached patches do that and I could "recover" the > > database state with following steps, > > Adding new option looks like new feature rather than bug fix. > I'm afraid that the backpatch of such a change to 9.3 or before

Re: [HACKERS] four minor proposals for 9.5

On 20/03/14 13:28, Josh Berkus wrote: 3. relation limit - possibility to set session limit for maximum size of relations. Any relation cannot be extended over this limit in session, when this value is higher than zero. Motivation - we use lot of queries like CREATE TABLE AS SELECT .. , and some

Re: [HACKERS] Archive recovery won't be completed on some situation.

Hi, I confirmed that 82233ce7ea4 surely did it. At Wed, 19 Mar 2014 09:35:16 -0300, Alvaro Herrera wrote > Fujii Masao escribió: > > On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas > > wrote: > > > >> 9.4 canceles backup mode even on immediate shutdown so the > > >> operation causes no probl

Re: [HACKERS] four minor proposals for 9.5

On Wed, Mar 19, 2014 at 9:04 PM, Pavel Stehule wrote: > Hello > > I wrote a few patches, that we use in our production. These patches are > small, but I hope, so its can be interesting for upstream: > > 1. cancel time - we log a execution time cancelled statements > > 2. fatal verbose - this patch

Re: [HACKERS] issue log message to suggest VACUUM FULL if a table is nearly empty

On Wed, Mar 19, 2014 at 6:25 AM, Wang, Jing wrote: > On Friday, 14 March 2014 2:42 PM, Amit Kapila wrote: >> I think it might be okay to even change this API to return the FreeSpace, as >> the other place it is used is for Index Vacuum, so even if we don't have any >> intention to print such a

Re: [HACKERS] Minimum supported version of Python?

I wrote: > Peter Eisentraut writes: >> It does pass the tests for me and others. If you are seeing something >> different, then we need to see some details, like what platform, what >> version, what Python version, how installed, what PostgreSQL version, >> how installed, actual diffs, etc. > Af

Re: [HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

On Wed, Mar 19, 2014 at 7:27 PM, Tom Lane wrote: > Alvaro Herrera writes: > > I'm not sure I understand the point of this whole thing. Realistically, > > how many transactions are there that do not access any database tables? > > I think that something like "select * from pg_stat_activity" migh

Re: Custom Scan APIs (Re: [HACKERS] Custom Plan node)

Hello, > > * Definition of add_join_path_hook > > > > I didn't have idea to improve the definition and location of this > > hook, so it is still on the tail of the add_paths_to_joinrel(). > > Its definition was a bit adjusted according to the feedback on the > > pgsql-hackers. I omitted the "merge

Re: [HACKERS] four minor proposals for 9.5

2014-03-20 1:28 GMT+01:00 Josh Berkus : > Pavel, > > > I wrote a few patches, that we use in our production. These patches are > > small, but I hope, so its can be interesting for upstream: > > > > 1. cancel time - we log a execution time cancelled statements > > Manually cancelled? statement_tim

Re: [HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

On Wed, Mar 19, 2014 at 7:27 PM, Tom Lane wrote: > Alvaro Herrera writes: >> I'm not sure I understand the point of this whole thing. Realistically, >> how many transactions are there that do not access any database tables? > > I think that something like "select * from pg_stat_activity" might n

Re: [HACKERS] jsonb status

On Wed, Mar 19, 2014 at 5:10 PM, Andrew Dunstan wrote: > I didn't like the _state->state stuff either, but I think you changed the > wrong name - it's the field name in the struct that needs changing. What > you've done is inconsistent with the common idiom in jsonfuncs.c. Okay. I've changed the

Re: [HACKERS] four minor proposals for 9.5

Pavel, > I wrote a few patches, that we use in our production. These patches are > small, but I hope, so its can be interesting for upstream: > > 1. cancel time - we log a execution time cancelled statements Manually cancelled? statement_timeout? Anyway, +1 to add the time to the existing log

Re: [HACKERS] four minor proposals for 9.5

2014-03-19 23:31 GMT+01:00 Vik Fearing : > On 03/19/2014 04:34 PM, Pavel Stehule wrote: > > Hello > > > > I wrote a few patches, that we use in our production. These patches > > are small, but I hope, so its can be interesting for upstream: > > > > 1. cancel time - we log a execution time cancelle

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

2014-03-20 0:32 GMT+01:00 Tom Lane : > Petr Jelinek writes: > > On 19/03/14 19:26, Alvaro Herrera wrote: > >> I think this should have the GUC_LIST_INPUT flag, and ensure that when > >> multiple values are passed, we can process them all in a sane fashion. > > > Well, as we said with Marko in the

Re: [HACKERS] jsonb status

On 03/19/2014 06:57 PM, Peter Geoghegan wrote: On Wed, Mar 19, 2014 at 9:28 AM, Andres Freund wrote: * Jsonb vs JsonbValue is just bad, the latter needs to be renamed, and there needs to be a very clear explanation about why two forms exist and what each is used for. I've pushed some co

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

Petr Jelinek writes: > On 19/03/14 19:26, Alvaro Herrera wrote: >> I think this should have the GUC_LIST_INPUT flag, and ensure that when >> multiple values are passed, we can process them all in a sane fashion. > Well, as we said with Marko in the original thread, the proper handling > is left

Re: [HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

Alvaro Herrera writes: > I'm not sure I understand the point of this whole thing. Realistically, > how many transactions are there that do not access any database tables? I think that something like "select * from pg_stat_activity" might not bump any table-access counters, once the relevant sysc

Re: [HACKERS] jsonb status

On Wed, Mar 19, 2014 at 9:28 AM, Andres Freund wrote: > * Jsonb vs JsonbValue is just bad, the latter needs to be renamed, and > there needs to be a very clear explanation about why two forms exist > and what each is used for. I've pushed some comments to Github that further clarify the disti

Re: [HACKERS] four minor proposals for 9.5

On 03/19/2014 04:34 PM, Pavel Stehule wrote: > Hello > > I wrote a few patches, that we use in our production. These patches > are small, but I hope, so its can be interesting for upstream: > > 1. cancel time - we log a execution time cancelled statements +1 I even wrote a patch to do this, but i

Re: [HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

Gurjeet Singh wrote: > On Wed, Mar 19, 2014 at 4:22 PM, Tom Lane wrote: > > > Gurjeet Singh writes: > > > Please find attached the patch to send transaction commit/rollback stats > > to > > > stats collector unconditionally. > > > > That's intentional to reduce stats traffic. What kind of perfo

Re: [HACKERS] First-draft release notes for next week's releases

Josh Berkus wrote: > On 03/19/2014 02:01 PM, Alvaro Herrera wrote: > > Josh Berkus wrote: > >> All, > >> > >> So, I'll ask again (because I didn't see a reply): is there any way > >> users can *check* if they've been corrupted? Short of waiting for PK/FK > >> violations? Some notes: 1. if there'

Re: [HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

On Wed, Mar 19, 2014 at 4:22 PM, Tom Lane wrote: > Gurjeet Singh writes: > > Please find attached the patch to send transaction commit/rollback stats > to > > stats collector unconditionally. > > That's intentional to reduce stats traffic. What kind of performance > penalty does this patch impo

Re: [pgsql-advocacy] [HACKERS] First draft of update announcement

On 2014-03-18, 2:42 PM, Josh Berkus wrote: Other PostgreSQL 9.3 only fixes in this update include: * Add read-only data_checksum parameter I recall being told last fall that this would not be added to 9.3.x (9.3.1 at the time I think) and only to 9.4.x because such a feature addition was som

Re: [HACKERS] First-draft release notes for next week's releases

On 03/19/2014 02:01 PM, Alvaro Herrera wrote: > Josh Berkus wrote: >> All, >> >> So, I'll ask again (because I didn't see a reply): is there any way >> users can *check* if they've been corrupted? Short of waiting for PK/FK >> violations? > > Obviously there are queries you can run to check each

[HACKERS] effective_cache_size cannot be changed by a reload

In 9.4dev, if the server is started with effective_cache_size = -1, then it cannot be changed away from that without a restart. If you change the config file and do a reload or pg_reload_conf(), it ignores the change without comment in the logs. If you start the server with a value other than -1,

Re: [HACKERS] First-draft release notes for next week's releases

Josh Berkus wrote: > All, > > So, I'll ask again (because I didn't see a reply): is there any way > users can *check* if they've been corrupted? Short of waiting for PK/FK > violations? Obviously there are queries you can run to check each FK -- the same queries that ri_triggers.c would run when

Re: [HACKERS] First-draft release notes for next week's releases

Josh Berkus writes: > So, I'll ask again (because I didn't see a reply): is there any way > users can *check* if they've been corrupted? Short of waiting for PK/FK > violations? I think it would work to do a REINDEX on each table (doesn't matter which index you select) and see if it complains ab

Re: [HACKERS] First draft of update announcement

On 03/18/2014 03:02 PM, Tom Lane wrote: > Josh Berkus writes: >> Updated per feedback. CC'd to Advocacy now for additional corrections. > > A few thoughts: Changes incorporated. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hacke

Re: [HACKERS] First-draft release notes for next week's releases

All, So, I'll ask again (because I didn't see a reply): is there any way users can *check* if they've been corrupted? Short of waiting for PK/FK violations? Given that all of the fixes we recommend involve extensive downtimes, nobody is going to want to do them "just in case". How can they test

Re: [HACKERS] Wiki Page Draft for upcoming release

Josh Berkus writes: > On 03/19/2014 10:37 AM, Alvaro Herrera wrote: >> I wonder about suggesting other versions of ALTER TABLE that can do >> heap rewrites. > I don't want to recommend any version of ALTER TABLE until someone > actually tests it on a corrupted database. A test would be a good id

Re: [HACKERS] jsonb status

On Wed, Mar 19, 2014 at 9:28 AM, Andres Freund wrote: > I've pushed one commit with minor fixes, and one with several FIXMEs to > http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git;a=shortlog;h=refs/heads/jsonb_and_hstore Cool. > * Jsonb vs JsonbValue is just bad, the latter nee

Re: [HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

Gurjeet Singh writes: > Please find attached the patch to send transaction commit/rollback stats to > stats collector unconditionally. That's intentional to reduce stats traffic. What kind of performance penalty does this patch impose? If the number of such transactions is large enough to creat

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

On 19/03/14 19:26, Alvaro Herrera wrote: Petr Jelinek escribió: + + These additional checks are enabled through the configuration variables + plpgsql.extra_warnings for warnings and + plpgsql.extra_errors for errors. Both can be set either to + a comma-separated list of checks, "none" or

Re: [HACKERS] jsonb status

On 03/19/2014 03:58 PM, Peter Geoghegan wrote: On Wed, Mar 19, 2014 at 9:28 AM, Andres Freund wrote: * Jsonb vs JsonbValue is just bad, the latter needs to be renamed, and there needs to be a very clear explanation about why two forms exist and what each is used for. Agreed. We should p

[HACKERS] Patch to send transaction commit/rollback stats to the stats collector unconditionally.

Please find attached the patch to send transaction commit/rollback stats to stats collector unconditionally. Without this patch, the transactions that do not read from/write to a database table do not get reported to the stats collector until the client disconnects. Hence the transaction counts in

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

Hi, On 19/03/14 15:12, Alvaro Herrera wrote: > I hope the silence meant assent, because I have pushed this patch now. Great, thanks! Best regards, -- Christian Kruse http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services pgpYfuVjR_gg_.pgp Descr

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

Petr Jelinek escribió: > + > + These additional checks are enabled through the configuration variables > + plpgsql.extra_warnings for warnings and > + plpgsql.extra_errors for errors. Both can be set either to > + a comma-separated list of checks, "none" or "all". > + The default is "none".

Re: [HACKERS] Wiki Page Draft for upcoming release

On 03/19/2014 10:37 AM, Alvaro Herrera wrote: > Tom Lane wrote: >> Josh Berkus writes: >>> On 03/17/2014 05:49 PM, Josh Berkus wrote: https://wiki.postgresql.org/wiki/20140320UpdateIssues >> >>> Anyone? We're going public with this in 36 hours, so I'd love for it to >>> actually be correct.

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

Alvaro Herrera escribió: > Tom Lane escribió: > > I think the enum idea you floated is probably worth doing. It's > > certainly no more complex than passing a string, no? > > Okay, done that way, attached. I think this one solves all concerns > there were. I hope the silence meant assent, beca

Re: [HACKERS] pg_archivecleanup bug

On Wed, Mar 19, 2014 at 09:59:19AM +0200, Heikki Linnakangas wrote: > >Would people accept? > > > > for (errno = 0; (dirent = readdir(dir)) != NULL; errno = 0) > > > >That would keep the errno's together and avoid the 'continue' additions. > > That's clever. A less clever way would be: > > fo

Re: [HACKERS] Wiki Page Draft for upcoming release

Tom Lane wrote: > Josh Berkus writes: > > On 03/17/2014 05:49 PM, Josh Berkus wrote: > >> https://wiki.postgresql.org/wiki/20140320UpdateIssues > > > Anyone? We're going public with this in 36 hours, so I'd love for it to > > actually be correct. > > I did a bit more hacking on this page. Coul

Re: [HACKERS] jsonb status

On 2014-03-19 09:55:03 -0700, Josh Berkus wrote: > On 03/19/2014 09:28 AM, Andres Freund wrote: > > * The whole datastructure doesn't have any sensible highlevel > > documentation. > > Explain ... ? I'm planning on improving the docs through the beta > period for this, so can you explain what k

Re: [HACKERS] jsonb status

On 03/19/2014 09:28 AM, Andres Freund wrote: > * The whole datastructure doesn't have any sensible highlevel > documentation. Explain ... ? I'm planning on improving the docs through the beta period for this, so can you explain what kind of docs we're missing here? -- Josh Berkus PostgreSQL E

Re: [HACKERS] jsonb status

Hi, On 2014-03-13 17:00:33 -0400, Andrew Dunstan wrote: > Peter Geoghegan has been doing a lot of great cleanup of the jsonb code, > after moving in the bits we wanted from nested hstore. You can see the > current state of the code at > I

[HACKERS] four minor proposals for 9.5

Hello I wrote a few patches, that we use in our production. These patches are small, but I hope, so its can be interesting for upstream: 1. cancel time - we log a execution time cancelled statements 2. fatal verbose - this patch ensure a verbose log for fatal errors. It simplify a investigation

Re: [HACKERS] logical decoding doc

On Tue, Mar 18, 2014 at 7:27 PM, Tatsuo Ishii wrote: > Maybe this is to demonstrating "peek ahead" does not consume changes, > but IMO this is a little bit confusing for readers and I think there's > a room to enhance the second sql session comment for example: I didn't write that text, but yeah,

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

2014-03-19 13:51 GMT+01:00 Alvaro Herrera : > Why start a new thread for this review? It seems to me it'd be more > comfortable to keep the review as a reply on the original thread. > I am sorry, I though so review should to start in separate thread Pavel > > -- > Álvaro Herrera

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

Why start a new thread for this review? It seems to me it'd be more comfortable to keep the review as a reply on the original thread. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (

Re: [HACKERS] Archive recovery won't be completed on some situation.

Fujii Masao escribió: > On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas > wrote: > >> 9.4 canceles backup mode even on immediate shutdown so the > >> operation causes no problem, but 9.3 and before are doesn't. > > > > Hmm, I don't think we've changed that behavior in 9.4. > > ISTM 82233ce7e

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

Hello all is pk Pavel 2014-03-19 11:28 GMT+01:00 Petr Jelinek : > > On 19/03/14 09:45, Pavel Stehule wrote: > >> Hello >> >> This patch introduce a possibility to implement some new checks without >> impact to current code. >> >> 1. there is a common agreement about this functionality, syntax,

Re: [HACKERS] Archive recovery won't be completed on some situation.

On Wed, Mar 19, 2014 at 7:57 PM, Heikki Linnakangas wrote: > On 03/19/2014 10:28 AM, Kyotaro HORIGUCHI wrote: >> >> The*problematic* operation sequence I saw was performed by >> >> pgsql-RA/Pacemaker. It stops a server already with immediate mode >> and starts the Master as a Standby at first, th

Re: [HACKERS] B-tree descend for insertion locking

On 18 March 2014 11:12, Heikki Linnakangas wrote: > When inserting into a B-tree index, all the pages are read-locked when > descending the tree. When we reach the leaf page, the read-lock is exchanged > for a write-lock. > > There's nothing wrong with that, but why don't we just directly grab a >

Re: [HACKERS] Archive recovery won't be completed on some situation.

On 03/19/2014 10:28 AM, Kyotaro HORIGUCHI wrote: The*problematic* operation sequence I saw was performed by pgsql-RA/Pacemaker. It stops a server already with immediate mode and starts the Master as a Standby at first, then promote. Focusing on this situation, there would be reasonable to reset

Re: [HACKERS] Archive recovery won't be completed on some situation.

On Wed, Mar 19, 2014 at 5:28 PM, Kyotaro HORIGUCHI wrote: > Hello, thank you for suggestions. > > The *problematic* operation sequence I saw was performed by > pgsql-RA/Pacemaker. It stops a server already with immediate mode > and starts the Master as a Standby at first, then > promote. Focusing

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

On 19/03/14 09:45, Pavel Stehule wrote: Hello This patch introduce a possibility to implement some new checks without impact to current code. 1. there is a common agreement about this functionality, syntax, naming 2. patching is clean, compilation is without error and warning 3. all regress

Re: [HACKERS] ALTER TABLE lock strength reduction patch is unsafe Reply-To:

On 18 March 2014 21:21, Noah Misch wrote: > On Tue, Mar 18, 2014 at 10:39:03AM +, Simon Riggs wrote: >> On 8 March 2014 11:14, Simon Riggs wrote: >> > Implemented in attached patch, v22 > >> > I commend this patch to you for final review; I would like to commit >> > this in a few days. >> >>

[HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

Hello This patch introduce a possibility to implement some new checks without impact to current code. 1. there is a common agreement about this functionality, syntax, naming 2. patching is clean, compilation is without error and warning 3. all regress tests passed 4. feature is well documented

Re: [HACKERS] Archive recovery won't be completed on some situation.

Hello, thank you for suggestions. The *problematic* operation sequence I saw was performed by pgsql-RA/Pacemaker. It stops a server already with immediate mode and starts the Master as a Standby at first, then promote. Focusing on this situation, there would be reasonable to reset backup positions

Re: [HACKERS] pg_archivecleanup bug

On 03/19/2014 02:30 AM, Bruce Momjian wrote: On Tue, Mar 18, 2014 at 09:13:28PM +0200, Heikki Linnakangas wrote: On 03/18/2014 09:04 PM, Simon Riggs wrote: On 18 March 2014 18:55, Alvaro Herrera wrote: That said, I don't find comma expression to be particularly "not simple". Maybe, but we'