Re: [HACKERS] Asynchronous execution on FDW

On Thu, Jul 2, 2015 at 3:07 PM, Kyotaro HORIGUCHI wrote: > Ouch! I mistakenly made two CF entries for this patch. Could > someone remove this entry for me? > > https://commitfest.postgresql.org/5/290/ > > The correct entry is "/5/291/" Done. -- Michael -- Sent via pgsql-hackers mailing list (

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-02 PM 03:52, Michael Paquier wrote: > On Thu, Jul 2, 2015 at 3:29 PM, Amit Langote > wrote: >> On 2015-07-02 PM 03:12, Fujii Masao wrote: >>> >>> So I'm thinking that we basically need to check the progress on each >>> standby to choose new master. >>> >> >> Does HA software determine a

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-02 PM 03:43, Beena Emerson wrote: > Amit wrote: > >> Does HA software determine a standby to promote based on replication >> progress >> or would things be reliable enough for it to infer one from the quorum >> setting >> specified in GUC (or wherever)? Is part of the job of this patc

[HACKERS] Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE

Hi, While working on the foreign-join-pushdown issue, I noticed that in READ COMMITTED isolation level it's possible that the result of SELECT ... ORDER BY ... FOR UPDATE is not sorted correctly due to concurrent updates that replaced the sort key columns with new values as shown in the below exam

Re: [HACKERS] Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE

On 7/2/15 9:15 AM, Etsuro Fujita wrote: > While working on the foreign-join-pushdown issue, I noticed that in READ > COMMITTED isolation level it's possible that the result of SELECT ... > ORDER BY ... FOR UPDATE is not sorted correctly due to concurrent > updates that replaced the sort key columns

Re: [HACKERS] Asynchronous execution on FDW

Thank you. At Thu, 2 Jul 2015 16:02:27 +0900, Michael Paquier wrote in > On Thu, Jul 2, 2015 at 3:07 PM, Kyotaro HORIGUCHI > wrote: > > Ouch! I mistakenly made two CF entries for this patch. Could > > someone remove this entry for me? > > > > https://commitfest.postgresql.org/5/290/ > > > > Th

Re: [HACKERS] pg_basebackup and replication slots

