Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree

Hi! 2017-01-23 11:32 GMT+05:00 Jeff Davis : > I have some reservations about the complexity and novelty of the > approach. I don't think I've seen an approach quite like this one > before. It seems like the main reason you are using this approach is > because the btree

Re: [HACKERS] Passing query string to workers

On Fri, Jan 13, 2017 at 4:25 PM, Rafia Sabih wrote: > > Please let me know your feedback over the same. > I've looked into the patch. I've some comments regarding that. +#define PARALLEL_KEY_QUERY_TEXTUINT64CONST(0xE010) It should be

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/01/20 14:24, Ashutosh Bapat wrote: On Thu, Jan 19, 2017 at 10:38 PM, Robert Haas wrote: On Wed, Jan 18, 2017 at 10:26 PM, Ashutosh Bapat wrote: Yes, I think that's broadly the approach Tom was recommending. I don't have

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra wrote: > On 01/23/2017 08:30 AM, Amit Kapila wrote: >> >> >> I think if we can get data for pgbench read-write workload when data >> doesn't fit in shared buffers but fit in RAM, that can give us some >> indication. We

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

Hi, Please find the attached v4 patch rebased on a latest commitID in head. I had to rebase it as the following git commit has some changes in pgstatindex.c file due to which 'git apply' was failing. commit f21a563d25dbae153937aec062161184189478b8 Author: Peter Eisentraut

Re: [HACKERS] Parallel bitmap heap scan

On Mon, Jan 23, 2017 at 3:42 PM, Dilip Kumar wrote: > On Thu, Jan 19, 2017 at 12:26 AM, Robert Haas > wrote: > >> Patch 0001 and 0003 required to rebase on the latest head. 0002 is > >> still the same. > > > > I've committed the first half of 0001.

Re: [HACKERS] Fix a comment in feelist.c

On Mon, Jan 23, 2017 at 9:47 AM, Tatsuo Ishii wrote: >> I've found a mistake in a comment of StrategyNotifyBgWriter >> in freelist.c. bgwriterLatch was replaced by bgwprocno in >> the following commit, but this is remained in the comment. >> >> commit

Re: [HACKERS] pg_hba_file_settings view patch

On Sat, Jan 21, 2017 at 8:01 AM, Tom Lane wrote: > Haribabu Kommi writes: > > [ pg_hba_rules_10.patch ] > > I took a quick look over this. > Thanks for the review. > * I'm not exactly convinced that the way you approached the error message >

Re: [HACKERS] Gather Merge

On Wed, Jan 18, 2017 at 11:31 AM, Rushabh Lathia wrote: > The patch needs a rebase after the commit 69f4b9c85f168ae006929eec4. -- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Declarative partitioning vs. BulkInsertState

On 2017/01/19 5:25, Robert Haas wrote: > On Wed, Jan 11, 2017 at 10:53 PM, Amit Langote wrote: >> On 2017/01/06 20:23, Amit Langote wrote: >>> >>> If a single BulkInsertState object is passed to >>> heap_insert()/heap_multi_insert() for different heaps corresponding to >>> different partitions

Re: [HACKERS] Checksums by default?

On 01/23/2017 09:57 AM, Amit Kapila wrote: On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra wrote: On 01/23/2017 08:30 AM, Amit Kapila wrote: I think if we can get data for pgbench read-write workload when data doesn't fit in shared buffers but fit in RAM, that

Re: [HACKERS] Logical Replication WIP

On 23 January 2017 at 01:11, Petr Jelinek wrote: > On 20/01/17 22:30, Petr Jelinek wrote: >> Since it's not exactly straight forward to find when these need to be >> initialized based on commands, I decided to move the initialization code >> to

[HACKERS] Odd plan shown in src/backend/optimizer/README

While working on a bug in postgres_fdw, I found this: NestLoop -> Seq Scan on SmallTable1 A NestLoop -> Seq Scan on SmallTable2 B NestLoop -> Index Scan using XYIndex on LargeTable C Index Condition: C.X =

Re: [HACKERS] Speedup twophase transactions

Hi Stas, > > So, here is brand new implementation of the same thing. > > Now instead of creating pgproc entry for prepared transaction during recovery, > I just store recptr/xid correspondence in separate 2L-list and > deleting entries in that > list if redo process faced commit/abort. In case of

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 3:56 PM, Tomas Vondra wrote: > On 01/23/2017 09:57 AM, Amit Kapila wrote: >> >> On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra >> wrote: >>> >>> On 01/23/2017 08:30 AM, Amit Kapila wrote: I

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

