Re: [HACKERS] backup tools ought to ensure created backups are durable

On Tue, Mar 29, 2016 at 10:12 AM, Andres Freund wrote: > On 2016-03-29 10:06:20 +0200, Magnus Hagander wrote: > > On Tue, Mar 29, 2016 at 8:46 AM, Jim Nasby > wrote: > > > > > On 3/28/16 11:03 AM, Magnus Hagander wrote: > > > > > >> > > >> That

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

On Tue, Mar 29, 2016 at 4:23 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Mon, 28 Mar 2016 18:38:22 +0900, Masahiko Sawada > wrote in > sawada.mshk> On Mon, Mar 28, 2016

Re: [HACKERS] Draft release notes for next week's releases

On Mon, Mar 28, 2016 at 6:08 PM, Robert Haas wrote: > On Mon, Mar 28, 2016 at 10:24 AM, Tom Lane wrote: > > I'm also not exactly convinced by your implicit assumption that ICU is > > bug-free. > > Noah spent some time looking at ICU back when he was

[HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

* Tom Lane wrote: Christian Ullrich writes: zic aborts somewhere between writing Etc/UTC and UTC. Huh ... I would not have guessed that. Can you track down exactly where it's failing? I'd love to, but with 656ee84 I cannot reproduce on my Windows 10 system. I can

Re: [HACKERS] Odd system-column handling in postgres_fdw join pushdown patch

On 2016/03/25 17:16, Etsuro Fujita wrote: The approach that we discussed would minimize the code for the FDW author to write, by providing the support functions you proposed. I'll post a patch for that early next week. I added two helper functions: GetFdwScanTupleExtraData and

Re: [HACKERS] Alter or rename enum value

On 3/28/16 4:42 AM, Emre Hasegeli wrote: Now, we are using a function to replace an enum type on all tables with another one, but we are not at all happy with this solution. It requires all objects which were using the enum to be dropped and recreated, and it rewrites the tables, so it greatly

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

Hello, At Mon, 28 Mar 2016 18:38:22 +0900, Masahiko Sawada wrote in sawada.mshk> On Mon, Mar 28, 2016 at 5:50 PM, Kyotaro HORIGUCHI > wrote: > > Thank you for the new

Re: [HACKERS] backup tools ought to ensure created backups are durable

On Tue, Mar 29, 2016 at 8:46 AM, Jim Nasby wrote: > On 3/28/16 11:03 AM, Magnus Hagander wrote: > >> >> That should work yeah. And given that we already use that check in other >> places, it seems it should be perfectly safe. And as long as we only do >> a WARNING and

Re: [HACKERS] backup tools ought to ensure created backups are durable

On 2016-03-29 10:06:20 +0200, Magnus Hagander wrote: > On Tue, Mar 29, 2016 at 8:46 AM, Jim Nasby wrote: > > > On 3/28/16 11:03 AM, Magnus Hagander wrote: > > > >> > >> That should work yeah. And given that we already use that check in other > >> places, it seems it

Re: [HACKERS] Relation extension scalability

On Tue, Mar 29, 2016 at 7:26 AM, Robert Haas wrote: > Well, it's less important in that case, but I think it's still worth > doing. Some people are going to do just plain GetPageWithFreeSpace(). > I am attaching new version v17. Its like this... In

Re: [HACKERS] Dealing with collation and strcoll/strxfrm/etc

On Mon, Mar 28, 2016 at 5:57 PM, Stephen Frost wrote: > All, > > Changed the thread name (we're no longer talking about release > notes...). > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Oleg Bartunov writes: > > > Should we start thinking about ICU ? >

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Tue, Mar 29, 2016 at 1:11 PM, Thomas Munro wrote: > On Tue, Mar 29, 2016 at 2:28 AM, Michael Paquier > wrote: >> I definitely prefer that, that's neater! libpq_select could be >> simplified because a timeout does not matter much. > >

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

I personally don't think it needs such a survive measure. It is very small syntax and the parser reads very short text. If the parser failes in such mode, something more serious should have occurred. At Tue, 29 Mar 2016 16:51:02 +0900, Fujii Masao wrote in

Re: [HACKERS] Draft release notes for next week's releases

On Mon, Mar 28, 2016 at 1:36 PM, Thomas Kellerer wrote: > Oleg Bartunov-2 wrote > > But still, icu provides us abbreviated keys and collation stability, > > Does include ICU mean that collation handling is identical across > platforms? > E.g. a query on Linux involving string

Re: [HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

On Mon, Mar 28, 2016 at 10:09 PM, Tom Lane wrote: > Christian Ullrich writes: >> * Tom Lane wrote: >>> Yeah. I've been staring at that for awhile, but it's not clear where >>> the problem is. There are a bunch of other SET TIME ZONE commands in >>> the

Re: [HACKERS] backup tools ought to ensure created backups are durable

On 3/28/16 11:03 AM, Magnus Hagander wrote: That should work yeah. And given that we already use that check in other places, it seems it should be perfectly safe. And as long as we only do a WARNING and not abort if the fsync fails, we should be OK if people intentionally store their backups on

Re: [HACKERS] pthread portability

## Alvaro Herrera (alvhe...@2ndquadrant.com): > > The below diff fixes one problem: you can't compare pthread_t values > > directly. Only the function pthread_equal(3) is defined. Direct > > comparison usually works because most implementations define pthread_t > > as an integer type. > > So is

[HACKERS] pg_largeobject

Hi pg_largeobject is creating performance issues as it grow due to single point storage(for all tables) is there any alternate apart from bytea ? like configuration large-object-table at table-column level and oid PK(primary key) stored at pg_largeobject Thanks Sridhar

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Hi, thank you for the suggestion. At Tue, 29 Mar 2016 12:54:01 +0300, Artur Zakirov wrote in <56fa50b9.7000...@postgrespro.ru> > On 29.03.2016 10:59, Pavel Stehule wrote: > > > > I am looking this patch. It looks well, but this feature doesn't > > > >

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

2016-03-29 12:08 GMT+02:00 Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp>: > Hi, Pavel. > > At Tue, 29 Mar 2016 09:59:01 +0200, Pavel Stehule > wrote in < > cafj8prdepggymz2axgtl33pud7x+xieao++wa+v9nqpqiyd...@mail.gmail.com> > > > > On 3/18/16 3:22 AM, Pavel

Re: [HACKERS] [COMMITTERS] pgsql: pgbench: Support double constants and functions.

On Tue, Mar 29, 2016 at 12:56 AM, Tom Lane wrote: > Michael Paquier writes: >> On Tue, Mar 29, 2016 at 9:52 AM, Robert Haas wrote: >>> pgbench: Support double constants and functions. > >> Instead of INT64_MIN and INT64_MAX, I

[HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

* Christian Ullrich wrote: * Tom Lane wrote: Christian Ullrich writes: zic aborts somewhere between writing Etc/UTC and UTC. Huh ... I would not have guessed that. Can you track down exactly where it's failing? I'd love to, but with 656ee84 I cannot reproduce

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

On 29.03.2016 10:59, Pavel Stehule wrote: Hi 2016-03-29 8:43 GMT+02:00 Kyotaro HORIGUCHI >: Thank you Pavel, David. Thank you for pointing syntaxes to be addressed. Most of the are addressed in the attached

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Hi, Pavel. At Tue, 29 Mar 2016 09:59:01 +0200, Pavel Stehule wrote in > > > On 3/18/16 3:22 AM, Pavel Stehule wrote: > > > > > > > I am looking this patch. It looks well, but this feature doesn't >

[HACKERS] in drop database, auto-vacuum and immediate shutdown concurrency scene, hot-standby server redo FATAL

hi all, I found that hot-standby server redo coredumped when the master do a concurrency test in drop database, auto-vacuum and immediate shutdown scene. Amm...the test steps as follow: 1. execute select txid_current() to force the auto vacuum launch frequenctly 2. in another session drop the

Re: [HACKERS] Draft release notes for next week's releases

Does include ICU mean that collation handling is identical across platforms? E.g. a query on Linux involving string comparison would yield the same result on MacOS and Windows? Yes, it does and that's the most important issue for us. Yes, exactly. Attached patch adds support for

Re: [HACKERS] Performance degradation in commit 6150a1b0

Hi, I am unable to revert 6150a1b0 on top of recent commit in the master branch. It seems like there has been some commit made recently that has got dependency on 6150a1b0. With Regards, Ashutosh Sharma EnterpriseDB: http://www.enterprisedb.com On Sun, Mar 27, 2016 at 5:45 PM, Andres Freund

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

Hi Robbie, On 3/20/16 12:09 AM, Robbie Harwood wrote: A new version of my GSSAPI encryption patchset is available Here's a more thorough review: * PATCH - Move common GSSAPI code into its own files diff --git a/src/backend/libpq/be-gssapi-common.c + if (msg_ctx) + + /*

Re: [HACKERS] snapshot too old, configured by time

Hi Kevin, On 3/21/16 4:05 PM, Kevin Grittner wrote: Thanks to all for the feedback; I will try to respond later this week. First I'm trying to get my reviews for other patches posted. We're getting to the end of the CF now. Do you know when you'll have an updated patch ready? Thanks, --

Re: [HACKERS] [PATCH] Supporting +-Infinity values by to_timestamp(float8)

17.03.2016 06:27, Vitaly Burovoy: On 2016-03-15, David Steele wrote: On 3/4/16 2:56 PM, Vitaly Burovoy wrote: On 3/4/16, Anastasia Lubennikova wrote: I think that you should update documentation. At least description of epoch on this page:

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/28/16 2:00 PM, Tom Lane wrote: I set to work on committing this, but was soon rather dissatisfied with it, because as-implemented there is no way to short-circuit elog.c's processing if the message is not to be sent to either the client or the postmaster log. Ideally this would be taken

Re: [HACKERS] pthread portability

Christoph Moench-Tegeder writes: > ## Alvaro Herrera (alvhe...@2ndquadrant.com): >>> The below diff fixes one problem: you can't compare pthread_t values >>> directly. Only the function pthread_equal(3) is defined. Direct >>> comparison usually works because most

Re: [HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

Christian Ullrich writes: > Anyway, I think Michael's fix is wrong. The bug is that the Win32 > version of link() (at the bottom of zic.c) does not set errno if its > attempt to copy the file fails, so what dolink() puts into link_errno is > bogus. Ah-hah, that explains

Re: [HACKERS] improving GROUP BY estimation

Hi Thomas, On 3/22/16 10:40 AM, Alexander Korotkov wrote: I think you should send a revision of patch including comments proposed by Deam Rasheed. I'm switching patch status to waiting on author in commitfest. We're getting pretty close to the end of the CF. Do you know when you will have

Re: [HACKERS] POC, WIP: OR-clause support for indexes

On 3/25/16 11:13 AM, David Steele wrote: Time is growing short and there seem to be some serious concerns with this patch. Can you provide a new patch soon? If not, I think it might be be time to mark this "returned with feedback". I have marked this patch "returned with feedback". Please

[HACKERS] [PATCH] Improve safety of FormatMessage() calls on Windows

There are some instances of calls to FormatMessage() with the FORMAT_MESSAGE_FROM_SYSTEM flag that omit the FORMAT_MESSAGE_IGNORE_INSERTS flag. The effect of that is that if the requested message string contains any insertion markers, the call to FormatMessage() will fail because none of these

Re: [HACKERS] Please correct/improve wiki page about abbreviated keys bug

On Tue, Mar 29, 2016 at 5:31 PM, Josh berkus wrote: > For Thursday's release, I've added a wiki page to give users more > information about the strxfrm() issue, especially since we're going to > ask them to do a bunch of REINDEXing. I made a pass over this, and changed some

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On 3/29/16 2:09 PM, Magnus Hagander wrote: > I had a chat with Heikki, and here's another suggestion: > > 1. We don't touch the current exclusive backups at all, as previously > discussed, other than deprecating their use. For backwards compat. > > 2. For new backups, we return the contents of

Re: [HACKERS] extend pgbench expressions with functions

On Wed, Mar 30, 2016 at 1:23 AM, Fabien COELHO wrote: > > Hello Robert, > >>> If we don't nuke it, it'll never die. >> >> >> Hearing no objections, BOOM. > > > FIZZ! :-) > > Thanks for the commits, and apology for the portability bugs. Thanks for the additions, Fabien. This

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Wed, Mar 30, 2016 at 12:45 AM, Robert Haas wrote: > On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote: >> I have machine ready, waiting for animal name and secret. > > Great! Nice. Thanks. >> It will obviously >> fail until we push the 0002

Re: [HACKERS] Using quicksort for every external sort run

On Tue, Mar 29, 2016 at 12:43 PM, Peter Geoghegan wrote: > A complete do-over from Tomas would be best, here. He has already > acknowledged that the i5 CREATE INDEX results were completely invalid. The following analysis is all based on Xeon numbers, which as I've said we should

Re: [BUGS] Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

Alvaro Herrera writes: > Tom Lane wrote: >> Anyway, as things stand, elog(ERROR) will abort the session safely but >> you won't necessarily get the kind of logging you want, so expected >> auth-failure cases should try to go the STATUS_ERROR route. > In other words, the

Re: [HACKERS] [COMMITTERS] pgsql: Allow to_timestamp(float8) to convert float infinity to timestam

Michael Paquier writes: > On Wed, Mar 30, 2016 at 6:09 AM, Tom Lane wrote: >> Allow to_timestamp(float8) to convert float infinity to timestamp infinity. > Some of the tests introduced are making MSVC unhappy, because they > depend on the

[HACKERS] Re: [COMMITTERS] pgsql: Allow to_timestamp(float8) to convert float infinity to timestam

On Wed, Mar 30, 2016 at 10:13 AM, Tom Lane wrote: > Michael Paquier writes: >> On Wed, Mar 30, 2016 at 6:09 AM, Tom Lane wrote: >>> Allow to_timestamp(float8) to convert float infinity to timestamp infinity. > >> Some of the

Re: [HACKERS] Relation extension scalability

On Tue, Mar 29, 2016 at 1:29 PM, Dilip Kumar wrote: > Attaching new version v18 > > - Some cleanup work on v17. > - Improved UpdateFreeSpaceMap function. > - Performance and space utilization are same as V17 Looks better. Here's a v19 that I hacked on a bit.

[HACKERS] Re: [COMMITTERS] pgsql: Allow to_timestamp(float8) to convert float infinity to timestam

On Wed, Mar 30, 2016 at 10:47 AM, Tom Lane wrote: > Michael Paquier writes: >> On Wed, Mar 30, 2016 at 10:13 AM, Tom Lane wrote: >>> I'm inclined to just drop the out-of-range test cases. They're not that >>> useful IMO, and

Re: [HACKERS] Using quicksort for every external sort run

Hi, On 03/29/2016 09:43 PM, Peter Geoghegan wrote: On Tue, Mar 29, 2016 at 9:11 AM, Robert Haas wrote: One test that kind of bothers me in particular is the "SELECT DISTINCT a FROM numeric_test ORDER BY a" test on the high_cardinality_random data set. That's a wash at

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/29/2016 08:48 PM, Michael Paquier wrote: On Wed, Mar 30, 2016 at 12:45 AM, Robert Haas wrote: On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote: I have machine ready, waiting for animal name and secret. Great! Nice. Thanks. It will

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan wrote: > I am currently travelling, but my intention is to deal with the remaining > patches when I'm back home this weekend, unless someone beats me to it. Cool. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Tue, Mar 29, 2016 at 5:47 PM, Thomas Munro wrote: > On Wed, Mar 30, 2016 at 6:04 AM, Robert Haas wrote: >> On Tue, Mar 29, 2016 at 3:17 AM, Michael Paquier >> wrote: >>> OK, so I am switching this patch as

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Tue, Mar 29, 2016 at 10:43 PM, Andres Freund wrote: > My gut feeling is that we should do both 1) and 2). > > Dilip, could you test performance of reducing ppc's spinlock to 1 byte? > Cross-compiling suggest that doing so "just works". I.e. replace the > #if

Re: [HACKERS] [COMMITTERS] pgsql: Allow to_timestamp(float8) to convert float infinity to timestam

Michael Paquier writes: > On Wed, Mar 30, 2016 at 10:13 AM, Tom Lane wrote: >> I'm inclined to just drop the out-of-range test cases. They're not that >> useful IMO, and alternate expected-files are a real PITA for maintenance. > Hm. Actually,

Re: [HACKERS] pgbench stats per script & other stuff

Hello, In doing this, I noticed that the latency output is wrong if you use -T instead of -t; it always says the latency is zero because "duration" is zero. I suppose it should be like in the attached instead. Indeed, I clearly overlooked option -t (transactions) which I never use. Patch

Re: [HACKERS] raw output from copy

2016-03-29 20:59 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > I am writing few lines as summary: > > > 1. invention RAW_TEXT and RAW_BINARY > > 2. for RAW_BINARY: PQbinaryTuples() returns 1 and PQfformat() returns 1 > > 3.a for RAW_TEXT:

Re: [HACKERS] Parallel Queries and PostGIS

On Mon, Mar 28, 2016 at 12:18 PM, Paul Ramsey wrote: > I spent some time over the weekend trying out the different modes of > parallel query (seq scan, aggregate, join) in combination with PostGIS > and have written up the results here: > >

Re: [HACKERS] Sequence Access Method WIP

On Tue, Mar 29, 2016 at 4:59 PM, Petr Jelinek wrote: > > On 29/03/16 19:46, Fabrízio de Royes Mello wrotez >> >> >> > >> > Hmm I am unable to reproduce this. What OS? Any special configure >> flags you use? >> > >> >> In my environment the error remains with your last

Re: [HACKERS] Parallel Queries and PostGIS

On Tue, Mar 29, 2016 at 3:48 PM, Paul Ramsey wrote: >> I have no idea why the cost adjustments that you need are different >> for the scan case and the aggregate case. That does seem problematic, >> but I just don't know why it's happening. > > What might be a good way

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

No one should care of this but to make shure.. At Tue, 29 Mar 2016 20:12:03 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160329.201203.78219296.horiguchi.kyot...@lab.ntt.co.jp> > By the way, memory blocks that readline sees are freed by it but >

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 3/29/16 10:18 AM, Tom Lane wrote: David Steele writes: On 3/28/16 2:00 PM, Tom Lane wrote: One idea is to invent a new elevel which is never sent to the client --- analogously to COMMERROR, though probably much higher priority than that, maybe the same priority as LOG.

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

Hi Amit, On 3/22/16 3:37 AM, Michael Paquier wrote: Hope this brings some light in. Do you know when you'll have time to respond to Michael's last email? I've marked this patch "waiting on author" in the meantime. Thanks, -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing

Re: [HACKERS] Speedup twophase transactions

Hi Stas, On 3/22/16 9:20 AM, Michael Paquier wrote: Not taking ProcArrayLock here? The comment at the top of XlogReadTwoPhaseData is incorrect. RecoverPreparedFromXLOG and RecoverPreparedFromFiles have a lot of code in common, having this duplication is not good, and you could simplify your

Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

On 3/24/16 5:22 PM, Alvaro Herrera wrote: Christian Ullrich wrote: To be honest, I'm not sure what can and cannot be done in auth code. I took inspiration from the existing SSPI code and nearly every error check in pg_SSPI_recvauth() ends up doing ereport(ERROR) already, directly or via

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

2016-03-30 5:43 GMT+02:00 Kyotaro HORIGUCHI : > Hello, > > At Tue, 29 Mar 2016 13:12:06 +0200, Pavel Stehule > wrote in

Re: [HACKERS] OOM in libpq and infinite loop with getCopyStart()

On Tue, Mar 29, 2016 at 8:31 PM, David Steele wrote: > Hi Amit, > > On 3/22/16 3:37 AM, Michael Paquier wrote: > > Hope this brings some light in. >> > > Do you know when you'll have time to respond to Michael's last email? I've > marked this patch "waiting on author" in the

Re: [HACKERS] multivariate statistics v14

>> with statistics without statistics >> case10.980.01 >> case298/01/0 > > The case2 shows that functional dependencies assume that the > conditions used in queries won't be incompatible - that's something > this type of statistics can't fix. It would

Re: [HACKERS] Postgres_fdw join pushdown - INNER - FULL OUTER join combination generating wrong result

> Observation:_ Inner join and full outer join combination on a table >> >> generating wrong result. >> >> SELECT * FROM lt; >> c1 >> >>1 >>2 >> (2 rows) >> >> SELECT * FROM ft; >> c1 >> >>1 >>2 >> (2 rows) >> >> \d+ ft >> Foreign table

[HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

* Tom Lane wrote: Christian Ullrich writes: Anyway, I think Michael's fix is wrong. The bug is that the Win32 version of link() (at the bottom of zic.c) does not set errno if its attempt to copy the file fails, so what dolink() puts into link_errno is bogus. Ah-hah,

Re: [HACKERS] PoC: Partial sort

Hi Alexander, On 3/23/16 8:39 PM, Peter Geoghegan wrote: This looks like an old change you missed: - * compare_path_fractional_costs + * compare_fractional_path_costs All in all, this looks significantly better. Thanks for your work on this. Sorry for the delay in my response, and that my

Re: [HACKERS] dealing with extension dependencies that aren't quite 'e'

Hi Abhijit, On 3/25/16 1:57 PM, Abhijit Menon-Sen wrote: Complete patch attached for reference, as before. (I know I haven't documented the function. I will go through the code to see if there are any other potential callers, but I wanted to share what I had already.) I'm not entirely sure

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

David Steele writes: > On 3/28/16 2:00 PM, Tom Lane wrote: >> One idea is to invent a new elevel which is never sent to the client --- >> analogously to COMMERROR, though probably much higher priority than that, >> maybe the same priority as LOG. If there actually is a use

Re: [HACKERS] Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.

Christian Ullrich writes: > * Tom Lane wrote: >> But then, should not this code make sure that errno *always* gets set? > A library function that does not fail does not touch errno. Right, I meant "always in the error path". >> I'd be inclined to think we should use

Re: [HACKERS] Updated backup APIs for non-exclusive backups

On 3/22/16 12:31 PM, Magnus Hagander wrote: On Tue, Mar 22, 2016 at 5:27 PM, David Steele > wrote: > > Adding the stop time column should be a simple addition and I don't see > a problem with that. I think I misunderstood your original

Re: [HACKERS] Relation extension scalability

On Wed, Mar 30, 2016 at 7:19 AM, Robert Haas wrote: Thanks for review and better comments.. > hio.c: In function ‘RelationGetBufferForTuple’: > hio.c:231:20: error: ‘freespace’ may be used uninitialized in this > function [-Werror=uninitialized] > hio.c:185:7: note:

Re: [HACKERS] Please correct/improve wiki page about abbreviated keys bug

Peter Geoghegan writes: > I made a pass over this, and changed some things. I noticed it said > something about incorrect unique violations on affected systems. Is > that really possible? A corrupt index could easily fail to detect uniqueness violations (because searches fail to

Re: [HACKERS] Combining Aggregates

On 26 March 2016 at 15:07, David Rowley wrote: Many thanks Robert for committing the serialize states portion. > 0005: > Haribabu's patch; no change from last time. Just in case you jump ahead. I just wanted to re-highlight something Haribabu mentioned a while ago

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Hello, At Tue, 29 Mar 2016 13:12:06 +0200, Pavel Stehule wrote in

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

Hello friends, A new version of my GSSAPI encryption patchset is available, both in this email and on my github: https://github.com/frozencemetery/postgres/tree/feature/gssencrypt9 This version is intended to address David's review suggestions: - The only code change (not counting SGML and

Re: [HACKERS] Please correct/improve wiki page about abbreviated keys bug

On Tue, Mar 29, 2016 at 7:31 PM, Tom Lane wrote: > A corrupt index could easily fail to detect uniqueness violations (because > searches fail to find entries they should find). Not sure I believe that > it would make false reports of a uniqueness conflict that's not really >

Re: [HACKERS] Using quicksort for every external sort run

On Tue, Mar 29, 2016 at 6:02 PM, Tomas Vondra wrote: > And why not? I mean, why should it be acceptable to slow down? My point was that over 80% of execution time was spent in the HashAggregate, which outputs tuples to the sort. That, and the huge i5/Xeon

Re: [HACKERS] Relation extension scalability

On Wed, Mar 30, 2016 at 7:51 AM, Dilip Kumar wrote: > + if (lockWaiters) > + /* > + * Here we are using same freespace for all the Blocks, but that > + * is Ok, because all are newly added blocks and have same freespace > + * And even some block which we just added to

Re: [HACKERS] Please correct/improve wiki page about abbreviated keys bug

Peter Geoghegan writes: > Do you think it would be okay if the SQL query to detect potentially > affected indexes only considered the leading attribute? Since that's > the only attribute that could use abbreviated keys, it ought to be > safe to not require users to REINDEX

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

Thank you for polishing this. At Tue, 29 Mar 2016 13:31:19 -0500, Kevin Grittner wrote in > I tried to whip this into shape, but there were a few areas I > didn't feel I had the necessary understanding to

Re: [HACKERS] Sequence Access Method WIP

On Tue, Mar 29, 2016 at 5:58 PM, Petr Jelinek wrote: > > On 29/03/16 22:08, Fabrízio de Royes Mello wrote: >> >> >> >> On Tue, Mar 29, 2016 at 4:59 PM, Petr Jelinek > > wrote: >> > >> > On 29/03/16 19:46, Fabrízio de

<    1   2