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 th
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 individually; I thin
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
>> https://www.postgresql.org/message-id/20140514155204.ge23...@awork2.anarazel
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 seq1
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 column using PQgetvalue. Think of
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 more close relation
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:
>> >>
>> >> After recent commit's 7819ba1e and 25216c98, this patch requires
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 we
>> may have to define procid as int8 in SQL f
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
>> additional sequential I/O bandwid
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
>> have to say about this point.
>
> It seems to
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 inste
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 hi
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
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 patch for a prompt change.
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 u
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 if
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 PQgetvalue
On 2/2/17 4:39 PM, Corey Huinker wrote:
On Wed, Feb 1, 2017 at 4:58 PM, Jim Nasby mailto:jim.na...@bluetreble.com>> 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
going on. That's similar to
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
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, Da
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 for any point of view.
In a
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 bounci
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 = 1 | w = 2 | w = 3 | w = 4 | w = 5 | w = 6 |
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 hand,
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 model for being able to apply a stream
> >>
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 transactions that can roll back individua
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
--
Sent via pgsql-hackers mailing
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 ability to have multipl
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 course,
> stringToNode() assumes saf
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 database owners.
> GRANT ALL
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 partition is
>> always inclusive a
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
> Instrumentation; like DMA trans
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
> backend for that.
Hmm, yea
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
> problems should be caught
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 th
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 trivi
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
> >> rebase. Attached is the rebased patch.
> >>
> >
> > Th
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 conclusion: halfway in bet
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 exactly for this pu
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 problems. It's certainly not a t
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
> -++---+---+---+---+--
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 take it as given that we
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 altogether and allow any valid pg_hba rule to invoke a
>>>
>
> 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
> imp
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 here :-)
>>
>> If there's o
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 that doesn't make sense to m
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 c
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 for the destination
>>
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 the moment I've added
> ps
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 or a related value s
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 next \else, \elif, or \endif.
> > if: error, ignor
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 BRIN
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
> else: true, executing commands
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.
>
> There are some big Power ma
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
>
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 functionality bound to this key
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 Heroku, and so can do very
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 took a look at this.
- The handling of the extension s
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 moving around).
You must mean m
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 for DB2 9.7. So yes,
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 to scan by itself the VM of each
> > >> relation and decide based on
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
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
>>> On Thu, Feb 2, 2017 at 2:36 PM, Michael Paquier
>>> wrote:
>>> > On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane wrote:
> 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 MODU
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 Ctrl+C
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 apprec
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 think it is probably reaso
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
> signedness. Objections
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 Intel,
>
> 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 u
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 rawpage.c,
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 of a "bytea"
is not m
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 universe
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.
regards, tom lane
--
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 that care about alig
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 (b) it
>> would bother us
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 other one and committed
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 but has been rejected. C
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 like it to me. You changed a bunch of places that say
>> UInt3
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
>> On Thu, Feb 2, 2017 at 2:36 PM, Michael Paquier
>> wrote:
>> > On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane wrote:
>> >> Kyotaro HORIGUCHI writes:
>> >>> Then, the reason for
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 ou
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 GetDatum you choose macr
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:
>> Hello hackers,
>>
>> The view information_schema.constra
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 \e
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 to have
>> approach 1. From what I gather, it'
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 src/commo
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 th
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 is because of a join
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
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 pr
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
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 mo
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 in
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 their json functions to be simil
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 proposal.
>
> You do not
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 func
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
> that
>
>
>
>
>>
>> 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 p
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 on
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 --git a/src/backend/executor/exec
1 - 100 of 107 matches
Mail list logo