On Wed, Jul 1, 2015 at 11:35 PM, Peter Eisentraut wrote: > On 7/1/15 8:37 AM, Michael Paquier wrote: >> On Wed, Jul 1, 2015 at 10:33 AM, Peter Eisentraut wrote: >>> (If you're looking at the patch and wondering why there is no code to >>> actually do anything with the replication slot, that's beca

Re: [HACKERS] Odd behaviour of SELECT ... ORDER BY ... FOR UPDATE

Hi Marko, On 2015/07/02 16:27, Marko Tiikkaja wrote: > On 7/2/15 9:15 AM, Etsuro Fujita wrote: >> While working on the foreign-join-pushdown issue, I noticed that in READ >> COMMITTED isolation level it's possible that the result of SELECT ... >> ORDER BY ... FOR UPDATE is not sorted correctly due

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 07/01/2015 09:19 PM, Peter Geoghegan wrote: On Wed, Jul 1, 2015 at 10:45 AM, Peter Geoghegan wrote: On Tue, Jun 30, 2015 at 11:19 AM, Heikki Linnakangas wrote: I agree it would be cleaner to have a separate CHECK_UNIQUE_XXX code for speculative insertions. You've defined CHECK_UNIQUE_SPECU

[HACKERS] 9.6 First Commitfest Begins

Hello everyone! It is time to start reviewing patches: 1. Pick a patch from the list at: https://commitfest.postgresql.org/5/ 2. Review it. Test it. Try to break it. Do we want the feature? Any weird interactions in corner-cases? 3. Reply on the thread on pgsql-hackers with your findings. I

Re: [HACKERS] Support for N synchronous standby servers - take 2

Hello, There has been a lot of discussion. It has become a bit confusing. I am summarizing my understanding of the discussion till now. Kindly let me know if I missed anything important. Backward compatibility: We have to provide support for the current format and behavior for synchronous replica

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

On 05/29/2015 10:41 AM, Pavel Stehule wrote: 2015-05-29 9:28 GMT+02:00 Jeevan Chalke : I agree with Peter that "We don't tab-complete everything we possibly could", but using tabs after "SET ROLE TO " provides "DEFAULT" as an option which seems wrong. This patch adds list of roles over there, w

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hi Fujita-san, Sorry for my late. > On 2015/06/27 21:09, Kouhei Kaigai wrote: > >>> BTW, if you try newer version of postgres_fdw foreign join patch, > >>> please provide me to reproduce the problem/ > > >> OK > > > Did you forget to attach the patch, or v17 is in use? > > Sorry, I made a mist

Re: [HACKERS] Patch to improve a few appendStringInfo* calls

On 06/15/2015 03:56 AM, David Rowley wrote: On 29 May 2015 at 12:51, Peter Eisentraut wrote: On 5/12/15 4:33 AM, David Rowley wrote: Shortly after I sent the previous patch I did a few more searches and also found some more things that are not quite right. Most of these are to use the binary

Re: [HACKERS] Patch to improve a few appendStringInfo* calls

On 2 July 2015 at 21:59, Heikki Linnakangas wrote: > Applied the straightforward parts. Thanks for committing. > I left out the changes like > > - appendStringInfoString(&collist, buf.data); >> + appendBinaryStringInfo(&collist, buf.data, buf.len); >> > > because

Re: [HACKERS] Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?

On 13 May 2015 at 09:35, Heikki Linnakangas wrote: > In summary, the X^1.5 correction seems to work pretty well. It doesn't > completely eliminate the problem, but it makes it a lot better. > Agreed > I don't want to over-compensate for the full-page-write effect either, > because there are a

Re: [HACKERS] raw output from copy

On 1 July 2015 at 07:42, Pavel Golub wrote: > I looked through the patch. Sources are OK. However I didn't find any > docs and test cases. Would you please provide me with short description on > this feature and why it is important. Because I didn't manage to find the > old Andrew Dunstan's post

[HACKERS] pg_archivecleanup, and backup filename to specify as an argument

Hi, While I'm implementing the patch around pg_archivecleanup, I found the following warning about pg_archivecleanup in the document. Note that the .backup file name passed to the program should not include the extension. ISTM that pg_archivecleanup works as expected even if the .backup file

Re: [HACKERS] Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?

On Thu, Jul 2, 2015 at 4:16 PM, Simon Riggs wrote: > On 13 May 2015 at 09:35, Heikki Linnakangas wrote: > > >> In summary, the X^1.5 correction seems to work pretty well. It doesn't >> completely eliminate the problem, but it makes it a lot better. >> > > Agreed > Do we want to consider if wal_

Re: [HACKERS] raw output from copy

Hi I'll do it today evening Pavel 2015-07-02 12:55 GMT+02:00 Simon Riggs : > On 1 July 2015 at 07:42, Pavel Golub wrote: > > >> I looked through the patch. Sources are OK. However I didn't find any >> docs and test cases. Would you please provide me with short description on >> this feature an

Re: [HACKERS] Memory Accounting v11

On 14 June 2015 at 23:51, Tomas Vondra wrote: > The current state, where HashAgg just blows up the memory, is just not >>> reasonable, and we need to track the memory to fix that problem. >>> >> >> Meh. HashAgg could track its memory usage without loading the entire >> system with a penalty. >>

Re: [HACKERS] psql tabcomplete - minor bugfix - tabcomplete for SET ROLE TO xxx

2015-07-02 11:03 GMT+02:00 Heikki Linnakangas : > On 05/29/2015 10:41 AM, Pavel Stehule wrote: > >> 2015-05-29 9:28 GMT+02:00 Jeevan Chalke : >> >> I agree with Peter that "We don't tab-complete everything we possibly >>> could", but using tabs after "SET ROLE TO " provides "DEFAULT" as an >>> op

Re: [HACKERS] PATCH: remove nclients/nthreads constraint from pgbench

On 05/08/2015 03:02 PM, Fabien COELHO wrote: Remove pgbench constraint that the number of clients must be a multiple of the number of threads, by sharing clients among threads as evenly as possible. Rational: allows to test the database load with any number of client without unrelated constrain

Re: [HACKERS] WAL-related tools and .paritial WAL file

On Thu, Jul 2, 2015 at 3:48 PM, Michael Paquier wrote: > On Thu, Jul 2, 2015 at 2:06 PM, Fujii Masao wrote: >> I implemented the patch accordingly. Patch attached. > > Cool, thanks. > > I have done some tests with pg_archivecleanup, and it works as > expected, aka if I define a backup file, the ba

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

Hi KaiGai-san, On 2015/07/02 18:31, Kouhei Kaigai wrote: Even though I'd like to see committer's opinion, I could not come up with the idea better than what you proposed; foreign-/custom-scan has alternative plan if scanrelid==0. I'd also like to hear the opinion! Let me introduce a few case

Re: [HACKERS] WAL-related tools and .paritial WAL file

On Thu, Jul 2, 2015 at 8:42 PM, Fujii Masao wrote: >> 3) Something not caused by this patch that I just noticed... But >> pg_resetxlog does not remove .backup files in pg_xlog. Shouldn't they >> get moved away as well? > > pg_resetxlog doesn't remove also .history file in pg_xlog. Those remaining >

