Re: [HACKERS] Proposal: RETURNING primary_key()

Igal, thanks for the analysis. Craig>Part of the question for Pg is what exactly we should and should not be returning. I think the following might be a good starting point: return set of columns that would identify the inserted row(s). E.g. columns of any primary key would do. Columns of any uni

Re: [HACKERS] The plan for FDW-based sharding

I have read the recent comments on this thread with great interest. I am glad people have expressed their concerns, rather than remain silent. Now that the responses have decreased, I can reply. I saw several concerns: 1. My motivation for starting this thread was to decrease interest in extern

[HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

Hi all I think I found a couple of logical decoding issues while writing tests for failover slots. Despite the docs' claim that a logical slot will replay data "exactly once", a slot's confirmed_lsn can go backwards and the SQL functions can replay the same data more than once.We don't mark a slo

Re: [HACKERS] The plan for FDW-based sharding

On 11 March 2016 at 16:09, Bruce Momjian wrote: > Ideally everything would have a well-defined plan, it is > sometimes hard to do. BDR helped for logical decoding etc - having something concrete really helped shape and guide each part of it as it was (or is/will be, in some cases) migrated fr

Re: [HACKERS] WAL logging problem in 9.4.3?

Hello, I considered on the original issue. At Fri, 19 Feb 2016 22:27:00 +0900, Michael Paquier wrote in > > Worth noting that this patch does not address the problem with index > > relations when a TRUNCATE is used in the same transaction as its Focusing this issue, what we should do is someho

Re: [HACKERS] The plan for FDW-based sharding

On Fri, Mar 11, 2016 at 04:30:13PM +0800, Craig Ringer wrote: > ... eventually. > > Sometimes the bug reports start. Occasionally you get a "thanks, this looks > interesting/handy". But usually just bug reports or complaints that whatever > you built isn't good enough to meet some random person's

Re: [HACKERS] Refectoring of receivelog.c

> On 15 Feb 2016, at 14:46, Magnus Hagander wrote: > > On Mon, Feb 15, 2016 at 7:15 AM, Craig Ringer > wrote: > On 15 February 2016 at 04:48, Magnus Hagander > wrote: > I was working on adding the tar streaming functionality we talked ab

Re: [HACKERS] Proposal: RETURNING primary_key()

On 11 March 2016 at 16:00, Vladimir Sitnikov wrote: > Igal, thanks for the analysis. > > Craig>Part of the question for Pg is what exactly we should and should > not be returning. > > I think the following might be a good starting point: return set of > columns that would identify the inserted ro

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 11 March 2016 at 08:19, Craig Ringer wrote: > Hi all > > I think I found a couple of logical decoding issues while writing tests > for failover slots. > > Despite the docs' claim that a logical slot will replay data "exactly > once", a slot's confirmed_lsn can go backwards and the SQL function

Re: [HACKERS] The plan for FDW-based sharding

On Fri, Mar 11, 2016 at 9:09 AM, Bruce Momjian wrote: > > > > 3. I have tried to encourage others to get involved, with limited > success. I do think the FDW is perhaps the only reasonable way to get > _built-in_ sharding. The external sharding solutions are certainly > viable, but external.

Re: [HACKERS] Improving replay of XLOG_BTREE_VACUUM records

On 10 March 2016 at 11:38, Simon Riggs wrote: > On 10 March 2016 at 09:22, Michael Paquier > wrote: > >> On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin >> wrote: >> > Let’s do immediately after you will send a new version of your patch? Or >> > even better after testing your patch? Don’t ge

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

On Thu, Mar 10, 2016 at 9:05 PM, Tom Lane wrote: > Gilles Darold writes: > > Then, should I have to use an alternate file to store the information or > > implement a bidirectional communication with the syslogger? > > I'd just define a new single-purpose file $PGDATA/log_file_name > or some such

Re: [HACKERS] Explain [Analyze] produces parallel scan for select Into table statements.

On Thu, Mar 10, 2016 at 9:39 PM, Robert Haas wrote: >I guess there must not be an occurrence of this pattern in the >regression tests, or previous force_parallel_mode testing would have >found this problem. Perhaps this patch should add one? I have added the test to select_into.sql. Added Explai

Re: [HACKERS] Endless loop calling PL/Python set returning functions

Alexey Grishchenko wrote: > Tom Lane wrote: > >> Alexey Grishchenko writes: >> > No, my fix handles this well. >> > In fact, with the first function call you allocate global variables >> > representing Python function input parameters, call the function and >> > receive iterator over the functi

Re: [HACKERS] Refectoring of receivelog.c

On Fri, Mar 11, 2016 at 9:40 AM, Daniel Gustafsson wrote: > > On 15 Feb 2016, at 14:46, Magnus Hagander wrote: > > > > On Mon, Feb 15, 2016 at 7:15 AM, Craig Ringer > wrote: > > On 15 February 2016 at 04:48, Magnus Hagander > wrote: > >

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Fri, Mar 11, 2016 at 6:31 PM, Thomas Munro wrote: > This patch introduces a drop-in replacement > check_unique_tuple_still_live to call instead of heap_hot_search. The > replacement function also calls heap_hot_search_buffer, but while it > has the buffer it takes the opportunity to do an SSI

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

On 11 March 2016 at 17:00, Simon Riggs wrote: > > >> Also, pg_logical_slot_get_changes and its _peek_ variant should have a >> param specifying the starting LSN to read and return. If this is lower than >> the restart_lsn but non-null it should ERROR; if it's greater than or equal >> it should u

Re: [HACKERS] auto_explain sample rate

On Thu, Mar 10, 2016 at 10:07 PM, Petr Jelinek wrote: > On 10/03/16 20:59, Julien Rouhaud wrote: > >> On 10/03/2016 04:37, Petr Jelinek wrote: >> >>> On 17/02/16 01:17, Julien Rouhaud wrote: >>> Agreed, it's too obscure. Attached v4 fixes as you said. >>> Seems to be simple en

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

On Fri, Jan 15, 2016 at 9:46 PM, Christian Ullrich wrote: > * Christian Ullrich wrote: > > * Christian Ullrich wrote: >> >> * Christian Ullrich wrote: >>> >>> > According to the release notes, the default for the "include_realm" >>> > option in SSPI authentication was changed from off to on in 9.

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

* From: Magnus Hagander [mailto:mag...@hagander.net] > I took a quick look at this one, and have some initial thoughts. > > I don't like the name "real_realm" as a parameter name. I'm wondering if > it might be better to reverse the meaning, and call it sspi_netbios_realm > (and then change the d

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Fri, Mar 11, 2016 at 12:00 AM, Amit Kapila wrote: > On Wed, Mar 9, 2016 at 5:46 PM, Haribabu Kommi > wrote: >> On Wed, Mar 9, 2016 at 10:06 PM, Amit Kapila >> wrote: >> > On Wed, Mar 9, 2016 at 11:46 AM, Haribabu Kommi >> > >> > wrote: >> >> >> >> >> >> I tried replacing the random() with Po

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Thu, Mar 10, 2016 at 1:50 PM, Simon Riggs wrote: > On 3 February 2016 at 23:12, Thomas Munro > wrote: > >> It quacks suspiciously like a bug. > > Agreed > > What's more important is that is very publicly a bug in the eyes > of others and should be fixed and backpatched soon. I really am ske

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Fri, Mar 11, 2016 at 5:21 PM, Haribabu Kommi wrote: > > On Fri, Mar 11, 2016 at 12:00 AM, Amit Kapila wrote: > > > > Okay, so one probable theory for such an error could be that when there is > > already an object with same name exists, this API requests access to the > > that existing object

Re: [HACKERS] Logical decoding slots can go backwards when used from SQL, docs are wrong

Craig Ringer wrote: > Hi all > > I think I found a couple of logical decoding issues while writing tests for > failover slots. > > Despite the docs' claim that a logical slot will replay data "exactly > once", a slot's confirmed_lsn can go backwards and the SQL functions can > replay the same dat

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Thu, Mar 10, 2016 at 11:31 PM, Thomas Munro wrote: > Here's a much simpler version with more comments > It handles the same set of isolation test specs. I'm impressed that you found a one-line patch that seems to get us 90% of the way to a new guarantee; but I think if we're going to do some

Re: [HACKERS] The plan for FDW-based sharding

On Fri, Mar 11, 2016 at 10:19:16AM +0100, Oleg Bartunov wrote: > Our XTM is the yet another example of infrastructure we need to work on > clustering. Should we wait other smart guy starts thinking on distributed > transactions ?  We described in https://wiki.postgresql.org/wiki/DTM our  API, > whi

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Fri, Mar 11, 2016 at 1:19 AM, Amit Kapila wrote: > On Fri, Mar 11, 2016 at 12:28 AM, Robert Haas wrote: >> Committed with some further editing. In particular, the way you >> determined whether we could safely access the tranche information for >> any given ID was wrong; please check over what

Re: [HACKERS] POC: Cache data in GetSnapshotData()

Thanks Amit, I did a quick pgbench write tests for unlogged tables at 88 clients as it had the peak performance from previous test. There is big jump in TPS due to clog changes. clients BASE ONLY CLOG CHANGES % Increase ONLY SAVE SNAPSHOT % Increase CLOG CHANGES + SAVE SNAPSHOT % Increase 88 3605

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Fri, Mar 11, 2016 at 11:15 PM, Amit Kapila wrote: > On Fri, Mar 11, 2016 at 5:21 PM, Haribabu Kommi > wrote: >> >> On Fri, Mar 11, 2016 at 12:00 AM, Amit Kapila >> wrote: >> > >> > Okay, so one probable theory for such an error could be that when there >> > is >> > already an object with same

Re: [HACKERS] \x auto and EXPLAIN

On Sun, Jan 3, 2016 at 4:36 AM, Andreas Karlsson wrote: > psql's "\x auto" is a nice feature, but it is made much less useful in my > opinion due to the expanded output format making query plans unreadable (and > query plans often end up using expanded display due to their width). I think > we sho

Re: [HACKERS] Tsvector editing functions

> On 10 Mar 2016, at 20:29, Teodor Sigaev wrote: > > I would like to suggest rename both functions to array_to_tsvector and > tsvector_to_array to have consistent name. Later we could add > to_tsvector([regconfig, ], text[]) with morphological processing. > > Thoughts? > Seems reasonable, d

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

Le 11/03/2016 10:49, Shulgin, Oleksandr a écrit : > On Thu, Mar 10, 2016 at 9:05 PM, Tom Lane > wrote: > > Gilles Darold > writes: > > Then, should I have to use an alternate file to store the > information or > > imp

Re: [HACKERS] Sanity checking for ./configure options?

On Sat, Feb 27, 2016 at 3:15 PM, Jim Nasby wrote: > On 2/26/16 9:29 PM, Peter Eisentraut wrote: >> To make this really robust, you might need to do pattern matching on the >> value. > > Yeah, and I don't see any reasonable way to do that... we don't require sed > or the like, do we? > > I'll look

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

On Mon, Jan 18, 2016 at 3:14 PM, Peter Geoghegan wrote: > On Mon, Jan 18, 2016 at 11:56 AM, Alvaro Herrera > wrote: >>> That's because I believe this is quite broken, as already pointed out. >> >> I think I like your approach better. > > That makes things far simpler, then. > >>> Your premise her

Re: [HACKERS] dblink: add polymorphic functions.

On Thu, Jan 28, 2016 at 6:12 AM, Alvaro Herrera wrote: > Joe Conway wrote: > >> Ok, back to the drawing board. Thanks for the feedback. > > Closing this one as returned-with-feedback. Please do resubmit for > CF 2016-03. Joe, it looks like you reactivated this patch for CF 2016-03 even though it

Re: [HACKERS] Improve error handling in pltcl

On Thu, Mar 3, 2016 at 9:51 AM, Pavel Stehule wrote: > I am testing behave, and some results looks strange Jim, this is waiting for you to respond to Pavel's review. If that doesn't happen soon, this should be marked Returned with Feedback and you can, if you wish, resubmit for 9.7. Thanks, --

Re: [HACKERS] proposal: get oldest LSN - function

On 28.02.2016 11:36, Michael Paquier wrote: On Sun, Feb 28, 2016 at 4:40 PM, Kartyshov Ivan wrote: It will not satisfy our purposes and our administrators for three reasons. 1) DBA set me task to get the oldest number that present in WAL, not last Yeah I got that. 2) Surely we can choose th

