Re: Using a single standalone-backend run in initdb (was Re: [HACKERS] Bootstrap DATA is a pita)

Mark Dilger writes: >> On Dec 12, 2015, at 3:42 PM, Tom Lane wrote: >> ... In general, though, I'd rather not try to >> teach InteractiveBackend() such a large amount about SQL syntax. > I use CREATE RULE within startup files in the fork that I

Re: [HACKERS] Disabling an index temporarily

On Sun, Dec 13, 2015 at 1:16 AM, Jaime Casanova < jaime.casan...@2ndquadrant.com> wrote: > indexrelid = 'indexname'::regclass; This works, but might bloat system catalog.

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-12-10 19:29 GMT+01:00 Pavel Stehule : > > > >> postgres=# \crosstabview 4 +month label >> > > Maybe using optional int order column instead label is better - then you > can do sort on client side > > so the syntax can be "\crosstabview VCol [+/-]HCol [[+-]HOrderCol]

Re: [HACKERS] PATCH: add pg_current_xlog_flush_location function

On Sun, Dec 13, 2015 at 12:07 AM, Tomas Vondra wrote: > Hi, > > attached is a patch adding a function pg_current_xlog_flush_location(), > which proved quite useful when investigating the ext4 data loss bug. It's > mostly what was already sent to that thread, except

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Sat, Dec 12, 2015 at 9:48 AM, Corey Huinker wrote: > > > What, if any, other load should be placed on the underlying table during the > test? > > I ask because CIC statements that run in seconds on our staging machine can > take many hours on our production machine,

Re: [HACKERS] PATCH: track last known XLOG segment in control file

On Sun, Dec 13, 2015 at 4:24 AM, Tomas Vondra wrote: > > > On 12/12/2015 11:39 PM, Andres Freund wrote: > >> On 2015-12-12 23:28:33 +0100, Tomas Vondra wrote: >> >>> On 12/12/2015 11:20 PM, Andres Freund wrote: >>> On 2015-12-12 22:14:13 +0100, Tomas Vondra

Re: [HACKERS] [patch] Proposal for \rotate in psql

2015-12-13 8:14 GMT+01:00 Pavel Stehule : > > > 2015-12-10 19:29 GMT+01:00 Pavel Stehule : > >> >> >> >>> postgres=# \crosstabview 4 +month label >>> >> >> Maybe using optional int order column instead label is better - then you >> can do sort on

Re: [HACKERS] Parallel Aggregate

On Sat, Dec 12, 2015 at 8:42 AM, David Rowley wrote: > On 12 December 2015 at 04:00, Robert Haas wrote: >> >> I'd like to commit David Rowley's patch from the other thread first, >> and then deal with this one afterwards. The only thing I

Re: [HACKERS] Disabling an index temporarily

> Tatsuo Ishii wrote: >>> Wouldn't something like: >>> >>> ALTER INDEX foo SET DISABLED; >>> >>> See more in line with our grammar? >> >> But this will affect other sessions, no? > > Not if it is used in a transaction that ends with a ROLLBACK, > but then you might as well use DROP INDEX, except

Re: [HACKERS] Error with index on unlogged table

On Fri, Dec 11, 2015 at 4:54 PM, Michael Paquier wrote: > On Fri, Dec 11, 2015 at 4:27 AM, Andres Freund wrote: >> On 2015-12-10 18:36:32 +0100, Andres Freund wrote: >>> On 2015-12-10 12:19:12 -0500, Robert Haas wrote: >>> > > The real problem there

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Wed, Dec 9, 2015 at 1:02 AM, Robert Haas wrote: > > On Thu, Dec 3, 2015 at 1:48 AM, Amit Kapila wrote: > > I think the way to address is don't add backend to Group list if it is > > not intended to update the same page as Group leader. For

Re: [HACKERS] Logical replication and multimaster

On 12 December 2015 at 02:24, Robert Haas wrote: > On Fri, Dec 11, 2015 at 5:16 AM, Andres Freund wrote: > > On 2015-12-11 18:12:55 +0800, Craig Ringer wrote: > >> On 10 December 2015 at 03:19, Robert Haas > wrote: > >> > On

