Re: [HACKERS] Idle In Transaction Session Timeout, revived

On 03/08/2016 10:42 PM, Robert Haas wrote: > On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing wrote: >> Attached is a rebased and revised version of my >> idle_in_transaction_session_timeout patch from last year. >> >> This version does not suffer the problems the old one

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On 03/16/2016 05:32 PM, Robert Haas wrote: > Committed with slight changes to the docs, and I added a flag variable > instead of relying on IdleInTransactionSessionTimeout not changing at > an inopportune time. Thank you! -- Vik Fearing +33 6 46

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

mentation is a little light, but I don't see what else needs to be said. The code is clean and well commented. All extraction options are supported. Regression tests are present and seemingly complete. I looked around for other places where this code should be used and di

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

On 01/22/2016 04:28 AM, Tom Lane wrote: > Vik Fearing writes: >> I looked around for other places where this code should be used and >> didn't find any. I am marking this patch Ready for Committer. > > I pushed this with some adjustments, mainly to make sure that th

[HACKERS] Idle In Transaction Session Timeout, revived

is if a session remains idle in a transaction for longer than the configured time, that connection will be dropped thus releasing the connection slot and any locks that may have been held by the broken client. Added to the March commitfest. -- Vik Fearing

Re: [HACKERS] Idle In Transaction Session Timeout, revived

;t put a bunch of effort into it though. Dropping the connection > is certainly better than nothing. You could always put SET idle_in_transaction_session_timeout = 0; in your .psqlrc file to exempt your manual sessions from it. Or change it just for your user or something. -- Vik Fearin

Re: [HACKERS] pg_dump data structures for triggers

t. The increment in the size of those data structures isn't much, > and we may have other uses for such an ability later. > > Anybody have an objection or better idea? No objections to this, but my "better idea" is simply to allow INSTEAD OF triggers on tables like discussed

Re: [HACKERS] Idle In Transaction Session Timeout, revived

On 02/04/2016 02:24 PM, Fujii Masao wrote: > On Sun, Jan 31, 2016 at 10:33 PM, Vik Fearing wrote: >> Attached is a rebased and revised version of my >> idle_in_transaction_session_timeout patch from last year. >> >> This version does not suffer the problems the old one

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

out not using DEFAULT parameters in system functions so you should leave the old function alone and create a new function with your use_all parameter. I don't recall the exact reason why so hopefully someone else will enlighten me. There is also no mention in the do

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

On 02/07/2016 04:00 PM, Filip Rembiałkowski wrote: > On Sun, Feb 7, 2016 at 11:54 AM, Vik Fearing wrote: >> I seem to remember some discussion about not using DEFAULT parameters in >> system functions so you should leave the old function alone and create a >> new funct

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