Re: [HACKERS] Support for N synchronous standby servers - take 2

On Thu, Jul 2, 2015 at 5:44 PM, Beena Emerson wrote: > Hello, > There has been a lot of discussion. It has become a bit confusing. > I am summarizing my understanding of the discussion till now. > Kindly let me know if I missed anything important. > > Backward compatibility: > We have to provide s

Re: [HACKERS] PATCH: remove nclients/nthreads constraint from pgbench

This doesn't behave correctly if you set -j to greater than -c, and also use the rate limit option: [...] I think that can be fixed by just setting nthreads internally to nclients, if nthreads > nclients. But please double-check that the logic used to calculate throttle_delay makes sense in

Re: [HACKERS] raw output from copy

On 07/02/2015 07:14 AM, Pavel Stehule wrote: Hi I'll do it today evening Pavel, Please don't top-post on the PostgreSQL lists. You've been around here long enough to know that bottom posting is our custom. I posted a patch for this in 2013 at

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On 06/27/2015 07:45 AM, Amit Kapila wrote: Sometime back on one of the PostgreSQL blog [1], there was discussion about the performance of drop/truncate table for large values of shared_buffers and it seems that as the value of shared_buffers increase the performance of drop/truncate table becomes

Re: [HACKERS] raw output from copy

On 07/02/2015 09:02 AM, Andrew Dunstan wrote: On 07/02/2015 07:14 AM, Pavel Stehule wrote: Hi I'll do it today evening Pavel, Please don't top-post on the PostgreSQL lists. You've been around here long enough to know that bottom posting is our custom. I posted a patch for this in 2013

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On 2015-07-02 16:08:03 +0300, Heikki Linnakangas wrote: > I'm marking this as "returned with feedback" in the commitfest. In addition > to the issues raised so far, ISTM that the patch makes dropping a very large > table with small shared_buffers slower (DropForkSpecificBuffers() is O(n) > where n

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On Thu, Jul 2, 2015 at 6:38 PM, Heikki Linnakangas wrote: > > On 06/27/2015 07:45 AM, Amit Kapila wrote: >> >> Sometime back on one of the PostgreSQL blog [1], there was >> discussion about the performance of drop/truncate table for >> large values of shared_buffers and it seems that as the value

Re: [HACKERS] WALWriter active during recovery

On Thu, Mar 5, 2015 at 5:22 PM, Fujii Masao wrote: > On Thu, Dec 18, 2014 at 6:43 PM, Fujii Masao wrote: >> On Tue, Dec 16, 2014 at 3:51 AM, Simon Riggs wrote: >>> Currently, WALReceiver writes and fsyncs data it receives. Clearly, >>> while we are waiting for an fsync we aren't doing any other

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On 2 July 2015 at 14:08, Heikki Linnakangas wrote: > On 06/27/2015 07:45 AM, Amit Kapila wrote: > >> Sometime back on one of the PostgreSQL blog [1], there was >> discussion about the performance of drop/truncate table for >> large values of shared_buffers and it seems that as the value >> of sha

Re: [HACKERS] WALWriter active during recovery

On 2 July 2015 at 14:31, Fujii Masao wrote: > On Thu, Mar 5, 2015 at 5:22 PM, Fujii Masao wrote: > > On Thu, Dec 18, 2014 at 6:43 PM, Fujii Masao > wrote: > >> On Tue, Dec 16, 2014 at 3:51 AM, Simon Riggs > wrote: > >>> Currently, WALReceiver writes and fsyncs data it receives. Clearly, > >>>

[HACKERS] Reducing the size of BufferTag & remodeling forks

