On Thu, Feb 2, 2017 at 1:26 AM, Fujii Masao wrote:
> I'm afraid that many WAL segments would start with a continuation record
> when there are the workload of short transactions (e.g., by pgbench), and
> which would make restart_lsn go behind very much. No?
I don't quite understand this argument.
>> Yeah. Was thinking about this yesterday. How about adding entries in
>> TwoPhaseState itself (which become valid later)? Only if it does not
>> cause a lot of code churn.
>
> That's possible as well, yes.
PFA a patch which does the above. It re-uses the TwoPhaseState gxact
entries to track 2PC
From: Michael Paquier [mailto:michael.paqu...@gmail.com]
>This has not been added yet to the next CF. As Ashutosh mentioned
>things tend to be easily forgotten. So I have added it here:
>https://commitfest.postgresql.org/13/982/
Thank you for adding this problem to CF.
> I have noticed this typo
Hi all,
While testing a bit the logical replication facility, I have bumped on
the fast that psql's completion does not show the list of things
already created. Attached is a patch.
Thanks,
--
Michael
subs-psql-completion.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (
On Thu, Feb 2, 2017 at 2:13 PM, Tom Lane wrote:
> Kyotaro HORIGUCHI writes:
>> Then, the reason for the TRY-CATCH cluase is that I found that
>> some functions called from there can throw exceptions.
>
> Yes, but all LWLocks should be released by normal error recovery.
> It should not be necessar
From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
>Sorry, attached wrong patch. Here's the right one.
> The code expects that there will be two PQgetResult() calls required.
> One to fetch the result of SHOW command and the other to extract NULL.
> If we require more calls or unexpecte
On Thu, Feb 2, 2017 at 3:49 AM, Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> I think what we ought to do about this is invent additional API
> >> functions, say
> >>
> >> Oid CatalogTupleInsertWithInfo(Relation heapRel, HeapTuple tup,
> >> CatalogIndexState indstate);
> >> v
Kyotaro HORIGUCHI writes:
> Then, the reason for the TRY-CATCH cluase is that I found that
> some functions called from there can throw exceptions.
Yes, but all LWLocks should be released by normal error recovery.
It should not be necessary for this code to clean that up by hand.
If it were neces
On 1/31/17 4:57 PM, Craig de Stigter wrote:
> However, this problem was not caught by the `--check` command. I'm
> looking at the source code and it appears that pg_upgrade does not
> attempt to verify relation filenodes actually exist before proceeding,
> whether using --check or not.
The purpose
On Thu, Feb 2, 2017 at 1:34 PM, Ashutosh Bapat
wrote:
> On Thu, Feb 2, 2017 at 10:04 AM, Ashutosh Bapat
> wrote:
>> [1] https://www.postgresql.org/docs/devel/static/libpq-exec.html:
>> PQgetvalue().
> The code expects that there will be two PQgetResult() calls required.
> One to fetch the result
On 1/22/17 10:29 PM, Michael Paquier wrote:
> As now wal_level = replica has become the default for Postgres 10,
> could we consider as well making replication connections enabled by
> default in pg_hba.conf? This requires just uncommenting a couple of
> lines in pg_hba.conf.sample.
Yes, I think t
On Wed, Feb 1, 2017 at 11:09 PM, Robert Haas wrote:
Hi Robert,
Thanks for the review.
> When Andres wrote in
> https://www.postgresql.org/message-id/20161017201558.cr34stc6zvxy3...@alap3.anarazel.de
> that you should try to share only the iteration arrays, I believe that
> he meant the results
On 2017-02-01 23:27:36 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> Tom, do you have an opinion?
>
> > Yes, it's broken. split_pathtarget_at_srfs seems to be doing the right
> > thing, but then something later is recombining the last two steps.
>
> Ah, no, I take that back:
On Thu, Feb 2, 2017 at 1:23 PM, Amit Kapila wrote:
> Many thanks to you for running the show. I think it might be okay if
> one consolidated mail is sent for all the patches that are marked
> "Returned with Feedback" or "Rejected" or "Moved to next CF". OTOH,
> there is some value in sending a s
Sorry, attached wrong patch. Here's the right one.
On Thu, Feb 2, 2017 at 10:04 AM, Ashutosh Bapat
wrote:
> On Thu, Feb 2, 2017 at 8:11 AM, Higuchi, Daisuke
> wrote:
>> From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
>>> Per the documentation [1], "PQgetResult must be called repeat
On Thu, Feb 2, 2017 at 8:11 AM, Higuchi, Daisuke
wrote:
> From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
>> Per the documentation [1], "PQgetResult must be called repeatedly
>> until it returns a null pointer, indicating that the command is
>> done.". The code in PQgetResult() under
I wrote:
> Andres Freund writes:
>> Tom, do you have an opinion?
> Yes, it's broken. split_pathtarget_at_srfs seems to be doing the right
> thing, but then something later is recombining the last two steps.
Ah, no, I take that back: split_pathtarget_at_srfs is doing the wrong
thing. It's gener
On Thu, Feb 2, 2017 at 8:50 AM, Michael Paquier
wrote:
> On Tue, Jan 31, 2017 at 4:01 PM, Michael Paquier
> wrote:
>> The CF finishing soon, I have done a first pass on the patches
>> remaining on it, moving patches to the next CF or updating them. There
>> are still 48 patches still on the track
On Thu, Feb 2, 2017 at 4:57 PM, Rafia Sabih
wrote:
> Apart from the previously reported regression, there appear one more
> issue in this set of patches. At times, running a query using parallel
> hash it hangs up and all the workers including the master shows the
> following backtrace,
Ugh, than
On Thu, Feb 2, 2017 at 1:19 AM, Thomas Munro
wrote:
> On Thu, Feb 2, 2017 at 3:34 AM, Rafia Sabih
> wrote:
>> 9 | 62928.88 | 59077.909
>
> Thanks Rafia. At first glance this plan is using the Parallel Shared
> Hash in one place where it should pay off, that is loading the orders
> tabl
On Wed, Feb 1, 2017 at 10:04 PM, Robert Haas wrote:
> On Tue, Jan 31, 2017 at 6:01 AM, Amit Kapila wrote:
>> Moved this patch to next CF.
>
> So here is what seems to be the key hunk from this patch:
>
> /*
> - * Since we don't have the ability to push subplans down to workers at
> -
On 2 February 2017 at 00:13, Heikki Linnakangas wrote:
> Ok, I'll drop the second patch for now. I committed the first patch after
> fixing the things you and Michael pointed out. Thanks for the review!
dbd69118 caused small compiler warning for me.
The attached fixed it.
--
David Rowley
On 01-02-2017 00:05, Kyotaro HORIGUCHI wrote:
> - Subscriber connects with client_encoding specification and the
> output plugin pgoutput decide whether it accepts the encoding
> or not. If the subscriber doesn't, pgoutput send data without
> conversion.
>
I don't think storage without conve
Andres Freund writes:
> On 2017-02-02 00:09:03 +0100, Erik Rijkers wrote:
>> Something is broken in HEAD:
> Hm. Indeed.
> The issue is that we're generating ProjectSet nodes instead of Result
> for the top-level nodes - but we currently assume that ProjectSet nodes
> actually contain sets. I'm
On Tue, Jan 31, 2017 at 4:01 PM, Michael Paquier
wrote:
> The CF finishing soon, I have done a first pass on the patches
> remaining on it, moving patches to the next CF or updating them. There
> are still 48 patches still on the tracker when writing this email:
> Needs review: 32.
> Ready for Com
Hello.
This version makes subscriber automatically set its database
encoding to clinet_encoding (if not explicitly set). And changed
the behavior when pg_server_to_client returns NULL to ERROR from
sending original string.
At Wed, 1 Feb 2017 08:39:41 +, "Shinoda, Noriyoshi"
wrote in
> Tha
On Tue, Jan 31, 2017 at 9:13 AM, David Rowley
wrote:
> On 31 January 2017 at 13:10, David Rowley
> wrote:
>> I've attached a patch which implements this.
>
> Please disregards previous patch. (I forgot git commit before git diff
> to make the patch)
>
> I've attached the correct patch.
Moved to
On Wed, Feb 1, 2017 at 10:20 PM, Amit Kapila wrote:
> makes sense, so changed accordingly.
I have moved this patch to CF 2017-03.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hac
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.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On Tue, Jan 24, 2017 at 3:32 AM, Kevin Grittner wrote:
> I will need some time to consider that
Moved to CF 2017-03 for now. The last patch sent still applies.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
On Sat, Jan 7, 2017 at 5:30 PM, Andrey Borodin wrote:
> The new status of this patch is: Ready for Committer
I don't think that this thread has reached a conclusion yet. From what
I can see the last patch does not apply, so I have moved the patch to
next CF with "waiting on author".
--
Michael
On Fri, Jan 27, 2017 at 11:38 PM, Robert Haas wrote:
> On Fri, Jan 27, 2017 at 9:14 AM, Peter Eisentraut
> wrote:
>> On 1/19/17 12:47 PM, Andrey Borodin wrote:
>>> 4. There is some controversy on where implemented feature shall be: in
>>> separate extension (as in this patch), in db_link, in som
At Thu, 2 Feb 2017 08:46:11 +0900, Michael Paquier
wrote in
> On Thu, Feb 2, 2017 at 2:14 AM, Fujii Masao wrote:
> > The lwlock would be released when an exception occurs, so I don't think
> > that TRY-CATCH is necessary here. Or it's necessary for another reason?
>
> +PG_CATCH();
> +{
On Wed, Feb 1, 2017 at 10:02 AM, Michael Paquier
wrote:
> On Wed, Feb 1, 2017 at 1:11 AM, Peter Eisentraut
> wrote:
>> And here is a rebased patch for the original feature. I think this
>> addresses all raised concerns and suggestions now.
>
> Thanks for the new version. That looks good to me af
On 2/1/17 4:27 PM, Andres Freund wrote:
On 2017-02-02 09:22:46 +0900, Michael Paquier wrote:
On Thu, Feb 2, 2017 at 9:17 AM, Jim Nasby wrote:
Speaking of which... I have a meeting in 15 minutes to discuss moving to a
server with 4TB of memory. With current limits shared buffers maxes at 16TB,
From: Ashutosh Bapat [mailto:ashutosh.ba...@enterprisedb.com]
> Per the documentation [1], "PQgetResult must be called repeatedly
> until it returns a null pointer, indicating that the command is
> done.". The code in PQgetResult() under CONNECTION_CHECK_WRITABLE
> case, violates that. The patch f
Thank you for the comment.
At Thu, 2 Feb 2017 01:26:03 +0900, Fujii Masao wrote in
> > The attached patch does that. Usually it reads page headers only
> > on segment boundaries, but once continuation record found (or
> > failed to read the next page header, that is, the first record on
> > the
On Tue, Jan 31, 2017 at 9:31 PM, Michael Paquier
wrote:
> On Wed, Feb 1, 2017 at 1:06 AM, Robert Haas wrote:
>> On Thu, Jan 5, 2017 at 12:54 AM, Kuntal Ghosh
>> wrote:
>>> I've attached the patch with the modified changes. PFA.
>>
>> Can this patch check contrib/bloom?
>
> Only full pages are ap
On 2017-02-01 20:38:58 -0500, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 8:35 PM, Andres Freund wrote:
> > On 2017-02-01 20:30:30 -0500, Robert Haas wrote:
> >> On Wed, Feb 1, 2017 at 7:28 PM, Andres Freund wrote:
> >> > On 2016-11-28 11:40:53 -0800, Jim Nasby wrote:
> >> >> With current limits,
On Wed, Feb 1, 2017 at 8:35 PM, Andres Freund wrote:
> On 2017-02-01 20:30:30 -0500, Robert Haas wrote:
>> On Wed, Feb 1, 2017 at 7:28 PM, Andres Freund wrote:
>> > On 2016-11-28 11:40:53 -0800, Jim Nasby wrote:
>> >> With current limits, the most bgwriter can do (with 8k pages) is 1000
>> >> pa
On 2017-02-01 20:30:30 -0500, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 7:28 PM, Andres Freund wrote:
> > On 2016-11-28 11:40:53 -0800, Jim Nasby wrote:
> >> With current limits, the most bgwriter can do (with 8k pages) is 1000 pages
> >> * 100 times/sec = 780MB/s. It's not hard to exceed that w
On Wed, Feb 1, 2017 at 7:28 PM, Andres Freund wrote:
> On 2016-11-28 11:40:53 -0800, Jim Nasby wrote:
>> With current limits, the most bgwriter can do (with 8k pages) is 1000 pages
>> * 100 times/sec = 780MB/s. It's not hard to exceed that with modern
>> hardware. Should we increase the limit on b
On 2016-11-28 11:40:53 -0800, Jim Nasby wrote:
> With current limits, the most bgwriter can do (with 8k pages) is 1000 pages
> * 100 times/sec = 780MB/s. It's not hard to exceed that with modern
> hardware. Should we increase the limit on bgwriter_lru_maxpages?
FWIW, I think working on replacing b
On 2017-02-02 09:22:46 +0900, Michael Paquier wrote:
> On Thu, Feb 2, 2017 at 9:17 AM, Jim Nasby wrote:
> > Speaking of which... I have a meeting in 15 minutes to discuss moving to a
> > server with 4TB of memory. With current limits shared buffers maxes at 16TB,
> > which isn't all that far in th
On Thu, Feb 2, 2017 at 9:17 AM, Jim Nasby wrote:
> Speaking of which... I have a meeting in 15 minutes to discuss moving to a
> server with 4TB of memory. With current limits shared buffers maxes at 16TB,
> which isn't all that far in the future. While 16TB of shared buffers might
> not be a good
On 2/1/17 3:36 PM, Michael Paquier wrote:
On Thu, Feb 2, 2017 at 7:01 AM, Jim Nasby wrote:
On 2/1/17 10:27 AM, Robert Haas wrote:
This looks fine to me.
This could go without the comments, they are likely going to be
forgotten if any updates happen in the future.
I'm confused... I put the c
On Thu, Feb 2, 2017 at 2:14 AM, Fujii Masao wrote:
> The lwlock would be released when an exception occurs, so I don't think
> that TRY-CATCH is necessary here. Or it's necessary for another reason?
+PG_CATCH();
+{
+LWLockRelease(LogicalRepLauncherLock);
+PG_RE_THROW();
+
Hi,
On 2017-02-02 00:09:03 +0100, Erik Rijkers wrote:
> Something is broken in HEAD:
Hm. Indeed.
> drop table if exists t;
> create table t(c text);
> insert into t (c) values ( 'abc' ) ;
>
> select
> regexp_split_to_array(
> regexp_split_to_table(
> c
>
On Thu, Feb 2, 2017 at 7:01 AM, Jim Nasby wrote:
> On 2/1/17 10:27 AM, Robert Haas wrote:
>> This looks fine to me.
This could go without the comments, they are likely going to be
forgotten if any updates happen in the future.
> If someone wants to proactively commit this, the CF entry is
> http
Something is broken in HEAD:
drop table if exists t;
create table t(c text);
insert into t (c) values ( 'abc' ) ;
select
regexp_split_to_array(
regexp_split_to_table(
c
, chr(13) || chr(10) )
, '","' )
On 02.02.2017 01:07, Jim Nasby wrote:
On 2/1/17 8:26 AM, Nikita Glukhov wrote:
Some comments about the code: I think it would be better to
* add function for extraction of scalars from pseudo-arrays
* iterate until WJB_DONE to pfree iterator
I'm not sure what your intent here is, but if the
On Wed, Feb 1, 2017 at 6:13 PM, Masahiko Sawada wrote:
> On Wed, Feb 1, 2017 at 10:02 PM, Claudio Freire
> wrote:
>> On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada
>> wrote:
>>> Thank you for updating the patch.
>>>
>>> Whole patch looks good to me except for the following one comment.
>>> Th
Still looking at 0002.
pg_ndistinct_in disallows input, claiming that pg_node_tree does the
same thing. But pg_node_tree does it for security reasons: you could
crash the backend if you supplied a malicious value. I don't think that
applies to pg_ndistinct_in. Perhaps it will be useful to injec
On 2/1/17 8:26 AM, Nikita Glukhov wrote:
If you find it useful, I can also add support of json and other types,
such as smallint and bigint.
Yes, I'd like to have support for other types and maybe for json.
There's been previous discussion about something similar, which would be
better suppo
Alvaro Herrera writes:
> Tom Lane wrote:
>> I think what we ought to do about this is invent additional API
>> functions, say
>>
>> Oid CatalogTupleInsertWithInfo(Relation heapRel, HeapTuple tup,
>> CatalogIndexState indstate);
>> void CatalogTupleUpdateWithInfo(Relation heapRel, ItemPointer otid
On 2/1/17 10:27 AM, Robert Haas wrote:
On Tue, Jan 31, 2017 at 5:07 PM, Jim Nasby wrote:
On 11/29/16 9:58 AM, Jeff Janes wrote:
Considering a single SSD can do 70% of that limit, I would say
yes.
Next question becomes... should there even be an upper limit?
Where the contortions
On Thu, Feb 2, 2017 at 4:05 AM, Robert Haas wrote:
> On Tue, Jan 31, 2017 at 8:26 PM, Michael Paquier
> wrote:
>> pq_sendcountedtext() does some encoding conversion, which is why I
>> haven't used because we deal only with integers in this patch... Now
>> if you wish to switch to that I have real
On 2/1/17 12:03 PM, Fabien COELHO wrote:
I'm unsure whether it is a good idea, I like terse interfaces, but this
is just an opinion.
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
On Wed, Feb 01, 2017 at 04:38:59PM -0500, Robert Haas wrote:
> On Wed, Feb 1, 2017 at 1:08 PM, Andres Freund wrote:
> > On 2017-02-01 12:59:36 -0500, Tom Lane wrote:
> >> David Fetter writes:
> >> > On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote:
> >> >> Make psql's \set display variabl
On 1/27/17 4:14 AM, Greg Stark wrote:
On 25 January 2017 at 20:06, Jim Nasby wrote:
GUCs support SET LOCAL, but that's not the same as local scoping because the
setting stays in effect unless the substrans aborts. What I'd like is the
ability to set a GUC in a plpgsql block *and have the settin
On Wed, Feb 1, 2017 at 1:08 PM, Andres Freund wrote:
> On 2017-02-01 12:59:36 -0500, Tom Lane wrote:
>> David Fetter writes:
>> > On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote:
>> >> Make psql's \set display variables in alphabetical order.
>>
>> > This is a substantial usability impro
On 2 Feb. 2017 08:32, "Tom Lane" wrote:
Robert Haas writes:
> Also, including the GID in the WAL for each COMMIT/ABORT PREPARED
> doesn't seem inordinately expensive to me.
I'm confused ... isn't it there already? If not, how do we handle
reconstructing 2PC state from WAL at all?
Right. Per
Tom Lane wrote:
> The source of both of those problems is that in some places, we
> did CatalogOpenIndexes and then used the CatalogIndexState for
> multiple tuple inserts/updates before doing CatalogCloseIndexes.
> The patch dealt with these either by not touching them, just
> leaving the simple_
I wrote:
> Evidently collateral damage from 2f5c9d9c9. But I'd suggest waiting
> to fix it until you can also do s/simple_heap_delete/CatalogTupleDelete/
> as I proposed in
> https://www.postgresql.org/message-id/462.1485902...@sss.pgh.pa.us
> I'll go make that happen right now, now that I realize
On Wed, Feb 1, 2017 at 10:02 PM, Claudio Freire wrote:
> On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada wrote:
>> Thank you for updating the patch.
>>
>> Whole patch looks good to me except for the following one comment.
>> This is the final comment from me.
>>
>> /*
>> * lazy_tid_reaped() --
On Mon, Jan 2, 2017 at 7:32 AM, Ashutosh Bapat
wrote:
> PFA the patch (pg_dp_join_v6.patch) with some bugs fixed and rebased
> on the latest code.
Maybe not surprisingly given how fast things are moving around here
these days, this needs a rebase.
Apart from that, my overall comment on this patc
On Wed, Feb 1, 2017 at 5:47 PM, Masahiko Sawada wrote:
> Thank you for updating the patch.
>
> Whole patch looks good to me except for the following one comment.
> This is the final comment from me.
>
> /*
> * lazy_tid_reaped() -- is a particular tid deletable?
> *
> * This has the right
Hi
2017-01-24 21:33 GMT+01:00 Pavel Stehule :
>
>
>
>>
>>> Perhaps that's as simple as renaming all the existing _ns_* functions to
>>> _block_ and then adding support for pragmas...
>>>
>>> Since you're adding cursor_options to PLpgSQL_expr it should probably be
>>> removed as an option to exec_
On Tue, Jan 31, 2017 at 3:05 AM, Claudio Freire wrote:
> On Mon, Jan 30, 2017 at 5:51 AM, Masahiko Sawada
> wrote:
>>
>> * We are willing to use at most maintenance_work_mem (or perhaps
>> * autovacuum_work_mem) memory space to keep track of dead tuples. We
>> * initially allocate an ar
Alvaro Herrera writes:
> Tom Lane wrote:
>> However, the patch misses an
>> important part of such an abstraction layer by not also converting
>> catalog-related simple_heap_delete() calls into some sort of
>> CatalogTupleDelete() operation. It is certainly a peculiarity of
>> PG heaps that delet
On 02/01/2017 08:28 PM, Heikki Linnakangas wrote:
>
> But if there's no pressing reason to change it, let's leave it alone. It's
> not related to the problem at hand, right?
>
Yes, I agree with you: we should better leave it as it is.
--
Konstantin Knizhnik
Postgres Professional: http://www.po
On 02/01/2017 08:30 PM, REIX, Tony wrote:
>
> Hi Konstantin,
>
> Please run:*/opt/IBM/xlc/13.1.3/bin/xlc -qversion* so that I know your exact
> XLC v13 version.
>
IBM XL C/C++ for AIX, V13.1.3 (5725-C72, 5765-J07)
> I'm building on Power7 and not giving any architecture flag to XLC.
>
> I'm not
On 02/01/2017 10:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> Also, including the GID in the WAL for each COMMIT/ABORT PREPARED
>> doesn't seem inordinately expensive to me.
> I'm confused ... isn't it there already? If not, how do we handle
> reconstructing 2PC state from WAL at all?
>
>
Hello,
We could just issue interactive-only warnings when:
- A user types a branching condition command which sets the branch inactive
- A user types a command or query when the current branch is inactive.
The warnings could be specific about state, something like:
psql session is now in an i
On Thu, Feb 2, 2017 at 3:34 AM, Rafia Sabih
wrote:
> 9 | 62928.88 | 59077.909
Thanks Rafia. At first glance this plan is using the Parallel Shared
Hash in one place where it should pay off, that is loading the orders
table, but the numbers are terrible. I noticed that it uses batch
fi
Robert Haas writes:
> Also, including the GID in the WAL for each COMMIT/ABORT PREPARED
> doesn't seem inordinately expensive to me.
I'm confused ... isn't it there already? If not, how do we handle
reconstructing 2PC state from WAL at all?
regards, tom lane
--
Sent v
Pavel Stehule writes:
> This patch is not possible to compile on today master
> commands/collationcmds.o: In function `AlterCollation':
> /home/pavel/src/postgresql/src/backend/commands/collationcmds.c:297:
> undefined reference to `CatalogUpdateIndexes'
Evidently collateral damage from 2f5c9d9c9
On Fri, Dec 23, 2016 at 12:54 AM, Ashutosh Bapat
wrote:
> Another question: do we want to commit the code for creating
> unflattened hierarchy separately or along with partition-wise join?
Probably separately. I suggest posting a series of two (or perhaps
more) patches on the same thread. 'git
On Mon, Jan 30, 2017 at 2:30 AM, Masahiko Sawada wrote:
> "txn" can be used for abbreviation of "Transaction", so for example
> pg_fdw_txn_resolver?
> I'm also fine to change the module and function name.
If we're judging the relative clarity of various ways of abbreviating
the word "transaction"
Hi
2017-01-24 18:44 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 1/15/17 5:53 AM, Pavel Stehule wrote:
> > the regress test fails
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x007bbc2b in pattern_char_isalpha (locale_is_c=0 '\000',
> > locale=
On Tue, Jan 31, 2017 at 9:05 PM, Michael Paquier
wrote:
>> Personally I don't think lack of access to the GID justifies blocking 2PC
>> logical decoding. It can be added separately. But it'd be nice to have
>> especially if it's cheap.
>
> I think it should be added reading this thread.
+1. If o
On Tue, Jan 31, 2017 at 8:26 PM, Michael Paquier
wrote:
> pq_sendcountedtext() does some encoding conversion, which is why I
> haven't used because we deal only with integers in this patch... Now
> if you wish to switch to that I have really no arguments against.
OK, I see. Well, I guess it's se
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> While playing with prepared statements in psql, I noticed that EXECUTE
> tab-completes the list of active prepared statements, but DEALLOCATE
> does not.
> Attached is a patch to fix this.
Good idea, but I think it would be be
I wrote:
> Attached is a finished version that includes hooks for all the variables
> for which they were clearly sensible. (FETCH_COUNT doesn't seem to really
> need one, and I didn't do anything with HISTSIZE or IGNOREEOF either.
> It might be worth bringing the latter two into the hooks paradig
On Tue, Jan 31, 2017 at 5:07 PM, Jim Nasby wrote:
> On 11/29/16 9:58 AM, Jeff Janes wrote:
>> Considering a single SSD can do 70% of that limit, I would say
>> yes.
>>
>> Next question becomes... should there even be an upper limit?
>>
>>
>> Where the contortions needed to prevent calc
>
>
> You can also run "make check" directly in the "src/bin/psql" directory.
Previously, that didn't do anything, but now that I've created a TAP test
it does. It doesn't, however, run the psql regress tests. But at least I
can use the two commands in combination and not have to run *all* TAP te
On Wed, Feb 1, 2017 at 8:53 AM, Corey Huinker
wrote:
>
>> Run make check-world (as opposed to just make check )
>
>
> I'll give that a shot.
>
That was it. Tests don't run if you don't invoke them. Thanks.
On 2017-02-01 12:59:36 -0500, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote:
> >> Make psql's \set display variables in alphabetical order.
>
> > This is a substantial usability improvement which nevertheless is hard
> > to imagine changes thi
On Sat, Jan 28, 2017 at 9:09 PM, Ashutosh Sharma wrote:
> okay. Thanks. I have done changes on top of this patch.
+ ptr = (char *) itup + IndexInfoFindDataOffset(itup->t_info);
+ Assert(ptr <= uargs->page + BLCKSZ);
I think this should be promoted to an ereport(); the
David Fetter writes:
> On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote:
>> Make psql's \set display variables in alphabetical order.
> This is a substantial usability improvement which nevertheless is hard
> to imagine changes things that scripts relied on. I think it's worth
> back-patc
>
> However I would say yes, it should provide some feedback... This means
> probably adding a new prompt substitution "%". In the worst
> case, the prompt should reflect the current stack, or at least the top of
> the task...
>
We could just issue interactive-only warnings when:
- A user types a
Hi hackers,
While playing with prepared statements in psql, I noticed that EXECUTE
tab-completes the list of active prepared statements, but DEALLOCATE
does not.
Attached is a patch to fix this.
Cheers,
Ilmari
--
"I use RMS as a guide in the same way that a boat captain would use
a lighthous
On Tue, Jan 31, 2017 at 6:05 AM, Dilip Kumar wrote:
>> 0002-hash-support-alloc-free-v14.patch:
>>
>>
>> + if (tb->alloc)
>> + {
>>
>> The memory for tb->alloc is allocated always, is the if check still
>> required?
>
> In parallel case, only first worker will call SH_CREATE, other worker
> will on
Hi Konstantin,
Please run: /opt/IBM/xlc/13.1.3/bin/xlc -qversion so that I know your exact
XLC v13 version.
I'm building on Power7 and not giving any architecture flag to XLC.
I'm not using -qalign=natural . Thus, by default, XLC use -qalign=power, which
is close to natural, as explained at:
On 02/01/2017 04:12 PM, Konstantin Knizhnik wrote:
On 01.02.2017 15:39, Heikki Linnakangas wrote:
On 02/01/2017 01:07 PM, Konstantin Knizhnik wrote:
Attached please find my patch for XLC/AIX.
The most critical fix is adding __sync to pg_atomic_fetch_add_u32_impl.
The comment in this file says t
On Wed, Feb 01, 2017 at 04:25:25PM +, Tom Lane wrote:
> Make psql's \set display variables in alphabetical order.
This is a substantial usability improvement which nevertheless is hard
to imagine changes things that scripts relied on. I think it's worth
back-patching.
Best,
David.
--
David F
Hello Corey,
There is a spurious empty line added at the very end of "mainloop.h":
+
#endif /* MAINLOOP_H */
Not in my diff, but that's been coming and going in your diff reviews.
Strange. Maybe this is linked to the warning displayed with "git apply" when
I apply the diff.
I
On Wed, Feb 1, 2017 at 5:36 PM, Kyotaro HORIGUCHI
wrote:
> Hello, while looking another bug, I found that standby cannot
> shutdown after DROP SUBSCRIPTION.
>
> standby=# CREATE SUBSCRPTION sub1 ...
> standby=#
> standby=# DROP SUBSCRIPTION sub1;
>
> Ctrl-C to the standby fails to work. Apply
On Sun, Jan 22, 2017 at 4:45 PM, Stephen Frost wrote:
> Amit,
>
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > On Sun, Jan 22, 2017 at 3:27 AM, Stephen Frost
> wrote:
> > > * Simon Riggs (si...@2ndquadrant.com) wrote:
> > >> On 12 August 2016 at 01:01, Tom Lane wrote:
> > >> > Michael Paq
On 01.02.2017 15:39, Heikki Linnakangas wrote:
In summary, I came up with the attached. It's essentially your patch,
with tweaks for the above-mentioned things. I don't have a powerpc
system to test on, so there are probably some silly typos there.
Attached pleased find fixed version of
1 - 100 of 147 matches
Mail list logo