Re: [HACKERS] pg_hba_file_settings view patch

On Fri, Oct 28, 2016 at 4:17 AM, Alvaro Herrera wrote: > Greg Stark wrote: > > > The fundamental problem is that the pga_hba.conf file has some bits of > > complex structure that aren't easily captured by linear arrays. The > > problem I struggled with most was the

Re: [HACKERS] Proposal: scan key push down to heap [WIP]

On Wed, Oct 26, 2016 at 12:01 PM, Andres Freund wrote: > On 2016-10-25 13:18:47 -0400, Tom Lane wrote: >> (Frankly, I'm pretty skeptical of this entire patch being worth the >> trouble...) > > The gains are quite noticeable in some cases. So if we can make it work > without

Re: [HACKERS] split up psql \d Modifiers column

2016-10-28 5:30 GMT+02:00 Peter Eisentraut : > I propose to change the psql \d output a bit, best shown with an example: > > \d persons3 > - Table "public.persons3" > - Column | Type |Modifiers > -+-+-- > - id |

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Fri, Oct 28, 2016 at 5:08 AM, Michael Paquier wrote: > On Fri, Oct 28, 2016 at 1:16 AM, Robert Haas wrote: >> On Thu, Oct 27, 2016 at 9:05 AM, Michael Paquier >> wrote: >>> On Thu, Oct 27, 2016 at 7:16 PM, Amit

Re: [HACKERS] Unicode mapping scripts cleanup

On 9/1/15 12:13 AM, Peter Eisentraut wrote: > ere is a series of patches to clean up the Unicode mapping script > business in src/backend/utils/mb/Unicode/. I never committed the last of these patches, which have the download locations of the files. I have updated this a bit now and propose it

[HACKERS] Applying XLR_INFO_MASK correctly when looking at WAL record information

Hi all, I have just been trapped by the fact that in some code paths we look at the RMGR information of a WAL record (record->xl_info) but the filter dedicated to it, ~XLR_INFO_MASK, is not applied. This is harmful now, but this could lead to problems if in the future new record-level flags,

Re: [HACKERS] Hash Indexes

On Fri, Oct 28, 2016 at 2:52 AM, Robert Haas wrote: > On Mon, Oct 24, 2016 at 10:30 AM, Amit Kapila wrote: >>> Amit, can you please split the buffer manager changes in this patch >>> into a separate patch? >> >> Sure, attached patch

Re: [HACKERS] save redundant code for pseudotype I/O functions

On 10/27/16 11:49 PM, Peter Eisentraut wrote: > Here is a patch to refactor some of the I/O functions in pseudotypes.c > to save redundant code and reduce the number of distinct translatable > strings. And here is the actual patch. -- Peter Eisentraut http://www.2ndQuadrant.com/

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

On Thu, 27 Oct 2016 19:03:11 +0200 Gilles Darold wrote: > The current v8 of the patch Perhaps instead of the define CURRENT_LOG_FILENAME a better name for the symbol would be LOG_METAINFO_FILE? Regards, Karl Free Software: "You don't pay back, you

[HACKERS] save redundant code for pseudotype I/O functions

Here is a patch to refactor some of the I/O functions in pseudotypes.c to save redundant code and reduce the number of distinct translatable strings. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

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

On Thu, 27 Oct 2016 22:09:41 -0500 "Karl O. Pinc" wrote: > On Thu, 27 Oct 2016 19:03:11 +0200 > Gilles Darold wrote: > > > The current v8 of the patch > > For your consideration. > > Attached is a patch to apply to v8 of your patch. > > I moved the

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

Hi Gilles, On Thu, 27 Oct 2016 19:03:11 +0200 Gilles Darold wrote: > The current v8 of the patch For your consideration. Attached is a patch to apply to v8 of your patch. I moved the call to logfile_writename() in write_syslogger_file() into the open_csvlogfile().

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

On Thu, 27 Oct 2016 19:03:11 +0200 Gilles Darold wrote: > The current v8 of the patch Attached is a patch to the v8 version of your patch. It rewords some of the comments in the code. Take the hunks or leave them as you wish. Regards, Karl Free

Re: [HACKERS] make coverage-html on OS X

On 10/27/16 1:27 PM, Jim Nasby wrote: > Well, that got me closer, but it's still blowing up on libpq: > > genhtml: ERROR: no valid records found in tracefile > ./src/interfaces/libpq/lcov.info I have seen similar problems when I use a gcov that does not match the gcc. I was able to run it

[HACKERS] move collation import to backend

Currently, initdb parses locale -a output to populate pg_collation. If additional collations are installed in the operating system, it is not possible to repeat this process, only by doing each step manually. So I propose to move this to a backend function that can be called separately, and have

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com] > Ok. In that case, I think we shouldn't even call PG_SETMASK() similar to > pgarch_exit(). Attached patch removes PG_SETMASK(). Let me know if it looks > good. It looks good. Thanks. Regards Takayuki Tsunakawa -- Sent via

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