On Mon, Jan 23, 2017 at 4:23 AM, Tom Lane wrote: > I wrote: >> I spent some time fooling with this today and came up with the attached >> patch. I think this is basically the direction we should go in, but >> there are various loose ends: > > Here's an updated patch that's

Re: [HACKERS] make async slave to wait for lsn to be replayed

Thank you for reviews and suggested improvements. I rewrote patch to make it more stable. Changes === I've made a few changes: 1) WAITLSN now doesn`t depend on snapshot 2) Check current replayed LSN rather than in xact_redo_commit 3) Add syntax WAITLSN_INFINITE '0/693FF800' - for infinite

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

Michael Paquier writes: > One thing though: even with this patch, it is still possible to define > a domain with unknown as underlying type and have a table grab it: > create domain name as unknown; > create table foo_name (a name); > I think that this case should be

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

Ashutosh Bapat writes: > Following error message might be misleading, > postgres=# create table t1 (a unknown); > ERROR: column "a" has pseudo-type unknown > UNKNOWN is not exactly a pseudo-type. Well, as I said to Michael just now, I think we should turn it

Re: [HACKERS] Failure in commit_ts tap tests

On 01/20/2017 01:22 PM, Tom Lane wrote: > Pavan Deolasee writes: >> I'm surprised nobody reported this problem earlier. > It looks like at least part of the answer is that the buildfarm isn't > running this test. AFAICS, it runs "make installcheck" not > "make check"

Re: [HACKERS] Failure on sittella

Andres Freund writes: > There's a buildfarm failure (just on sittella so far) that I can't quite > interpret from here. Timing wise it looks like it might be correlated > with ea15e18677fc2eff3135023e27f69ed8821554ed - "Remove obsoleted code > relating to targetlist SRF

Re: [HACKERS] Protect syscache from bloating with negative cache entries

On 1/22/17 5:03 PM, Tom Lane wrote: Ok, after reading the code I see I only partly understood what you were saying. In any case, it might still be useful to do some testing with CATCACHE_STATS defined to see if there's caches that don't accumulate a lot of negative entries. There definitely

Re: [HACKERS] Checksums by default?

On 01/23/2017 01:40 PM, Amit Kapila wrote: On Mon, Jan 23, 2017 at 3:56 PM, Tomas Vondra wrote: On 01/23/2017 09:57 AM, Amit Kapila wrote: On Mon, Jan 23, 2017 at 1:18 PM, Tomas Vondra wrote: On 01/23/2017 08:30 AM, Amit Kapila

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 6:57 PM, Tomas Vondra wrote: > On 01/23/2017 01:40 PM, Amit Kapila wrote: >> >> On Mon, Jan 23, 2017 at 3:56 PM, Tomas Vondra >> wrote: >>> >>> On 01/23/2017 09:57 AM, Amit Kapila wrote: On Mon,

Re: [HACKERS] Failure in commit_ts tap tests

On 01/23/2017 09:03 AM, Tom Lane wrote: > Andrew Dunstan writes: >> On 01/20/2017 01:22 PM, Tom Lane wrote: >>> It looks like at least part of the answer is that the buildfarm isn't >>> running this test. AFAICS, it runs "make installcheck" not >>> "make check"

Re: [HACKERS] Failure in commit_ts tap tests

Tom, Andrew, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Andrew Dunstan writes: > > On 01/20/2017 01:22 PM, Tom Lane wrote: > >> It looks like at least part of the answer is that the buildfarm isn't > >> running this test. AFAICS, it runs "make installcheck" not >

Re: [HACKERS] Odd plan shown in src/backend/optimizer/README

Etsuro Fujita writes: > This seems odd to me; we would not need the bottom-level Nestloop. > Attached is a small patch for fixing that. Pushed, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Failure in commit_ts tap tests

Andrew Dunstan writes: > On 01/20/2017 01:22 PM, Tom Lane wrote: >> It looks like at least part of the answer is that the buildfarm isn't >> running this test. AFAICS, it runs "make installcheck" not >> "make check" in src/test/modules. I don't know whether any

Re: [HACKERS] Failure in commit_ts tap tests