Re: [HACKERS] proposal: get oldest LSN - function

On 11.03.2016 16:33, Kartyshov Ivan wrote: On 28.02.2016 11:36, Michael Paquier wrote: On Sun, Feb 28, 2016 at 4:40 PM, Kartyshov Ivan wrote: It will not satisfy our purposes and our administrators for three reasons. 1) DBA set me task to get the oldest number that present in WAL, not last

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

On Thu, Mar 3, 2016 at 2:40 PM, Kevin Grittner wrote: > Thanks for the tips. Attached is a minimal set of isolation tests. > I can expand on it if needed, but wanted: > > (1) to confirm that this is the right way to do this, and > > (2) how long people were willing to tolerate these tests running

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

On Sun, Feb 28, 2016 at 9:38 PM, Vitaly Burovoy wrote: >> However, I'm not sure we ought to tinker with the behavior in this >> area. If -MM-DD is going to accept things that are not of the >> format -MM-DD, and I'd argue that -1-06-01 is not in that format, > > It is not about format, it

Re: [HACKERS] dblink: add polymorphic functions.

On 03/11/2016 08:31 AM, Robert Haas wrote: > On Thu, Jan 28, 2016 at 6:12 AM, Alvaro Herrera > wrote: >> Joe Conway wrote: >> >>> Ok, back to the drawing board. Thanks for the feedback. >> >> Closing this one as returned-with-feedback. Please do resubmit for >> CF 2016-03. > > Joe, it looks like

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