> * updated the docs to include new syntax and clarify behavior > > * no hashtable in AsyncExistsPendingNotify > (I don't see much sense in that part; and it can be well done > separately from this) Please add this to the next commitfest: https://comm

Re: [HACKERS] Re: Add generate_series(date, date) and generate_series(date, date, integer)

dding this missing function. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.

Re: [HACKERS] create opclass documentation outdated

ist now represents a full 50% of the available AMs. I submit it should be removed altogether. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@pos

[HACKERS] VACUUM's ancillary tasks

r: Please note that some of the documentation in the first patch gets removed by the second patch, in case they both don't get committed. I have added this to the imminent commitfest. These patches are rebased as of 26fa446. -- Vik Fearing +33

[HACKERS] Sample configuration files

y of this patch. Current as of 26fa446, added to next commitfest. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support sample_confs_v01.patch Description: invalid/octet-stream -- Sent via pgsql-hackers mail

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

ry" relpersistence (I don't care which letter it gets) and when a backend tries to access it, it uses its own private relfilenode instead of whatever is in pg_class, creating one if necessary. That way the structure of the table is fixed, with all the depe

Re: [HACKERS] autonomous transactions

y* to do. We can already audit what they've actually done. With your solution, we still wouldn't know when an unauthorized attempt to do something happened. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertis

Re: [HACKERS] Sample configuration files

On 09/02/2016 08:58 AM, Robert Haas wrote: > On Mon, Aug 29, 2016 at 7:04 AM, Vik Fearing wrote: >> We have sample configuration files for postgresql.conf and >> recovery.conf, but we do not have them for contrib modules. This patch >> attempts to add them. >> >

Re: [HACKERS] INSERT .. SET syntax

hat uses it (or anything like it) is MySQL. However, I can see how it would be a huge win for very wide tables and so my personal opinion is to accept this syntax as a PostgreSQL extension to the standard. Marking ready for committer, the minor gripes above notwithstanding. -- Vik Fearing

Re: [HACKERS] sequence data type

On 08/31/2016 06:22 AM, Peter Eisentraut wrote: > Here is a patch that adds the notion of a data type to a sequence. So > it might be CREATE SEQUENCE foo AS integer. The types are restricted to > int{2,4,8} as now. This patch does not apply cleanly to current master (=600dc4c). -- Vi

[HACKERS] Long options for pg_ctl waiting

ing that --wait (and --no-wait) aren't a thing. Trivial patch attached. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support pg_ctl_wait-01.patch Description: invalid/octet-stream -- Sent via pgsql-

Re: [HACKERS] Fun fact about autovacuum and orphan temp tables

On 09/05/2016 01:54 PM, Grigory Smolkin wrote: > What is the purpose of keeping orphan tables around and not dropping > them on the spot? You can read the discussion about it here: https://www.postgresql.org/message-id/flat/3507.1214581513%40sss.pgh.pa.us -- Vik F

Re: [HACKERS] INSERT .. SET syntax

eturned With Feedback. You're probably right (even though you're quoting the wrong message), so I've changed it to that. Marko, please resubmit an updated patch. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expert

Re: [HACKERS] Long options for pg_ctl waiting

go as far as just documenting --no-sync only and > keeping the --nosync one working with minimal (if any) visibility in > docs. Okay, here's a patch to do that. I don't think it's the other patch's job to do it. I also changed --noclean to --no-clean, and --no-locale was a

Re: [HACKERS] Long options for pg_ctl waiting

On 09/07/2016 11:39 PM, Gavin Flower wrote: > On 08/09/16 09:08, Vik Fearing wrote: >> On 09/07/2016 10:41 PM, Alvaro Herrera wrote: >>> Gavin Flower wrote: >>> >>>> possibly '--nosync' (& any similar) should have a '--no-sync' va

Re: [HACKERS] Long options for pg_ctl waiting

On 09/08/2016 01:05 AM, Tom Lane wrote: > Vik Fearing writes: >> On 09/07/2016 11:39 PM, Gavin Flower wrote: >>> Possibly generate warningswhen the non hyphenated form is used? > >> I'm not quite sure how I got volunteered to do this work, but it's easy &g

Re: [HACKERS] Sample configuration files

On 08/29/2016 03:34 AM, Vik Fearing wrote: > We have sample configuration files for postgresql.conf and > recovery.conf, but we do not have them for contrib modules. This patch > attempts to add them. > > Although the patch puts the sample configuration files in the tree, it &

Re: [HACKERS] Quorum commit for multiple synchronous replication.

for a new feature that is going to be > GA soon. Indeed. I'll vote for pulling a fast one on 9.6 for this. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql

[HACKERS] Project Policies

I often see mention of project policies for various things (the one triggering this email is in commit 967a7b0). Where can I find documentation for these policies? -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise

Re: [HACKERS] Quorum commit for multiple synchronous replication.

hen. But I still stand by what I did understand, namely that 'k (...)' should mean 'any k (...)'. It's much more natural than having it mean 'first k (...)' and I also think it will be more frequent in practice. -- Vik Fearing

Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints

x27;t want to hijack the thread, but you can do that with exclusion constraints. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To mak

Re: [HACKERS] [PATCH] pageinspect function to decode infomasks

sagree. Fair enough.> > I guess it is that simple. FWIW, my opinion falls in line with Robert's. Also, whichever way it goes, this is a patch I've been wanting for a long time. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr Po

Re: [HACKERS] Determine state of cluster (HA)

recovery.conf into >>>> postgresql.conf. >>> >>> Definitely. >> >> There's a patch from Abhijit Menon-Sen you could adopt for PostgreSQL >> 11 for that. > > Do you have a link to this? https://commitfest.postgresql.org/search/?searcht

Re: [HACKERS] Queuing all tables for analyze after recovery

when there are 199,999,999 dead tuples, you currently get to wait for another 200 million to die before anything gets cleaned up. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-

Re: [HACKERS] Queuing all tables for analyze after recovery

On 10/19/2017 11:26 PM, Tom Lane wrote: > Vik Fearing writes: >> On 10/19/2017 10:54 PM, Tom Lane wrote: >>> Uh ... recommended by whom? pg_statistic has exactly the same reliability >>> guarantees as the rest of the system catalogs. > >> For data statistics

Re: [HACKERS] Sample configuration files

r by default. These could then live in there and all I would have had to do is uncomment the values I wanted. This patch doesn't do that, of course, but I could easily write a patch that does. Would that go over better with the -1ers? -- Vik Fearing

Re: [HACKERS] VACUUM's ancillary tasks

On 10/01/2016 09:28 AM, Thomas Munro wrote: > On Mon, Aug 29, 2016 at 1:26 PM, Vik Fearing wrote: >> The attached two patches scratch two itches I've been having for a >> while. I'm attaching them together because the second depends on the first. >> >> Both

Re: [HACKERS] Renaming of pg_xlog and pg_clog

_subxact. >>> >>> Nice suggestion, good naming for consistency with the rest. >> >> Agreed. > > +1 +1 from me, too. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support --

Re: [HACKERS] Patch to implement pg_current_logfile() function

number of rotations per time/size and whatnot. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscripti

Re: [HACKERS] Mail thread references in commits

9 extra characters, less 2 if you remove the <> delimiters. I > think the extra usability makes the slight increase in ugliness worth > it. Can we just agree or disagree on this? If non-committers are voting, I'll add my +1 to this. -- Vik Fearing

Re: [HACKERS] "RETURNING PRIMARY KEY" syntax extension

On 06/09/2014 07:13 PM, Andres Freund wrote: > On 2014-06-09 13:42:22 +0200, Vik Fearing wrote: >> On 06/09/2014 09:06 AM, Gavin Flower wrote: >>> From memory all unique keys can be considered 'candidate primary keys', >>> but only one can be designated '

Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules

On 06/17/2014 09:43 AM, Hannu Krosing wrote: > On 06/14/2014 09:35 PM, Tom Lane wrote: >> > As I mentioned awhile ago, I'm thinking about implementing the >> > SQL-standard construct >> > >> >UPDATE foo SET ..., (a,b,...) = (SELECT x,y,...), ... >> > >> > I've run into a rather nasty problem, w

Re: [HACKERS] GSoC on WAL-logging hash indexes

On 04/30/2014 11:41 PM, Tom Lane wrote: > We really oughta fix the WAL situation, not just band-aid around it. After re-reading this thread, it is not clear that anyone is going to work on it so I'll just ask: Is anyone working on this? If not, I'd like to put it on my plate. -- Vik -- Sen

Re: [HACKERS] Minmax indexes

On 06/18/2014 12:46 PM, Andres Freund wrote: >>> Isn't 'simpler implementation' a valid reason that's already been >>> > >discussed onlist? Obviously simpler implementation doesn't trump >>> > >everything, but it's one valid reason... >>> > >Note that I have zap to do with the design of this featur

