[HACKERS] Building from git source on ubuntu with gssapi

I can't ./configure --with-gssapi from git on ubuntu 14.04.3 because: configure: error: gssapi.h header file is required for GSSAPI If I download the distribution-specific 9.3 source with apt, I find their secret sauce to make it work: ./debian/rules:LDFLAGS+= -Wl,--as-needed

[HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Simple patch, applies and makes cleanly, does what it says and says

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

On Sun, Nov 1, 2015 at 11:09 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Nov 2, 2015 at 2:58 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: >> Simple patch, applies and makes cleanly, does what it says and says what it >> does. >> >>

Re: [HACKERS] New gist vacuum.

On Thu, Sep 10, 2015 at 3:52 PM, Костя Кузнецов wrote: > Hello. I am student from gsoc programm. > My project is sequantial access in vacuum of gist. > > New vacuum has 2 big step: > physical order scan pages and cleaning after 1 step. > > > 1 scan - scan all pages and create

Re: [HACKERS] pg_dump

On Thu, Oct 29, 2015 at 7:51 AM, Tom Lane wrote: > =?koi8-r?B?5M3J1NLJyiD3z9LPzsnO?= writes: >>> šIt's a problem. See this recent discussion: >>> šhttp://www.postgresql.org/message-id/flat/20150710115735.gh26...@alap3.anarazel.de > >> Postgresmen, we

Re: [HACKERS] [PATCH v2] GSSAPI encryption support

On Tue, Sep 29, 2015 at 7:53 AM, Robbie Harwood wrote: > Robbie Harwood writes: > > Michael Paquier writes: > >> Well, the issue is still here: login through gssapi fails with >> your patch, not with HEAD. This

Re: [HACKERS] quieting DEBUG3

On Wed, Oct 28, 2015 at 6:57 AM, Robert Haas wrote: > On Wed, Oct 28, 2015 at 1:51 AM, Tom Lane wrote: >> Craig Ringer writes: >>> I think it'd be helpful to define some level of policy about what the >>> debug levels are

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

On Sun, Oct 18, 2015 at 9:12 PM, Thomas Munro wrote: > > Thanks for taking a look at this! The word count returned by > get_previous_words was incorrect. Here is a corrected version. > I haven't looked at v6 yet, but in v5: "set work_mem TO" completes to

Re: [HACKERS] 9.5Beta1 psql wrapped format expanded output

On Fri, Oct 23, 2015 at 5:11 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Fri, Oct 23, 2015 at 3:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > >> Jeff Janes wrote: > >>> When I use psql

Re: [HACKERS] 9.5Beta1 psql wrapped format expanded output

On Fri, Oct 23, 2015 at 3:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: >> Jeff Janes wrote: >>> When I use psql with wrapped format with expanded output, I get the >>> period that is supposed to be at the end

[HACKERS] 9.5Beta1 psql wrapped format expanded output

When I use psql with wrapped format with expanded output, I get the period that is supposed to be at the end of the line being at the beginning of the next line. Can anyone else verify this? I want to verify it is not some local issue before looking into it too far. I've made the screen

Re: [HACKERS] COPY FREEZE and PD_ALL_VISIBLE

On Tue, Oct 20, 2015 at 7:02 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Oct 18, 2015 at 5:23 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > > I'm planning on adding a todo item to have COPY FREEZE set > PD_ALL_VISIBLE. > > Or is there some reason thi

Re: [HACKERS] pg_restore cancel TODO

On Mon, Oct 19, 2015 at 9:37 AM, Bruce Momjian <br...@momjian.us> wrote: > On Mon, Oct 19, 2015 at 09:26:21AM -0700, Jeff Janes wrote: > > It seems like gdb eats signals that you send a process while it is being > > debugged, so it is hard to figure out what is going on. Fr

Re: [HACKERS] pg_restore cancel TODO

On Mon, Oct 19, 2015 at 8:28 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > Jeff Janes wrote: > >> I've added the TODO item: > >> > >> When pg_upgrade -j ... is interrupted (for example, ctrl-C fro

[HACKERS] COPY FREEZE and PD_ALL_VISIBLE

I'm planning on adding a todo item to have COPY FREEZE set PD_ALL_VISIBLE. Or is there some reason this can't be done? Since the whole point of COPY FREEZE is to avoid needing to rewrite the entire table, it seems rather perverse that the first time the table is vacuumed, it needs to rewrite the

[HACKERS] tab completion for extension versions

This patch adds "VERSION" to the list of words completed after "create extension foo", and adds the list of available versions of foo after "create extension foo version". There is no point in filtering out the already installed version, as the entire statement is doomed already if any version of

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

On Sun, Oct 18, 2015 at 5:31 PM, Thomas Munro wrote: > Hi > > Here is a new version merging recent changes. > For reasons I do not understand, "SET work_mem " does not complete with "TO". But if I change: else if (Matches2("SET", MatchAny)) to: else if

[HACKERS] pg_restore cancel TODO

I've added the TODO item: When pg_upgrade -j ... is interrupted (for example, ctrl-C from the keyboard) make it cancel the children processes. The context where this arises is that I want to populate data into a new installation compiled with a patch under review, but immediately get error

Re: [HACKERS] about fsync in CLOG buffer write

On Sat, Sep 12, 2015 at 5:21 PM, Andres Freund <and...@anarazel.de> wrote: > On September 12, 2015 5:18:28 PM PDT, Jeff Janes <jeff.ja...@gmail.com> > wrote: > >On Wed, Sep 2, 2015 at 5:32 AM, Andres Freund <and...@anarazel.de> > >wrote: > > > &

Re: [HACKERS] Potential GIN vacuum bug

On Thu, Sep 3, 2015 at 10:42 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Mon, Aug 31, 2015 at 12:10 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > >> On Sun, Aug 30, 2015 at 3:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >>> Jeff Janes <je

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

On Fri, Sep 11, 2015 at 8:01 PM, Amit Kapila wrote: > On Fri, Sep 11, 2015 at 9:21 PM, Robert Haas > wrote: > > > > On Fri, Sep 11, 2015 at 10:31 AM, Amit Kapila > wrote: > > > > Could you perhaps try to create a testcase

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Thu, Oct 1, 2015 at 7:48 AM, Magnus Hagander wrote: > On Thu, Oct 1, 2015 at 4:35 PM, Robert Haas wrote: > >> >> - Bug numbers are sometimes preserved in commit messages, but they >> never make it into release notes. This actually seems like

Re: [HACKERS] Potential GIN vacuum bug

On Tue, Sep 1, 2015 at 8:05 AM, Robert Haas wrote: > On Sun, Aug 30, 2015 at 6:57 PM, Tom Lane wrote: > >> But we would still have to deal with the > >> fact that unconditional acquire attempt by the backends will cause a > vacuum > >> to cancel

[HACKERS] Building with MinGW

Has anyone had success following the instructions at https://wiki.postgresql.org/wiki/Building_With_MinGW#Installing_Git recently? I've followed the instructions to set up the build environment on a Windows box, and I can't build from git. I can from the nightly tarball. So I think the most

[HACKERS] Re: Reusing abbreviated keys during second pass of ordered [set] aggregates

This needs a rebase, there are several conflicts in src/backend/executor/nodeAgg.c Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Sep 23, 2015 at 2:14 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Jeff Janes wrote: > > > > I'd rather, say, put some more work into cleaning the kruft out of the > > To-Do list, then put that effort into migrating the kruft to a fancier > >

[HACKERS] Tab completion for ALTER COLUMN SET STATISTICS

If I have "alter table foo alter COLUMN bar SET STATISTICS" in the line buffer, it tab completes to add " TO", which is not legal. The attached patch makes it not tab complete anything at all, which is at least not actively misleading. I thought of having it complete "-1", "" so that it gives a

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Sep 23, 2015 at 11:43 AM, Robert Haas wrote: > On Wed, Sep 23, 2015 at 2:30 PM, Kam Lasater wrote: > > Thanks for the suggestion. However, an issue tracker is not a > > replacement for mailing list(s) and vice versa. They are both > > necessary

Re: [HACKERS] creating extension including dependencies

On Sep 17, 2015 7:52 PM, "Petr Jelinek" <p...@2ndquadrant.com> wrote: > > On 2015-09-17 17:31, Jeff Janes wrote: >> >> >> Also, It would be nice to have psql tab complete the word CASCADE. >> > > Hmm, it already does? Indeed it does. Oops. I n

Re: [HACKERS] [COMMITTERS] pgsql: Add pages deleted from pending list to FSM

On Fri, Sep 18, 2015 at 6:27 AM, Tom Lane wrote: > [ moving thread to -hackers ] > > Fujii Masao writes: > > So autoanalyze still doesn't call IndexFreeSpaceMapVacuum(). > > That is, only backend can clean the list in INSERT-only workload. > > I don't

Re: [HACKERS] creating extension including dependencies

On Tue, Sep 15, 2015 at 8:44 PM, Petr Jelinek wrote: > On 2015-09-08 04:06, Michael Paquier wrote: > >> On Tue, Sep 8, 2015 at 10:44 AM, Michael Paquier >> wrote: >> >>> >>> Attached are as well changes for the documentation that I spotted in >>>

Re: [HACKERS] [PATCH] Microvacuum for gist.

On Wed, Sep 16, 2015 at 8:36 AM, Teodor Sigaev wrote: > But It seems to me that it would be better to rewrite all mentions of >> TupleDelete to MultiDelete in gist code. >> > > Sure. Patch is attached, and it changes WAL format, so be carefull with > testing. > Please, have a

[HACKERS] BUFFER_LOCK_* synonyms

All of the index methods have their own synonyms of the BUFFER_LOCK_* constants, for example: #define GIN_SHARE BUFFER_LOCK_SHARE #define GIST_SHARE BUFFER_LOCK_SHARE #define HASH_READ BUFFER_LOCK_SHARE #define BT_READ BUFFER_LOCK_SHARE But most of them pass their

Re: [HACKERS] [PATCH] Microvacuum for gist.

On Tue, Sep 8, 2015 at 2:35 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > > Fixed patch is attached. > > The commit of this patch seems to have created a bug in which updated tuples can disappear from the index, while remaining in the table. It looks like the bug depends on

Re: [HACKERS] pgbench progress with timestamp

On Wed, Sep 9, 2015 at 1:35 AM, Fabien COELHO wrote: > > In the sgml, second should be plural in 'intead of the number of second >> since the'. And 'intead' should be 'instead'. >> > > Ok. > > --progress-timestamp use a Unix-like epoch timestamp for progress >>

Re: [HACKERS] Summary of plans to avoid the annoyance of Freezing

On Wed, Sep 9, 2015 at 6:03 AM, Greg Stark wrote: > On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund wrote: > > My vote is that we should try to get freeze maps into 9.6 - that seems > > more realistic given that we have a patch right now. Yes, it might end > >

Re: [HACKERS] Spurious standby query cancellations

On Fri, Sep 4, 2015 at 3:25 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 27 August 2015 at 22:55, Jeff Janes <jeff.ja...@gmail.com> wrote: > >> In ResolveRecoveryConflictWithLock, there is the comment: >> >> /* >> * If blowing away eve

Re: [HACKERS] about fsync in CLOG buffer write

On Wed, Sep 2, 2015 at 5:32 AM, Andres Freund wrote: > On 2015-09-10 19:39:59 +0800, 张广舟(明虚) wrote: > > We found there is a fsync call when CLOG buffer > > is written out in SlruPhysicalWritePage(). It is often called when a > backend > > needs to check transaction status

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

On Thu, Sep 10, 2015 at 8:14 AM, Alvaro Herrera wrote: > dinesh kumar wrote: > > > Also, I was under impression that, all our TODO > > items are filtered for the real > use > > cases. Is my impression wrong. If I wanted to work on

Re: [HACKERS] checkpointer continuous flushing

On Wed, Sep 9, 2015 at 12:12 PM, Andres Freund wrote: > On 2015-09-09 20:56:15 +0200, Fabien COELHO wrote: > > As I wrote before, FreeBSD would be a good candidate because the > > posix_fadvise seems much more reasonable than on Linux, and should be > > profitable, so it

[HACKERS] ALTER INDEX...SET tab completion

I can never remember the syntax for setting index storage parameters. Is it =, TO, or just a space between the parameter name and the setting? This makes the tab completion more helpful, by providing the (mandatory) equals sign. Cheers, Jeff alter_index_tabcomplete_v1.patch Description:

Re: [HACKERS] pgbench progress with timestamp

On Mon, Sep 7, 2015 at 11:25 PM, Fabien COELHO wrote: > > Use milliseconds for consistency with the '%n' log_prefix patch currently >>> submitted by Tomas Vondra in the CF. >>> >>> sh> ./pgbench -P 1 -N -T 100 -c 2 >>> starting vacuum...end. >>> progress: 1.0 s, 546.0

Re: [HACKERS] pgbench progress with timestamp

On Sun, Aug 23, 2015 at 4:25 AM, Fabien COELHO wrote: > > It is not easy to compare events on a pgbench runs (oops, the tps is down) > with for instance events in postgres log, so as to figure out what may have > cause a given glitch. > > This patches adds an option to

Re: [HACKERS] Too many duplicated condition query return wrong value

On Thu, Sep 3, 2015 at 10:55 PM, Atsushi Yoshida wrote: > >> Can you give an "explain (analyze, buffers)" for each query? Maybe > you have a corrupted index, and one query uses the index and the other does > not. > > > > > > Index Scan using idx_attend_00 on attend

Re: [HACKERS] PATCH: index-only scans with partial indexes

On Fri, Sep 4, 2015 at 4:28 AM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > > > 25.08.2015 20:19, Jeff Janes пишет: > > On Fri, Jul 10, 2015 at 11:29 AM, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > >> Hi, >> >> cu

Re: [HACKERS] [PROPOSAL] Inputs on forcing VACUUM VERBOSE to write timestamp

On Thu, Sep 3, 2015 at 9:18 AM, Andres Freund wrote: > Hi, > > On 2015-09-03 21:45:52 +0530, dinesh kumar wrote: > > Forcing VACUUM VERBOSE to write timestamp, for each "INFO" entry. This > was > > raised already in this > > < >

Re: [HACKERS] Potential GIN vacuum bug

On Mon, Aug 31, 2015 at 12:10 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Sun, Aug 30, 2015 at 3:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Jeff Janes <jeff.ja...@gmail.com> writes: >> > On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane <t...@sss.p

Re: [HACKERS] Too many duplicated condition query return wrong value

On Thu, Sep 3, 2015 at 5:14 AM, Atsushi Yoshida wrote: > Hi. > > I cought a strange result. > I execute such query. > > > SELECT "attend"."lid", "attend"."status" FROM "attend" WHERE > "attend"."sid" = 325 AND "attend"."lid" IN ('ABF0010', 'ABF0010', > 'ABF0010', 'ABF0010',

Re: [HACKERS] Allow a per-tablespace effective_io_concurrency setting

On Wed, Sep 2, 2015 at 2:31 PM, Josh Berkus wrote: > On 09/02/2015 02:25 PM, Tomas Vondra wrote: > > > > As I explained, spindles have very little to do with it - you need > > multiple I/O requests per device, to get the benefit. Sure, the DBAs > > should know how many

Re: [HACKERS] Potential GIN vacuum bug

On Sun, Aug 30, 2015 at 3:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Jeff Janes <jeff.ja...@gmail.com> writes: > > On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Your earlier point about how the current design throttles insertion

Re: [HACKERS] Buildfarm failure from overly noisy warning message

On Tue, Jul 28, 2015 at 2:38 PM, Tom Lane wrote: > Kevin Grittner writes: > > Tom Lane wrote: > >> Kevin Grittner writes: > >>> I think a LOG entry when an autovacuum process is actually canceled > >>> has value

Re: [HACKERS] Potential GIN vacuum bug

On Sat, Aug 22, 2015 at 11:25 AM, Jeff Janes jeff.ja...@gmail.com wrote: On Tue, Aug 18, 2015 at 8:59 AM, Robert Haas robertmh...@gmail.com wrote: On Mon, Aug 17, 2015 at 5:41 PM, Jeff Janes jeff.ja...@gmail.com wrote: User backends attempt to take the lock conditionally, because otherwise

Re: [HACKERS] Potential GIN vacuum bug

On Sun, Aug 30, 2015 at 11:11 AM, Tom Lane t...@sss.pgh.pa.us wrote: Jeff Janes jeff.ja...@gmail.com writes: Your earlier point about how the current design throttles insertions to keep the pending list from growing without bound seems like a bigger deal to worry about. I think we'd like

Re: [HACKERS] buffer README is out of date

On Sat, Aug 29, 2015 at 1:27 PM, Jim Nasby jim.na...@bluetreble.com wrote: On 8/29/15 2:21 PM, Jeff Janes wrote: The buffer/README section on buffer clean up locks never got updated for the creation of Heap Only Tuples and their associated compaction logic. I've attached

[HACKERS] buffer README is out of date

The buffer/README section on buffer clean up locks never got updated for the creation of Heap Only Tuples and their associated compaction logic. I've attached a patch to change the explanation. I'm sure someone can word it better than I have. Cheers, Jeff

Re: [HACKERS] buffer README is out of date

On Sat, Aug 29, 2015 at 11:45 AM, Jeff Janes jeff.ja...@gmail.com wrote: The buffer/README section on buffer clean up locks never got updated for the creation of Heap Only Tuples and their associated compaction logic. I've attached a patch to change the explanation. I'm sure someone can

Re: [HACKERS] patch: version_stamp.pl: Add Git commit info to version if 'git' is specified

On Fri, Aug 28, 2015 at 1:44 AM, Andres Freund and...@anarazel.de wrote: On 2015-08-28 07:48:28 +0200, Fabien COELHO wrote: Salesforce did something similar in their internal build, and TBH I do not find it a good idea. The basic problem is it's completely misleading to equate the last

[HACKERS] Spurious standby query cancellations

In ResolveRecoveryConflictWithLock, there is the comment: /* * If blowing away everybody with conflicting locks doesn't work, after * the first two attempts then we just start blowing everybody away until * it does work. But what it does is something different than that. At

Re: [HACKERS] PATCH: index-only scans with partial indexes

On Fri, Jul 10, 2015 at 11:29 AM, Tomas Vondra tomas.von...@2ndquadrant.com wrote: Hi, currently partial indexes end up not using index only scans in most cases, because check_index_only() is overly conservative, as explained in this comment: * XXX this is overly conservative for partial

Re: [HACKERS] Resource Owner reassign Locks

On Tue, Aug 25, 2015 at 5:48 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund and...@anarazel.de wrote: On July 9, 2015 9:13:20 PM GMT+02:00, Jeff Janes jeff.ja...@gmail.com wrote: Unfortunately I don't know what that means about the API

Re: [HACKERS] statistics for array types

On Thu, Aug 20, 2015 at 6:00 PM, Tomas Vondra tomas.von...@2ndquadrant.com wrote: Hi, On 08/11/2015 04:38 PM, Jeff Janes wrote: When reviewing some recent patches, I decided the statistics gathered for arrays had some pre-existing shortcomings. The main one is that when the arrays

Re: [HACKERS] Potential GIN vacuum bug

On Tue, Aug 18, 2015 at 8:59 AM, Robert Haas robertmh...@gmail.com wrote: On Mon, Aug 17, 2015 at 5:41 PM, Jeff Janes jeff.ja...@gmail.com wrote: User backends attempt to take the lock conditionally, because otherwise they would cause an autovacuum already holding the lock to cancel itself

Re: [HACKERS] Test code is worth the space

On Tue, Aug 18, 2015 at 3:32 PM, David Fetter da...@fetter.org wrote: On Tue, Aug 18, 2015 at 04:54:07PM +0100, Greg Stark wrote: On Tue, Aug 18, 2015 at 2:16 PM, David Fetter da...@fetter.org wrote: I'm given to understand that this tight coupling is necessary for performance. Are you

Re: [HACKERS] Patch for ginCombineData

On Wed, Aug 5, 2015 at 3:17 AM, Robert Abraham robert.abraha...@googlemail.com wrote: Hello, we are using gin indexes on big tables. these tables happen to have several billion rows. the index creation fails in ginCombineData in src/backend/access/ginbulk.c because repalloc is limited to 1

Re: [HACKERS] Make HeapTupleSatisfiesMVCC more concurrent

On Tue, Aug 18, 2015 at 5:36 PM, Tom Lane t...@sss.pgh.pa.us wrote: I wrote: Just thinking about this ... I wonder why we need to call TransactionIdIsInProgress() at all rather than believing the answer from the snapshot? Under what circumstances could TransactionIdIsInProgress() return

Re: [HACKERS] Mention column name in error messages

On Sun, Aug 9, 2015 at 8:44 AM, Franck Verrot fra...@verrot.fr wrote: On Wed, Jul 1, 2015 at 12:30 AM, Tom Lane t...@sss.pgh.pa.us wrote: What seems more likely to lead to a usable patch is to arrange for the extra information you want to be emitted as error context, via an error context

[HACKERS] Make HeapTupleSatisfiesMVCC more concurrent

When we check a tuple for MVCC, it has to pass checks that the inserting transaction has committed, and that it committed before our snapshot began. And similarly that the deleting transaction hasn't committed, or did so after our snapshot. XidInMVCCSnapshot is (or can be) very much cheaper than

Re: [HACKERS] Potential GIN vacuum bug

On Mon, Aug 17, 2015 at 6:23 AM, Jeff Janes jeff.ja...@gmail.com wrote: On Aug 16, 2015 11:49 PM, Heikki Linnakangas hlinn...@iki.fi wrote: On 08/16/2015 12:58 AM, Jeff Janes wrote: When ginbulkdelete gets called for the first time in a VACUUM(i.e. stats == NULL), one of the first

Re: [HACKERS] Potential GIN vacuum bug

On Mon, Aug 17, 2015 at 3:02 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Jeff Janes wrote: The attached patch takes a ShareUpdateExclusiveLock lock on the index in order to clean the pending list. Does it take a lock on the table also? Because if not ... There must be some kind

[HACKERS] Potential GIN vacuum bug

When ginbulkdelete gets called for the first time in a VACUUM(i.e. stats == NULL), one of the first things it does is call ginInsertCleanup to get rid of the pending list. It does this in lieu of vacuuming the pending list. This is important because if there are any dead tids still in the

[HACKERS] GIN pending list clean up exposure to SQL

I've written a function which allows users to clean up the pending list. It takes the index name and returns the number of pending list pages deleted. # select * from gin_clean_pending_list('foo_text_array_idx'); gin_clean_pending_list 278 (1 row)

Re: [HACKERS] GIN pending clean up is not interruptable

On Tue, Aug 11, 2015 at 5:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andres Freund and...@anarazel.de writes: On 2015-08-11 15:07:15 -0700, Jeff Janes wrote: The attached patch adds an else branch to call CHECK_FOR_INTERRUPTS(). But I think we could instead just call vacuum_delay_point

[HACKERS] statistics for array types

When reviewing some recent patches, I decided the statistics gathered for arrays had some pre-existing shortcomings. The main one is that when the arrays contain rare elements there is no histogram to fall back upon when the MCE array is empty, the way there is for scalar stats. So it has to

[HACKERS] GIN pending clean up is not interruptable

When a user backend (as opposed to vacuum or autoanalyze) gets burdened with cleaning up the GIN pending list, it does not call CHECK_FOR_INTERRUPTS(). Since cleaning does a lot of random IO, it can take a long time and it is not nice to be uninterruptable. The attached patch adds an else branch

Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: [HACKERS] HEAD seems to generate larger WAL regarding GIN index

On Thu, Oct 30, 2014 at 5:30 AM, Fujii Masao masao.fu...@gmail.com wrote: On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote: + { + {pending_list_cleanup_size, PGC_USERSET, CLIENT_CONN_STATEMENT, +

Re: [HACKERS] GIN pageinspect functions

On Fri, Nov 21, 2014 at 2:04 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 11/20/2014 05:52 AM, Michael Paquier wrote: On Wed, Nov 19, 2014 at 7:01 AM, Peter Geoghegan p...@heroku.com wrote: On Tue, Nov 4, 2014 at 7:26 AM, Amit Kapila amit.kapil...@gmail.com wrote: 1.

Re: [HACKERS] FSM versus GIN pending list bloat

On Tue, Aug 4, 2015 at 12:38 PM, Jeff Janes jeff.ja...@gmail.com wrote: On Tue, Aug 4, 2015 at 1:39 AM, Simon Riggs si...@2ndquadrant.com wrote: On 4 August 2015 at 06:03, Jeff Janes jeff.ja...@gmail.com wrote: The attached proof of concept patch greatly improves the bloat for both

Fwd: [HACKERS] 9.5 release notes

On Wed, Jun 10, 2015 at 9:15 PM, Bruce Momjian br...@momjian.us wrote: I have committed the first draft of the 9.5 release notes. You can view the output here: http://momjian.us/pgsql_docs/release-9-5.html and it will eventually appear here:

Re: [HACKERS] LWLock deadlock and gdb advice

On Sun, Aug 2, 2015 at 8:05 AM, Andres Freund and...@anarazel.de wrote: On 2015-08-02 17:04:07 +0200, Andres Freund wrote: I've attached a version of the patch that should address Heikki's concern. It imo also improves the API and increases debuggability by not having stale variable values

Re: [HACKERS] FSM versus GIN pending list bloat

On Tue, Aug 4, 2015 at 1:39 AM, Simon Riggs si...@2ndquadrant.com wrote: On 4 August 2015 at 06:03, Jeff Janes jeff.ja...@gmail.com wrote: The attached proof of concept patch greatly improves the bloat for both the insert and the update cases. You need to turn on both features: adding

Re: [HACKERS] FSM versus GIN pending list bloat

On Tue, Aug 4, 2015 at 6:35 AM, Simon Riggs si...@2ndquadrant.com wrote: On 4 August 2015 at 09:39, Simon Riggs si...@2ndquadrant.com wrote: On 4 August 2015 at 06:03, Jeff Janes jeff.ja...@gmail.com wrote: The attached proof of concept patch greatly improves the bloat for both the insert

Re: [HACKERS] optimizing vacuum truncation scans

On Mon, Jul 27, 2015 at 1:40 PM, Simon Riggs si...@2ndquadrant.com wrote: On 22 July 2015 at 17:11, Jeff Janes jeff.ja...@gmail.com wrote: On Wed, Jul 22, 2015 at 6:59 AM, Robert Haas robertmh...@gmail.com wrote: On Mon, Jun 29, 2015 at 1:54 AM, Jeff Janes jeff.ja...@gmail.com wrote

[HACKERS] FSM versus GIN pending list bloat

For a GIN index with fastupdate turned on, both the user backends and autoanalyze routine will clear out the pending list, pushing the entries into the normal index structure and deleting the pages used by the pending list. But those deleted pages will not get added to the freespace map until a

Re: [HACKERS] Re: Using quicksort and a merge step to significantly improve on tuplesort's single run external sort

On Jul 31, 2015 4:22 AM, Jeremy Harris j...@wizmail.org wrote: On 30/07/15 02:05, Peter Geoghegan wrote: Since heapification is now a big fraction of the total cost of a sort sometimes, even where the heap invariant need not be maintained for any length of time afterwards, it might be

Re: [HACKERS] LWLock deadlock and gdb advice

On Thu, Jul 30, 2015 at 8:22 PM, Andres Freund and...@anarazel.de wrote: On 2015-07-30 09:03:01 -0700, Jeff Janes wrote: On Wed, Jul 29, 2015 at 6:10 AM, Andres Freund and...@anarazel.de wrote: What do you think about something roughly like the attached? I've not evaluated the code

Re: [HACKERS] LWLock deadlock and gdb advice

On Wed, Jul 29, 2015 at 6:10 AM, Andres Freund and...@anarazel.de wrote: On 2015-07-29 14:22:23 +0200, Andres Freund wrote: On 2015-07-29 15:14:23 +0300, Heikki Linnakangas wrote: Ah, ok, that should work, as long as you also re-check the variable's value after queueing. Want to write

Re: [HACKERS] LWLock deadlock and gdb advice

On Tue, Jul 28, 2015 at 9:06 AM, Jeff Janes jeff.ja...@gmail.com wrote: On Tue, Jul 28, 2015 at 7:06 AM, Andres Freund and...@anarazel.de wrote: Hi, On 2015-07-19 11:49:14 -0700, Jeff Janes wrote: After applying this patch to commit fdf28853ae6a397497b79f, it has survived testing long

Re: [HACKERS] LWLock deadlock and gdb advice

On Wed, Jul 29, 2015 at 9:26 AM, Andres Freund and...@anarazel.de wrote: On 2015-07-29 09:23:32 -0700, Jeff Janes wrote: On Tue, Jul 28, 2015 at 9:06 AM, Jeff Janes jeff.ja...@gmail.com wrote: I've reproduced it again against commit b2ed8edeecd715c8a23ae462. It took 5 hours on a 8 core

Re: [HACKERS] LWLock deadlock and gdb advice

On Tue, Jul 28, 2015 at 7:06 AM, Andres Freund and...@anarazel.de wrote: Hi, On 2015-07-19 11:49:14 -0700, Jeff Janes wrote: After applying this patch to commit fdf28853ae6a397497b79f, it has survived testing long enough to convince that this fixes the problem. What was the actual

Re: [HACKERS] make check changes have caused buildfarm deterioration.

On Tue, Jul 21, 2015 at 6:31 PM, Michael Paquier michael.paqu...@gmail.com wrote: On Wed, Jul 22, 2015 at 10:04 AM, Peter Eisentraut pete...@gmx.net wrote: On 7/21/15 10:00 AM, Tom Lane wrote: I agree; this change may have seemed like a good idea at the time, but it was not. Failures

Re: [HACKERS] optimizing vacuum truncation scans

On Wed, Jul 22, 2015 at 6:59 AM, Robert Haas robertmh...@gmail.com wrote: On Mon, Jun 29, 2015 at 1:54 AM, Jeff Janes jeff.ja...@gmail.com wrote: Attached is a patch that implements the vm scan for truncation. It introduces a variable to hold the last blkno which was skipped during

Re: [HACKERS] brin index vacuum versus transaction snapshots

On Tue, Jul 21, 2015 at 3:10 PM, Kevin Grittner kgri...@ymail.com wrote: Kevin Grittner kgri...@ymail.com wrote: If you run `make installcheck` against a cluster with default_transaction_isolation = 'repeatable read' you get one failure: + ERROR: brin_summarize_new_values() cannot run

Re: [HACKERS] LWLock deadlock and gdb advice

On Thu, Jul 16, 2015 at 12:03 AM, Jeff Janes jeff.ja...@gmail.com wrote: On Wed, Jul 15, 2015 at 8:44 AM, Heikki Linnakangas hlinn...@iki.fi wrote: Both. Here's the patch. Previously, LWLockAcquireWithVar set the variable associated with the lock atomically with acquiring it. Before

Re: [HACKERS] LWLock deadlock and gdb advice

On Wed, Jul 15, 2015 at 8:44 AM, Heikki Linnakangas hlinn...@iki.fi wrote: On 06/30/2015 11:24 PM, Andres Freund wrote: On 2015-06-30 22:19:02 +0300, Heikki Linnakangas wrote: Hm. Right. A recheck of the value after the queuing should be sufficient to fix? That's how we deal with the exact

Re: [HACKERS] LWLock deadlock and gdb advice

On Wed, Jul 15, 2015 at 8:44 AM, Heikki Linnakangas hlinn...@iki.fi wrote: Both. Here's the patch. Previously, LWLockAcquireWithVar set the variable associated with the lock atomically with acquiring it. Before the lwlock-scalability changes, that was straightforward because you held the

Re: [HACKERS] WIP: Enhanced ALTER OPERATOR

On Tue, Jul 14, 2015 at 8:22 AM, Heikki Linnakangas hlinn...@iki.fi wrote: On 07/13/2015 03:43 PM, Uriy Zhuravlev wrote: Hello hackers. Attached is a new version of patch: * port syntax from NULL to truth NONE * fix documentation (thanks Heikki) * rebase to master Thanks, committed

Re: [HACKERS] pg_trgm version 1.2

On Tue, Jul 7, 2015 at 6:33 AM, Alexander Korotkov a.korot...@postgrespro.ru wrote: See Tom Lane's comment about downgrade scripts. I think just remove it is a right solution. The new patch removes the downgrade path and the ability to install the old version. (If anyone wants an easy

Re: [HACKERS] Selectivity estimation for intarray with @@

On Tue, May 26, 2015 at 4:58 AM, Uriy Zhuravlev u.zhurav...@postgrespro.ru wrote: Hello. Attached patch based on: http://www.postgresql.org/message-id/capphfdssy+qepdcovxx-b4lp3ybr+qs04m6-arggknfk3fr...@mail.gmail.com and adds selectivity estimation functions to @@ (port from tsquery). Now

[HACKERS] intarray planning/exeuction problem with multiple operators

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. If I do a query that involves both an = op and a @@ op ANDed together, it gives a high cost estimate, which is justified by the slow

Re: [HACKERS] optimizing vacuum truncation scans

On Wed, Jul 8, 2015 at 9:46 PM, Haribabu Kommi kommi.harib...@gmail.com wrote: On Mon, Jun 29, 2015 at 3:54 PM, Jeff Janes jeff.ja...@gmail.com wrote: Attached is a patch that implements the vm scan for truncation. It introduces a variable to hold the last blkno which was skipped during

<    1   2   3   4   5   6   7   8   9   10   >