Andrew Dunstan writes: > On 01/23/2017 09:03 AM, Tom Lane wrote: >> Andrew Dunstan writes: >>> On 01/20/2017 01:22 PM, Tom Lane wrote: It looks like at least part of the answer is that the buildfarm isn't running this

Re: [HACKERS] pageinspect: Hash index support

On Wed, Jan 18, 2017 at 3:24 PM, Ashutosh Sharma wrote: > >> 4. >> +Datum >> +hash_page_items(PG_FUNCTION_ARGS) >> +{ >> + bytea *raw_page = PG_GETARG_BYTEA_P(0); >> >> >> +Datum >> +hash_bitmap_info(PG_FUNCTION_ARGS) >> +{ >> + Oid indexRelid = PG_GETARG_OID(0); >> +

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

I think this patch no longer applies because of conflicts with the one I just pushed. Please rebase. Thanks -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Online enabling of page level checksums

So as mentioned on IRC, I have a patch that I am working to rebase on HEAD with the following design. It is very similar to what you have proposed, so maybe we can use my development notes as a jumping-off point for discussion/refinement. * Incremental Checksums PostgreSQL users should have

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Fri, Jan 20, 2017 at 6:24 AM, Masahiko Sawada wrote: > On Thu, Jan 19, 2017 at 8:31 PM, Claudio Freire > wrote: >> On Thu, Jan 19, 2017 at 6:33 AM, Anastasia Lubennikova >> wrote: >>> 28.12.2016 23:43, Claudio

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

Kevin Grittner writes: > (1) The new GUCs are named max_pred_locks_per_*, but the > implementation passes them unmodified from a function specifying at > what count the lock should be promoted. We either need to change > the names or (probably better, only because I can't

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

I pushed this patch after rewriting it rather completely. I added tracing notices to inspect the blocks it was prefetching and observed that the original coding was failing to prefetch the final streak of blocks in the table, which is an important oversight considering that it may very well be

Re: [HACKERS] Logical Replication WIP

On Sat, Jan 21, 2017 at 1:39 AM, Petr Jelinek wrote: > On 20/01/17 17:33, Jaime Casanova wrote: >> On 20 January 2017 at 11:25, Petr Jelinek >> wrote: >>> On 20/01/17 17:05, Fujii Masao wrote: On Fri, Jan 20, 2017 at 11:08 PM,

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

On Mon, Jan 23, 2017 at 2:56 PM, Ashutosh Sharma wrote: > Hi, > > Please find the attached v4 patch rebased on a latest commitID in > head. I had to rebase it as the following git commit has some changes > in pgstatindex.c file due to which 'git apply' was failing. > I've

Re: [HACKERS] Assignment of valid collation for SET operations on queries with UNKNOWN types.

I wrote: > Ashutosh Bapat writes: >> UNKNOWN is not exactly a pseudo-type. > Well, as I said to Michael just now, I think we should turn it into one > now that we're disallowing it in tables, because "cannot be used as a > table column" is more or less the

Re: [HACKERS] GSoC 2017

All, * Alexander Korotkov (a.korot...@postgrespro.ru) wrote: > Also, we need to decide who would > be our admin this year. I don't see anyone jumping at the bit to be the admin (it's not exactly a fun and exciting job, after all), so, unless someone really wants it (or someone wishs to object),

Re: [HACKERS] Logical decoding on standby

On 5 January 2017 at 01:21, Craig Ringer wrote: > On 5 January 2017 at 09:19, Craig Ringer wrote: > >> so here's a rebased series on top of master. No other changes. > > Now with actual patches. Patch 5 no longer applies: patching file

Re: [HACKERS] [COMMITTERS] pgsql: Add function to import operating system collations

On 1/22/17 3:47 AM, Michael Paquier wrote: > It would be nice at least to avoid an error, still even if we decide > to keep it an error I can add a couple of locales in hamster and > dangomushi and we are good to go in the buildfarm. Regarding the > warning, I have found it useful a couple of

Re: [HACKERS] [COMMITTERS] pgsql: Add pg_sequence system catalog

Peter, all, * Stephen Frost (sfr...@snowman.net) wrote: > * Peter Eisentraut (pete...@gmx.net) wrote: > > Add pg_sequence system catalog > > The query this added to dumpSequence() seems to think that sequence > names are unique across databases: Just FYI, I've added this to the PG10 open items

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 1/17/17 5:03 PM, Robert Haas wrote: > Right. I think a lot of that stuff should also be changed. If we > weren't OK with breaking compatibility, why'd we change pg_xlog -> > pg_wal? If we're not willing to change other things to match, let's > revert that change and be done with it. For the

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 1/17/17 5:03 PM, Robert Haas wrote: > > Right. I think a lot of that stuff should also be changed. If we > > weren't OK with breaking compatibility, why'd we change pg_xlog -> > > pg_wal? If we're not willing to change

Re: [HACKERS] [PATCH] Generic type subscription

Dmitry Dolgov <9erthali...@gmail.com> writes: > [ generic_type_subscription_v6.patch ] Not too surprisingly, this doesn't apply anymore in the wake of commit ea15e1867. Could you rebase? Changes for that should be pretty trivial I'd expect. I took an extremely quick look over the patch ---

Re: [HACKERS] Online enabling of page level checksums

> On Jan 23, 2017, at 10:59 AM, David Christensen wrote: > >> >> On Jan 23, 2017, at 10:53 AM, Simon Riggs wrote: >> >> On 23 January 2017 at 16:32, David Christensen wrote: >> >>> ** Handling checksums on a standby: >>> >>>

Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically

Peter Eisentraut writes: > On 1/18/17 7:38 AM, Tom Lane wrote: >> Why do fmgroids.h, fmgrprotos.h, and fmgrtab.c now get mentioned >> twice? I suspect there is something broken about the parallelization. > I've pushed a fix for this. Seems to fix the problem

Re: [HACKERS] [PATCH] Generic type subscription

I wrote: > ... (If that means > we use two functions not one per datatype, that's fine with me.) Actually, after thinking about that a bit more: you've really squeezed *three* different APIs into one function. Namely, subscript-reference parse analysis, array subscripting execution, and array

Re: [HACKERS] Allowing nonzero return codes from \quit

Fabien COELHO writes: >> I didn't think about it too much, but I don't see why a user couldn't set >> one of those error codes. >> I did, however, think that any attempt to set an exit_code outside of >> [0,127] would itself be an error, resulting in an exit code of 3. >

Re: [HACKERS] Undefined psql variables

"David G. Johnston" writes: > On Mon, Jan 23, 2017 at 11:16 AM, Fabien COELHO wrote: >> Currently the value of a non existing psql-variable is... its own >> reference:-( >> >> psql> \echo :x >> :x >> >> I'm not sure of the rational, apart from

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

A few comments: Argh, better with the attachements:-( -- Fabien. if-error-1.sql Description: application/sql if-error-2.sql Description: application/sql if-error-3.sql Description: application/sql if-error-4.sql Description: application/sql -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Microvacuum support for Hash Index

Hi Ashutosh, On 01/20/2017 03:24 PM, Jesper Pedersen wrote: Yeah, those are the steps; just with a Skylake laptop. However, I restarted with a fresh master, with WAL v8 and MV v5, and can't reproduce the issue. I have done some more testing with this, and have moved to the patch back to

Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory

Jia Yu writes: > However, these methods don't work in the normal PG server. It gave me > "segmentation fault" > ... > Here is my backtrace. It looks like I cannot access fcinfo. Can you help me > about this? Or just some hints? I have been struggling with this problem > for

[HACKERS] PoC plpgsql - possibility to force custom or generic plan

Hi, this patch is based on discussions related to plpgsql2 project. Currently we cannot to control plan cache from plpgsql directly. We can use dynamic SQL if we can enforce oneshot plan - but it means little bit less readable code (if we enforce dynamic SQL from performance reasons). It means

Re: [HACKERS] [COMMITTERS] pgsql: Generate fmgr prototypes automatically

On 1/18/17 7:38 AM, Tom Lane wrote: > Why do fmgroids.h, fmgrprotos.h, and fmgrtab.c now get mentioned > twice? I suspect there is something broken about the parallelization. > If indeed multiple instances of gmake are writing these files > concurrently, that's likely to result in irreproducible

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

And here's the patch. I've changed the subject line and will be submitting a new entry to the commitfest. A few comments: Patch applies, make check is ok, but currently really too partial. I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL has "ELSIF" like perl, that

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL > has "ELSIF" like perl, that I do not like much, though. Given the syntax > and behavioral proximity with cpp, I suggest that "elif" would be a better > choice. > I'm personally indifferent to elif vs elsif vs elseif,

Re: [HACKERS] GSoC 2017

A new currency type would be nice, and if kept small in scope, might be manageable. Bringing Christoph Berg's PostgreSQL-units into core and extending it could be interesting. Peter E's URL and email types might be good candidates. What else? Informix Datablades had a media type way back in the

Re: [HACKERS] Allowing nonzero return codes from \quit

As \q does not currently have an argument, this seems an easy and reasonnable extension. However, currently there are 4 existing exit status for psql: 0 (ok), 1 (fatal error), 2 (connection error), 3 (script error...). +128 status are also already used when killing a psql process. I didn't

Re: [HACKERS] patch proposal

Hi Venkata, On 11/8/16 5:47 PM, Venkata B Nagothi wrote: > Attached is the 2nd version of the patch with some enhancements. Here's my review of the patch. 1) There are a number of whitespace error when applying the patch: $ git apply ../other/recoveryTargetIncomplete.patch-version2

[HACKERS] src/test/README for logical replication

src/test/README wasn't updated for the new src/test/subscription entry. Patch attached. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services From 491587b3fcb7a2fa2689171161354a708efa3cc1 Mon Sep 17 00:00:00 2001 From: Craig

[HACKERS] IndexBuild Function call fcinfo cannot access memory

Dear hackers, Currently, I am developing a backend index access method for my research project. I built corresponding routines such as MyIndexbuild, MyIndexInsert, and so on and put them in "src/backend/access/hippo" (hippo is my index's name). I also added new entries in corresponding catalog

Re: [HACKERS] Undefined psql variables

Back in the day, PG allowed ":" as a generic operator name, making this even worse; but I think the only remaining SQL syntax that could include a colon is array slicing. Ok, so the behavior of replacing ":unknown" by same cannot be changed. Some fun: \set 1 1 SELECT

Re: [HACKERS] PoC: Grouped base relation

On 20 January 2017 at 00:22, Antonin Houska wrote: > Sorry, it was my thinko - I somehow confused David's CROSS JOIN example with > this one. If one side of the join clause is unique and the other becomes > unique due to aggregation (and if parallel processing is not engaged)

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Mon, Jan 23, 2017 at 4:12 PM, Corey Huinker wrote: > I do not like the choice of "elseif", which exists in PHP & VB. PL/pgSQL >> has "ELSIF" like perl, that I do not like much, though. Given the syntax >> and behavioral proximity with cpp, I suggest that "elif" would

Re: [HACKERS] Checksums by default?

On Sat, Jan 21, 2017 at 9:09 AM, Tom Lane wrote: > Not at all; I just think that it's not clear that they are a net win > for the average user, and so I'm unconvinced that turning them on by > default is a good idea. I could be convinced otherwise by suitable > evidence.

Re: [HACKERS] Checksums by default?

Jim Nasby writes: > On 1/23/17 7:47 PM, Stephen Frost wrote: >> It might be interesting to consider checking them in 'clean' pages in >> shared_buffers in a background process, as that, presumably, *would* >> detect shared buffers corruption. > Hmm... that would be

Re: [HACKERS] Proposal : For Auto-Prewarm.

I took a look at this again, and it doesn't appear to be working for me. The library is being loaded during startup, but I don't see any further activity in the log, and I don't see an autoprewarm file in $PGDATA. There needs to be some kind of documentation change as part of this patch. I'm

[HACKERS] Contrib: alternative MATERIALIZED VIEWs

Attached is an alternative implementation of MATERIALIZED VIEWs. The idea is to explore possible enahncements to the PostgreSQL MATERIALIZED VIEW features. Features: - All SQL-coded. - Keeps history of deltas computed at each refresh. - Allows DMLs of the materialized view, recording the

Re: [HACKERS] Fix a comment in feelist.c

>> I've found a mistake in a comment of StrategyNotifyBgWriter >> in freelist.c. bgwriterLatch was replaced by bgwprocno in >> the following commit, but this is remained in the comment. >> >> commit d72731a70450b5e7084991b9caa15cb58a2820df >> Author: Andres Freund >> Date:

Re: [HACKERS] [COMMITTERS] pgsql: Add function to import operating system collations

On Tue, Jan 24, 2017 at 3:47 AM, Peter Eisentraut wrote: > On 1/22/17 3:47 AM, Michael Paquier wrote: >> It would be nice at least to avoid an error, still even if we decide >> to keep it an error I can add a couple of locales in hamster and >> dangomushi and we

Re: [HACKERS] Online enabling of page level checksums

Jim Nasby writes: > For a first pass, I think it's acceptable for autovac and vac to notice > if a relation needs checksums computed and ignore the VM in that case > (make sure it's ignoring all frozen bits too). > Likewise, for right now I think it's OK to force

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 6:01 PM, Tom Lane wrote: > Maybe this is a terminology problem. I'm taking "false positive" to mean > "checksum reports a failure, but in fact there is no observable data > corruption". Depending on why the false positive occurred, that might > help

Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory

Dear Tom, Thanks for your reply! Actually, I already compiled the source code with "-O0" and then got those backtraces. The hippobuild function just starts building an index access method and it will call hippobuildcallback to iterate each parent table tuple in its function body. What makes me

Re: [HACKERS] Checksums by default?

On 1/23/17 6:14 PM, Peter Geoghegan wrote: In practice, Postgres checksums do *not* seem to catch problems. That's been my experience, at least. For someone running on a bunch of AWS hardware that doesn't really surprise me. Presumably, anyone operating at that scale would be quickly

Re: [HACKERS] Checksums by default?

On 1/23/17 7:15 PM, Tom Lane wrote: Uhm, Peter G just said that Heroku enables this on all their databases and have yet to see a false-positive report or an issue with having it enabled. That, plus the reports and evidence we've seen in the past couple days, look like a pretty ringing

Re: [HACKERS] Checksums by default?

Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > On 1/23/17 6:55 PM, Stephen Frost wrote: > >* Jim Nasby (jim.na...@bluetreble.com) wrote: > >>As others have mentioned, right now practically no one enables this, > >>so we've got zero data on how useful it might actually be. > >Uhm, Peter G

Re: [HACKERS] Checksums by default?

On Tue, Jan 24, 2017 at 10:26 AM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> >> I don't recall ever seeing a checksum failure on a Heroku Postgres >> >> database, > > Not sure how this part of that sentence was missed: > > - > ... even though they

Re: [HACKERS] Checksums by default?

* Peter Geoghegan (p...@heroku.com) wrote: > On Mon, Jan 23, 2017 at 5:26 PM, Stephen Frost wrote: > > Not sure how this part of that sentence was missed: > > > > - > > ... even though they were enabled as soon as the feature became > > available. > > - > > > > Which

Re: [HACKERS] Contrib: pqasyncnotifier.c -- a shell command client for LISTEN

On Tue, Jan 24, 2017 at 12:40 AM, Nico Williams wrote: > psql(1) does not output notifications asynchronously, as it does not > check for them when idle. This makes it difficult to script handling of > NOTIFYs. > > Attached is pqasyncnotifier.c, a simple command that

Re: [HACKERS] Checksums by default?

Jim, * Jim Nasby (jim.na...@bluetreble.com) wrote: > As others have mentioned, right now practically no one enables this, > so we've got zero data on how useful it might actually be. Uhm, Peter G just said that Heroku enables this on all their databases and have yet to see a false-positive

Re: [HACKERS] Checksums by default?

On 1/23/17 7:47 PM, Stephen Frost wrote: It might be interesting to consider checking them in 'clean' pages in shared_buffers in a background process, as that, presumably, *would* detect shared buffers corruption. Hmm... that would be interesting. Assuming the necessary functions are exposed

[HACKERS] Contrib: pqasyncnotifier.c -- a shell command client for LISTEN

psql(1) does not output notifications asynchronously, as it does not check for them when idle. This makes it difficult to script handling of NOTIFYs. Attached is pqasyncnotifier.c, a simple command that allows one to handle NOTIFYs asynchronously. Cheers, Nico -- -- Sent via pgsql-hackers

Re: [HACKERS] Contrib: alternative MATERIALIZED VIEWs

On 1/23/17 5:38 PM, Nico Williams wrote: Attached is an alternative implementation of MATERIALIZED VIEWs. Interesting. I don't see this being accepted into core because it's plpgsql and it depends on the user to track what criteria to use to apply the update. The second item is the biggest

Re: [HACKERS] GSoC 2017

On 1/23/17 3:45 PM, Peter van Hardenberg wrote: A new currency type would be nice, and if kept small in scope, might be manageable. I'd be rather nervous about this. My impression of community consensus on this is a currency type that doesn't somehow support conversion between different

Re: [HACKERS] Checksums by default?

On Sat, Jan 21, 2017 at 12:35 PM, Tom Lane wrote: > Andres Freund writes: >> Sure, it might be easy, but we don't have it. Personally I think >> checksums just aren't even ready for prime time. If we had: >> - ability to switch on/off at runtime (early

Re: [HACKERS] Checksums by default?

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Jim Nasby (jim.na...@bluetreble.com) wrote: > >> As others have mentioned, right now practically no one enables this, > >> so we've got zero data on how useful it might actually be. > > > Uhm, Peter G just

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 5:26 PM, Stephen Frost wrote: > Not sure how this part of that sentence was missed: > > - > ... even though they were enabled as soon as the feature became > available. > - > > Which would seem to me to say "the code's been running for a long

Re: [HACKERS] Checksums by default?

Peter Geoghegan writes: > I thought that checksums went in in part because we thought that there > was some chance that they'd find bugs in Postgres. Not really. AFAICS the only point is to catch storage-system malfeasance. It's barely possible that checksumming would help

[HACKERS] COPY IN/BOTH vs. extended query mode

According to the documentation for COPY IN mode, "If the COPY command was issued via an extended-query message, the backend will now discard frontend messages until a Sync message is received, then it will issue ReadyForQuery and return to normal processing." I added a similar note to the

Re: [HACKERS] Checksums by default?

Peter Geoghegan writes: > Perhaps I've missed the point entirely, but, I have to ask: How could > there ever be false positives? Bugs. For example, checksum is computed while somebody else is setting a hint bit in the page, so that what is written out is completely valid except

Re: [HACKERS] Protect syscache from bloating with negative cache entries

On 1/21/17 6:42 PM, Jim Nasby wrote: On 12/26/16 2:31 AM, Kyotaro HORIGUCHI wrote: The points of discussion are the following, I think. 1. The first patch seems working well. It costs the time to scan the whole of a catcache that have negative entries for other reloids. However, such

Re: [HACKERS] IndexBuild Function call fcinfo cannot access memory

Dear Tom, BTW, my current implementation is on PG 9.5... Thanks, Jia Yu Jia Yu, Ph.D. Student Computer Science Arizona State University Reach me via Jia Yu's Homepage | GitHub Repositories

Re: [HACKERS] Checksums by default?

On 1/23/17 1:30 AM, Amit Kapila wrote: On Sun, Jan 22, 2017 at 3:43 PM, Tomas Vondra wrote: That being said, I'm ready to do some benchmarking on this, so that we have at least some numbers to argue about. Can we agree on a set of workloads that we want to

Re: [HACKERS] [PATCH] Generic type subscription

On 1/23/17 1:36 PM, Tom Lane wrote: Is there a way for a function in an extension to find the OID of one of its sibling functions? Obviously there's regprocedure (or it's C equivalent), but then you're stuck re-computing at runtime. I've messed around with that a bit in an effort to have an

Re: [HACKERS] Online enabling of page level checksums

On 1/23/17 1:11 PM, David Christensen wrote: I’m not sure that this will work as-is, unless we’re forcing VACUUM to ignore the visibility map. I had originally considered having this sit on top of VACUUm though, we just need a way to iterate over all relations and read every page. Another

Re: [HACKERS] Checksums by default?

Stephen Frost writes: > * Jim Nasby (jim.na...@bluetreble.com) wrote: >> As others have mentioned, right now practically no one enables this, >> so we've got zero data on how useful it might actually be. > Uhm, Peter G just said that Heroku enables this on all their databases

Re: [HACKERS] Checksums by default?

On 1/23/17 6:55 PM, Stephen Frost wrote: * Jim Nasby (jim.na...@bluetreble.com) wrote: As others have mentioned, right now practically no one enables this, so we've got zero data on how useful it might actually be. Uhm, Peter G just said that Heroku enables this on all their databases and have

Re: [HACKERS] Checksums by default?

On Mon, Jan 23, 2017 at 5:47 PM, Stephen Frost wrote: >> Perhaps I've missed the point entirely, but, I have to ask: How could >> there ever be false positives? With checksums, false positives are >> simply not allowed. Therefore, there cannot be a false positive, >> unless we

Re: [HACKERS] Checksums by default?

On 24/01/17 02:39, Michael Paquier wrote: > On Tue, Jan 24, 2017 at 10:26 AM, Stephen Frost wrote: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: > I don't recall ever seeing a checksum failure on a Heroku Postgres > database, >> >> Not sure how this part of that sentence

  1   2   >