Re: [HACKERS] idle_in_transaction_timeout

On 06/19/2014 05:42 PM, Kevin Grittner wrote: > Abhijit Menon-Sen wrote: >> At 2014-06-19 10:58:34 +0200, pavel.steh...@gmail.com wrote: > >>> pgbouncer has idle_transaction_timeout defined some years >>> without any problems, so we can take this design >>> >>> idle_transaction_timeout >> >> Let'

Re: [HACKERS] change alter user to be a true alias for alter role

On 01/20/2014 03:31 PM, Jov wrote: > the doc say: > > ALTER USER is now an alias for ALTER ROLE > . > > > but alter user lack the following format: > > [...] > > this make alter user a true alias for alter role. This is

Re: [HACKERS] change alter user to be a true alias for alter role

On 06/19/2014 07:18 PM, Tom Lane wrote: > Jov writes: >> the doc say: >>> ALTER USER is now an alias for ALTER >>> ROLE > >> but alter user lack the following format: >> ... > > If we're going to have a policy that these commands b

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

I've had a chance to look at this and here is my review. On 04/14/2014 01:19 PM, David Rowley wrote: > I've included the updated patch with some regression tests. The first thing I noticed is there is no documentation, but I don't think we document such things outside of the release notes, so tha

Re: [HACKERS] SQL access to database attributes

On 06/21/2014 10:11 PM, Pavel Stehule wrote: > Hello > > I am looking createdb_alterdb_grammar_refactoring.v1.patch > > http://www.postgresql.org/message-id/53868e57.3030...@dalibo.com Thank you for looking at this. > Is any reason or is acceptable incompatible change CONNECTION_LIMIT > instead

Re: [HACKERS] SQL access to database attributes