On Fri, Oct 28, 2016 at 5:15 AM, Jim Nasby wrote: > On 10/27/16 6:39 AM, Mithun Cy wrote: >> >> # pg_autoprewarm. > > > IMO it would be better to add this functionality to pg_prewarm instead of > creating another contrib module. That would reduce confusion and reduce the

Re: [HACKERS] [bug fix] Stats collector is not restarted on the standby

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > The delay is intentional. Per pgstat_start(): It's kind of you to tell the reason. > Committed and back-patched all the way. Thanks again! Regards Takayuki Tsunakawa -- Sent

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy > # pg_autoprewarm. > > This a PostgreSQL contrib module which automatically dump all of the > blocknums present in buffer pool at the time of server shutdown(smart and > fast mode only,

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Oct 19, 2016 at 11:33 AM, Peter Geoghegan wrote: > I don't think that eager merging will prove all that effective, > however it's implemented. I see a very I/O bound system when parallel > CREATE INDEX merges serially. There is no obvious reason why you'd > have a

Re: [HACKERS] emergency outage requiring database restart

On Thu, Oct 27, 2016 at 9:53 PM, Merlin Moncure wrote: > I think we can rule out faulty storage Nobody ever expects the faulty storage -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Fri, Oct 28, 2016 at 1:16 AM, Robert Haas wrote: > On Thu, Oct 27, 2016 at 9:05 AM, Michael Paquier > wrote: >> On Thu, Oct 27, 2016 at 7:16 PM, Amit Kapila wrote: >>> This can create problem if the checkpoint record

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

On Thu, 27 Oct 2016 16:18:02 -0500 "Karl O. Pinc" wrote: > On Thu, 27 Oct 2016 19:03:11 +0200 > Gilles Darold wrote: > > > The current v8 of the patch > > Attached is a doc patch for your v8 patch. > > Added , so the docs would build. > > Added

Re: [HACKERS] Hash Indexes

On Mon, Oct 24, 2016 at 10:30 AM, Amit Kapila wrote: >> Amit, can you please split the buffer manager changes in this patch >> into a separate patch? > > Sure, attached patch extend_bufmgr_api_for_hash_index_v1.patch does that. The additional argument to

Re: [HACKERS] make coverage-html on OS X

On 10/27/16 12:27 PM, Jim Nasby wrote: I've attached a build log if anyone wants to take a look... BTW, while the log shows Apple's make in use I also tried with gmake out of macports with the same results. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics,

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

On Thu, 27 Oct 2016 19:03:11 +0200 Gilles Darold wrote: > The current v8 of the patch Attached is a doc patch for your v8 patch. Added , so the docs would build. Added markup of "system values". Hope to look at code soon! Karl Free Software: "You

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

On Thu, 27 Oct 2016 19:57:18 +0200 Christoph Berg wrote: > Re: Karl O. Pinc 2016-10-27 <20161027121141.6bd95...@slate.meme.com> > > SELECT * from postgres.pg_current_logfile; > We were discussing exactly that idea upthread before concluding that a > function with a single

Re: [HACKERS] pg_hba_file_settings view patch

Greg Stark wrote: > The fundamental problem is that the pga_hba.conf file has some bits of > complex structure that aren't easily captured by linear arrays. The > problem I struggled with most was the keywords like "all", "samerole", > and "replication". A simple array of text makes it awkward to

Re: [HACKERS] condition variables

On Tue, Oct 4, 2016 at 3:12 PM, Thomas Munro wrote: > On Mon, Aug 15, 2016 at 5:58 PM, Thomas Munro > wrote: >> Please find attached a -v2 of your patch which includes suggestions >> 1-3 above. > > Here's a rebased patch.

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

On 10/27/16 6:39 AM, Mithun Cy wrote: # pg_autoprewarm. IMO it would be better to add this functionality to pg_prewarm instead of creating another contrib module. That would reduce confusion and reduce the amount of code necessary. + cmp_member_elem(database); +

Re: [HACKERS] Improving RLS planning

On 25 October 2016 at 22:58, Tom Lane wrote: > The alternative I'm now thinking about pursuing is to get rid of the > conversion of RLS quals to subqueries. Instead, we can label individual > qual clauses with security precedence markings. Concretely, suppose we > add an

Re: [HACKERS] [bug fix] Stats collector is not restarted on the standby

