Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

A few comments about v5. New patch. Patch applies (with patch, I gave up on "git apply"). Make check ok. Psql tap test ok. Highlights: - Interactive barking on branching state changes, commands typed while in inactive state I noticed that the "barking" is conditional to "success". ISTM

Re: [HACKERS] logical decoding of two-phase transactions

On 02/04/2017 03:08 AM, Andres Freund wrote: > On 2017-02-03 18:47:23 -0500, Robert Haas wrote: >> On Fri, Feb 3, 2017 at 6:00 PM, Andres Freund wrote: >>> I still haven't seen a credible model for being able to apply a stream >>> of interleaved transactions that can roll back

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

On Sat, Feb 4, 2017 at 12:12 AM, Alvaro Herrera wrote: > Pavan Deolasee wrote: > >> Looking at the history and some past discussions, it seems Tomas reported >> somewhat similar problem and Andres proposed a patch here >>

[HACKERS] pg_sequences bug ?

Hi hackers, I tried a committed pg_sequences for PostgreSQL 10dev (https://commitfest.postgresql.org/12/771/). I found that when multiple users create SEQUENCE, I cannot see the pg_sequences catalog. I think that should work just like pg_tables. $ psql -U user1 postgres=> CREATE SEQUENCE

Re: [HACKERS] libpq Alternate Row Processor

Kyle Gearhart writes: > The guts of pqRowProcessor in libpq does a good bit of work to maintain the > internal data structure of a PGresult. There are a few use cases where the > caller doesn't need the ability to access the result set row by row, column > by

Re: [HACKERS] Packages: Again

2017-02-03 23:24 GMT+01:00 Serge Rielau : > > > > > Still I little bit afraid about nesting - Postgres allows function > overloading with specific mechanism of selecting called function. Sometimes > it is problematic now, and the this structure is flat. > > > > I like a idea of

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Sat, Feb 4, 2017 at 4:37 AM, Jeff Janes wrote: > On Thu, Jan 12, 2017 at 7:23 PM, Amit Kapila > wrote: >> >> On Fri, Jan 13, 2017 at 1:04 AM, Jesper Pedersen >> wrote: >> > On 12/27/2016 01:58 AM, Amit Kapila wrote:

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

On Fri, Feb 3, 2017 at 8:29 PM, Robert Haas wrote: > On Fri, Feb 3, 2017 at 7:41 AM, Ashutosh Sharma wrote: >> I think UInt32GetDatum(metad->hashm_procid) looks fine, the reason >> being 'hashm_procid' is defined as 32-bit unsigned integer but then

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

On Fri, Feb 3, 2017 at 4:15 PM, Thomas Munro wrote: >> I suspect that this system isn't particularly well balanced for the >> task of benchmarking the patch. You would probably see notably better >> scalability than any you've shown in any test if you could add >>

Re: [HACKERS] Parallel Index Scans

On Sat, Feb 4, 2017 at 5:54 AM, Robert Haas wrote: > On Wed, Feb 1, 2017 at 12:58 AM, Amit Kapila wrote: >> Yeah, I understand that point and I can see there is strong argument >> to do that way, but let's wait and see what others including Robert

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2017-02-03 19:26:55 -0600, Jim Nasby wrote: > On 2/3/17 6:20 PM, Andres Freund wrote: > > > - The ringbuffers in shared buffers can be problematic. One possible way > > > of > > > solving that is to get rid of ringbuffers entirely and rely on different > > > initial values for usage_count

Re: [HACKERS] PinBuffer() no longer makes use of strategy

Hi, On 2017-02-03 19:13:45 -0600, Jim Nasby wrote: > No, I noticed it while reading code. Removing that does mean that if any > non-default strategy (in any backend) hits that buffer again then the buffer > will almost certainly migrate into the main buffer pool the next time one of > the rings

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2/3/17 6:20 PM, Andres Freund wrote: - The ringbuffers in shared buffers can be problematic. One possible way of solving that is to get rid of ringbuffers entirely and rely on different initial values for usage_count instead, but that's not desirable if it just means more clock sweep work for

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 7:42 PM, Jim Nasby wrote: > Since the current consensus is to be very verbose about \if, this is > obviously a non-issue. Maybe worth adding a 'I' case to %R, but no big deal > if that doesn't happen. I think we left the door open to a separate

Re: [HACKERS] PinBuffer() no longer makes use of strategy

On 2/3/17 6:39 PM, Andres Freund wrote: Hi, On 2017-02-03 18:32:03 -0600, Jim Nasby wrote: Commit 48354581a49c30f5757c203415aa8412d85b0f70 (Allow Pin/UnpinBuffer to operate in a lockfree manner) removed the code in PinBuffer that conditionally incremented usage_count when a ring buffer was in

Re: [HACKERS] Checksums by default?

On 2/3/17 5:31 PM, Andres Freund wrote: You can't really see things from other databases that way tho. So you need to write a tool that iterates all databases and such. Not that that's a huge problem, but it doesn't make things easier at least. True. Not terribly hard to iterate though, and

Re: [HACKERS] libpq Alternate Row Processor

On 2/3/17 3:53 PM, Kyle Gearhart wrote: The guts of pqRowProcessor in libpq does a good bit of work to maintain the internal data structure of a PGresult. There are a few use cases where the caller doesn't need the ability to access the result set row by row, column by column using

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On 2/2/17 4:39 PM, Corey Huinker wrote: On Wed, Feb 1, 2017 at 4:58 PM, Jim Nasby > wrote: I think the issue here is that the original case for this is a user accidentally getting into an \if and then having no clue what's

Re: [HACKERS] PinBuffer() no longer makes use of strategy

Hi, On 2017-02-03 18:32:03 -0600, Jim Nasby wrote: > Commit 48354581a49c30f5757c203415aa8412d85b0f70 (Allow Pin/UnpinBuffer to > operate in a lockfree manner) removed the code in PinBuffer that > conditionally incremented usage_count when a ring buffer was in use. Was > that intentional? ISTM the

[HACKERS] PinBuffer() no longer makes use of strategy

Commit 48354581a49c30f5757c203415aa8412d85b0f70 (Allow Pin/UnpinBuffer to operate in a lockfree manner) removed the code in PinBuffer that conditionally incremented usage_count when a ring buffer was in use. Was that intentional? ISTM the old behavior should have been retained. -- Jim Nasby,

Re: [HACKERS] Parallel Index Scans

On Wed, Feb 1, 2017 at 12:58 AM, Amit Kapila wrote: > Yeah, I understand that point and I can see there is strong argument > to do that way, but let's wait and see what others including Robert > have to say about this point. It seems to me that you can make an argument

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2017-02-03 18:12:48 -0600, Jim Nasby wrote: > Interesting. Probably kills a couple birds with one stone: > > - This should be a lot cheaper for backends then the clock sweep Right, that's one of the motivations - the current method is pretty much guaranteed to create the worst cacheline

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

On Sat, Feb 4, 2017 at 11:58 AM, Peter Geoghegan wrote: > On Fri, Feb 3, 2017 at 5:04 AM, Thomas Munro > wrote: >> 1. 'asc' = pre-sorted data (w = 0 shows time in seconds, other columns >> show speed-up relative to that time): >> >> mem | w = 0 | w

Re: [HACKERS] Time to up bgwriter_lru_maxpages?

On 2/2/17 1:50 PM, Andres Freund wrote: FWIW, I think working on replacing bgwriter (e.g. by working on the patch I send with a POC replacement) wholesale is a better approach than spending time increasing limits. Do you have a link to that? I'm not seeing anything in the archives. Not at

Re: [HACKERS] logical decoding of two-phase transactions

On 2017-02-03 19:09:43 -0500, Robert Haas wrote: > On Fri, Feb 3, 2017 at 7:08 PM, Andres Freund wrote: > > On 2017-02-03 18:47:23 -0500, Robert Haas wrote: > >> On Fri, Feb 3, 2017 at 6:00 PM, Andres Freund wrote: > >> > I still haven't seen a credible

Re: [HACKERS] logical decoding of two-phase transactions

On Fri, Feb 3, 2017 at 7:08 PM, Andres Freund wrote: > On 2017-02-03 18:47:23 -0500, Robert Haas wrote: >> On Fri, Feb 3, 2017 at 6:00 PM, Andres Freund wrote: >> > I still haven't seen a credible model for being able to apply a stream >> > of interleaved

Re: [HACKERS] Redundant comment in ExecutePlan

On Fri, Feb 3, 2017 at 6:07 AM, Rafia Sabih wrote: > Hello all, > I noticed there is a redundant comment in ExecutePlan, Hmm, yeah. Thanks for the patch. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

Re: [HACKERS] logical decoding of two-phase transactions

On 2017-02-03 18:47:23 -0500, Robert Haas wrote: > On Fri, Feb 3, 2017 at 6:00 PM, Andres Freund wrote: > > I still haven't seen a credible model for being able to apply a stream > > of interleaved transactions that can roll back individually; I think we > > really need the

Re: [HACKERS] multivariate statistics (v19)

On Thu, Feb 2, 2017 at 3:59 AM, Tomas Vondra wrote: > There's a subtle difference between pg_node_tree and the data types for > statistics - pg_node_tree stores the value as a string (matching the > nodeToString output), so the _in function is fairly simple. Of

Re: [HACKERS] Superowners

On Mon, Jan 30, 2017 at 5:33 AM, Simon Riggs wrote: > I would call these "super privileges". > > Peter suggests that we have a much more flexible structure for > super-privileges. > > In Peter's model, Tom's suggestion woud be to grant all of these > automatically to

Re: [HACKERS] Declarative partitioning - another take

On Mon, Jan 30, 2017 at 4:42 PM, Peter Eisentraut wrote: > On 1/25/17 12:54 AM, Ashutosh Bapat wrote: >> The documentation available at >> https://www.postgresql.org/docs/devel/static/sql-createtable.html, >> does not make it clear that the lower bound of a range

Re: ParallelFinish-hook of FDW/CSP (Re: [HACKERS] Steps inside ExecEndGather)

On Mon, Oct 31, 2016 at 11:33 AM, Kouhei Kaigai wrote: > Hello, > > The attached patch implements the suggestion by Amit before. > > What I'm motivated is to collect extra run-time statistics specific > to a particular ForeignScan/CustomScan, not only the standard >

Re: [HACKERS] logical decoding of two-phase transactions

On Fri, Feb 3, 2017 at 6:00 PM, Andres Freund wrote: > I still haven't seen a credible model for being able to apply a stream > of interleaved transactions that can roll back individually; I think we > really need the ability to have multiple transactions alive in one >

Re: [HACKERS] Checksums by default?

On Mon, Jan 30, 2017 at 12:29 PM, David Steele wrote: > The solution was to simply ignore the checksums of any pages with an LSN >>= the LSN returned by pg_start_backup(). This means that hot blocks > may never be checked during backup, but if they are active then any >

Re: [HACKERS] Checksums by default?

On 2017-02-03 17:23:15 -0600, Jim Nasby wrote: > On 1/25/17 6:40 PM, Stephen Frost wrote: > > Obviously, having to bring up a full database is an extra step (one we > > try to make easy to do), but, sadly, we don't have any way to ask PG to > > verify all the checksums with released versions, so

Re: [HACKERS] Checksums by default?

On 1/25/17 6:40 PM, Stephen Frost wrote: Obviously, having to bring up a full database is an extra step (one we try to make easy to do), but, sadly, we don't have any way to ask PG to verify all the checksums with released versions, so that's what we're working with. Wouldn't it be fairly

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Thu, Jan 12, 2017 at 7:23 PM, Amit Kapila wrote: > On Fri, Jan 13, 2017 at 1:04 AM, Jesper Pedersen > wrote: > > On 12/27/2016 01:58 AM, Amit Kapila wrote: > >> > >> After recent commit's 7819ba1e and 25216c98, this patch requires a > >>

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Thu, Jan 26, 2017 at 3:55 PM, Robert Haas wrote: > The substantive issue here is whether we should go forward with this > change, back out the change we already did, or leave things as they > are. Tom, David, and I seem to be in lock step on at least the > following

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

On Fri, Feb 3, 2017 at 9:52 PM, Heikki Linnakangas wrote: > On 12/20/2016 03:47 AM, Michael Paquier wrote: >> >> The first thing is to be able to understand in the SCRAM code if a >> string is UTF-8 or not, and this code is in src/common/. pg_wchar.c >> offers a set of routines

Re: [HACKERS] logical decoding of two-phase transactions

On 2017-02-03 17:47:50 -0500, Robert Haas wrote: > On Thu, Feb 2, 2017 at 7:14 PM, Craig Ringer wrote: > > We could make reorder buffers persistent and shared between decoding > > sessions but it'd totally change the logical decoding model and create > > some other

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

On Fri, Feb 3, 2017 at 5:04 AM, Thomas Munro wrote: > 1. 'asc' = pre-sorted data (w = 0 shows time in seconds, other columns > show speed-up relative to that time): > > mem | w = 0 | w = 1 | w = 2 | w = 3 | w = 4 | w = 5 | w = 6 | w = 7 | w = 8 >

Re: [HACKERS] logical decoding of two-phase transactions

On Thu, Feb 2, 2017 at 7:14 PM, Craig Ringer wrote: > We could make reorder buffers persistent and shared between decoding > sessions but it'd totally change the logical decoding model and create > some other problems. It's certainly not a topic for this patch. So we > can

Re: [HACKERS] Enabling replication connections by default in pg_hba.conf

On Fri, Feb 3, 2017 at 4:59 AM, Simon Riggs wrote: > On 2 February 2017 at 18:48, Peter Eisentraut > wrote: >> On 2/2/17 8:32 AM, Simon Riggs wrote: >>> I think we should remove the "replication" false database concept in >>> pg_hba.conf

Re: [HACKERS] Packages: Again

> > Still I little bit afraid about nesting - Postgres allows function > overloading with specific mechanism of selecting called function. Sometimes > it is problematic now, and the this structure is flat. > > I like a idea of more close relation between function and schema. This means >

Re: [HACKERS] Speedup twophase transactions

On Wed, Feb 1, 2017 at 3:29 AM, Nikhil Sontakke wrote: >>> Shouldn’t the singular part of the message above be: >>> "%u two-phase state file was written for a long-running prepared >>> transaction" >>> >>> But, then, English is not my native language, so I might be off

Re: [HACKERS] pageinspect: Hash index support

On Fri, Feb 3, 2017 at 11:49 AM, Jesper Pedersen wrote: > Disregard, as Tom has committed a fix. So we're six commits into this mess now and I'm hopeful that we've got most of the problems with type selection and crashing fixed now. However, I discovered another thing

[HACKERS] libpq Alternate Row Processor

The guts of pqRowProcessor in libpq does a good bit of work to maintain the internal data structure of a PGresult. There are a few use cases where the caller doesn't need the ability to access the result set row by row, column by column using PQgetvalue. Think of an ORM that is just going to

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Fri, Feb 3, 2017 at 5:21 AM, Stephen Frost wrote: > Daniel, > > * Daniel Verite (dan...@manitou-mail.org) wrote: >> What if we look at the change from the pessimistic angle? >> An example of confusion that the change would create: >> a lot of users currently choose pg_wal

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 4:24 PM, Corey Huinker wrote: > That might be what we end up doing. I'm willing to see how unwieldy it gets > before rolling back to "endif: peace out". All I'm saying is, give peace a chance. :-) > The state logic has stuff to do anyway, so for

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