On 06/21/2014 10:21 PM, Pavel Stehule wrote: > Second question related to second patch: > > Must be new syntax ALLOW_CONNECTIONS? It doesn't *have* to be called that, but that's what the corresponding column in pg_database is called so why add confusion? (Actually, it's called datallowconn but

Re: [HACKERS] idle_in_transaction_timeout

On 06/21/2014 08:23 PM, Kevin Grittner wrote: > OK, so I think we want to see a patch based on v1 (FATAL approach) > with a change of the name to idle_in_transaction_session_timeout > and the units changed to milliseconds. I don't see why the > remoteversion test shouldn't be changed to use 90500

Re: [HACKERS] idle_in_transaction_timeout

On 06/22/2014 07:47 PM, Andres Freund wrote: > On 2014-06-22 09:27:24 -0700, Kevin Grittner wrote: >> Andres Freund wrote: >> >>> The idea with the GUC name is that if we ever get support for >>> cancelling transactions we can name that >>> idle_in_transaction_transaction_timeout? >>> That seems a

Re: [HACKERS] please review source(SQLServer compatible)‏

On 06/23/2014 04:51 PM, rohtodeveloper wrote: > 1.SQL statement support > INSERT statement without INTO keyword > DELETE statement without FROM keywork Why would we want this? -- Vik -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: h

Re: [HACKERS] SQL access to database attributes

On 06/23/2014 06:21 PM, Robert Haas wrote: > On Sun, Jun 22, 2014 at 2:59 PM, Pavel Stehule > wrote: >> I found only one problem - first patch introduce a new property >> CONNECTION_LIMIT and replace previously used "CONNECTION LIMIT" in >> documentation. But "CONNECTION LIMIT" is still supported

Re: [HACKERS] idle_in_transaction_timeout

On 06/22/2014 05:11 PM, Kevin Grittner wrote: > I found one substantive issue that had been missed in discussion, > though. The patch modifies the postgres_fdw extension to make it > automatically exempt from an attempt to set a limit like this on > the server to which it connects. I'm not sure t

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 03:29 PM, David G Johnston wrote: > On Tue, Jun 24, 2014 at 9:20 AM, Vik Fearing [via PostgreSQL] <[hidden > email] >wrote: > > On 06/22/2014 05:11 PM, Kevin Grittner wrote: > > I found one substantive issue that had been missed in discussion, &g

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 04:04 PM, Robert Haas wrote: >> If the local transaction is actually idle in transaction and the local >> > server doesn't have a timeout, we're no worse off than before this patch. > > I think we are. First, the correct timeout is a matter of > remote-server-policy, not local-server

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 06:43 PM, Josh Berkus wrote: A long idle in transaction state pretty much always indicates a >>> problematic interaction with postgres. >>> >> >>> >> True. Which makes me wonder whether we shouldn't default this to >>> >> something non-zero -- even if it is 5 or 10 days. >

Re: [HACKERS] idle_in_transaction_timeout

On 06/24/2014 07:17 PM, Tom Lane wrote: > BTW, has anyone thought about the interaction of this feature with > prepared transactions? I wonder whether there shouldn't be a similar but > separately-settable maximum time for a transaction to stay in the prepared > state. If we could set a nonzero d

Re: [HACKERS] ALTER SYSTEM RESET?

On 06/25/2014 03:04 PM, Amit Kapila wrote: > On Wed, Jun 25, 2014 at 6:20 PM, Christoph Berg > wrote: >> >> Hi, >> >> is there a reason there's no ALTER SYSTEM RESET? >> >> The natural idiom to reset SET statements is "RESET guc;", I don't >> think "SET guc = default;" is in

Re: [HACKERS] idle_in_transaction_timeout

On 06/26/2014 06:45 AM, Fujii Masao wrote: >> The point of this feature, AFAICS, is to detect clients that are failing >> > to issue another query or close their transaction as a result of bad >> > client logic. It's not to protect against network glitches. > > If so, the document should explain t

Re: [HACKERS] ALTER SYSTEM RESET?

On 06/26/2014 05:07 AM, Amit Kapila wrote: > On Wed, Jun 25, 2014 at 9:56 PM, Vik Fearing <mailto:vik.fear...@dalibo.com>> wrote: >> On 06/25/2014 03:04 PM, Amit Kapila wrote: >> > Currently you can achieve that by >> > "ALTER SYSTEM RESET guc = Defaul

Re: [HACKERS] SQL access to database attributes

On 06/23/2014 06:45 PM, Pavel Stehule wrote: > > > > 2014-06-23 18:39 GMT+02:00 Vik Fearing <mailto:vik.fear...@dalibo.com>>: > > On 06/23/2014 06:21 PM, Robert Haas wrote: > > On Sun, Jun 22, 2014 at 2:59 PM, Pavel Stehule > mailto:pavel.s

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

On 06/21/2014 02:03 PM, David Rowley wrote: > I'm marking this Waiting on Author pending discussion on pushing down > entire expressions, but on the whole I think this is pretty much ready. > > > As I said above, I don't think playing around with that code is really > work for this patch.

Re: [HACKERS] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses

On 06/27/2014 02:49 AM, Tom Lane wrote: > Vik Fearing writes: >> This latest patch is ready for a committer to look at now. The weird >> comments have been changed, superfluous regression tests removed, and >> nothing done about expression pushdown per (brief) discussion. &

Re: [HACKERS] ALTER SYSTEM RESET?

On 06/27/2014 06:22 AM, Amit Kapila wrote: > On Thu, Jun 26, 2014 at 8:17 PM, Vik Fearing <mailto:vik.fear...@dalibo.com>> wrote: >> On 06/26/2014 05:07 AM, Amit Kapila wrote: >> > I think it will make sense if we support RESET ALL as well similar >> > to Alt

Re: [HACKERS] ALTER SYSTEM RESET?

On 06/27/2014 08:49 AM, Vik Fearing wrote: > This third patch reformats the documentation in the way I expected it to > be committed. Amit, I added this to the next commitfest with your name as reviewer. https://commitfest.postgresql.org/action/patch_view?id=1495 Please update the sta

Re: [HACKERS] change alter user to be a true alias for alter role

On 06/19/2014 07:18 PM, Tom Lane wrote: > Jov writes: >> the doc say: >>> ALTER USER is now an alias for ALTER >>> ROLE > >> but alter user lack the following format: >> ... > > If we're going to have a policy that these commands b

Re: [HACKERS] Cluster name in ps output

On 06/29/2014 02:25 PM, Andres Freund wrote: > On 2014-06-29 11:11:14 +0100, Thomas Munro wrote: >> > On 29 June 2014 10:55, Andres Freund wrote: >>> > > So, I'd looked at it with an eye towards committing it and found some >>> > > more things. I've now >>> > > * added the restriction that the clu

Re: [HACKERS] Cluster name in ps output

On 07/04/2014 08:50 AM, Fujii Masao wrote: > On Wed, Jul 2, 2014 at 3:45 AM, Vik Fearing wrote: >> Is there a reason for not using this in synchronous_standby_names, >> perhaps falling back to application_name if not set? > > You mean that if synchronous_standby

Re: [HACKERS] DISTINCT with btree skip scan

On 07/05/2014 02:17 AM, Thomas Munro wrote: > As an exercise I hacked up the simplest code I could think of that would > demonstrate a faster DISTINCT based on skipping ahead to the next > distinct value in an index-only scan. Please see the attached (extremely > buggy) patch, and the example sessi

Re: [HACKERS] Aggregate function API versus grouping sets

On 07/02/2014 10:15 PM, Andrew Gierth wrote: > (Had one request so far for a mode() variant that returns the unique > modal value if one exists, otherwise null; so the current set of > ordered-set aggs by no means exhausts the possible applications.) I resemble that remark. :) But seriously, am I

