Re: [HACKERS] emergency outage requiring database restart

Merlin Moncure wrote: > castaging=# CREATE OR REPLACE VIEW vw_ApartmentSample AS > castaging-# SELECT ... > ERROR: 42809: "pg_cast_oid_index" is an index > LINE 11: FROM ApartmentSample s > ^ > LOCATION: heap_openrv_extended, heapam.c:1304 > > should I be restoring from

Re: [HACKERS] Stats sender and 2pc minor problem

Tom Lane wrote: > Stas Kelvich writes: > > Statistics sender logic during usual commit and two-phase commit do not > > strictly matches each other and that leads to delta_live_tuples added to > > n_live_tup in case of truncate in two phase commit. > > Yeah, that code

Re: [HACKERS] Pluggable storage

I have sent the partial patch I have to Hari Babu Kommi. We expect that he will be able to further this goal some more. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Non-empty default log_line_prefix

Peter Eisentraut wrote: > On 10/12/16 11:58 AM, Christoph Berg wrote: > > (Yes, the '' default might be fine for syslog, but I don't think > > that's a good argument for sticking with it for default installs. I've > > seen way too many useless log files out there, and at worst we'll have > >

Re: [HACKERS] logical replication connection information management

Peter Eisentraut wrote: > An idea is to make the foreign server concept more general and allow > it to exist independently of a foreign data wrapper. Then create more > specific syntax like > > CREATE SERVER node1 FOR SUBSCRIPTION OPTIONS ( ... ); > > or > > CREATE SUBSCRIPTION SERVER

Re: [HACKERS] munmap() failure due to sloppy handling of hugepage size

Tom Lane wrote: > Andres Freund writes: > > On October 12, 2016 1:25:54 PM PDT, Tom Lane wrote: > >> A little bit of research suggests that on Linux the thing to do would > >> be to get the actual default hugepage size by reading /proc/meminfo and > >>

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

Tom Lane wrote: > Vitaly Burovoy writes: > > P.S.: I still think it is a good idea to change storage format, > > I'm not sure which part of "no" you didn't understand, but we're > not breaking on-disk compatibility of existing macaddr columns. > Breaking the on-the-wire

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

Julien Rouhaud wrote: > On 12/10/2016 14:32, Alvaro Herrera wrote: > > Julien Rouhaud wrote: > > > >> and you can instead make macaddr64 support both format, and provide a > >> macaddr::macaddr64 cast > > > > Having macaddr64 support both formats s

Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support

Julien Rouhaud wrote: > and you can instead make macaddr64 support both format, and provide a > macaddr::macaddr64 cast Having macaddr64 support both formats sounds nice, but how does it work? Will we have to reserve one additional bit to select the representation? That would make the type be 65

Re: [HACKERS] pg_dump getBlobs query broken for 7.3 servers

Stephen Frost wrote: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > Stephen Frost wrote: > > > > > What would be really nice would be code coverage information for the > > > back-branches also, as that would allow us to figure out what we're >

Re: [HACKERS] pg_dump getBlobs query broken for 7.3 servers

Stephen Frost wrote: > What would be really nice would be code coverage information for the > back-branches also, as that would allow us to figure out what we're > missing coverage for. I realize that we don't like adding new things to > back-branches as those changes could impact packagers, but

Re: [HACKERS] Question / requests.

Robert Haas wrote: > On Wed, Oct 5, 2016 at 10:58 AM, Francisco Olarte > <fola...@peoplecall.com> wrote: > > On Tue, Oct 4, 2016 at 7:50 PM, Robert Haas <robertmh...@gmail.com> wrote: > >> On Mon, Oct 3, 2016 at 5:44 PM, Alvaro Herrera <alvhe...@2ndquadrant.com&

Re: [HACKERS] Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.

Robert Haas wrote: > On Tue, Oct 4, 2016 at 11:29 AM, Tom Lane wrote: > > Robert Haas writes: > >> Apparently, 'make world' does not build worker_spi. I thought 'make > >> world' was supposed to build everything? > > > > You'd have thunk, yeah. It

Re: [HACKERS] Question / requests.

Robert Haas wrote: > On Fri, Sep 30, 2016 at 11:20 AM, Francisco Olarte > wrote: > > After some messages due to vacuumdb auto-deadlocking itself on the > > system tables when doing paralell vacuum of a full database I > > suggested adding some flags to make vacuumdb

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

Thomas Munro wrote: > On Thu, Sep 29, 2016 at 6:19 PM, David Fetter wrote: > > Please find attached the next revision. > > I'm not sold on ERRCODE_SYNTAX_ERROR. There's nothing wrong with the > syntax, since parsing succeeded. It would be cool if we could use >

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Tom Lane wrote: > Thomas Kellerer writes: > > for some reason pg_upgrade failed on Windows 10 for me, with an error > > message that one specifc _vm file couldn't be copied. > > Hmm ... a _vm file would go through rewriteVisibilityMap(), which is new > code for 9.6 and

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Tom Lane wrote: > Robert Haas writes: > > As long as we get %t and %p in there we're going to be way ahead, really. > > Could we get consensus on just changing the default to > > log_line_prefix = '%t [%p] ' > > and leaving the rest out of it? +1 from me. --

Re: [HACKERS] compiler warning read_objtype_from_string()

Tom Lane wrote: > I do not think you should assume that the compiler is smart enough to > deduce that, nor that all compilers even know ereport(ERROR) doesn't > return. Personally I don't see the point of the "type" variable at > all, anyway. I would have written this as > > [code] Makes

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Tom Lane wrote: > Robert Haas writes: > > On Thu, Sep 15, 2016 at 5:18 PM, Robert Haas wrote: > >> On Sat, Aug 27, 2016 at 3:59 PM, Tom Lane wrote: > >>> I think the odds of getting to something that everyone would agree on > >>>

Re: [HACKERS] Showing parallel status in \df+

Pavel Stehule wrote: > I am sorry, I disagree. Proposed form is hard readable. Is not possible to > simply copy/paste. Why do you care? You can use \sf if you want to copy the function code. > I cannot to imagine any use case for proposed format. My vote (which was not counted by Stephen) was

Re: [HACKERS] compiler warning read_objtype_from_string()

Peter Eisentraut wrote: > I'm getting the following compiler warning (using nondefault > optimization options): > > objectaddress.c: In function 'read_objtype_from_string': > objectaddress.c:2309:9: error: 'type' may be used uninitialized in this > function [-Werror=maybe-uninitialized] >

Re: [HACKERS] pageinspect: Hash index support

Peter Eisentraut wrote: > On 9/26/16 1:39 PM, Jesper Pedersen wrote: > >> - hash_metap result fields spares and mapp should be arrays of integer. > > > > B-tree and BRIN uses a 'text' field as output, so left as is. > > These fields are specific to hash, so the precedent doesn't necessarily >

Re: [HACKERS] Add support for restrictive RLS policies

Stephen Frost wrote: > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > > Stephen Frost wrote: > > > + > > > + If the policy is a "permissive" or "restrictive" policy. > > > Permissive > > > + p

Re: [HACKERS] pageinspect: Hash index support

Jeff Janes wrote: > On Tue, Sep 20, 2016 at 12:19 AM, Michael Paquier > wrote: > > > > > Note: the patch checks if a superuser is calling the new functions, > > which is a good thing. > > > > If we only have the bytea functions and the user needs to supply the raw >

Re: [HACKERS] Add support for restrictive RLS policies

Stephen Frost wrote: Stephen, the typo "awseome" in the tests is a bit distracting. Can you please fix it? > Updated patch changes to using IDENT and an strcmp() (similar to > AlterOptRoleElem and vacuum_option_elem) to check the results at parse-time, > and then throwing a more specific error

Re: [HACKERS] ICU integration

Petr Jelinek wrote: > > I'm not sure how well it will work to replace all the bits of LIKE and > > regular expressions with ICU API calls. One problem is that ICU likes > > to do case folding as a whole string, not by character. I need to do > > more research about that. > > Can't we use the

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

Peter Eisentraut wrote: > How about having the tag not be a column name but a row entry. So you'd > do something like > > SELECT * FROM pg_stat_sql WHERE tag = 'ALTER VIEW'; > > That way, we don't have to keep updating (and re-debating) this when new > command types or subtypes are added. And

Re: [HACKERS] [PATCH] get_home_path: use HOME

Rudolf Gavlas wrote: > 2016-09-20 18:55 GMT+02:00, Alvaro Herrera <alvhe...@2ndquadrant.com>: > > Rudolf Gavlas wrote: > > > >> I work in an environment, where servers are administered by people > >> with different user names and identical ui

Re: [HACKERS] "Some tests to cover hash_index"

Why not use generate_series() queries to insert the appropriate number of tuples, instead of a handful of INSERT lines each time? Since each insert is a separate transaction, that would probably be faster. Why do you have a plpgsql function just to create a cursor? Wouldn't it be simpler to

Re: [HACKERS] [PATCH] get_home_path: use HOME

Rudolf Gavlas wrote: > I work in an environment, where servers are administered by people > with different user names and identical uid (0). So everyone is superuser there? That sounds, um, unorthodox. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: [HACKERS] more parallel query documentation

Robert Haas wrote: > Hey, everybody: I intended to add this to the documentation before 9.6 > went out, but that didn't get done. Maybe it'll have to happen later > at this point, but can I get some advice on WHERE in the documentation > this stuff could be added? Assuming people agree it

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

Christoph Berg wrote: > Re: Michael Paquier 2016-09-15 > > > On Thu, Sep 15, 2016 at 8:57 PM, Heikki Linnakangas wrote: > > > I backpatched this to 9.5, but not further than that. The functions this > > >

Re: [HACKERS] select_parallel test fails with nonstandard block size

Robert Haas wrote: > On Thu, Sep 15, 2016 at 9:59 AM, Tom Lane wrote: > > Possibly we ought to change things so that the default value of > > min_parallel_relation_size is a fixed number of bytes rather > > than a fixed number of blocks. Not sure though. > > The reason why

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

Robert Haas wrote: > Actually, I think that probably *is* worthwhile, specifically because > it might let us avoid multiple index scans in cases where we currently > require them. Right now, our default maintenance_work_mem value is > 64MB, which is enough to hold a little over ten million

Re: [HACKERS] Printing bitmap objects in the debugger

Tom Lane wrote: > Ashutosh Bapat writes: > > While working on partition-wise join, I had to examine Relids objects > > many times. Printing the Bitmapset::words[] in binary format and then > > inferring the relids takes time and is error prone. > > FWIW, I

Re: [HACKERS] Printing bitmap objects in the debugger

Ashutosh Bapat wrote: > Hi All, > While working on partition-wise join, I had to examine Relids objects > many times. Printing the Bitmapset::words[] in binary format and then > inferring the relids takes time and is error prone. Instead I wrote a > function bms_to_char() which allocates a

Re: [HACKERS] Event trigger and CREATE/ALTER ROLE/USER

Tatsuo Ishii wrote: > Simple question: Is there any reason for event trigger to not support > CREATE/ALTER ROLE/USER? As I understand the issue, the main reason is that event triggers execute procedures, and those exist in a single database only. If you were to create an event trigger in

Re: [HACKERS] Inheriting PostgresNode object

Victor Wagner wrote: > Hi hackers! > > I've encountered need to extend functionality of PostgresNode class > from the TAP test framework. What I want can easily be done via perl > object inheritation. > > But documentation in the PostgresNode.pm recommends to use get_new_node > function rather

Re: [HACKERS] An extra error for client disconnection on Windows

Michael Paquier wrote: > On Tue, Sep 13, 2016 at 10:42 AM, Kyotaro HORIGUCHI > wrote: > > If we take a policy to try to imitate the behavior of some > > reference platform (specifically Linux) on other platforms, this > > is required disguising. Another potential

Re: [HACKERS] 9.6 TAP tests and extensions

Craig Ringer wrote: > I suggest that the above patches be applied to 9.6 and v10. Then for > v10 I don't object to patching 9.6 in this way, but kindly do not pollute this thread with future ideas on what to do on pg10, at least until the current release is sorted out. You'll only distract

Re: [HACKERS] SELECT FOR UPDATE regression in 9.5

Magnus wrote: > I ran the web application mentioned in Marti's original mail on a patched > Postgres server. It looks like it is working correctly now, no more test > failures. Thanks for the confirmation. I pushed the fix, along with the presented test case. I chose to backpatch all the way

Re: [HACKERS] Assertion failure in REL9_5_STABLE

Marko Tiikkaja wrote: > Hi, > > Running one specific test from our application against REL9_5_STABLE > (current as of today) gives me this: Just pushed the fix. Thanks for the report! -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote

Re: [HACKERS] CVE-2016-1238 fix breaks (at least) pg_rewind tests

Andres Freund wrote: > On 2016-09-08 18:13:06 -0300, Alvaro Herrera wrote: > > I suppose -I$(srcdir) should be fine. (Why the quotes?) > > Because quoting correctly seems like a good thing to do? Most people > won't have whitespace in there, but it doesn't seem impossib

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > Tom Lane wrote: > >> That comment seems utterly wrong to me, because both PageIndexTupleDelete > >> and PageIndexMultiDelete certainly contain assertions that every item on > >>

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Tom Lane wrote: > Hey Alvaro, can you comment on this bit in the proposed patch? > > + for (i = FirstOffsetNumber; i <= itemcount; i++) > + { > + ItemId ii = PageGetItemId(phdr, i); > + > + /* Normally here was following

Re: [HACKERS] CVE-2016-1238 fix breaks (at least) pg_rewind tests

Andres Freund wrote: > On 2016-09-08 17:58:03 -0300, Alvaro Herrera wrote: > > Andres Freund wrote: > > > > > ISTM that the easiest fix is to just tack -I '$(srcdir)' into the prove > > > flags like: > > > PROVE = @PROVE@ > > > PG_PROVE_F

Re: [HACKERS] CVE-2016-1238 fix breaks (at least) pg_rewind tests

Andres Freund wrote: > ISTM that the easiest fix is to just tack -I '$(srcdir)' into the prove > flags like: > PROVE = @PROVE@ > PG_PROVE_FLAGS = -I $(top_srcdir)/src/test/perl/ -I '$(srcdir)' > PROVE_FLAGS = --verbose > > I don't think there's any security concerns for us here. Maybe not, but

Re: [HACKERS] Add support for restrictive RLS policies

Stephen Frost wrote: > Greetings! > > * Stephen Frost (sfr...@snowman.net) wrote: > > Based on Robert's suggestion and using Thom's verbiage, I've tested this > > out: > > > > CREATE POLICY pol ON tab AS [PERMISSIVE|RESTRICTIVE] ... Can't you keep those words as Sconst or something (DefElems?)

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Tom Lane wrote: > Andrew Borodin writes: > > Thank you for your corrections. > > Here is the patch with suggestions taken into account, except 6th. > > I'll pick this up, unless some other committer is already on it. > > I think that we should buy back the addition of

Re: [HACKERS] Default make target in test modules

Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > I suppose this is a very easy mistake to make -- but also fortunately an > > easy one to correct. Do you want me to fix the affected modules? > > I was going to do it, but if you want to, feel fre

Re: [HACKERS] Default make target in test modules

Tom Lane wrote: > I happened to notice that if you type "make" in > src/test/modules/test_pg_dump, you will get a "make check" action > not "make all". I hope this is just somebody being thoughtless > about Makefile ordering and not an intentional override of the > default make target. If the

Re: [HACKERS] CF app and patch series

Craig Ringer wrote: > Hi all > > Now that it's becoming more common to post patch series, not just > standalone patches, it might be worth looking at how the CF app can > help manage them. > > Any ideas? I agree that we don't consider this case at all currently and that it's causing some pain.

Re: [HACKERS] Long options for pg_ctl waiting

Gavin Flower wrote: > possibly '--nosync' (& any similar) should have a '--no-sync' variation > added, with the '--nosync' variation documented as depreciated? I agree -- I would go as far as just documenting --no-sync only and keeping the --nosync one working with minimal (if any) visibility in

Re: [HACKERS] ICU integration

> - I can't remember the specific language but they had the collation rule > that "CH" was treated as a distinct entity between C and D. This gave the > order C < CG < CI < CZ < CH < D. Then they removed CH as special which gave > C < CG < CH < CI < CZ < D. Suppose there was the constraint CHECK

Re: [HACKERS] SELECT FOR UPDATE regression in 9.5

Marti Raudsepp wrote: > Hello list > > While testing an application with PostgreSQL 9.5, we experienced an issue > involving aborted subtransactions and SELECT FOR UPDATE. In certain > situations, a locking query doesn't return rows that should be visible and > already locked by the current

Re: [HACKERS] SELECT FOR UPDATE regression in 9.5

Marko Tiikkaja wrote: > On 2016-09-06 6:02 PM, Marti Raudsepp wrote: > >This issue is also reproducible on the current master branch. In an > >assertions-enabled build, it traps an assertion in HeapTupleHeaderGetCmax > >called by heap_lock_tuple. The following test case demonstrates the issue... >

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

Grigory Smolkin wrote: > > On 09/05/2016 04:34 PM, Alvaro Herrera wrote: > >Grigory Smolkin wrote: > > > >>Funny part is that it never drops them. So when backend is finally > >>terminated, it tries to drop them and fails with error: > >> > >>

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

Grigory Smolkin wrote: > Funny part is that it never drops them. So when backend is finally > terminated, it tries to drop them and fails with error: > > FATAL: out of shared memory > HINT: You might need to increase max_locks_per_transaction > > If I understand that rigth, we are trying to

Re: [HACKERS] pg_sequence catalog

Andres Freund wrote: > Hi, > > On 2016-08-31 12:53:30 -0400, Tom Lane wrote: > > Improving on the space wastage is exactly the point IMO. If it's still > > going to be 8k per sequence on disk (*and* in shared buffers, remember), > > I'm not sure it's worth all the work to change things at all. >

Re: [HACKERS] pg_sequence catalog

Andres Freund wrote: > On 2016-08-31 11:23:27 -0400, Tom Lane wrote: > > Another issue is what is the low-level interlock between nextvals > > in different processes. Right now it's the buffer lock on the > > sequence's page. With a scheme like this, if we just kept doing > > that, we'd have a

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

Haribabu Kommi wrote: > Apart from the above, here are the following list of command tags that > are generated in the code, I took only the first word of the command tag > just to see how many categories present. The number indicates the > subset of operations or number of types it is used. Like

Re: [HACKERS] pageinspect: Hash index support

Jesper Pedersen wrote: > Hi, > > Attached is a patch that adds support for hash indexes in pageinspect. > > The functionality (hash_metap, hash_page_stats and hash_page_items) follows > the B-tree functions. I suggest that pageinspect functions are more convenient to use via the get_raw_page

Re: [HACKERS] Re: [COMMITTERS] pgsql: Change the way that LWLocks for extensions are allocated.

Robert Haas wrote: > That would also have the advantage of improving the test coverage for > pg_stat_statements, which is at the moment quite a bit thinner than > the coverage for lwlock.c. Hmm, the coverage-html report is not currently covering contrib ... I suppose that's an easily fixable

Re: [HACKERS] Write Ahead Logging for Hash Indexes

Amit Kapila wrote: > How about attached? That works; pushed. (I removed a few #includes from the new file.) > If you want, I think we can one step further and move hash_redo to a > new file hash_xlog.c which is required for main patch, but we can > leave it for later as well. I think that can

Re: [HACKERS] Renaming of pg_xlog and pg_clog

Michael Paquier wrote: > On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund wrote: > > On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote: > >> I agree with all that. But the subject line is specifically about > >> moving pg_xlog. So if your opinion is that we shouldn't move

Re: [HACKERS] Renaming some binaries

Simon Riggs wrote: > On 26 August 2016 at 18:26, Euler Taveira wrote: > > > I'm bringing this $subject into discussion again. Historically, we are > > carrying binary names that have been confused newbies. createuser is the > > worst name so for. Also, names like createdb,

Re: [HACKERS] PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

Tom Lane wrote: > So far as I can find, the attached is all we need to do to introduce a > new message field. (This patch doesn't address the memory-context > questions, but it does fix the localization-driven failure demonstrated > upthread.) > > Any objections? Anyone want to bikeshed the

Re: [HACKERS] WAL consistency check facility

Kuntal Ghosh wrote: > Thanks a lot. > > I just want to mention the situation where I was getting the > speculative token related inconsistency. > > ItemPointer in backup page from master: > LOG: ItemPointer BlockNumber: 1 OffsetNumber:65534 Speculative: true > CONTEXT: xlog redo at 0/127F4A48

Re: [HACKERS] increasing the default WAL segment size

Gavin Flower wrote: > On 26/08/16 05:43, Josh Berkus wrote: > >The one thing I'd be worried about with the increase in size is folks > >using PostgreSQL for very small databases. If your database is only > >30MB or so in size, the increase in size of the WAL will be pretty > >significant (+144MB

Re: [HACKERS] [COMMITTERS] pgsql: Add the "snapshot too old" feature

Kevin Grittner wrote: > On Thu, Aug 25, 2016 at 2:56 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > > I'm wondering about the TestForOldSnapshot call in scanPendingInsert(). > > Why do we apply it to the metapage buffer (line 1717 in master)?

Re: [HACKERS] increasing the default WAL segment size

Robert Haas wrote: > On Thu, Aug 25, 2016 at 3:21 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > Does it work to set the minimum to one WAL segment, i.e. 64MB? guc.c > > has a hardcoded minimum of 2, but I couldn't find an explanation for it. > > Well,

Re: [HACKERS] [COMMITTERS] pgsql: Add the "snapshot too old" feature

Kevin Grittner wrote: > Add the "snapshot too old" feature > src/backend/access/gin/ginbtree.c | 9 +- > src/backend/access/gin/gindatapage.c | 7 +- > src/backend/access/gin/ginget.c| 22 +- > src/backend/access/gin/gininsert.c

Re: [HACKERS] increasing the default WAL segment size

Robert Haas wrote: > On Thu, Aug 25, 2016 at 2:49 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > I think the relevant one for that case is the minimum, though: > > > > #min_wal_size = 80MB > > > > which corresponds to 5 segments. I suppose th

Re: [HACKERS] increasing the default WAL segment size

Robert Haas wrote: > On Thu, Aug 25, 2016 at 1:43 PM, Josh Berkus wrote: > > The one thing I'd be worried about with the increase in size is folks > > using PostgreSQL for very small databases. If your database is only > > 30MB or so in size, the increase in size of the WAL

Re: [HACKERS] WAL consistency check facility

Kuntal Ghosh wrote: > 4. For Speculative Heap tuple insert operation, there was > inconsistency in t_ctid value. So, I've modified the t_ctid value (in > backup page) to current block number and offset number. Need > suggestions!! In speculative insertions, t_ctid is used to store the

Re: [HACKERS] Write Ahead Logging for Hash Indexes

Amit Kapila wrote: > On Wed, Aug 24, 2016 at 11:46 PM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > Can you split the new xlog-related stuff to a new file, say hash_xlog.h, > > instead of cramming it in hash.h? Removing the existing #include > > "xlog

Re: [HACKERS] Pluggable storage

Alvaro Herrera wrote: > Many have expressed their interest in this topic, but I haven't seen any > design of how it should work. Here's my attempt; I've been playing with > this for some time now and I think what I propose here is a good initial > plan. I regret to announce th

Re: [HACKERS] Write Ahead Logging for Hash Indexes

Amit Kapila wrote: > $SUBJECT will make hash indexes reliable and usable on standby. Nice work. Can you split the new xlog-related stuff to a new file, say hash_xlog.h, instead of cramming it in hash.h? Removing the existing #include "xlogreader.h" from hash.h would be nice. I volunteer for

[HACKERS] Re: [COMMITTERS] pgsql: Modify BufferGetPage() to prepare for "snapshot too old" feature

Kevin Grittner wrote: > Modify BufferGetPage() to prepare for "snapshot too old" feature I just noticed that this commit added a line to #include catalog/catalog.h in storage/bufmgr.h. I can't find any reason for it doing so, and I think it's a bad line to have there. Can we get it removed? --

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

Claudio Freire wrote: > After looking at it from a birdseye view, I agree it's conceptually > complex (reading HeapTupleSatisfiesSelf already makes one dizzy). > > But other than that, the implementation seems rather simple. It seems > to me, if one figures out that it is safe to do so

Re: [HACKERS] Patch: initdb: "'" for QUOTE_PATH (non-windows)

Ryan Murphy wrote: > Thanks for committing it Tom! Thank you all for your help. > > I really like the Postgres project! If there's anything that especially > needs worked on let me know, I'd love to help. https://wiki.postgresql.org/wiki/Todo -- Álvaro Herrera

Re: [HACKERS] [BUGS] BUG #14244: wrong suffix for pg_size_pretty()

Bruce Momjian wrote: > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote: > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian wrote: > > > That's why I was asking you to comment on the final patch, which I am > > > planning to apply to PG 10 soon. > > > > Oh, OK. I

Re: [HACKERS] Block level parallel vacuum WIP

Robert Haas wrote: > On Tue, Aug 23, 2016 at 11:17 AM, Alvaro Herrera > <alvhe...@2ndquadrant.com> wrote: > > Robert Haas wrote: > >> 2. When you finish the heap scan, or when the array of dead tuple IDs > >> is full (or very nearly full?), perform a cycle of

Re: [HACKERS] Block level parallel vacuum WIP

Robert Haas wrote: > 2. When you finish the heap scan, or when the array of dead tuple IDs > is full (or very nearly full?), perform a cycle of index vacuuming. > For now, have each worker process a separate index; extra workers just > wait. Perhaps use the condition variable patch that I posted

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

Bruce Momjian wrote: > On Tue, Aug 16, 2016 at 11:47:09AM -0700, Andres Freund wrote: > > On 2016-08-15 18:09:02 +, Piotr Stefaniak wrote: > > > There are more fixes I intend to do, of which the most relevant for > > > Postgres are: > > > 1) fixing "function pointer typedef formatting" > > >

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

Robert Haas wrote: > However: > > 1. The number of tables for which we would need to add a duplicate, > unlogged table is formidable. You need pg_attribute, pg_attrdef, > pg_constraint, pg_description, pg_type, pg_trigger, pg_rewrite, etc. > And the backend changes needed so that we used the

Re: [HACKERS] Exporting more function in libpq

Craig Ringer wrote: > On 19 August 2016 at 14:17, Tatsuo Ishii wrote: > > > I would like to proppse to export these functions in libpq. > > > > pqPutMsgStart > > pqPutMsgEnd > > pqPutc > > pqPuts > > pqPutInt > > pqPutnchar > > pqFlush > > pqHandleSendFailure > > > > I think

Re: [HACKERS] distinct estimate of a hard-coded VALUES list

Robert Haas wrote: > On Sat, Aug 20, 2016 at 4:58 PM, Tom Lane wrote: > > Jeff Janes writes: > >> On Thu, Aug 18, 2016 at 2:25 PM, Tom Lane wrote: > >>> It does know it, what it doesn't know is how many duplicates there are. > > > >>

Re: [HACKERS] improved DefElem list processing

Peter Eisentraut wrote: > I'm not happy that utils/acl.h has prototypes for aclchk.c, because > acl.h is included all over the place. Perhaps I should make a > src/include/catalog/aclchk.c to clean that up. I've been bothered by that too in the past. +1 for the cleanup. -- Álvaro Herrera

Re: [HACKERS] errno clobbering in reorderbuffer

Andres Freund wrote: > Not at all, thanks. Done, thanks both for the look-over. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] errno clobbering in reorderbuffer

Andres Freund wrote: > On 2016-08-18 19:06:02 -0300, Alvaro Herrera wrote: > > While researching a customer issue with BDR I noticed that one ereport() > > call happens after clobbering errno, leading to the wrong strerror being > > reported. This patch fixes it by

[HACKERS] errno clobbering in reorderbuffer

While researching a customer issue with BDR I noticed that one ereport() call happens after clobbering errno, leading to the wrong strerror being reported. This patch fixes it by saving before calling CloseTransientFile and restoring afterwards. I also threw in a missing errcode I noticed while

Re: [HACKERS] [WIP] [B-Tree] Keep indexes sorted by heap physical location

Claudio Freire wrote: > Unique indexes still need to scan all duplicates to check visibility > and will become O(N^2) there. That scenario doesn't matter, because on unique indexes there aren't many duplicate values anyway -- only one can be a live tuple. -- Álvaro Herrera

Re: [HACKERS] WIP: About CMake v2

Christian Convey wrote: > I see. In other projects I've worked on, the configuration of a build > farm has been driven by some list of platforms that were considered > important to support. Build farm members are systems that somebody has seen as interesting enough that they deserve enough

Re: [HACKERS] WIP: About CMake v2

Christian Convey wrote: > * Allow the CMake-based build system to assume a fairly modern version > of CMake. (Maybe 2.8.12, or 3.0.) > > * For systems where the minimum CMake version isn't readily available, > have an alternative build system which is just a simplistic Bash > script that

Re: [HACKERS] WIP: About CMake v2

Stefan Kaltenbrunner wrote: > On 08/18/2016 09:30 PM, Christian Convey wrote: > > Yury: Would it make sense to add a call to "cmake_minimum_required" in > > one or more of your CMakeLists.txt files? > > it would make sense nevertheless but I dont think that 2.8.11 is old > enough - looking at

[HACKERS] Re: [COMMITTERS] pgsql: Fix deletion of speculatively inserted TOAST on conflict

Andres Freund wrote: > This commit also adds a isolationtester spec test, exercising the > relevant code path. Unfortunately 9.5 cannot handle two waiting > sessions, and thus cannot execute this test. This test seems to fail randomly, depending on which session is awakened first. Annoying ...

Re: [HACKERS] [Patch] New psql prompt substitution %r (m = master, r = replica)

Aleksander Alekseev wrote: > Peter has a good point that in general case it's more complicated than > just master or replica. I also agree with David that what actually > would be nice to have is a some syntax that allows user to execute > arbitrary commands before displaying a prompt. This way

Re: [HACKERS] [Patch] New psql prompt substitution %r (m = master, r = replica)

Aleksander Alekseev wrote: > $ cat ~/.psqlrc > select (case when pg_is_in_recovery() then 'r' else 'm' end) as mor > \gset > > \set PROMPT1 '%p (%:mor:) =# ' Okay, this seems moderately reasonable, but ... > Besides I figured out that replica promotion case could also be properly > handled

Re: [HACKERS] CLUSTER, reform_and_rewrite_tuple(), and parallelism

Peter Geoghegan wrote: > This doesn't seem that interesting, but not sure what you're looking for. > > I also attach cycles flamegraph. I may be blind, but what are those write() calls attributed to heap_form_tuple? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL

<    4   5   6   7   8   9   10   11   12   13   >