On Fri, Feb 3, 2017 at 12:04 PM, Tom Lane wrote: > One thing to think about is what will happen if someday we want to use > 64-bit hash codes (a day I think is not that far away). It sounds like > you've already chosen bigint for any output field that represents a > hash code

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 3:49 PM, Robert Haas wrote: > On Fri, Feb 3, 2017 at 11:08 AM, Corey Huinker > wrote: > > I could bulk up the error message on if/elif like such: > > > > if: true, executing commands. > > if: false, ignoring commands until

Re: [HACKERS] new autovacuum criterion for visible pages

Stephen Frost wrote: > Tracking the INSERTs as a reason to VACUUM is also very natural when you > consider the need to update BRIN indexes. I am a bit worried that if we > focus just on if the VM needs to be updated or not that we might miss > out on cases where we need to VACUUM because the

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 11:08 AM, Corey Huinker wrote: > I could bulk up the error message on if/elif like such: > > if: true, executing commands. > if: false, ignoring commands until next \else, \elif, or \endif. > if: error, ignoring all commands until next \endif >

Re: [HACKERS] LWLock optimization for multicore Power machines

On Fri, Feb 3, 2017 at 12:01 PM, Alexander Korotkov wrote: > Hi everybody! > > During FOSDEM/PGDay 2017 developer meeting I said that I have some special > assembly optimization for multicore Power machines. From the answers of > other hackers I realized following. > >