Re: [HACKERS] Missing autocomplete for CREATE DATABASE

On 07/10/2014 09:32 PM, Magnus Hagander wrote: > It seems psql is missing autocomplete entries for LC_COLLATE and > LC_CTYPE for the CREATE DATABASE command. Attached patch adds that. > > I doubt this is important enough to backpatch - thoughts? It won't apply to current head, but otherwise I see

Re: [HACKERS] [BUGS] BUG #10823: Better REINDEX syntax.

On 07/30/2014 07:46 PM, Tom Lane wrote: > Bruce Momjian writes: >> On Wed, Jul 30, 2014 at 01:29:31PM -0400, Tom Lane wrote: >>> I don't find it all that odd. We should not be encouraging routine >>> database-wide reindexes. > >> Uh, do we encourage database-wide VACUUM FULL or CLUSTER, as we us

Re: [HACKERS] New partitioning - some feedback

it would be good if the 'main' partitioned table and > its 'partitions' showed up as a different type in some way. I've just read through this thread, and I'm wondering why we can't just have something like \set SHOW_PARTITIONS true or some

Re: [HACKERS] password_encryption, default and 'plain' support

ot;Backwards" is not plural, it's a regional variation of "backward" (or vice versa depending on which region you come from). Both are correct. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Su

Re: [HACKERS] CTE inlining

notably so, in which case they can easily figure where to add the > MATERIALIZED option and regain the original performance. I am overwhelmingly in favor of this option. I am in favor of an enable_inlinedcte guc in the same spirit as the other enable_* gucs, but violently opposed to any

[HACKERS] Renaming a table to an array's autogenerated name

ray's name (which was my case when I found this bug), the new array name will be ___foo instead of just __foo. I don't know if it's worth worrying about that. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise,

Re: [HACKERS] Renaming a table to an array's autogenerated name

On 05/25/2017 05:24 PM, Tom Lane wrote: > Vik Fearing writes: >> In commit 9aa3c782c93, Tom fixed a bug in which creating a table _foo >> when an array type of that name already existed would make the array >> type change its name to get out of the way. But it missed a trick