Hi, I've complained a number of times that our BufferTag is ridiculously large: typedef struct buftag { RelFileNode rnode; /* physical relation identifier */ ForkNumber forkNum; BlockNumber blockNum; /* blknum relative to begin of reln */ } BufferTag; typedef struct Re

Re: [HACKERS] WALWriter active during recovery

On 2015-07-02 14:34:48 +0100, Simon Riggs wrote: > This was pushed back from last CF and I haven't worked on it at all, nor > will I. > > Pushing back again. Let's "return with feedback", not " move", it then.. Moving a entries along which aren't expected to receive updates anytime soon isn't a g

Re: [HACKERS] raw output from copy

On 2 July 2015 at 14:02, Andrew Dunstan wrote: > > Please don't top-post on the PostgreSQL lists. You've been around here > long enough to know that bottom posting is our custom. > > I posted a patch for this in 2013 at < > http://www.postgresql.org/message-id/50f2fa92.9040...@dunslane.net> but >

Re: [HACKERS] Patch to improve a few appendStringInfo* calls

David Rowley wrote: > On 2 July 2015 at 21:59, Heikki Linnakangas wrote: > > > I left out the changes like > > > > - appendStringInfoString(&collist, buf.data); > >> + appendBinaryStringInfo(&collist, buf.data, buf.len); > >> > > > > because they're not an improvement

Re: [HACKERS] WALWriter active during recovery

On 2 July 2015 at 14:38, Andres Freund wrote: > On 2015-07-02 14:34:48 +0100, Simon Riggs wrote: > > This was pushed back from last CF and I haven't worked on it at all, nor > > will I. > > > > Pushing back again. > > Let's "return with feedback", not " move", it then.. Moving a entries > along w

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2 July 2015 at 09:44, Beena Emerson wrote: > I am not sure how combining both will work out. > Use cases needed. > Catalog Method: > Is it safe to assume we may not going ahead with the Catalog approach? > Yes -- Simon Riggshttp://www.2ndQuadrant.com/

Re: [HACKERS] Reducing the size of BufferTag & remodeling forks

Andres Freund writes: > 1) Introduce a shared pg_relfilenode table. Every table, even >shared/nailed ones, get an entry therein. It's there to make it >possibly to uniquely allocate relfilenodes across databases & >tablespaces. > 2) Replace relation forks, with the exception of the ini

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On 07/02/2015 04:18 PM, Amit Kapila wrote: On Thu, Jul 2, 2015 at 6:38 PM, Heikki Linnakangas wrote: On 06/27/2015 07:45 AM, Amit Kapila wrote: Sometime back on one of the PostgreSQL blog [1], there was discussion about the performance of drop/truncate table for large values of shared_buffer

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On 07/02/2015 04:33 PM, Simon Riggs wrote: On 2 July 2015 at 14:08, Heikki Linnakangas wrote: On 06/27/2015 07:45 AM, Amit Kapila wrote: Sometime back on one of the PostgreSQL blog [1], there was discussion about the performance of drop/truncate table for large values of shared_buffers and i

Re: [HACKERS] raw output from copy

On 07/02/2015 09:43 AM, Simon Riggs wrote: On 2 July 2015 at 14:02, Andrew Dunstan > wrote: Please don't top-post on the PostgreSQL lists. You've been around here long enough to know that bottom posting is our custom. I posted a patch for this in 2013 a

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

Hello, >Unless I am missing something, I guess you can still keep the actual code that >updates counters outside the core if you adopt an approach that Simon suggests. Yes. The code to extract progress information from VACUUM and storing in shared memory can be outside core even with pg_stat_act

Re: [HACKERS] raw output from copy

2015-07-02 15:43 GMT+02:00 Simon Riggs : > On 2 July 2015 at 14:02, Andrew Dunstan wrote: > >> >> Please don't top-post on the PostgreSQL lists. You've been around here >> long enough to know that bottom posting is our custom. >> >> I posted a patch for this in 2013 at < >> http://www.postgresql.

Re: [HACKERS] Reducing the size of BufferTag & remodeling forks

On 2015-07-02 09:51:59 -0400, Tom Lane wrote: > Andres Freund writes: > > 1) Introduce a shared pg_relfilenode table. Every table, even > >shared/nailed ones, get an entry therein. It's there to make it > >possibly to uniquely allocate relfilenodes across databases & > >tablespaces. >