Re: [HACKERS] LWLock optimization for multicore Power machines

On Fri, 2017-02-03 at 20:11 +0300, Alexander Korotkov wrote: > On Fri, Feb 3, 2017 at 8:01 PM, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > > > Unfortunately, I have no big enough Power machine at hand to > > reproduce > > that results.  Actually, I have no Power machine at hand at

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 12:20 PM, Daniel Verite wrote: > If we add the functionality that Ctrl+C also exits from branches, > we could do it like the shell does Ctrl+D for logout, that is it > logs out only if the input buffer is empty, otherwise it does > the other

Re: [HACKERS] Possible issue with expanded object infrastructure on Postgres 9.6.1

On Thu, Jan 19, 2017 at 6:39 PM, Tom Lane wrote: > If $customer wants a quick fix, I'd suggest seeing whether disabling > parallel query makes the problem go away. That might be a good first > step anyway, just to narrow down where the problem lies. I no longer work at

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

On Wed, Feb 1, 2017 at 10:13 PM, Michael Paquier wrote: > On Tue, Jan 24, 2017 at 8:36 PM, Kuntal Ghosh > wrote: >> Nothing else to add from my side. I'm marking this 'Ready for commiter'. > > Moved to CF 2017-03 with the same status. OK, I

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

On Fri, Feb 3, 2017 at 5:04 AM, Thomas Munro wrote: > I applied your v2 patch on top of > 7ac4a389a7dbddaa8b19deb228f0a988e79c5795^ to avoid a conflict. It > still had a couple of harmless conflicts that I was able to deal with > (not code, just some header stuff

Re: [HACKERS] Packages: Again

2017-02-03 18:30 GMT+01:00 Serge Rielau : > > DB2 propose using schemas instead packages >> > >> > https://www.ibm.com/developerworks/data/library/ >> techarticle/dm-0711zubiri/ > > That article by Adriana is 6 years ago and was written actually while we > implemented MODULE’s

Re: [HACKERS] new autovacuum criterion for visible pages

On Sat, Jan 21, 2017 at 1:57 PM, Stephen Frost wrote: > All, > > * Simon Riggs (si...@2ndquadrant.com) wrote: > > On 12 August 2016 at 01:01, Tom Lane wrote: > > > Michael Paquier writes: > > >> In short, autovacuum will need

Re: [HACKERS] Index corruption with CREATE INDEX CONCURRENTLY

Pavan Deolasee wrote: > Looking at the history and some past discussions, it seems Tomas reported > somewhat similar problem and Andres proposed a patch here > https://www.postgresql.org/message-id/20140514155204.ge23...@awork2.anarazel.de > which got committed via b23b0f5588d2e2. Not exactly the

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

On Sat, Feb 4, 2017 at 12:49 AM, Fujii Masao wrote: > On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI > wrote: >> At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao wrote >> in

Re: [HACKERS] Packages: Again

> DB2 propose using schemas instead packages > > https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/ > [https://www.ibm.com/developerworks/data/library/techarticle/dm-0711zubiri/] > That article by Adriana is 6 years ago and was written actually while we > implemented

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker wrote: > I meant in the specific psql-context, does it do anything other > than (attempt to) terminate sent-but-not-received SQL queries? It cancels the current edit in the query buffer, including the case when it spans multiple lines. If we add the functionality that

Re: [HACKERS] LWLock optimization for multicore Power machines

On Fri, Feb 3, 2017 at 8:01 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > Unfortunately, I have no big enough Power machine at hand to reproduce > that results. Actually, I have no Power machine at hand at all. So, > lwlock-power-2.patch was written "blindly". I would very

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Corey Huinker writes: > Well played (again). That one ranks up there with "and don't call me > Shirley." I meant in the specific psql-context, does it do anything other > than (attempt to) terminate sent-but-not-received SQL queries? It also flushes the input buffer. I

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

Robert Haas writes: > So based on that theory, here's a patch. > ... > In short, this patch makes hashfuncs.c consistent about (1) using the > next wider signed type to report unsigned values and (2) using the > GetDatum macro that matches the SQL return type in width and >

[HACKERS] LWLock optimization for multicore Power machines

Hi everybody! During FOSDEM/PGDay 2017 developer meeting I said that I have some special assembly optimization for multicore Power machines. From the answers of other hackers I realized following. 1. There are some big Power machines with PostgreSQL in production use. Not as many as

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

> > Can anyone think of a reason why Ctrl-C would be a bad idea? If not I'll >> start looking into it, as I'm not presently aware of what it is used for. >> > > Not me. > > Wikipedia, which holds all the knowledge in the universe, says: "In many > command-line interface environments, control-C is

Re: [HACKERS] pageinspect: Hash index support

On 02/03/2017 11:41 AM, Jesper Pedersen wrote: contrib/pageinspect actually seems to lack *any* infrastructure for sharing functions across modules. It's time to remedy that. I propose inventing "pageinspect.h" to hold commonly visible declarations, and moving get_page_from_raw() into

Re: [HACKERS] pageinspect: Hash index support

Hi, On 02/03/2017 11:36 AM, Robert Haas wrote: On Fri, Feb 3, 2017 at 10:11 AM, Tom Lane wrote: BTW, the buildfarm is still crashing on ia64 and sparc64 members. I believe this is the same problem addressed in 84ad68d64 for pageinspect's GIN functions, to wit, the payload

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

I could bulk up the error message on if/elif like such: [...] Looks ok to me. Can anyone think of a reason why Ctrl-C would be a bad idea? If not I'll start looking into it, as I'm not presently aware of what it is used for. Not me. Wikipedia, which holds all the knowledge in the

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

Robert Haas writes: > Hopefully that will turn the buildfarm green again, but we'll see. It won't make the unhappy 64-bit machines happy, but I just pushed a change that should deal with those problems. With a little luck we're over the hump now.

Re: [HACKERS] pageinspect: Hash index support

On Fri, Feb 3, 2017 at 10:11 AM, Tom Lane wrote: > BTW, the buildfarm is still crashing on ia64 and sparc64 members. > I believe this is the same problem addressed in 84ad68d64 for > pageinspect's GIN functions, to wit, the payload of a "bytea" > is not maxaligned, so machines

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

On Fri, Feb 3, 2017 at 10:54 AM, Robert Haas wrote: >> What needs to be resolved to decide if any of this is actually sane is to >> figure out which of these values need to be int64 on the SQL side because >> (a) they could practically exceed the range of signed int32 and

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

On Fri, Feb 3, 2017 at 7:41 AM, Ashutosh Sharma wrote: >> I think for now selecting named fields is sufficient. > > +1. Attached is the patch that has this changes. Thanks for the patch, but you only handled one of the two cases Tom reported upthread. Added a fix for the

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Fri, Feb 3, 2017 at 7:24 AM, Fabien COELHO wrote: > > Hello Erik, > > Still, it would be an improvement to be able to break out of an inactive >> \if-branch with Ctrl-C. >> > > Yes. > > '\endif' is too long to type, /and/ you have to know it. >> > > Yep. \if is shorter

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

On Fri, Feb 3, 2017 at 10:28 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Feb 2, 2017 at 11:16 PM, Tom Lane wrote: >>> I just made the C code agree with what the SQL declarations for the >>> functions say. > >> Doesn't look

Re: [HACKERS] Cannot shutdown subscriber after DROP SUBSCRIPTION

On Fri, Feb 3, 2017 at 10:56 AM, Kyotaro HORIGUCHI wrote: > At Fri, 3 Feb 2017 01:02:47 +0900, Fujii Masao wrote > in

Re: [HACKERS] pageinspect: Hash index support

BTW, the buildfarm is still crashing on ia64 and sparc64 members. I believe this is the same problem addressed in 84ad68d64 for pageinspect's GIN functions, to wit, the payload of a "bytea" is not maxaligned, so machines that care about alignment won't be happy when trying to fetch 64-bit values

Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

On Fri, Feb 3, 2017 at 7:41 AM, Ashutosh Sharma wrote: > I think UInt32GetDatum(metad->hashm_procid) looks fine, the reason > being 'hashm_procid' is defined as 32-bit unsigned integer but then we > may have to define procid as int8 in SQL function. No, you're wrong. The

Re: [HACKERS] patch: optimize information_schema.constraint_column_usage

Please add this patch to the commitfest so that it's not forgotten. On Fri, Feb 3, 2017 at 6:10 PM, Ashutosh Bapat wrote: > The patch applies cleanly. No regression test fails. > > On Thu, Feb 2, 2017 at 6:57 PM, Alexey Bashtanov wrote: >>

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

2. Inside an \if block \q should be given precedence and cause a direct exit of psql (or at the very least exit the if block(s)), as in regular SQL statements (compare: 'select * from t \q' which will immediately exit psql -- this is good. ) One use case if to be able to write "\if ... \q

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

On Wed, Feb 1, 2017 at 8:46 PM, Peter Geoghegan wrote: > On Tue, Jan 31, 2017 at 11:23 PM, Thomas Munro > wrote: >> So I'm in favour of this patch, which is relatively simple and give us >> faster index builds soon. Eventually we might also be able

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

On 12/20/2016 03:47 AM, Michael Paquier wrote: The first thing is to be able to understand in the SCRAM code if a string is UTF-8 or not, and this code is in src/common/. pg_wchar.c offers a set of routines exactly for this purpose, which is built with libpq but that's not available for

Re: [HACKERS] pageinspect: Hash index support

On 02/02/2017 02:28 PM, Jesper Pedersen wrote: On 02/02/2017 02:24 PM, Robert Haas wrote: So, committed. Wow, I wish every patch had this many reviewers. Thanks Robert ! This message should have included a thank you to everybody who provided valuable feedback for this feature, and for

Re: [HACKERS] patch: optimize information_schema.constraint_column_usage

The patch applies cleanly. No regression test fails. On Thu, Feb 2, 2017 at 6:57 PM, Alexey Bashtanov wrote: > Hello hackers, > > The view information_schema.constraint_column_usage becomes slow when the > number of columns and constraints raise to substantial values. > This

Re: [HACKERS] Gather Merge

Hi, I have done some testing with the latest patch 1)./pgbench postgres -i -F 100 -s 20 2) update pgbench_accounts set filler = 'foo' where aid%10 = 0; 3) vacuum analyze pgbench_accounts; 4) set max_parallel_workers_per_gather = 4; 5) set max_parallel_workers = 4; *Machine Configuration :-* RAM

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello Erik, Still, it would be an improvement to be able to break out of an inactive \if-branch with Ctrl-C. Yes. '\endif' is too long to type, /and/ you have to know it. Yep. \if is shorter but has been rejected. Ctrl-C should be the way out. 2. Inside an \if block \q should be given