Re: [HACKERS] Renaming a table to an array's autogenerated name

On 05/26/2017 03:20 PM, Tom Lane wrote: > Vik Fearing writes: >> On 05/25/2017 05:24 PM, Tom Lane wrote: >>> After some experimentation, I came up with the attached, which simply >>> skips the "recursive" step if it would apply to the same array type we >&g

Re: [HACKERS] Inconsistent syntax for NumericOnly grammar production

; ERROR: syntax error at or near "4.2" > LINE 1: set random_page_cost = +4.2; > ^ > Any objections to allowing "+ FCONST" here? I'm inclined to > fix this and back-patch it as well. Seems like the right thing to do; no objections h

[HACKERS] Logging idle checkpoints

d trick in 6ef2eba3f57. Attached is a one-liner fix. I realize how imminent we are from releasing v10 but I hope there is still time for such a minor issue as this. -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Su

Re: [HACKERS] Tab completion for CREATE SEQUENCE

eywords tracked. >> I am switching at the same time this patch as "Ready for committer". > > You didn't remove RESTART, so I did that. And this needed some more > parentheses to make my compiler happy. > > Committed with those changes. Thank you, Bren

Re: [HACKERS] CREATE TABLESPACE WITH

On 12/26/2013 06:10 PM, David Fetter wrote: > On Tue, Dec 24, 2013 at 07:25:01PM +0100, Vik Fearing wrote: >> I was recently annoyed that I had to do >> >> CREATE TABLESPACE x LOCATION y; >> ALTER TABLESPACE x SET (random_page_cost = z); >> >> The attached

Re: [HACKERS] CREATE TABLESPACE WITH

On 01/15/2014 03:07 AM, Michael Paquier wrote: > I just had a quick look at this patch, no testing at all. Thank you for looking at it. > I am seeing that regression tests are still missing here, they should be > added in > src/test/regress/input/tablespace.source. New patch attached, with re

Re: [HACKERS] CREATE FOREIGN TABLE ( ... LIKE ... )

On 11/24/2013 02:03 AM, Vik Fearing wrote: > On 10/15/2013 07:50 AM, David Fetter wrote: >> On Mon, Oct 07, 2013 at 11:16:56PM -0700, David Fetter wrote: >>> Folks, >>> >>> Please find attached a patch implementing and documenting, to some >>> extent,

Re: [HACKERS] CREATE FOREIGN TABLE ( ... LIKE ... )

On 01/16/2014 01:21 AM, Tom Lane wrote: > Vik Fearing writes: >>> I am marking this patch as 'returned with feedback' in the commitfest app. >> It looks like this patch got left behind in the previous commitfest. >> What is the policy for moving it? Is it too l

Re: [HACKERS] CREATE TABLESPACE WITH

On 01/18/2014 03:21 PM, Michael Paquier wrote: > So, except for the regression output problem, I think that the code is > clean so marking it as "Ready for committer" on the commit fest app. Thank you for the review. Sorry about the regression thing. I tried to randomize it a bit so that I would

Re: [HACKERS] Closing commitfest 2013-11

On 01/20/2014 10:31 PM, Tom Lane wrote: > I think the idea was that patch authors should take responsibility for > pushing their patches forward to 2014-01 if they still wanted them > considered. Quite a few patches already were moved that way, IIRC. > > Agreed though that we shouldn't let them ju

Re: [HACKERS] [PATCH] Use MAP_HUGETLB where supported (v3)

On 01/29/2014 01:12 PM, Heikki Linnakangas wrote: > On 01/28/2014 06:11 PM, Christian Kruse wrote: >> Hi, >> >> attached you will find a new version of the patch, ported to HEAD, >> fixed the mentioned bug and - hopefully - dealing the the remaining >> issues. > > Thanks, I have committed this now.

Re: [HACKERS] pg_sleep_enhancements.patch

