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 t

[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 try on the animals whe

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. > > Ok, here is a new version that exits the streaming loop corr

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 patch. Sorry to have overlooked some > > versions. I'm looking the v19 patch now. > > > > make complains for an unused variabl

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

On 15 March 2016 at 04:48, Andres Freund wrote: > On 2016-01-31 05:09:33 +0800, Craig Ringer wrote: > > On 29 January 2016 at 18:16, Andres Freund wrote: > > > > > Hi, > > > > > > so, I'm reviewing the output of: > > > > > > > Thankyou very much for the review. > > Afaics you've not posted an up

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 at 5:50 PM, Kyotaro HORIGUCHI >> wrote: >> > Thank you for the new patch. Sorry to have overlooked some >> > versions. I'm l

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

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 patch. > > > At Tue, 22 Mar 2016 12:57:27 -0400, David Steele > wrote in <56f17977.8040...@pgmasters.net> > > Hi Kyotaro, >

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 not abort if the fsync fails

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 should be perfectly safe. And

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 should work yeah. And given that we already use tha

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 > On Tue, Mar 29, 2016 at 4:23 PM, Kyo

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 *RelationAddExtraBlocks* { -- Add Block

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 ? > > > > Isn't it still true that ICU fails

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 comparison would yie

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 EnterpriseDB, and > his conclusion was that I

[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

[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 on my Windows 10 system.

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 mailto:horiguchi.kyot...@lab.ntt.co.jp>>: Thank you Pavel, David. Thank you for pointing syntaxes to be addressed. Most of the are addressed in the attached patch. At Tue, 22 Mar 2016 12:

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 > > > > respect upper or lower chars. It enforce upper chars. This is not > > > > consi

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 think that it would be better to >> use PG_INT64_MIN and PG_INT64_MAX

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 > > > > respect upper or lower chars

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 Stehule wrote: > > > > > > > > >

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 libi

[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 dat

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 wro

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: http://www.postgresql.org/docs/devel/static/functio

[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] [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] [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 in

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 implementations define pthread_t >

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 things nicely. The pre

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 a

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] 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 f

[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, that explains things ni

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 rev

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 wh

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 for a range of >> eleve

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 "p

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 _dosmaperr(), too, rather th

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 mailto:da...@pgmasters.net>> 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 request on > that.

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. If there actually is

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 li

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 p

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 pg_SSPI

Re: [HACKERS] multivariate statistics v14

Hi Tomas, On 3/28/16 4:42 AM, Tomas Vondra wrote: Yes, those are valid omissions. I plan to address them, and I'd also considering adding a section to 65.1 (How the Planner Uses Statistics), explaining more thoroughly how the planner uses multivariate stats. It looks you need post a new patch

Re: [HACKERS] WIP: Access method extendability

On 3/28/16 1:26 PM, Alvaro Herrera wrote: Alexander Korotkov wrote: On Thu, Mar 24, 2016 at 6:19 PM, Alvaro Herrera wrote: .. Oh crap. I just noticed I forgot to update a comment in pg_dump's getAccessMethods. And we're missing psql tab-complete support for the new commands. Attached patc

Re: [HACKERS] WIP: Access method extendability

On Tue, Mar 29, 2016 at 6:20 PM, David Steele wrote: > On 3/28/16 1:26 PM, Alvaro Herrera wrote: > >> Alexander Korotkov wrote: >> >>> On Thu, Mar 24, 2016 at 6:19 PM, Alvaro Herrera < >>> alvhe...@2ndquadrant.com> >>> wrote: >>> >>> .. Oh crap. I just noticed I forgot to update a comment in pg_

Re: [HACKERS] Sequence Access Method WIP

Hi Petr, On 3/28/16 3:11 PM, Fabrízio de Royes Mello wrote: fabrizio@bagual:~/pgsql $ bin/pg_dump > /tmp/fabrizio.sql pg_dump: [archiver (db)] query failed: ERROR: column "sequence_name" does not exist LINE 1: SELECT sequence_name, start_value, increment_by, CASE WHEN i... ^ pg

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

On 29/03/16 03:06, Robert Haas wrote: On Sun, Mar 27, 2016 at 10:35 PM, Michael Paquier wrote: On Fri, Mar 25, 2016 at 9:48 PM, Andrew Dunstan wrote: OK, sounds good. Just a side-note. Andres has pushed the fix for the GinIs* macros as af4472bc, making patch 0003 from the last series useles

Re: [HACKERS] WIP: Access method extendability

Does that mean this patch should be closed or is there more remaining to commit? Petr promises to check english in comments/docs in generic-wal patch at this week, bloom patch depends on it. Bloom patch is ready from my point of view. -- Teodor Sigaev E-mai

Re: [HACKERS] 2016-03 Commitfest

The 2016-03 commitfest is nearly over! There are still a number of patches in need of review and a few that still have no reviewer (https://commitfest.postgresql.org/9/?status=1&reviewer=-2). Needs review: 28 (was 55 last week) Needs *reviewer*: 4 (was 12 last week) If you are signed up to r

Re: [HACKERS] raw output from copy

Hi 2016-03-29 0:26 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > [ copy-raw-format-20160227-03.patch ] > > I looked at this patch. I'm having a hard time accepting that it has > a use-case large enough to justify it, and here's the reason: it's > a protocol break. Conveniently omitting to u

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

On Tue, Mar 29, 2016 at 11:31 AM, Petr Jelinek wrote: > I have machine ready, waiting for animal name and secret. Great! > It will obviously > fail until we push the 0002 and 0004 though. I think it would be a shame if we shipped 9.6 without MSVC 2015 support, but it'd be nice if Andrew or Magn

Re: [HACKERS] More stable query plans via more predictable column statistics

On Tue, Mar 15, 2016 at 4:47 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Wed, Mar 9, 2016 at 5:28 PM, Tom Lane wrote: > >> "Shulgin, Oleksandr" writes: >> > Yes, I now recall that my actual concern was that sample_cnt may >> calculate >> > to 0 due to the latest condition

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

Christian Ullrich writes: > 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 > FormatMessa

Re: [HACKERS] WIP: Access method extendability

On 29/03/16 17:33, Teodor Sigaev wrote: Does that mean this patch should be closed or is there more remaining to commit? Petr promises to check english in comments/docs in generic-wal patch at this week, bloom patch depends on it. Bloom patch is ready from my point of view. And here it is. I

Re: [HACKERS] pthread portability

Alvaro Herrera wrote: > Michael McConville wrote: > > 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 i

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

On Mon, Mar 28, 2016 at 11:18 PM, Peter Geoghegan wrote: > Note that amcheck V2, which I posted just now features tests for > external sorting. The way these work requires discussion. The tests > are motivated in part by the recent strxfrm() debacle, as well as by > the need to have at least some

Re: [HACKERS] extend pgbench expressions with functions

On Mon, Mar 28, 2016 at 9:36 PM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> On Tue, Mar 29, 2016 at 9:54 AM, Robert Haas wrote: >> > On Sun, Mar 27, 2016 at 5:01 AM, Fabien COELHO wrote: >> >> v40 is yet another rebase. >> > >> > Thanks. Committed after remov

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

David Steele wrote: > On 3/29/16 10:18 AM, Tom Lane wrote: > >Repurposing COMMERROR is definitely starting to seem like a low-impact > >solution compared to these others. Under what circumstances would you > >be wanting hide-from-client with an elevel different from LOG, anyway? > > In pgaudit t

Re: [HACKERS] WIP: Access method extendability

And here it is. It's not perfect but it's better (I am not native speaker either). It's same as v12, just changed comments somewhat. Thank you, but I have a problems with applying: % patch -p1 < ~/Downloads/0002-generic-xlog.13.patch Hmm... Looks like a new-style context diff to me... ... |dif

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

On 3/29/16 11:37 AM, Alvaro Herrera wrote: David Steele wrote: On 3/29/16 10:18 AM, Tom Lane wrote: Repurposing COMMERROR is definitely starting to seem like a low-impact solution compared to these others. Under what circumstances would you be wanting hide-from-client with an elevel differen

Re: [HACKERS] unexpected result from to_tsvector

On Sun, Mar 20, 2016 at 3:42 PM, Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > On Mar 20, 2016 01:09, "Dmitrii Golub" wrote: > >> Alex, actually subdomain can start with digit, > > > Not according to the RFC you have linked to. > > The powers-that-be relaxed that some time ago; I assume th

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

On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote: > 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_

Re: [HACKERS] Some messages of pg_rewind --debug not getting translated

Michael Paquier wrote: > On Tue, Mar 29, 2016 at 2:45 AM, Alvaro Herrera > wrote: > > If you're interesting in improving translatability of this program > > further, I suggest that messages of this sort > > msgid "BKPBLOCK_HAS_DATA set, but no data included at %X/%X" > > should have a %s instea

Re: [HACKERS] raw output from copy

Pavel Stehule writes: > I tested COPY RAW on old psql clients - and it is working without any > problem - so when the client uses same logic as psql, then it should to > work. Sure, there can be differently implemented clients, but the COPY > client side is usually simple - store stream to output.

Re: [HACKERS] extend pgbench expressions with functions

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. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.post

Re: [HACKERS] More stable query plans via more predictable column statistics

"Shulgin, Oleksandr" writes: > I've just seen that this patch doesn't have a reviewer assigned anymore... I took my name off it because I was busy with other things and didn't want to discourage other people from reviewing it meanwhile. I do hope to get to it eventually but there's a lot of stuf

Re: [HACKERS] WIP: Access method extendability

Petr Jelinek wrote: > And here it is. It's not perfect but it's better (I am not native speaker > either). It's same as v12, just changed comments somewhat. I think this can still be improved a bit more, in particular this large comment, which I edit inline for expediency. > + /*

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

Alvaro Herrera writes: > David Steele wrote: >> On 3/29/16 10:18 AM, Tom Lane wrote: >>> Repurposing COMMERROR is definitely starting to seem like a low-impact >>> solution compared to these others. Under what circumstances would you >>> be wanting hide-from-client with an elevel different from L

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

On 3/29/16 12:28 PM, Tom Lane wrote: Alvaro Herrera writes: David Steele wrote: On 3/29/16 10:18 AM, Tom Lane wrote: Repurposing COMMERROR is definitely starting to seem like a low-impact solution compared to these others. Under what circumstances would you be wanting hide-from-client with a

Re: [HACKERS] More stable query plans via more predictable column statistics

On Tue, Mar 29, 2016 at 6:24 PM, Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > I've just seen that this patch doesn't have a reviewer assigned > anymore... > > I took my name off it because I was busy with other things and didn't > want to discourage other people from reviewing it meanwhile

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

On 2016-03-29 12:28:40 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > David Steele wrote: > >> On 3/29/16 10:18 AM, Tom Lane wrote: > >>> Repurposing COMMERROR is definitely starting to seem like a low-impact > >>> solution compared to these others. Under what circumstances would you > >>> b

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Tue, Mar 15, 2016 at 4:44 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane wrote: > >> "Shulgin, Oleksandr" writes: >> > What I dislike about this POC is all the disruption in libpq, to be >> > honest. >> >> Yeah, I don't much like that

Re: [HACKERS] PoC: Partial sort

On Tue, Mar 29, 2016 at 4:56 PM, David Steele wrote: > 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 >

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

On 2016-03-29 18:33:19 +0200, Andres Freund wrote: > A couple years back I proposed making thinks like COMERROR into flags | > ed into elevel, rather than distinct levels. I still think that's a > better approach; and it doesn't force us to forgo using distinct log > levels. http://archives.postg

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

Andres Freund writes: > On 2016-03-29 12:28:40 -0400, Tom Lane wrote: >> My proposal would be to invent a new elevel macro, maybe LOG_ONLY, >> for this purpose. But under the hood it'd be the same as COMMERROR. > A couple years back I proposed making thinks like COMERROR into flags | > ed into e

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

On Tue, Mar 29, 2016 at 4:36 PM, David Steele wrote: > 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 probl

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

On 2016-03-29 12:38:48 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-03-29 12:28:40 -0400, Tom Lane wrote: > If we invent LOG_ONLY (feel free to bikeshed the name), we could later > redefine it as (LOG | ERR_HIDE_FROM_CLIENT), if we ever upgrade the > underlying implementation to allo

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

[This is a rather informal user-review] Here are some thoughts and experiences on using the new features, I focused on testing the basic funcionality of setting password_encryption to scram and then generating some users with passwords. After that, I took a look at the documentation, s

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

On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-03-29 12:28:40 -0400, Tom Lane wrote: >>> My proposal would be to invent a new elevel macro, maybe LOG_ONLY, >>> for this purpose. But under the hood it'd be the same as COMMERROR. > >> A couple years back I pro

Re: [HACKERS] WIP: Access method extendability

On 29/03/16 18:25, Alvaro Herrera wrote: + /*- >+ * API for construction of generic xlog records >+ * >+ * This API allows user to construct generic xlog records which describe >+ * difference between pages in a generic w

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

Robert Haas wrote: > Yeah, I think it's dead certain that such code exists, and, ahem, not > only in our tree. I suspect that EDB is not the only organization > that has written code that involves comparing error levels. Putting > the flags in the low-order bits seems like it might be workable,

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

Robert Haas writes: > On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane wrote: >> If we invent LOG_ONLY (feel free to bikeshed the name), we could later >> redefine it as (LOG | ERR_HIDE_FROM_CLIENT), if we ever upgrade the >> underlying implementation to allow that. But I remain concerned about >> dea

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

On Tue, Mar 29, 2016 at 3:17 AM, Michael Paquier wrote: > OK, so I am switching this patch as "Ready for committer", for 0001. > It is in better shape now. Well... I have a few questions yet. The new argument to SyncRepWaitForLSN is called "bool commit", but RecordTransactionAbortPrepared passe

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

On Tue, Mar 29, 2016 at 12:58 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Mar 29, 2016 at 12:38 PM, Tom Lane wrote: >>> If we invent LOG_ONLY (feel free to bikeshed the name), we could later >>> redefine it as (LOG | ERR_HIDE_FROM_CLIENT), if we ever upgrade the >>> underlying implement

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

On 2016-03-29 12:58:22 -0400, Tom Lane wrote: > Looking back at the earlier thread Andres mentioned, I see that he was > specifically on about being able to do ereport(ERROR | LOG_NO_CLIENT), > which I've got a problem with because of the point about not breaking > wire-protocol expectations. Yes.

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Mon, Mar 28, 2016 at 9:09 AM, Andres Freund wrote: > On 2016-03-28 11:48:46 +0530, Dilip Kumar wrote: >> On Sun, Mar 27, 2016 at 5:48 PM, Andres Freund wrote: >> > What's sizeof(BufferDesc) after applying these patches? It should better >> > be <= 64... >> > >> >> It is 72. > > Ah yes, miscalc

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

Andres Freund writes: > There's a number of cases during early startup/auth where we really > don't want client to get messages. Right, which we handle at present with ClientAuthInProgress. But I think it's worth drawing a distinction between "don't send message to client because of the state we

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-29 13:09:05 -0400, Robert Haas wrote: > On Mon, Mar 28, 2016 at 9:09 AM, Andres Freund wrote: > > On 2016-03-28 11:48:46 +0530, Dilip Kumar wrote: > >> On Sun, Mar 27, 2016 at 5:48 PM, Andres Freund wrote: > >> > What's sizeof(BufferDesc) after applying these patches? It should better

[HACKERS] Pg-Logical output pkg; can't install 9.4 and 9.5 on same Wheezy box

Hackers, please see below. Posted on Admin and then General but not sure anyone of authority has noticed. Briefly, conflicting files in an include directory prevent 9.4/9.5 installed on same host instance. Thanks - Posted to Admin a few days ago... I'll try here next before going to Hac

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

Andres Freund writes: > 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 defined(__ppc__) typedef from an int to a char. AFAICS, lwarx/stwcx are specifically *word* wide.

Re: [HACKERS] Reworks of CustomScan serialization/deserialization

On Mon, Mar 28, 2016 at 11:00 PM, Kouhei Kaigai wrote: >> -Original Message- >> From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas >> Sent: Tuesday, March 29, 2016 10:54 AM >> To: Kaigai Kouhei(海外 浩平) >> Cc: Petr Jelinek; pgsql-

Re: [HACKERS] raw output from copy

Hi 2016-03-29 18:19 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > I tested COPY RAW on old psql clients - and it is working without any > > problem - so when the client uses same logic as psql, then it should to > > work. Sure, there can be differently implemented clients, but the COPY > > cl

Re: [HACKERS] WIP: Access method extendability

I incorporated your changes and did some additional refinements on top of them still. Attached is delta against v12, that should cause less issues when merging for Teodor. But last version is 13th? BTW, it would be cool to add odcs in VII. Internals chapter, description should be similar to i

Re: [HACKERS] Relation extension scalability

On Tue, Mar 29, 2016 at 2:09 PM, Dilip Kumar wrote: > > Attaching new version v18 - Some cleanup work on v17. - Improved *UpdateFreeSpaceMap *function. - Performance and space utilization are same as V17 -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com multi_extend_v18.pat

Re: [HACKERS] WIP: Access method extendability

On 29/03/16 19:29, Teodor Sigaev wrote: I incorporated your changes and did some additional refinements on top of them still. Attached is delta against v12, that should cause less issues when merging for Teodor. But last version is 13th? No, 12 is last version from Alexander afaics, I named

Re: [HACKERS] WIP: Access method extendability

On Tue, Mar 29, 2016 at 8:29 PM, Teodor Sigaev wrote: > I incorporated your changes and did some additional refinements on top of >> them >> still. >> >> Attached is delta against v12, that should cause less issues when merging >> for >> Teodor. >> > > But last version is 13th? > > BTW, it would

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On 2016-03-29 13:24:40 -0400, Tom Lane wrote: > Andres Freund writes: > > 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 defined(__ppc__) typedef from an int to a char. > > AFAICS, lwarx/stw

  1   2   >