Re: [HACKERS] \h tab-completion

On 01/25/2017 07:13 AM, Michael Paquier wrote: What I think you should do is making the code path of \\h smarter with some exceptions by using TailMatchesCS2() for ALTER. There is as well the case of DROP commands that should be treated by the way. Yes, I think that is correct approach. I have

[HACKERS] Redundant comment in ExecutePlan

Hello all, I noticed there is a redundant comment in ExecutePlan, /* * If a tuple count was supplied, we must force the plan to run without * parallelism, because we might exit early. Also disable parallelism * when writing into a relation, because no database changes are allowed * in parallel

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On 2017-02-03 08:16, Corey Huinker wrote: 0001.if_endif.v5.diff 1. Well, with this amount of interactive output it is impossible to get stuck without knowing :) This is good. Still, it would be an improvement to be able to break out of an inactive \if-branch with Ctrl-C. (I noticed that

Re: [HACKERS] Harmonization of json functions (SQLITE)

Hi 2017-02-03 8:52 GMT+01:00 Tobias Schönit : > Hello, > > > > I just saw on hackernews the announcement that sqlite includes a json > extension. > > The proposed functions are really well documented and easy to apply and I > was wondering if postgres could extend

Re: [HACKERS] proposal: session server side variables

2017-02-03 11:18 GMT+01:00 Fabien COELHO : > > We can implement XA support for variables, ale I don't think so default >> should be XA. >> > > I was answering your question, which is what you can do about the > feedback: take the one hard/strong point into account in your

[HACKERS] Harmonization of json functions (SQLITE)

Hello, I just saw on hackernews the announcement that sqlite includes a json extension. The proposed functions are really well documented and easy to apply and I was wondering if postgres could extend their json functions to be similar to those. https://www.sqlite.org/json1.html Some

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

Daniel, * Daniel Verite (dan...@manitou-mail.org) wrote: > What if we look at the change from the pessimistic angle? > An example of confusion that the change would create: > a lot of users currently choose pg_wal for the destination > directory of their archive command. Less-informed users >

Re: [HACKERS] proposal: session server side variables

> > > > >> >> My "hard" opinion is that providing an unsafe by default feature (i.e. >> which works as in some particular cases, but may fail silently if the >> transaction fails), especially for a security related use case which >> motivates the whole feature addition, is a very bad idea for the

Re: [HACKERS] proposal: session server side variables

We can implement XA support for variables, ale I don't think so default should be XA. I was answering your question, which is what you can do about the feedback: take the one hard/strong point into account in your proposal. You do not want to do that. Too bad. The argument that you keep

Re: [HACKERS] asynchronous execution

Kyotaro HORIGUCHI wrote: > I noticed that this patch is conflicting with 665d1fa (Logical > replication) so I rebased this. Only executor/Makefile > conflicted. I was lucky enough to see an infinite loop when using this patch, which I fixed by this change: diff

  1   2   >