On 01/29/2014 08:04 PM, Pavel Stehule wrote: > Hello > > I am looking on this patch Thank you for looking at it. > http://www.postgresql.org/message-id/525fe206.6000...@dalibo.com > > a) pg_sleep_for - no objection - it is simple and secure Okay. > b) pg_sleep_until > > I am not sure - maybe th

Re: [HACKERS] pg_sleep_enhancements.patch

On 01/29/2014 08:21 PM, Pavel Stehule wrote: > second question - is not this functionality too dangerous? If somebody > use it as scheduler, then > > a) can holds connect, session data, locks too long time > b) it can stop on query timeout probably much more early then user expect > > What is expec

Re: [HACKERS] [PATCH] pg_sleep(interval)

On 01/30/2014 09:48 PM, Robert Haas wrote: > On Thu, Oct 17, 2013 at 9:11 AM, Vik Fearing wrote: >> On 10/17/2013 02:42 PM, Robert Haas wrote: >>> On Thu, Oct 17, 2013 at 8:26 AM, Vik Fearing wrote: >>>> On 10/17/2013 10:03 AM, Fabien COELHO wrote: >>>>&

Re: [HACKERS] CREATE FOREIGN TABLE ( ... LIKE ... )

On 01/25/2014 06:25 AM, David Fetter wrote: >> I like this patch, but I don't like its implementation at all. >> > >> > First of all, the documentation doesn't compile: >> > >> > openjade:ref/create_foreign_table.sgml:124:17:E: end tag for "LISTITEM" >> > omitted, but OMITTAG NO was specified >>

Re: [HACKERS] [GENERAL] Insert result does not match record count

On 01/31/2014 06:19 PM, Bruce Momjian wrote: > On Wed, Jul 24, 2013 at 08:08:32PM +0200, Andres Freund wrote: >> On 2013-07-24 13:48:23 -0400, Tom Lane wrote: >>> Vik Fearing writes: >>>> Also worth mentioning is bug #7766. >>>> http://ww

Re: [HACKERS] [GENERAL] Insert result does not match record count

On 01/31/2014 10:56 PM, Bruce Momjian wrote: > On Fri, Jan 31, 2014 at 04:38:21PM -0500, Tom Lane wrote: >> Bruce Momjian writes: >>> On Fri, Jan 31, 2014 at 06:34:27PM +0100, Vik Fearing wrote: >>>> Unfortunately, I gave up on it as being over my head when I n

Re: [HACKERS] [GENERAL] Insert result does not match record count

On 02/01/2014 02:26 AM, Bruce Momjian wrote: > On Sat, Feb 1, 2014 at 02:25:16AM +0100, Vik Fearing wrote: >>> OK, thanks for the feedback. I understand now. The contents of the >>> string will potentially have a larger integer, but the byte length of >>> the strin

[HACKERS] nextVictimBuffer in README

While reading through src/backend/storage/buffer/README and looking at the code that it describes, I noticed that the case is wrong for nextVictimBuffer. It's no big deal really, but the attached trivial patch makes the README match the code. -- Vik *** a/src/backend/storage/buffer/README --- b

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

On 03/01/2014 12:06 PM, Simon Riggs wrote: > On 27 February 2014 08:48, Simon Riggs wrote: >> On 26 February 2014 15:25, Andres Freund wrote: >>> On 2014-02-26 15:15:00 +, Simon Riggs wrote: On 26 February 2014 13:38, Andres Freund wrote: > Hi, > > On 2014-02-26 07:32:45 +00

Re: [HACKERS] commit fest status and release timeline

On 03/01/2014 07:50 PM, Josh Berkus wrote: > On 03/01/2014 09:01 AM, Peter Eisentraut wrote: >> Status Summary. Needs Review: 36, Waiting on Author: 7, Ready for >> Committer: 16, Committed: 43, Returned with Feedback: 8, Rejected: 4. >> Total: 114. >> >> We're still on track to achieve about 50% c

  1   2   3   >