Re: [HACKERS] raw output from copy

2015-07-02 16:02 GMT+02:00 Andrew Dunstan : > > On 07/02/2015 09:43 AM, Simon Riggs wrote: > >> On 2 July 2015 at 14:02, Andrew Dunstan > and...@dunslane.net>> wrote: >> >> >> Please don't top-post on the PostgreSQL lists. You've been around >> here long enough to know that bottom posting

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

On Thu, Jul 2, 2015 at 7:27 PM, Heikki Linnakangas wrote: > > On 07/02/2015 04:18 PM, Amit Kapila wrote: >> >> >> Don't you think the approach discussed (delayed cleanup of buffers >> during checkpoint scan) is sufficient to fix the issues raised. > > > Dunno, but there is no patch for that. > Th

Re: [HACKERS] drop/truncate table sucks for large values of shared buffers

Simon Riggs writes: > On 2 July 2015 at 14:08, Heikki Linnakangas wrote: >> I'm marking this as "returned with feedback" in the commitfest. > There are no unresolved issues with the approach, nor is it true it is > slower. If you think there are some, you should say what they are, not act > high

Re: [HACKERS] [BUGS] BUG #13126: table constraint loses its comment

On 2015-05-27 15:10, Michael Paquier wrote: On Wed, Apr 29, 2015 at 1:30 PM, Michael Paquier wrote: On Sun, Apr 26, 2015 at 6:05 AM, Tom Lane wrote: x...@resolvent.net writes: In some circumstances, the comment on a table constraint disappears. Here is an example: Hm, yeah. The problem i

Re: [HACKERS] Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file

Amit Kapila wrote: > On Sat, Jun 27, 2015 at 12:54 AM, Robert Haas wrote: > > > > On Mon, Jun 15, 2015 at 2:52 PM, Amit Kapila > > wrote: > > > Attached patch provides a fix as per above discussion. > > > > I think we should emit some LOG messages here. When we detect the > > file is there: > >

Re: [HACKERS] Foreign join pushdown vs EvalPlanQual