Re: [HACKERS] Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On Sat, Dec 12, 2015 at 11:37 AM, Noah Misch wrote: > On Fri, Dec 11, 2015 at 09:34:34PM +0900, Michael Paquier wrote: >> On Fri, Dec 11, 2015 at 8:48 PM, Alvaro Herrera >> wrote: >> > Michael Paquier wrote: >> >> On Fri, Dec 11, 2015 at 5:35 AM,

Re: [HACKERS] Disabling an index temporarily

Tatsuo Ishii wrote: >> Wouldn't something like: >> >> ALTER INDEX foo SET DISABLED; >> >> See more in line with our grammar? > > But this will affect other sessions, no? Not if it is used in a transaction that ends with a ROLLBACK, but then you might as well use DROP INDEX, except that DROP INDEX

Re: [HACKERS] Making tab-complete.c easier to maintain

On Sat, Dec 12, 2015 at 12:00 AM, Tom Lane wrote: > Greg Stark writes: >> So I don't think it makes sense to hold up improvements today hoping >> for something like this. > > Yeah, it's certainly a wishlist item rather than something that should > block

Re: [HACKERS] Error with index on unlogged table

On 2015-12-11 16:54:45 +0900, Michael Paquier wrote: > + if (rel->rd_rel->relpersistence == > RELPERSISTENCE_PERMANENT || > + (rel->rd_rel->relpersistence == > RELPERSISTENCE_UNLOGGED && > +forkNum ==

Re: [HACKERS] Using quicksort for every external sort run

On Sun, Dec 6, 2015 at 4:25 PM, Peter Geoghegan wrote: > Maybe we should consider trying to get patch 0002 (the memory > pool/merge patch) committed first, something Greg Stark suggested > privately. That might actually be an easier way of integrating this > work, since it

Re: [HACKERS] Disabling an index temporarily

On 12/12/2015 11:42, Albe Laurenz wrote: > Tatsuo Ishii wrote: >>> Wouldn't something like: >>> >>> ALTER INDEX foo SET DISABLED; >>> >>> See more in line with our grammar? >> >> But this will affect other sessions, no? > > Not if it is used in a transaction that ends with a ROLLBACK, > but then

Re: [HACKERS] Error with index on unlogged table

On 2015-12-12 20:49:52 +0900, Michael Paquier wrote: > Should we consider this bug a 9.5 blocker? I don't think so. But either way, I'm right now working on getting it fixed anyway. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] psql tab completion bug for ALL IN TABLESPACE

Hi all, I just bumped into the following thing while looking again at Thomas' patch for psql tab completion: --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql/tab-complete.c @@ -1040,7 +1040,7 @@ psql_completion(const char *text, int start, int end)

Re: [HACKERS] Making tab-complete.c easier to maintain

On Wed, Dec 9, 2015 at 8:17 PM, Thomas Munro wrote: > Thanks for looking at this Michael. It's probably not much fun to > review! Here is a new version with that bit removed. More responses > inline below. Could this patch be rebased? There are now conflicts with 8b469bd7 and it does not apply

Re: [HACKERS] Error with index on unlogged table

On 2015-12-12 12:52:21 +0100, Andres Freund wrote: > On 2015-12-12 20:49:52 +0900, Michael Paquier wrote: > > Should we consider this bug a 9.5 blocker? > > I don't think so. But either way, I'm right now working on getting it > fixed anyway. And done. Took a bit longer than predicted - I had to

Re: [HACKERS] Error with index on unlogged table

Michael Paquier writes: > Should we consider this bug a 9.5 blocker? I feel uneasy with the fact > of releasing a new major version knowing that we know some bugs on it, > and this one is not cool so I have added it in the list of open items. > We know the problem and

Re: [HACKERS] Disabling an index temporarily

> Oleg and Teodor announced some time ago an extension for this exact use > case, see > http://www.postgresql.org/message-id/pine.lnx.4.64.0910062354510.6...@sn.sai.msu.ru > > This also has the advantage of not needing an exclusive lock on the index. Thanks for the info. I will try out them.

Re: [HACKERS] Rework the way multixact truncations work

Noah, Robert, All On 2015-12-11 11:20:21 -0500, Robert Haas wrote: > On Thu, Dec 10, 2015 at 9:32 AM, Robert Haas wrote: > >> Adding a 'prevOffsetStopLimit' and using it seems like a ~5 line patch. > > > > So let's do that, then. > > Who is going to take care of this?

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Fri, Dec 11, 2015 at 5:35 PM, Peter Geoghegan wrote: > On Fri, Dec 11, 2015 at 2:26 PM, Corey Huinker > wrote: > > Sure, the machine we called "ninefivealpha", which incidentally, failed > to > > find a single bug in alpha2 thru beta2, is currently

Re: [HACKERS] Bootstrap DATA is a pita

Mark Dilger writes: >> On Dec 11, 2015, at 2:54 PM, Caleb Welton wrote: >> Compare: >> CREATE FUNCTION lo_export(oid, text) RETURNS integer LANGUAGE internal >> STRICT AS 'lo_export' WITH (OID=765); >> >> DATA(insert OID = 765 ( lo_export

[HACKERS] PATCH: add pg_current_xlog_flush_location function

Hi, attached is a patch adding a function pg_current_xlog_flush_location(), which proved quite useful when investigating the ext4 data loss bug. It's mostly what was already sent to that thread, except for docs that were missing in the initial version. I'll put this into 2016-01 CF.

Re: [HACKERS] Disabling an index temporarily

On 11 December 2015 at 22:03, Joshua D. Drake wrote: > On 12/11/2015 06:25 PM, Tatsuo Ishii wrote: > >> What about inventing a new SET command something like: >> >> SET disabled_index to >> >> This adds to "disabled index list". The disabled index >> list let the planner

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Sat, Dec 12, 2015 at 9:48 AM, Corey Huinker wrote: > I ask because CIC statements that run in seconds on our staging machine can > take many hours on our production machine, when most of the access is just > reads, though those reads may have been part of a larger

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Greg Stark writes: > There may be other errors that would be surprising for Tom or Robert. What > I did with the string argument fuzzer was printed counts for each sqlstate > for the errors and watched for errors that only occurred occasionally or > didn't make sense to me. > > Also, do you have

Re: [HACKERS] WIP: Rework access method interface

On 2015-12-09 15:09, Alexander Korotkov wrote: ​Patch was rebased against current master. Any notes about current version of patch? It would be nice to commit it and continue work on other parts of am extendability.​ The rebase seems broken, there are things missing in this version of the

Re: [HACKERS] [COMMITTERS] pgsql: Handle policies during DROP OWNED BY

On 12/11/15 4:12 PM, Stephen Frost wrote: > As with ACLs, the DROP OWNED BY caller must have permission to modify > the policy or a WARNING is thrown and no change is made to the policy. That warning doesn't tell the user anything about how to fix the situation or whether or why the situation is

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On 2015-11-15 16:24:24 -0500, Robert Haas wrote: > I think what we should do about the buffer locks is polish up this > patch and get it applied: > > http://www.postgresql.org/message-id/20150907175909.gd5...@alap3.anarazel.de > > I think it needs to be adapted to use predefined constants for

Re: [HACKERS] Using quicksort for every external sort run

On Sat, Dec 12, 2015 at 12:41 AM, Greg Stark wrote: > On Wed, Dec 9, 2015 at 2:44 AM, Peter Geoghegan wrote: >> On Tue, Dec 8, 2015 at 6:39 PM, Greg Stark wrote: >> >> I guess you mean insertion sort. What's the theoretical justification >> for the

Re: [HACKERS] Using quicksort for every external sort run

On Sat, Dec 12, 2015 at 7:42 PM, Ants Aasma wrote: > As the open coding doesn't help with eliminating control flow > dependencies, so my idea is to encode the sort network comparison > order in an array and use that to drive a simple loop. The code size > would be pretty

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de wrote: > On 2015-11-15 16:24:24 -0500, Robert Haas wrote: >> I think what we should do about the buffer locks is polish up this >> patch and get it applied: >> >>

Re: [HACKERS] Parallel Aggregate

On Fri, Dec 11, 2015 at 4:42 PM, David Rowley wrote: > On 12 December 2015 at 04:00, Robert Haas wrote: >> I'd like to commit David Rowley's patch from the other thread first, >> and then deal with this one afterwards. The only thing I feel

Re: [HACKERS] [COMMITTERS] pgsql: Handle policies during DROP OWNED BY

On Sat, Dec 12, 2015 at 4:35 PM, Stephen Frost wrote: > * Peter Eisentraut (pete...@gmx.net) wrote: >> On 12/11/15 4:12 PM, Stephen Frost wrote: >> > As with ACLs, the DROP OWNED BY caller must have permission to modify >> > the policy or a WARNING is thrown and no change is

Re: Using a single standalone-backend run in initdb (was Re: [HACKERS] Bootstrap DATA is a pita)

> On Dec 12, 2015, at 3:42 PM, Tom Lane wrote: > > Joe Conway writes: >> On 12/12/2015 02:31 PM, Tom Lane wrote: >>> I'm not particularly wedded to this rule. In principle we could go so >>> far as to import psql's code that parses commands and figures

Re: [HACKERS] Rework the way multixact truncations work

On Sat, Dec 12, 2015 at 12:02 PM, Andres Freund wrote: > Noah, Robert, All > > On 2015-12-11 11:20:21 -0500, Robert Haas wrote: >> On Thu, Dec 10, 2015 at 9:32 AM, Robert Haas wrote: >> >> Adding a 'prevOffsetStopLimit' and using it seems like a ~5 line

[HACKERS] [PATCH] PostGIS Doc Urls

The attached patch changes web references to PostGIS to point to the actual community site (postgis.net) which is active, rather than the historical site (postgis.org). P. --  Paul Ramsey http://cleverelephant.ca http://postgis.net postgis_doc.patch Description: Binary data -- Sent via

Re: [HACKERS] Using quicksort for every external sort run

On Sat, Dec 12, 2015 at 2:28 PM, Peter Geoghegan wrote: > On Sat, Dec 12, 2015 at 12:10 AM, Jeff Janes wrote: >> I have a question about the terminology used in this patch. What is a >> tuple proper? What is it in contradistinction to? I would think that

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

On Sun, Dec 13, 2015 at 12:04:34AM +, Greg Stark wrote: > On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich > wrote: > Did you publish the source already? I haven't been following all > along, sorry if these are all answered questions. Either he has, or the following

Re: Using a single standalone-backend run in initdb (was Re: [HACKERS] Bootstrap DATA is a pita)

Andres Freund writes: > That's cool too. Besides processing the .bki files, and there largely > reg*_in, the many restarts are the most expensive parts of initdb. BTW, in case anyone is doubting it, I did a little bit of "perf" tracing and confirmed Andres' comment here: more

Re: [HACKERS] [PATCH] PostGIS Doc Urls

Paul Ramsey writes: > The attached patch changes web references to PostGIS to point to the actual > community site (postgis.net) which is active, rather than the historical site > (postgis.org). Pushed, thanks. regards, tom lane -- Sent

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Greg Stark writes: > On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich > wrote: > When you hit the timeout is this implemented in your fuzzer or using > statement_timeout? If the former, can you add a statement_timeout of > just short of the timeout in the fuzzer and find

Re: [HACKERS] [COMMITTERS] pgsql: Handle policies during DROP OWNED BY

* Peter Eisentraut (pete...@gmx.net) wrote: > On 12/11/15 4:12 PM, Stephen Frost wrote: > > As with ACLs, the DROP OWNED BY caller must have permission to modify > > the policy or a WARNING is thrown and no change is made to the policy. > > That warning doesn't tell the user anything about how to

Re: [HACKERS] PATCH: track last known XLOG segment in control file

Hi, On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote: > this is the second improvement proposed in the thread [1] about ext4 data > loss issue. It adds another field to control file, tracking the last known > WAL segment. This does not eliminate the data loss, just the silent part of > it when

Re: [HACKERS] Using quicksort for every external sort run

On Sat, Dec 12, 2015 at 12:10 AM, Jeff Janes wrote: > I have a question about the terminology used in this patch. What is a > tuple proper? What is it in contradistinction to? I would think that > a tuple which is located in its own palloc'ed space is the "proper" > one,

Re: [HACKERS] PATCH: track last known XLOG segment in control file

On 12/12/2015 11:20 PM, Andres Freund wrote: Hi, On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote: this is the second improvement proposed in the thread [1] about ext4 data loss issue. It adds another field to control file, tracking the last known WAL segment. This does not eliminate the

Re: Using a single standalone-backend run in initdb (was Re: [HACKERS] Bootstrap DATA is a pita)

On 12/12/2015 02:31 PM, Tom Lane wrote: > I'm not particularly wedded to this rule. In principle we could go so > far as to import psql's code that parses commands and figures out which > semicolons are command terminators --- but that is a pretty large chunk > of code, and I think it'd really be

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Fri, Dec 11, 2015 at 9:13 AM, Robert Haas wrote: > Also, I'd be in favor of you updating the patch to reflect the > comments from Tom and Simon on November 17th. Attached revision: * Has more worked out comments on encoding, per Simon's request. * Uses Tom's preferred

Using a single standalone-backend run in initdb (was Re: [HACKERS] Bootstrap DATA is a pita)

I wrote: > BTW, there's another thing I'd like to see improved in this area, which is > a problem already but will get a lot worse if we push more work into the > post-bootstrap phase of initdb. That is that the post-bootstrap phase is > both inefficient and impossible to debug. If you've ever

Re: [HACKERS] Bootstrap DATA is a pita

On 2015-12-12 13:28:28 -0500, Tom Lane wrote: > BTW, there's another thing I'd like to see improved in this area, which is > a problem already but will get a lot worse if we push more work into the > post-bootstrap phase of initdb. That is that the post-bootstrap phase is > both inefficient and

Re: Using a single standalone-backend run in initdb (was Re: [HACKERS] Bootstrap DATA is a pita)

On 2015-12-12 17:31:49 -0500, Tom Lane wrote: > I thought this sounded like a nice lazy-Saturday project, so I started > poking at it, and attached is a WIP patch. Not bad, not bad at all. > After some experimentation, I came up with the idea of executing any > time that a semicolon followed by

Re: [HACKERS] Error with index on unlogged table

On Sat, Dec 12, 2015 at 10:31 PM, Andres Freund wrote: > On 2015-12-12 12:52:21 +0100, Andres Freund wrote: >> On 2015-12-12 20:49:52 +0900, Michael Paquier wrote: >> > Should we consider this bug a 9.5 blocker? >> >> I don't think so. But either way, I'm right now working on

Re: Using a single standalone-backend run in initdb (was Re: [HACKERS] Bootstrap DATA is a pita)

Andres Freund writes: > On 2015-12-12 17:31:49 -0500, Tom Lane wrote: >> Does anyone know of people using standalone mode other than >> for initdb? > Unfortunately yes. There's docker instances around that configure users > and everything using it. Hm, that means that we

[HACKERS] PATCH: track last known XLOG segment in control file

Hi, this is the second improvement proposed in the thread [1] about ext4 data loss issue. It adds another field to control file, tracking the last known WAL segment. This does not eliminate the data loss, just the silent part of it when the last segment gets lost (due to forgetting the

Re: [HACKERS] PATCH: track last known XLOG segment in control file

On 2015-12-12 23:28:33 +0100, Tomas Vondra wrote: > On 12/12/2015 11:20 PM, Andres Freund wrote: > >On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote: > >>this is the second improvement proposed in the thread [1] about ext4 data > >>loss issue. It adds another field to control file, tracking the

Re: [HACKERS] PATCH: track last known XLOG segment in control file

On 12/12/2015 11:39 PM, Andres Freund wrote: On 2015-12-12 23:28:33 +0100, Tomas Vondra wrote: On 12/12/2015 11:20 PM, Andres Freund wrote: On 2015-12-12 22:14:13 +0100, Tomas Vondra wrote: this is the second improvement proposed in the thread [1] about ext4 data loss issue. It adds another

Re: Using a single standalone-backend run in initdb (was Re: [HACKERS] Bootstrap DATA is a pita)

Joe Conway writes: > On 12/12/2015 02:31 PM, Tom Lane wrote: >> I'm not particularly wedded to this rule. In principle we could go so >> far as to import psql's code that parses commands and figures out which >> semicolons are command terminators --- but that is a pretty

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich wrote: > I currently set statement_timeout to 1s to avoid wasting time letting > postgres crunch numbers. Less than 0.5% of the queries run into this > timeout. I wonder if any of these timeouts would be interesting to