On Wed, Oct 26, 2016 at 8:41 AM, Kuntal Ghosh wrote: > On Wed, Oct 26, 2016 at 4:47 PM, Michael Paquier > wrote: >> >> If you test on a master node that would be the same: there is a delay >> until the stats process restart. I have not

Re: [HACKERS] emergency outage requiring database restart

On Thu, Oct 27, 2016 at 2:31 AM, Ants Aasma wrote: > On Wed, Oct 26, 2016 at 8:43 PM, Merlin Moncure wrote: >> /var/lib/pgsql/9.5/data/pg_log/postgresql-26.log | grep "page >> verification" >> 2016-10-26 11:26:42 CDT [postgres@castaging]: WARNING: page

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Wed, Oct 26, 2016 at 2:00 AM, Masahiko Sawada wrote: > I think we can consider the atomic commit and the atomic visibility > separately, and the atomic visibility can build on the top of the > atomic commit. It is true that we can do that, but I'm not sure whether it's

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Fri, Oct 21, 2016 at 1:38 AM, Ashutosh Bapat wrote: > Once we have that information, the foreign server can actively poll > the local server to get the status of transaction xid and resolves the > prepared transaction itself. It can go a step further and inform

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

Re: Gilles Darold 2016-10-27 > > I'm partial to "format path" over just line number, because > > it's more explicit. Either way works. > > This is the format used. Ex: > > ~$ cat /usr/local/postgresql/data/current_logfile > stderr

Re: [HACKERS] Issues with building snap packages and psql

On Thu, Oct 27, 2016 at 12:24 PM, Joshua D. Drake wrote: > This problem clearly an improper implementation on our part. We have found a > work around by wrapping the launch of psql so we can set PSQLRC. At some > point, perhaps with v10 we could change this. This problem

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Thu, Oct 27, 2016 at 9:46 AM, Mithun Cy wrote: > On Wed, Oct 26, 2016 at 8:49 PM, Robert Haas wrote: >> Let me know your thoughts. > > One small issue. I tried to run make installcheck after applying patch there > seems to be a invalid write

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

On Thu, 27 Oct 2016 19:03:11 +0200 Gilles Darold wrote: > >> Re: Karl O. Pinc 2016-10-27 > >> <20161026222513.74cd3...@slate.meme.com> > > Your comment makes me wonder if pg_current_logfile(), without > > arguments, should instead be "SHOW current_logfile;". > -1,

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

Le 27/10/2016 à 14:14, Karl O. Pinc a écrit : > On Thu, 27 Oct 2016 11:07:43 +0200 > Christoph Berg wrote: > >> Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3...@slate.meme.com> >>> But what if current_logfile contains only a single line? What >>> sort of file format does the

Re: [HACKERS] Issues with building snap packages and psql

On 10/26/2016 12:10 PM, Joshua D. Drake wrote: On 10/26/2016 11:33 AM, Robert Haas wrote: On Wed, Oct 26, 2016 at 2:22 PM, Joshua D. Drake It is also inconsistent with how other programs behave. For example if psql uses readline, and you change the value of $HOME, then readline uses

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Thu, Oct 27, 2016 at 9:05 AM, Michael Paquier wrote: > On Thu, Oct 27, 2016 at 7:16 PM, Amit Kapila wrote: >> This can create problem if the checkpoint record spans across multiple >> segments, because you are updating minRecoveryPoint to

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

On Wed, Oct 26, 2016 at 9:33 PM, Peter Geoghegan wrote: > Besides, parallel CREATE INDEX alone will probably > be quite effective at speeding up CLUSTER in practice, simply because > that's often where most wall clock time is spent during a CLUSTER > operation. Creating all

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Wed, Oct 26, 2016 at 8:49 PM, Robert Haas wrote: > Let me know your thoughts. One small issue. I tried to run make installcheck after applying patch there seems to be a invalid write access in code (resulting in crash). ==118997== Invalid write of size 1 ==118997==

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Thu, Oct 27, 2016 at 7:16 PM, Amit Kapila wrote: > This can create problem if the checkpoint record spans across multiple > segments, because you are updating minRecoveryPoint to start of > checkpoint record. We need to update it to end+1 of checkpoint > record.

Re: [HACKERS] [PATCH] pgpassfile connection option

I would suggest that the struct gets the value (from option, environment or default) and is always used elsewhere. The getPgPassFilename function should disappear and PasswordFromFile should be simplified significantly. I agree, however that's easier said than done because the "default" is

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

On Thu, Oct 27, 2016 at 5:14 PM, Amit Kapila wrote: >>> Thanks Tomas and Dilip for doing detailed performance tests for this >>> patch. I would like to summarise the performance testing results. >>> >>> 1. With update intensive workload, we are seeing gains from 23%~192%

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