> > Let me introduce a few cases we should pay attention. > > > > Foreign/CustomScan node may stack; that means a Foreign/CustomScan node > > may have child node that includes another Foreign/CustomScan node with > > scanrelid==0. > > (At this moment, ForeignScan cannot have child node, however, mo

Re: [HACKERS] raw output from copy

On 2 July 2015 at 15:07, Pavel Stehule wrote: > It can be used from psql without any problems. > It can, but your patch does not yet do that, while Andrew's does. We want a solution that works from psql and other clients. Hopefully the same-ish solution. -- Simon Riggshttp://

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

"Syed, Rahila" writes: > Hello, >> Unless I am missing something, I guess you can still keep the actual code >> that updates counters outside the core if you adopt an approach that Simon >> suggests. > Yes. The code to extract progress information from VACUUM and storing in > shared memory can

Re: [HACKERS] raw output from copy

On 07/02/2015 10:07 AM, Pavel Stehule wrote: 2015-07-02 16:02 GMT+02:00 Andrew Dunstan >: On 07/02/2015 09:43 AM, Simon Riggs wrote: On 2 July 2015 at 14:02, Andrew Dunstan mailto:and...@dunslane.net>

Re: [HACKERS] raw output from copy

Andrew Dunstan writes: > Does the COPY line protocol even support binary data? The protocol, per se, just transmits a byte stream. There is a field in the CopyInResponse/CopyOutResponse messages that indicates whether a text or binary copy is being done. One thing we'd have to consider is wheth

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Jul 2, 2015 at 1:06 AM, Fujii Masao wrote: > On Thu, Jul 2, 2015 at 12:13 AM, Sawada Masahiko > wrote: >> On Thu, May 28, 2015 at 11:34 AM, Sawada Masahiko >> wrote: >>> On Thu, Apr 30, 2015 at 8:07 PM, Sawada Masahiko >>> wrote: On Fri, Apr 24, 2015 at 11:21 AM, Sawada Masahiko

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On 6/10/15 2:17 AM, Magnus Hagander wrote: > AIUI that one was just about the DN field, and not about the rest. If I > understand you correctly, you are referring to the whole thing, not just > one field? I think at least the DN field shouldn't be visible to unprivileged users. Actually, I think

Re: [HACKERS] raw output from copy

On 07/02/2015 11:02 AM, Tom Lane wrote: Andrew Dunstan writes: Does the COPY line protocol even support binary data? The protocol, per se, just transmits a byte stream. There is a field in the CopyInResponse/CopyOutResponse messages that indicates whether a text or binary copy is being done.

Re: [HACKERS] Raising our compiler requirements for 9.6

On Wed, Jul 1, 2015 at 6:24 PM, Andres Freund wrote: > On 2015-07-02 00:15:14 +0200, Andres Freund wrote: >> animal OS compiler inline quiet inline >>varargs > >> brolga cygwin gcc-4.3 yy > > 4.3 obviously supports

Re: [HACKERS] Rework the way multixact truncations work

On Mon, Jun 29, 2015 at 3:48 PM, Andres Freund wrote: > New version attached. 0002 looks good, but the commit message should perhaps mention the comment fix. Or commit that separately. Will look at 0003 next. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL C

Re: [HACKERS] Raising our compiler requirements for 9.6

On 2015-07-02 11:46:25 -0400, Robert Haas wrote: > In the case of static inline, the main problem with the status quo > AFAICS is that you have to do a little dance any time you'd otherwise > use a static inline function (for those following along at home, "git > grep INCLUDE_DEFINITIONS src/includ

Re: [HACKERS] Raising our compiler requirements for 9.6

Robert Haas writes: > So far this thread is all about the costs of desupporting compilers > that don't have these features, and you're making a good argument > (that I think we all agree with) that the cost is small. But you > haven't really said what the benefits are. I made the same remark wit

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 5/30/15 10:14 PM, Andreas Karlsson wrote: > I have written a patch which makes it possible to change SSL > certificates (and other SSL parameters, including the CRL) without > restarting PostgreSQL. In fact this patch also makes it possible to turn > on or off ssl entirely without restart. It do

Re: [HACKERS] Fix autoconf deprecation warnings

On 05/31/2015 05:22 AM, Andreas Karlsson wrote: I have attached new versions which apply on the current master. Thanks, applied. --- a/configure.in +++ b/configure.in @@ -1473,7 +1473,7 @@ if test x"$pgac_cv_func_sigsetjmp" = x"yes"; then AC_DEFINE(HAVE_SIGSETJMP, 1, [Define to 1 if you ha

Re: [HACKERS] Freeze avoidance of very large table.

On 2 July 2015 at 16:30, Sawada Masahiko wrote: > Also, the flags of each heap page header might be set PD_ALL_FROZEN, > as well as all-visible > Is it possible to have VM bits set to frozen but not visible? The description makes those two states sound independent of each other. Are they? Or

Re: [HACKERS] Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested Looks functionally complete Need a test to show that ALTER TABLE works on vi

Re: [HACKERS] Configurable location for extension .control files

On 03/04/2015 09:41 AM, Oskari Saarenmaa wrote: 18.02.2015, 01:49, Jim Nasby kirjoitti: On 2/17/15 4:39 PM, Oskari Saarenmaa wrote: 10.06.2013, 17:51, Dimitri Fontaine kirjoitti: Andres Freund writes: In any case, no packager is going to ship an insecure-by-default configuration, which is wh

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Thu, Jul 2, 2015 at 1:30 AM, Heikki Linnakangas wrote: >> Sure, if a speculative inserter detects a conflict, it still has to >> wait. But not in the aminsert call, and not until it cleans up its >> physical insertion (by super-deleting). Clearly a >> CHECK_UNIQUE_SPECULATIVE would have to be m

Re: [HACKERS] Rework the way multixact truncations work

On Thu, Jul 2, 2015 at 11:52 AM, Robert Haas wrote: > Will look at 0003 next. +appendStringInfo(buf, "offsets [%u, %u), members [%u, %u)", I don't think we typically use this style for notating intervals. case XLOG_MULTIXACT_CREATE_ID: id = "CREATE_ID";

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 07/01/2015 11:12 PM, Fujii Masao wrote: > I don't think this is good approach because there can be the case where > you need to promote even the standby server not having sync flag. > Please imagine the case where you have sync and async standby servers. > When the master goes down, the async st

Re: [HACKERS] Memory leak fixes for pg_dump, pg_dumpall, initdb and pg_upgrade

On 06/08/2015 09:48 AM, Michael Paquier wrote: Hi all, Please find attached a set of fixes for a couple of things in src/bin: - pg_dump/pg_dumpall: -- getFormattedTypeName, convertTSFunction and myFormatType return strdup'd results that are never free'd. -- convertTSFunction returns const char.

Re: [HACKERS] Reducing ClogControlLock contention

On Wed, Jul 1, 2015 at 6:21 AM, Andres Freund wrote: > On 2015-07-01 11:19:40 +0100, Simon Riggs wrote: >> What "tricks" are being used?? >> >> Please explain why taking 2 locks is bad here, yet works fine elsewhere. > > I didn't say anything about 'bad'. It's more complicated than one > lock. Sud

Re: [HACKERS] Time to fully remove heap_formtuple() and friends?

On 06/13/2015 07:10 AM, Peter Geoghegan wrote: On Fri, Jun 12, 2015 at 8:47 PM, Tom Lane wrote: Peter Geoghegan writes: Attached patch actually removes heap_formtuple() and friends. Does this seem worthwhile? Seems reasonable, but at this point I would say this is 9.6 material; third-party-

[HACKERS] [PATCH v1] GSSAPI encryption support

Hello -hackers, As previously discussed on this list, I have coded up GSSAPI encryption support. If it is easier for anyone, this code is also available for viewing on my github: https://github.com/postgres/postgres/compare/master...frozencemetery:feature/gssencrypt Fallback support is present i

Re: [HACKERS] Rework the way multixact truncations work

On 2015-07-02 13:58:45 -0400, Robert Haas wrote: > On Thu, Jul 2, 2015 at 11:52 AM, Robert Haas wrote: > > Will look at 0003 next. > > +appendStringInfo(buf, "offsets [%u, %u), members [%u, %u)", > > I don't think we typically use this style for notating intervals. I don't think we real

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-02 11:10:27 -0700, Josh Berkus wrote: > If we're always going to be polling the replicas for furthest ahead, > then why bother implementing quorum synch at all? That's the basic > question I'm asking. What does it buy us that we don't already have? What do those topic have to do with e

Re: [HACKERS] Memory Accounting v11

On 14 June 2015 at 23:51, Tomas Vondra wrote: > The current state, where HashAgg just blows up the memory, is just not >>> reasonable, and we need to track the memory to fix that problem. >>> >> >> Meh. HashAgg could track its memory usage without loading the entire >> system with a penalty. >>

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 07/02/2015 11:31 AM, Andres Freund wrote: > On 2015-07-02 11:10:27 -0700, Josh Berkus wrote: >> If we're always going to be polling the replicas for furthest ahead, >> then why bother implementing quorum synch at all? That's the basic >> question I'm asking. What does it buy us that we don't al

[HACKERS] Improve testing notes?

Hackers: I've added the following section to "how to beta test": https://wiki.postgresql.org/wiki/HowToBetaTest#Particular_Things_to_Test_in_9.5 It would be great if other folks could add particular things they'd like to see users test, so that we can make the alpha/beta cycle as fast and fruitf

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut wrote: > On 6/10/15 2:17 AM, Magnus Hagander wrote: > > AIUI that one was just about the DN field, and not about the rest. If I > > understand you correctly, you are referring to the whole thing, not just > > one field? > > I think at least the DN

Re: [HACKERS] Improve testing notes?

On Thu, Jul 2, 2015 at 11:52 AM, Josh Berkus wrote: > I've added the following section to "how to beta test": > > https://wiki.postgresql.org/wiki/HowToBetaTest#Particular_Things_to_Test_in_9.5 > > It would be great if other folks could add particular things they'd like > to see users test, so tha

[HACKERS] Add checksums without --initdb

So on #postgresql, I was musing about methods of getting checksums enabled/disabled without requiring a separate initdb step and minimizing the downtime required to get such functionality enabled. What about adapting pg_basebackup to add the following options: -k|--checksums - build the replica

Re: [HACKERS] Faster setup_param_list() in plpgsql

I wrote: > What this patch does is to remove setup_param_list() overhead for the > common case of PLPGSQL_DTYPE_VAR variables (ie, any non-composite type). > It does that by the expedient of keeping the ParamExternData image of such > a variable valid at all times. That adds a few cycles to assign

Re: [HACKERS] Support for N synchronous standby servers - take 2

On 2015-07-02 11:50:44 -0700, Josh Berkus wrote: > So there's two parts to this: > > 1. I need to ensure that data is replicated to X places. > > 2. I need to *know* which places data was synchronously replicated to > when the master goes down. > > My entire point is that (1) alone is useless un

Re: [HACKERS] Add checksums without --initdb

On 07/02/2015 12:39 PM, David Christensen wrote: > So on #postgresql, I was musing about methods of getting checksums > enabled/disabled without requiring a separate initdb step and minimizing the > downtime required to get such functionality enabled. Funny, I was thinking just yesterday about h

Re: [HACKERS] Information of pg_stat_ssl visible to all users

Magnus Hagander wrote: > On Thu, Jul 2, 2015 at 5:40 PM, Peter Eisentraut wrote: > > Actually, I think the whole view shouldn't be accessible to unprivileged > > users, except maybe your own row. > > > I could go for some of the others if we think there's reason, but I don't > understand the dn p

Re: [HACKERS] Add checksums without --initdb

On 07/02/2015 10:39 PM, David Christensen wrote: Possible concerns here are whether checksums are included in WAL full_page_writes or if they are independently calculated; if the latter I think we’d be fine. If checksums are all handled at the layer below WAL than any streamed/processed changes

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On 2015-07-02 16:52:01 -0300, Alvaro Herrera wrote: > If there's interest in closing these holes, this might be a first I don't think such an isolated attempt buys us anything except maybe unsatisfied users. I can see a benefit in allowing to restrict information about users and such in other clu

Re: [HACKERS] Add checksums without --initdb

On 2015-07-02 22:53:40 +0300, Heikki Linnakangas wrote: > On 07/02/2015 10:39 PM, David Christensen wrote: > >Possible concerns here are whether checksums are included in WAL > >full_page_writes or if they are independently calculated; if the > >latter I think we’d be fine. If checksums are all ha

Re: [HACKERS] Configurable location for extension .control files

02.07.2015, 20:31, Heikki Linnakangas kirjoitti: > On 03/04/2015 09:41 AM, Oskari Saarenmaa wrote: >> 18.02.2015, 01:49, Jim Nasby kirjoitti: >>> On 2/17/15 4:39 PM, Oskari Saarenmaa wrote: Here's a patch to allow overriding extension installation directory. The patch allows superusers to

Re: [HACKERS] [PATCH] two-arg current_setting() with fallback

Jeevan Chalke writes: > Attached patch which fixes my review comments. Applied with minor adjustments (mostly cosmetic, but did neither of you notice the compiler warning?) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Add checksums without --initdb

On 07/02/2015 11:28 PM, Andres Freund wrote: On 2015-07-02 22:53:40 +0300, Heikki Linnakangas wrote: Add a "enabling-checksums" mode to the server where it calculates checksums for anything it writes, but doesn't check or complain about incorrect checksums on reads. Put the server into that mode

Re: [HACKERS] Add checksums without --initdb

On 2015-07-02 23:43:17 +0300, Heikki Linnakangas wrote: > >You'd need, afaics, a bgworker that connects to every database to read > >pg_class, to figure out what type of page a relfilenode has. And this > >probably should call back into the relevant AM or such. > > Nah, we already assume that ever

Re: [HACKERS] PATCH:do not set Win32 server-side socket buffer size on windows 2012

On 04/10/2015 01:46 PM, chenhj wrote: PostgreSQL set Win32 server-side socket buffer size to 32k since 2006, for performance reasons. While,on the newer version of Windows,such as windows 2012,the default socket buffer size is 64k, and seem has better performance(high throughput). So, i propos

Re: [HACKERS] Information of pg_stat_ssl visible to all users

On Thu, Jul 2, 2015 at 10:06 PM, Andres Freund wrote: > On 2015-07-02 16:52:01 -0300, Alvaro Herrera wrote: > > If there's interest in closing these holes, this might be a first > > I don't think such an isolated attempt buys us anything except maybe > unsatisfied users. > > I can see a benefit i

Re: [HACKERS] Exposing PG_VERSION_NUM in pg_config

Michael Paquier writes: > On Wed, Mar 25, 2015 at 8:26 AM, Tom Lane wrote: > ... So attached is a patch that adds VERSION_NUM in > Makefile.global. While there was not exactly universal consensus that we need this, the patch as given is merely two lines, so it seems awfully cheap to Just Do It.

  1   2   >