On Thu, Feb 18, 2016 at 9:23 AM, Daniel Verite wrote: > Dean Rasheed wrote: > >> If I want to sort the rows coming out of a query, my first thought >> is always going to be to add/adjust the query's ORDER BY clause, not >> use some weird +/- psql syntax. > > About the vertical sort, I agre

Re: [HACKERS] auto_explain sample rate

On 11/03/2016 11:45, Magnus Hagander wrote: > > Coming back to the previous discussions about random() - AFAICT this > patch will introduce the random() call always (in explain_ExecutorStart): > > +if (auto_explain_log_min_duration >= 0 && nesting_level == 0) > +current_query_sampled = (random()

Re: [HACKERS] dblink: add polymorphic functions.

On Fri, Mar 11, 2016 at 8:44 AM, Joe Conway wrote: > On 03/11/2016 08:31 AM, Robert Haas wrote: >> On Thu, Jan 28, 2016 at 6:12 AM, Alvaro Herrera >> wrote: >>> Joe Conway wrote: >>> Ok, back to the drawing board. Thanks for the feedback. >>> >>> Closing this one as returned-with-feedback.

Re: [HACKERS] auto_explain sample rate

On Fri, Mar 11, 2016 at 2:51 PM, Julien Rouhaud wrote: > On 11/03/2016 11:45, Magnus Hagander wrote: > > > > Coming back to the previous discussions about random() - AFAICT this > > patch will introduce the random() call always (in explain_ExecutorStart): > > > > +if (auto_explain_log_min_duratio

Re: [HACKERS] auto_explain sample rate

On 11/03/16 11:45, Magnus Hagander wrote: On Thu, Mar 10, 2016 at 10:07 PM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: On 10/03/16 20:59, Julien Rouhaud wrote: On 10/03/2016 04:37, Petr Jelinek wrote: On 17/02/16 01:17, Julien Rouhaud wrote: Agr

Re: [HACKERS] auto_explain sample rate

On Fri, Mar 11, 2016 at 3:03 PM, Magnus Hagander wrote: > > > On Fri, Mar 11, 2016 at 2:51 PM, Julien Rouhaud > wrote: > >> On 11/03/2016 11:45, Magnus Hagander wrote: >> > >> > Coming back to the previous discussions about random() - AFAICT this >> > patch will introduce the random() call alway

Re: [HACKERS] Small patch: fix warnings during compilation on FreeBSD

Hello, Tom > I think what we need is configure logic to find out where wcstombs_l() > is declared, and then #include only if it's necessary to > get that definition. I haven't experimented but probably you could > make such a check with nested uses of AC_CHECK_DECL. Sounds like quite a dirty ha

Re: [HACKERS] auto_explain sample rate

On 11/03/2016 15:11, Magnus Hagander wrote: > > > On Fri, Mar 11, 2016 at 3:03 PM, Magnus Hagander > wrote: > > > > On Fri, Mar 11, 2016 at 2:51 PM, Julien Rouhaud > mailto:julien.rouh...@dalibo.com>> wrote: > > On 11/03/2016 11:45, Magnus Hagander

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

Gilles Darold writes: > Le 11/03/2016 10:49, Shulgin, Oleksandr a écrit : >> Would it make sense to have it as a symlink instead? > The only cons I see is that it can be more "difficult" with some > language to gather the real path, but do we really need it? There is > also little time where the

Re: [HACKERS] [PATCH] Logical decoding support for sequence advances

On 02/03/16 08:05, Craig Ringer wrote: On 1 March 2016 at 05:30, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote: On 29/02/16 03:23, Craig Ringer wrote: Sound reasonable? I wonder if it would be acceptable to create new info flag for RM_SEQ_ID that would behave just like

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

On Fri, Mar 11, 2016 at 2:35 PM, Robert Haas wrote: > On Thu, Mar 3, 2016 at 2:40 PM, Kevin Grittner wrote: >> Thanks for the tips. Attached is a minimal set of isolation tests. >> I can expand on it if needed, but wanted: >> >> (1) to confirm that this is the right way to do this, and >> >> (2)

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

On 3/10/16 11:00 AM, Petr Jelinek wrote: > The comment above errhidefromclient says "Only log levels below ERROR > can be hidden from the client." but use of the errhidefromclient(true) > actually does hide the error message from client, client just gets > failed query without any message when use

Re: [HACKERS] proposal: get oldest LSN - function

On Fri, Mar 11, 2016 at 2:35 PM, Kartyshov Ivan wrote: > You wrote "If you care about the oldest record available you should look for > the first LSN position of the oldest segment, no?" > Yes I do it exactly this way. Your patch does that: +XLogRecPtrresult; + +XLogSegNoOffsetToRecPt

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

On 3/10/16 11:07 AM, Tom Lane wrote: > Petr Jelinek writes: >> The comment above errhidefromclient says "Only log levels below ERROR >> can be hidden from the client." but use of the errhidefromclient(true) >> actually does hide the error message from client, client just gets >> failed query wi

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

On 3/10/16 9:51 AM, Tom Lane wrote: > The patch is evidently modeled on errhidestmt and errhidectx, which are > making the same assumption for their fields. > > I wonder whether, instead of continuing to proliferate random bool fields > in struct ErrorData, we oughta replace them all with an "int

Re: [HACKERS] dblink: add polymorphic functions.

On 03/11/2016 08:51 AM, Robert Haas wrote: > Thanks for understanding. Rejecting patches is not much more fun that > getting your patches rejected, but it's got to be done... sorry! +1 Sorry I didn't already do this myself when it became clear I wasn't going to get it done in time. -- Crunchy

[HACKERS] PostgreSQL 9.6 Release Management Team (RMT)

At the recent Dev Meeting in Brussels we discussed release management processes and schedules. The recommendation from the meeting was to explore the creation of a Release Management Team (RMT) with the skills and authority to keep us on schedule. That has now been discussed and agreed by the pgsql

Re: [HACKERS] Small patch: fix warnings during compilation on FreeBSD

On Fri, Mar 11, 2016 at 9:13 AM, Aleksander Alekseev wrote: > Hello, Tom > >> I think what we need is configure logic to find out where wcstombs_l() >> is declared, and then #include only if it's necessary to >> get that definition. I haven't experimented but probably you could >> make such a ch

Re: [HACKERS] Small patch: fix warnings during compilation on FreeBSD

Robert Haas writes: > On Fri, Mar 11, 2016 at 9:13 AM, Aleksander Alekseev > wrote: >> Sounds like quite a dirty hack to me. Besides so far we have only two >> procedures from xlocale.h and this requires two checks. If we go this >> way someday there will be 15 checks for every procedure from xlo

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

Le 11/03/2016 15:22, Tom Lane a écrit : > Gilles Darold writes: >> Le 11/03/2016 10:49, Shulgin, Oleksandr a écrit : >>> Would it make sense to have it as a symlink instead? >> The only cons I see is that it can be more "difficult" with some >> language to gather the real path, but do we really n

Re: [HACKERS] Proposal: BSD Authentication support

On 1/14/16 11:22 PM, Robert Haas wrote: > On Tue, Jan 12, 2016 at 2:27 AM, Marisa Emerson wrote: >> I've attached the latest version of this patch. I've fixed up an issue with >> the configuration scripts that I missed. > Looks reasonable on a quick read-through. Can anyone with access to a > BSD

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

01.03.2016 03:09, Peter Geoghegan: I was assigned an "action point" during the FOSDEM developer meeting: "Post new version of btree consistency checker patch". I attach a new WIP version of my consistency checker tool, amcheck. This patch is proposed for 9.6, as an extension in contrib -- maybe w

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

On Fri, Mar 11, 2016 at 5:19 PM, Anastasia Lubennikova wrote: > BTW, if you know a good way to corrupt index (and do it reproducible) I'd be > very glad to see it. You can use for example dd in non-truncate mode to corrupt on-disk page data, say that for example: dd if=/dev/random bs=8192 count=1

Re: [HACKERS] auto_explain sample rate

Hi, On Fri, 2016-03-11 at 15:11 +0100, Magnus Hagander wrote: >  > > > Applied with a minor word-fix in the documentation and removal of > some unrelated whitespace changes.  A bit late, but I think we should rename the GUC variable to "sampling_rate" (instead of sample_ratio) as that's what pgb

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On 1/21/16 9:53 AM, Shulgin, Oleksandr wrote: > On Thu, Jan 21, 2016 at 3:25 PM, Robert Haas > wrote: > > > So it's true that the client can't unilaterally terminate COPY BOTH > mode; it can only send CopyDone. But an error on the server side > should do

Re: [HACKERS] Speedup twophase transactions

On 01/26/2016 07:43 AM, Stas Kelvich wrote: Thanks for reviews and commit! As Simon and Andres already mentioned in this thread replay of twophase transaction is significantly slower then the same operations in normal mode. Major reason is that each state file is fsynced during replay and w

Re: [HACKERS] amcheck (B-Tree integrity checking tool)

Hi, On Fri, 2016-03-11 at 17:24 +0100, Michael Paquier wrote: > On Fri, Mar 11, 2016 at 5:19 PM, Anastasia Lubennikova wrote: > > > > BTW, if you know a good way to corrupt index (and do it > > reproducible) I'd be > > very glad to see it. > You can use for example dd in non-truncate mode to corr

Re: [HACKERS] Proposal: RETURNING primary_key()

On 3/11/2016 12:40 AM, Craig Ringer wrote: That's why (sorry, Igal) I'd like to see some more tests for cases other than identity columns. How is GENERATED ALWAYS handled, if supported? What about if it's on a UNIQUE column? How about a PRIMARY KEY whose value is assigned by a DEFAULT or by a

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Fri, Mar 11, 2016 at 11:36 AM, David Steele wrote: > It looks like a decision needs to be made here whether to apply this patch, > send it back to the author, or reject it so I'm marking it "Ready for > Committer". > > Robert, since you were participating in this conversation can you have a > l

Re: [HACKERS] auto_explain sample rate

On Fri, Mar 11, 2016 at 11:33 AM, Tomas Vondra wrote: > A bit late, but I think we should rename the GUC variable to > "sampling_rate" (instead of sample_ratio) as that's what pgbench uses > for the same thing. That'd be more consistent. I like that idea. It seems like slightly better terminolog

Re: [HACKERS] Tsvector editing functions

> > On 11 Mar 2016, at 16:13, Stas Kelvich wrote: > > >> On 10 Mar 2016, at 20:29, Teodor Sigaev wrote: >> >> I would like to suggest rename both functions to array_to_tsvector and >> tsvector_to_array to have consistent name. Later we could add >> to_tsvector([regconfig, ], text[]) with mo

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

On 3/11/16, Robert Haas wrote: > On Sun, Feb 28, 2016 at 9:38 PM, Vitaly Burovoy > wrote: >>> However, I'm not sure we ought to tinker with the behavior in this >>> area. If -MM-DD is going to accept things that are not of the >>> format -MM-DD, and I'd argue that -1-06-01 is not in that

Re: [HACKERS] Tsvector editing functions

I saw errors on windows, here is the fix: Thank you, pushed -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make ch

Re: [HACKERS] Combining Aggregates

On 1/20/16 11:42 PM, David Rowley wrote: > On 21 January 2016 at 08:06, Robert Haas > wrote: > > On Wed, Jan 20, 2016 at 7:38 AM, David Rowley > mailto:david.row...@2ndquadrant.com>> > wrote: > > Agreed. So I've attached a version of the patch which d

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

On Thu, Mar 10, 2016 at 10:47 PM, Masahiko Sawada wrote: >> Thanks. I adopted some of your suggested, rejected others, fixed a >> few minor things that I missed previously, and committed this. If you >> think any of the changes that I rejected still have merit, please >> resubmit those changes a

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

On Sat, Mar 12, 2016 at 2:37 AM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 10:47 PM, Masahiko Sawada > wrote: >>> Thanks. I adopted some of your suggested, rejected others, fixed a >>> few minor things that I missed previously, and committed this. If you >>> think any of the changes that I

Re: [HACKERS] GinPageIs* don't actually return a boolean

Andres Freund wrote: I plan to commit something like this, unless there's very loud protest from Peter's side. I agree. Peter proposal can be considered in a separate thread. Thanks. -- Yury Zhuravlev Postgres Professional: http://www.postgrespro.com The Russian Postgres Company -- Sent vi

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

On 03/11/2016 09:48 AM, Masahiko Sawada wrote: Thank you so much! What I wanted deal with in thread is almost done. I'm going to more test the feature for 9.6 releasing. Nicely done! Regards, -- Masahiko Sawada -- Command Prompt, Inc. http://the.postgres.company/

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On 2/10/16 12:50 PM, Konstantin Knizhnik wrote: > PostgresProffesional cluster teams wants to propose new version of > eXtensible Transaction Manager API. > Previous discussion concerning this patch can be found here: > > http://www.postgresql.org/message-id/f2766b97-555d-424f-b29f-e0ca0f6d1...@p

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

Robert Haas writes: > On Fri, Mar 11, 2016 at 11:36 AM, David Steele wrote: >> It looks like a decision needs to be made here whether to apply this patch, >> send it back to the author, or reject it so I'm marking it "Ready for >> Committer". >> >> Robert, since you were participating in this co

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On 3/11/16 1:11 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Mar 11, 2016 at 11:36 AM, David Steele wrote: >>> It looks like a decision needs to be made here whether to apply this patch, >>> send it back to the author, or reject it so I'm marking it "Ready for >>> Committer". >>> >>> Robe

Re: [HACKERS] WIP: Access method extendability

On Wed, Mar 9, 2016 at 8:31 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > Hi! > > On Wed, Mar 9, 2016 at 3:27 PM, Alvaro Herrera > wrote: > >> Hi. As I just said to Tomas Vondra: since your patch creates a new >> object type, please make sure to add a case to cover it in the >> ob

Re: [HACKERS] remove wal_level archive

On 2/8/16 2:34 PM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> On 1/26/16 10:56 AM, Simon Riggs wrote: >>> Removing one of "archive" or "hot standby" will just cause confusion and >>> breakage, so neither is a good choice for removal. >>> >>> What we should do is >>> 1. Map "archive" and "h

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On Fri, Mar 11, 2016 at 1:11 PM, David Steele wrote: > On 2/10/16 12:50 PM, Konstantin Knizhnik wrote: >> PostgresProffesional cluster teams wants to propose new version of >> eXtensible Transaction Manager API. >> Previous discussion concerning this patch can be found here: >> >> http://www.postg

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On 3/11/16 1:30 PM, Robert Haas wrote: > There's been a lot of discussion on another thread about this patch. > The subject is "The plan for FDW-based sharding", but the thread kind > of got partially hijacked by this issue. The net-net of that is that > I don't think we have a clear enough idea

Re: [HACKERS] proposal: make NOTIFY list de-duplication optional

Hi Filip, On 2/20/16 8:00 AM, Filip Rembiałkowski wrote: > On Fri, Feb 19, 2016 at 10:09 PM, Catalin Iacob On 2/9/16, Tom Lane mailto:t...@sss.pgh.pa.us>> > wrote: > > FWIW, I think it would be a good thing if the NOTIFY statement syntax > were > > not remarkably different from t

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On Fri, Mar 11, 2016 at 7:11 PM, David Steele wrote: > On 2/10/16 12:50 PM, Konstantin Knizhnik wrote: > > > PostgresProffesional cluster teams wants to propose new version of > > eXtensible Transaction Manager API. > > Previous discussion concerning this patch can be found here: > > > > > http:/

Re: [HACKERS] eXtensible Transaction Manager API (v2)

On 3/11/16 2:00 PM, Oleg Bartunov wrote: > On Fri, Mar 11, 2016 at 7:11 PM, David Steele I'm concerned about the lack of response or reviewers for this patch. > It may be because everyone believes they had their say on the original > thread, or because it seems like a big change to go

Re: [HACKERS] insufficient qualification of some objects in dump files

Hi Peter, On 2/26/16 1:30 AM, Tom Lane wrote: > Michael Paquier writes: >> On Fri, Feb 26, 2016 at 9:47 AM, Peter Eisentraut wrote: >>> Tom thought this might require an archive version dump, but I'm not >>> sure. The tags are more of an informational string for human >>> consumption, not stric

[HACKERS] Background Processes and reporting

Hi, We now have "Provide much better wait information in pg_stat_activity" and "Add a generic command progress reporting facility" making it easier to provide insight into the system. While working on the writeback control / checkpoint sorting patch I'd the following statement in BufferSync()'s

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

Robert Haas writes: > On Sun, Feb 28, 2016 at 9:38 PM, Vitaly Burovoy > wrote: >>> However, I'm not sure we ought to tinker with the behavior in this >>> area. If -MM-DD is going to accept things that are not of the >>> format -MM-DD, and I'd argue that -1-06-01 is not in that format, >

[HACKERS] Change error code for hstore syntax error

The hstore module uses elog() to default to ERRCODE_INTERNAL_ERROR (SQLSTATE XX000) when the error message reads "Syntax error near '%c' at position %d". I propose to switch to ereport() to return ERRCODE_SYNTAX_ERROR (SQLSTATE 42601), on the grounds that it's more transparent. It took me longer t

Re: [HACKERS] Change error code for hstore syntax error

Sherrylyn Branchaw writes: > The hstore module uses elog() to default to ERRCODE_INTERNAL_ERROR > (SQLSTATE XX000) when the error message reads "Syntax error near '%c' at > position %d". Yeah, that is entirely bogus. No user-facing error report should ever return ERRCODE_INTERNAL_ERROR. > I pro

[HACKERS] Saving SRF context

Hi, I have implemented a SRF[*] that returns rows one by one (using ExprMultipleResult). But now I need to save somewhere some context information between calls pertaining to the same result set and I am unable to find a proper place for that. I have seen that cfinfo->flinfo->fn_extra is ava

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

On 3/11/16, Tom Lane wrote: > [ catches up with thread... ] > > Yes. It would be more reasonable IMO for to_date to throw an error > because this is bad input. On the other hand, to_date mostly doesn't > throw an error no matter how bad the input is. I think that may have > been intentional, al

Re: [HACKERS] eXtensible Transaction Manager API (v2)

Robert Haas writes: > On Fri, Mar 11, 2016 at 1:11 PM, David Steele wrote: >> Is anyone willing to volunteer a review or make an argument for the >> importance of this patch? > There's been a lot of discussion on another thread about this patch. > The subject is "The plan for FDW-based sharding"

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas wrote: > I'm not direly opposed to most of what's on that page, > but I'm not excited about most of it, either. May I ask, what improvements of PL/pgSQL would you personally be most excited about, if you or someone else would have unlimited resources

Re: [HACKERS] Background Processes and reporting

> 11 марта 2016 г., в 22:16, Andres Freund написал(а): > > Hi, > > We now have "Provide much better wait information in pg_stat_activity" > and "Add a generic command progress reporting facility" making it easier > to provide insight into the system. > > > While working on the writeback contr

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 3:44 PM, Joel Jacobson wrote: > On Fri, Mar 11, 2016 at 11:14 AM, Robert Haas wrote: >> I'm not direly opposed to most of what's on that page, >> but I'm not excited about most of it, either. > > May I ask, what improvements of PL/pgSQL would you personally be most > excit

  1   2   >