On Thu, 27 Oct 2016 11:07:43 +0200 Christoph Berg wrote: > Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3...@slate.meme.com> > > But what if current_logfile contains only a single line? What > > sort of file format does the logfile have? If you don't know > > you can't

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/10/27 18:06, Ashutosh Bapat wrote: On Thu, Oct 27, 2016 at 12:46 PM, Etsuro Fujita wrote: On 2016/10/26 19:53, Ashutosh Bapat wrote: On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita My concern about your proposal is: it might not be worth complicating the

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

On Thu, Oct 27, 2016 at 5:09 PM, Mithun Cy wrote: > This a PostgreSQL contrib module which automatically dump all of the blocknums >present in buffer pool at the time of server shutdown(smart and fast mode only, >to be enhanced to dump at regular interval.) and load

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

On Thu, Oct 27, 2016 at 4:15 AM, Tomas Vondra wrote: > On 10/25/2016 06:10 AM, Amit Kapila wrote: >> >> On Mon, Oct 24, 2016 at 2:48 PM, Dilip Kumar >> wrote: >>> >>> On Fri, Oct 21, 2016 at 7:57 AM, Dilip Kumar >>>

[HACKERS] Proposal : For Auto-Prewarm.

# pg_autoprewarm. This a PostgreSQL contrib module which automatically dump all of the blocknums present in buffer pool at the time of server shutdown(smart and fast mode only, to be enhanced to dump at regular interval.) and load these blocks when server restarts. Design: -- We have created

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Thu, Oct 27, 2016 at 9:51 AM, Michael Paquier wrote: > On Thu, Oct 27, 2016 at 2:59 AM, Robert Haas wrote: >> On Wed, Oct 26, 2016 at 2:06 AM, Michael Paquier >> wrote: >>> But yes, thinking *harder*, I agree that

Re: [HACKERS] Gather Merge

Please find attached latest patch which fix the review point as well as additional clean-up. - Get rid of funnel_slot as its not needed for the Gather Merge - renamed fill_tuple_array to form_tuple_array - Fix possible infinite loop into gather_merge_init (Reported by Amit Kaplia) - Fix tqueue.c

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

Re: Karl O. Pinc 2016-10-27 <20161026222513.74cd3...@slate.meme.com> > Since it now can contain multiple pathnames perhaps the name of the > file should be "current_logfiles"? Seems more descriptive. Not sure about that, most often it would contain one logfile only, and catering for that seems

Re: [HACKERS] Push down more full joins in postgres_fdw

On Thu, Oct 27, 2016 at 12:46 PM, Etsuro Fujita wrote: > On 2016/10/26 19:53, Ashutosh Bapat wrote: >> >> On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita >> wrote: > > >>> In practice, the search cost would be negligible compared to the

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

On Thu, Oct 27, 2016 at 7:29 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Ashutosh Bapat >> In pgstat_quickdie(), I think a call to sigaddset(, SIGQUIT) is >> missing before

Re: [HACKERS] WAL consistency check facility

On Thu, Sep 29, 2016 at 12:49 PM, Michael Paquier wrote: > Seeing nothing happening, I have moved the patch to next CF as there > is a new version, but no reviews for it. Just a note for anybody potentially looking at this patch. I am currently looking at it in depth,

Re: [HACKERS] emergency outage requiring database restart

On Wed, Oct 26, 2016 at 8:43 PM, Merlin Moncure wrote: > /var/lib/pgsql/9.5/data/pg_log/postgresql-26.log | grep "page > verification" > 2016-10-26 11:26:42 CDT [postgres@castaging]: WARNING: page > verification failed, calculated checksum 37251 but expected 37244 >

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/10/26 19:53, Ashutosh Bapat wrote: On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita wrote: In practice, the search cost would be negligible compared to the cost of explaining/executing the query. My concern about your proposal is: it might not be worth

Re: [HACKERS] pg_hba_file_settings view patch

On Wed, Oct 26, 2016 at 11:04 PM, Joshua D. Drake wrote: > On 10/26/2016 12:54 PM, Josh Berkus wrote: >> I mean, I'm not particularly in favor of using JSON for this (arrays >> seem OK), but that seems like an invalid reason not to. > > -1 to JSON for this. Sigh. Well I

[HACKERS] Query regarding selectDumpableExtension()

Hi ​,​ ​ selectDumpableExtension() function skip ​s dump of​ built-in extensions in case of binary-upgrade only, ​ ​ why not in normal ​dump​ ? ​ ​ Can't we assume those will already be installed in the target database ​ at restore ? Thanks ​ & Regards, Amul​