Hello Corey,
In cases where there was a boolean parsing failure, and ON_ERROR_STOP is
on, the error message no longer speak of a future which the session does
not have. I could left the ParseVariableBool() message as the only one, but
wasn't sure that that was enough of an error message on its
On 07/02/17 01:00, Michael Paquier wrote:
> On Tue, Feb 7, 2017 at 2:07 AM, Petr Jelinek
> wrote:
>> On 06/02/17 05:15, Michael Paquier wrote:
>>> Hi all,
>>>
>>> Lately I have bumped into a case where it would have been useful to
>>> make the difference between a failure because of a slot already
On Tue, Feb 7, 2017 at 10:44 AM, Mithun Cy wrote:
>
> ==
> One problem now I have kept it open is multiple "auto pg_prewarm dump"
> can be launched even if already a dump/load worker is running by
> calling launch_pg_prewarm_dump. I can avoid this by dropping a
> lock-file before s
On Tue, Feb 7, 2017 at 11:53 AM, Beena Emerson wrote:
> Hello,
>
> Thank you for the updated patch.
>
> On Tue, Feb 7, 2017 at 10:44 AM, Mithun Cy
> wrote:
>>
>> Hi all,
>> Here is the new patch which fixes all of above comments, I changed the
>> design a bit now as below
>>
>> What is it?
>> ===
Hello,
Thank you for the updated patch.
On Tue, Feb 7, 2017 at 10:44 AM, Mithun Cy
wrote:
> Hi all,
> Here is the new patch which fixes all of above comments, I changed the
> design a bit now as below
>
> What is it?
> ===
> A pair of bgwrokers one which automatically dumps buffer pool'
Hi Hackers,
I just want to discuss adding of a new statistics view that provides
the information of wal writing details as follows
postgres=# \d pg_stat_wal_writer
View "pg_catalog.pg_stat_wal_writer"
Column | Type | Collation | Nullable
On 2017/02/06 20:51, Ruben Buchatskiy wrote:
> Also we have seen in the mailing list that Kumar Rajeev had been
> investigating this idea too, and he reported that the results were
> impressive (unfortunately, without specifying more details):
>
> https://www.postgresql.org/message-id/BF2827DCCE55
On Mon, Feb 06, 2017 at 08:54:13PM +0100, Christoph Berg wrote:
> The majority of voices here was in favor of using \gx, so here is
> another version of the same patch which implements that.
Patch is useful, and works as documented.
Maybe it could get a test or two in src/test/regress/*/psql.*
B
Hi all,
Here is the new patch which fixes all of above comments, I changed the
design a bit now as below
What is it?
===
A pair of bgwrokers one which automatically dumps buffer pool's block
info at a given interval and another which loads those block into
buffer pool when
the server resta
On Mon, Jan 23, 2017 at 2:46 PM, Kuntal Ghosh
wrote:
> I've looked into the patch. I've some comments regarding that.
>
> +#define PARALLEL_KEY_QUERY_TEXTUINT64CONST(0xE010)
> It should be UINT64CONST(0xE00A)
>
> + query_len = strlen(query_data) + 1;
> +
On Mon, Jan 30, 2017 at 9:15 PM, Peter Geoghegan wrote:
>> IIUC worker_wait() is only being used to keep the worker around so its
>> files aren't deleted. Once buffile cleanup is changed to be
>> ref-counted (in an on_dsm_detach hook?) then workers might as well
>> exit sooner, freeing up a worke
Horiguchi-san,
On 2017/01/31 12:45, Kyotaro HORIGUCHI wrote:
> I noticed that this patch is conflicting with 665d1fa (Logical
> replication) so I rebased this. Only executor/Makefile
> conflicted.
With the latest set of patches, I observe a crash due to an Assert failure:
#0 0x003969632625
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -6083,7 +6083,7 @@ StartupXLOG(void)
ereport(LOG,
(errmsg("database system was shut
diff --git a/src/test/regress/sql/plpgsql.sql b/src/test/regress/sql/plpgsql.sql
--- a/src/test/regress/sql/plpgsql.sql
+++ b/src/test/regress/sql/plpgsql.sql
@@ -2219,15 +2219,15 @@ drop type eitype cascade;
-- SQLSTATE and SQLERRM test
--
-create function excpt_test1() returns void as $$
+cr
diff --git a/src/backend/access/transam/multixact.c
b/src/backend/access/transam/multixact.c
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -3342,7 +3342,7 @@ pg_get_multixact_members(PG_FUNCTION_ARG
} mxact;
MultiXactId mxid = PG_GETA
diff --git a/contrib/ltree/ltxtquery_io.c b/contrib/ltree/ltxtquery_io.c
--- a/contrib/ltree/ltxtquery_io.c
+++ b/contrib/ltree/ltxtquery_io.c
@@ -96,7 +96,7 @@ gettoken_query(QPRS_STATE *state, int32
if (*flag)
On Mon, Feb 6, 2017 at 10:40 PM, Amit Kapila wrote:
>> Maybe we should call them "unused pages".
>
> +1. If we consider some more names for that column then probably one
> alternative could be "empty pages".
Yeah, but I think "unused" might be better. Because a page could be
in use (as an overf
On Tue, Feb 7, 2017 at 2:04 AM, Robert Haas wrote:
> On Sun, Feb 5, 2017 at 11:36 PM, Ashutosh Sharma
> wrote:
>>> Committed with those changes.
>>
>> Thanks for above corrections and commit. But, There are couple of
>> things that we might have to change once the patch for 'WAL in Hash
>> Index
On Mon, Feb 6, 2017 at 10:28 PM, Tom Lane wrote:
> Amit Kapila writes:
>> Hmm. Consider that the first time relcahe invalidation occurs while
>> computing id_attrs, so now the retry logic will compute the correct
>> set of attrs (considering two indexes, if we take the example given by
>> Alvaro
On Mon, Feb 6, 2017 at 11:54 PM, Tom Lane wrote:
> After some discussion among the release team, we've concluded that the
> best thing to do is to push Pavan's/my patch into today's releases.
> This does not close the matter by any means: we should continue to
> study whether there are related bu
On Mon, Feb 6, 2017 at 9:55 PM, Heikki Linnakangas wrote:
> I rebased the SCRAM authentication patches over current master. Here you
> are.
Thanks! Nice to see you around.
> So, if you haven't paid attention on this for a while, now would be a good
> time to have another look at the patch. I bel
On Tue, Feb 7, 2017 at 3:12 AM, Aleksander Alekseev
wrote:
> No, I'm afraid `make distclean` doesn't help. I've re-checked twice.
Hm. I can see the failure on macos and python2 builds as well with the
set of patches applied. And the master branch is working properly.
This needs some investigation
Still about 0003. dependencies.c comment at the top of the file should
contain some details about what is it implementing and a general
description of the algorithm and data structures. As before, it's best
to have the main entry point build_mv_dependencies at the top, the other
public functions,
On Fri, Feb 3, 2017 at 5:04 AM, Antonin Houska wrote:
> 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, w
On Tue, Feb 7, 2017 at 2:07 AM, Petr Jelinek
wrote:
> On 06/02/17 05:15, Michael Paquier wrote:
>> Hi all,
>>
>> Lately I have bumped into a case where it would have been useful to
>> make the difference between a failure because of a slot already
>> dropped and an internal failure of Postgres. Is
On Mon, Feb 6, 2017 at 3:43 PM, Corey Huinker
wrote:
> I did some more tests. I found a subtlety that I missed before: when
>> running under ON_ERROR_STOP, messages are not fully consistent:
>>
>> sh> cat test.sql
>> \set ON_ERROR_STOP on
>> \if error
>>\echo NO
>> \endif
>> \echo NO
>>
Looking at 0003, I notice that gram.y is changed to add a WITH ( .. )
clause. If it's not specified, an error is raised. If you create
stats with (ndistinct) then you can't alter it later to add
"dependencies" or whatever; unless I misunderstand, you have to drop the
statistics and create another
On 2/6/17 10:54 AM, Fujii Masao wrote:
> Yes, that's an option. And, if we add dbid to pg_stat_subscription,
> I'm tempted to add all the pg_subscription's columns except subconninfo
> into pg_stat_subscription. Since subconninfo may contain security-sensitive
> information, it should be excluded.
On 2/5/17 11:52 PM, Michael Paquier wrote:
>> In "CREATE SUBSCRIPTION ... PUBLICATION" and "ALTER SUBSCRIPTION ... SET
>> PUBLICATION" cases, the publication defined in the publisher side should be
>> specified. But, with this patch, the tab-completion for PUBLICATION shows
>> the publications defi
On 2/2/17 2:59 PM, Simon Riggs wrote:
> We currently have REPLICATION to mean "physical replication".
Well, it doesn't really mean that. The same facilities are used to
control access to both logical and physical replication.
> I think if we have another capability for logical replication then w
Tomas Vondra wrote:
> On 02/01/2017 11:52 PM, Alvaro Herrera wrote:
> > Nearby, some auxiliary functions such as n_choose_k and
> > num_combinations are not documented. What it is that they do? I'd
> > move these at the end of the file, keeping the important entry points
> > at the top of the file
On 2017-02-06 16:06:25 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-02-06 15:39:10 -0500, Peter Eisentraut wrote:
> >> On 2/6/17 6:28 AM, Konstantin Knizhnik wrote:
> >>> I wonder why do we prohibit now configuration of Postgres without mmap?
>
> >> It's not really prohibited, but i
Andres Freund writes:
> On 2017-02-06 15:39:10 -0500, Peter Eisentraut wrote:
>> On 2/6/17 6:28 AM, Konstantin Knizhnik wrote:
>>> I wonder why do we prohibit now configuration of Postgres without mmap?
>> It's not really prohibited, but it's not something that people generally
>> need, and we wa
2017-02-06 21:36 GMT+01:00 Fabien COELHO :
>
> Hello,
>
> I'll work on my proposal in v11 time. Maybe in this time Postgres will
>> support autonomous transactions.
>>
>
> Maybe.
>
> The variables syntax should be better integrated to core - it should be
>> implemented without getter/setter functi
On Mon, 2017-02-06 at 22:44 +0300, Alexander Korotkov wrote:
> Results looks strange for me. I wonder why there is difference
> between
> lwlock-power-1.patch and lwlock-power-3.patch? From my intuition, it
> shouldn't be there because it's not much difference between them.
> Thus, I
> have foll
On 2017-02-06 15:39:10 -0500, Peter Eisentraut wrote:
> On 2/6/17 6:28 AM, Konstantin Knizhnik wrote:
> > I wonder why do we prohibit now configuration of Postgres without mmap?
>
> It's not really prohibited, but it's not something that people generally
> need, and we want to keep the number of c
>
> I did some more tests. I found a subtlety that I missed before: when
> running under ON_ERROR_STOP, messages are not fully consistent:
>
> sh> cat test.sql
> \set ON_ERROR_STOP on
> \if error
>\echo NO
> \endif
> \echo NO
>
> sh> ./psql < test.sql
> SET
> # ok
> unrecognized value
On 2/6/17 6:28 AM, Konstantin Knizhnik wrote:
> I wonder why do we prohibit now configuration of Postgres without mmap?
It's not really prohibited, but it's not something that people generally
need, and we want to keep the number of configuration variations low.
--
Peter Eisentraut
Hello,
I'll work on my proposal in v11 time. Maybe in this time Postgres will
support autonomous transactions.
Maybe.
The variables syntax should be better integrated to core - it should be
implemented without getter/setter functions.
Yes, a nicer syntax would be great.
Note that setter/
On Sun, Feb 5, 2017 at 11:36 PM, Ashutosh Sharma wrote:
>> Committed with those changes.
>
> Thanks for above corrections and commit. But, There are couple of
> things that we might have to change once the patch for 'WAL in Hash
> Indexes' gets checked-in.
>
> 1) The test-case result needs to be c
On 2/4/17 7:30 AM, Michael Paquier wrote:
> We could perhaps just use has_sequence_privilege() and return NULL if
> the caller of pg_sequences does not have select and usage access to a
> given sequence? Please see the patch attached.
Committed with documentation updates. Thanks.
--
Peter Eisen
Consolidated Fabien's TAP test additions with v7, in case anyone else wants
to be reviewing.
Patch applies (with "patch"), make check ok, psql tap test ok.
I did some more tests. I found a subtlety that I missed before: when
running under ON_ERROR_STOP, messages are not fully consistent:
The majority of voices here was in favor of using \gx, so here is
another version of the same patch which implements that.
Christoph
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
new file mode 100644
index ae58708..e0302ea
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/d
Hi,
On 2017-02-03 20:01:03 +0300, Alexander Korotkov wrote:
> Using assembly in lwlock.c looks rough. This is why I refactored it by
> introducing new atomic operation pg_atomic_fetch_mask_add_u32 (see
> lwlock-power-2.patch). It checks that all masked bits are clear and then
> adds to variable.
On Mon, Feb 6, 2017 at 2:32 PM, Fabien COELHO wrote:
>
> Do you think the TAP tests would benefit from having the input described
>> in a q(...) block rather than a string?
>>
>
> My 0.02€: Not really, so I would not bother. It breaks perl indentation
> and logic for a limited benefit. Maybe add
On Mon, Feb 6, 2017 at 8:28 PM, Bernd Helmle wrote:
> Am Montag, den 06.02.2017, 16:45 +0300 schrieb Alexander Korotkov:
> > I tried lwlock-power-2.patch on multicore Power machine we have in
> > PostgresPro.
> > I realized that using labels in assembly isn't safe. Thus, I removed
> > labels and
Do you think the TAP tests would benefit from having the input described
in a q(...) block rather than a string?
My 0.02€: Not really, so I would not bother. It breaks perl indentation
and logic for a limited benefit. Maybe add comments if you feel that a
test case is unclear.
--
Fabien.
-
On 2/2/17 12:43 PM, Peter Moser wrote:
> Hereby, we used the following commands to create both patches:
> git diff --no-prefix origin/master -- src/ ':!src/test/*' >
> tpg_primitives_out_v4.patch
>
> git diff --no-prefix origin/master -- src/test/ >
> tpg_primitives_out_tests_v2.patch
>
> We have
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
On Mon, Feb 6, 2017 at 11:21 AM, Corey Huinker
wrote:
>
>> Find attached a small patch to improve tap tests, which also checks that
>>> psql really exited by checking that nothing is printed afterwards.
>>>
>>
>>
> Do you think the TAP tests would benefit from having the input described
> in a q(
After some discussion among the release team, we've concluded that the
best thing to do is to push Pavan's/my patch into today's releases.
This does not close the matter by any means: we should continue to
study whether there are related bugs or whether there's a more principled
way of fixing this
No, I'm afraid `make distclean` doesn't help. I've re-checked twice.
On Mon, Feb 06, 2017 at 12:52:11PM -0300, Alvaro Herrera wrote:
> Aleksander Alekseev wrote:
> > Hello.
> >
> > Good to know that the work on this great feature continues!
> >
> > However this set of patches does not pass `make
On Sun, Feb 5, 2017 at 9:42 PM, Pavan Deolasee wrote:
> On Mon, Feb 6, 2017 at 5:41 AM, Peter Geoghegan wrote:
>> On Sun, Feb 5, 2017 at 4:09 PM, Robert Haas wrote:
>> > I don't think this kind of black-and-white thinking is very helpful.
>> > Obviously, data corruption is bad. However, this bu
Hello,
PFA the updated patches.
On Fri, Jan 27, 2017 at 2:17 PM, Beena Emerson
wrote:
> Hello Andres,
>
> Thank you for your review.
>
> On Fri, Jan 27, 2017 at 12:39 AM, Andres Freund
> wrote:
>
>> Hi,
>>
>> On 2017-01-23 11:35:11 +0530, Beena Emerson wrote:
>> > Please find attached an update
Alvaro Herrera writes:
> Tom Lane wrote:
>> Better to fix the callers so that they don't have the assumption you
>> refer to. Or maybe we could adjust the API of RelationGetIndexAttrBitmap
>> so that it returns all the sets needed by a given calling module at
>> once, which would allow us to guar
On Mon, Feb 6, 2017 at 5:24 AM, Michael Paquier
wrote:
> On Sat, Feb 4, 2017 at 6:39 AM, Robert Haas wrote:
> > 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
Am Montag, den 06.02.2017, 16:45 +0300 schrieb Alexander Korotkov:
> I tried lwlock-power-2.patch on multicore Power machine we have in
> PostgresPro.
> I realized that using labels in assembly isn't safe. Thus, I removed
> labels and use relative jumps instead (lwlock-power-2.patch).
> Unfortunat
Tom Lane wrote:
> Better to fix the callers so that they don't have the assumption you
> refer to. Or maybe we could adjust the API of RelationGetIndexAttrBitmap
> so that it returns all the sets needed by a given calling module at
> once, which would allow us to guarantee they're consistent.
No
On 06/02/17 17:33, Fujii Masao wrote:
> On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
> wrote:
>> On 03/02/17 19:38, Fujii Masao wrote:
>>> 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 +09
On 06/02/17 05:15, Michael Paquier wrote:
> Hi all,
>
> Lately I have bumped into a case where it would have been useful to
> make the difference between a failure because of a slot already
> dropped and an internal failure of Postgres. Is there any interest for
> support of IE and INE for CREATE
Amit Kapila writes:
> Hmm. Consider that the first time relcahe invalidation occurs while
> computing id_attrs, so now the retry logic will compute the correct
> set of attrs (considering two indexes, if we take the example given by
> Alvaro above.). However, the attrs computed for hot_* and key
On Sun, Feb 5, 2017 at 5:11 AM, Petr Jelinek
wrote:
> On 03/02/17 19:38, Fujii Masao wrote:
>> 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
>
>
> Find attached a small patch to improve tap tests, which also checks that
>> psql really exited by checking that nothing is printed afterwards.
>>
>
>
Do you think the TAP tests would benefit from having the input described in
a q(...) block rather than a string?
q(\if false
\echo a
\elif inv
Tobias Bussmann writes:
> another typo taken over from commit log:
> s/Tobias Bussman/Tobias Bussmann/
Will fix, thanks!
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Fujii Masao writes:
> On Tue, Feb 7, 2017 at 12:36 AM, Tom Lane wrote:
>> If the proposal is to have SHOW report something other than the setting
>> of the variable, that's not a great plan either. It's generally important
>> that the output of SHOW be something that's acceptable to SET, as not
Hi
2017-02-03 9:17 GMT+01:00 Kyotaro HORIGUCHI :
> Hello. This is the new version of this patch.
>
> - Rebased to the current master (555494d)
> PUBLICATION/SUBSCRIPTION stuff conflicted.
>
> - Fix a bug of CREATE INDEX(0012-Simplify-completion-for-CREATE-INDEX.
> patch).
> CREATE INDEX ON no
On Tue, Feb 7, 2017 at 12:36 AM, Tom Lane wrote:
> Fujii Masao writes:
>> On Mon, Feb 6, 2017 at 4:01 PM, Tsunakawa, Takayuki
>> wrote:
>>> I don't have a strong opinion on that, but I think a bit that it would be
>>> better to reflect the effective setting, i.e. SHOW displays huge_pages as
>>
On Mon, Feb 6, 2017 at 1:52 PM, Michael Paquier
wrote:
> On Sun, Feb 5, 2017 at 5:04 AM, Fujii Masao wrote:
>> With this patch, when normal users type TAB after SUBSCRIPTION,
>> they got "permission denied" error. I don't think that's acceptable.
>
> Right, I can see that now. pg_stat_get_subscri
On 2017-02-06 10:40, Heikki Linnakangas wrote:
> On 02/06/2017 04:50 AM, Josh Soref wrote:
>> NUL-terminated -> NULL-terminated
>
> When we're talking about NUL-terminated strings, NUL refers to the NUL
> ASCII character. NULL usually refers to a NULL pointer. We're probably
> not consistent about
Aleksander Alekseev wrote:
> Hello.
>
> Good to know that the work on this great feature continues!
>
> However this set of patches does not pass `make check-world` on my
> laptop.
>
> Here is how I build and test PostgreSQL:
>
> https://github.com/afiskon/pgscripts/blob/master/full-build.sh
I
Fujii Masao writes:
> On Mon, Feb 6, 2017 at 4:01 PM, Tsunakawa, Takayuki
> wrote:
>> I don't have a strong opinion on that, but I think a bit that it would be
>> better to reflect the effective setting, i.e. SHOW displays huge_pages as
>> off, not try.
> Not sure if this is best way to do tha
On Mon, Feb 6, 2017 at 4:01 PM, Tsunakawa, Takayuki
wrote:
> Hello, all
>
> Could you give me your opinions on whether the SHOW command should display
> the effective value or the specified value for huge_pages? During the review
> of "Supporting huge_pages on Windows", which is now shifted to
Hello.
Good to know that the work on this great feature continues!
However this set of patches does not pass `make check-world` on my
laptop.
Here is how I build and test PostgreSQL:
https://github.com/afiskon/pgscripts/blob/master/full-build.sh
Error message:
http://afiskon.ru/s/0b/258c6e4f1
On Mon, Feb 6, 2017 at 1:24 PM, Michael Paquier
wrote:
> On Sat, Feb 4, 2017 at 6:39 AM, Robert Haas wrote:
>> 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?
On Sun, Feb 5, 2017 at 10:24 PM, Michael Paquier
wrote:
>> So... somebody want to tally up the votes here?
>
> Here is what I have, 6 votes clearly stated:
> 1. Rename nothing: Daniel,
> 2. Rename directory only: Andres
> 3. Rename everything: Stephen, Vladimir, David S, Michael P (with
> aliases
On Wed, Feb 1, 2017 at 8:25 PM, Robert Haas wrote:
> 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
On Fri, Feb 3, 2017 at 11:31 PM, Bernd Helmle wrote:
> > UPD: It appears that Postgres Pro have access to big Power machine
> > now.
> > So, I can do testing/benchmarking myself.
>
> We currently also have access to a LPAR on an E850 machine with 4
> sockets POWER8 running a Ubuntu 16.04 LTS Serv
Andres Freund wrote:
> On 2017-02-05 21:05:50 -0500, Josh Soref wrote:
> > A complete diff would be roughly 130k. I've recently tried to submit a
> > similarly sized patch to another project and it was stuck in
> > moderation (typically mailing lists limit attachments to around 40k).
>
> IIRC 13
I rebased the SCRAM authentication patches over current master. Here you
are.
I'm trying to whack this into the final shape that it could actually be
committed. The previous thread on SCRAM authentication has grown
ridiculously long and meandered into all kinds of details, so I thought
it's b
Andres Freund wrote:
> To show what I mean here's an *unpolished* and *barely tested* patch
> implementing the first of my suggestions.
>
> Alvaro, Pavan, I think should address the issue as well?
Hmm, interesting idea. Maybe a patch along these lines is a good way to
make index-list cache less
Tom Lane wrote:
> Pavan Deolasee writes:
> > 2. In the second patch, we tried to recompute attribute lists if a relcache
> > flush happens in between and index list is invalidated. We've seen problems
> > with that, especially it getting into an infinite loop with
> > CACHE_CLOBBER_ALWAYS. Not c
2017-01-10 12:53 GMT+03:00 Alexander Korotkov :
>
> 1. What project ideas we have?
>
>
Hi!
We would like to propose a project on rewriting PostgreSQL executor from
traditional Volcano-style [1] to so-called push-based architecture as
implemented in
Hyper [2][3] and VitesseDB [4]. The idea is to
Attached v02 version (rebased to HEAD).
--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/access/gist/gistutil.c b/src/backend/access/gist/gistutil.c
index f92baed..1dfaba2 100644
--- a/src/backend/access/gist/gistutil.c
+++
I tried to rebuild Postgres without mmap and the problem disappears
(pgbench with -C doesn't cause connection limit exhaustion any more).
Unfortunately there is no any convenient way to configure PostgreSQL not
to use mmap.
I have to edit sysv_shmem.c file, commenting
#ifndef EXEC_BACKEND
#defi
Am 04.02.2017 um 18:57 schrieb Tom Lane :
> Right now the question is whether individual items are
> correctly/adequately documented.
> Allow statements prepared with PREPARE to be given parallel plans (Amit
> Kapila, Tobias Bussman)
another typo taken over from commit log:
s/Tobias Bussman/Tob
On 02/06/2017 12:52 PM, Josh Soref wrote:
Did you want me to submit emails for the remaining portions from
https://github.com/jsoref/postgres/commits/spelling
Ah, yes please. Post them over and I'll have a look at those as well.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers
sent the previous mail before completing my reply. Sorry for that.
Here's the rest of the reply.
>>
>> + if (bms_num_members(outer_relids) > 1)
>>
>> Seems like bms_get_singleton_member could be used.
>>
>> +* Partitioning scheme in join relation indicates a possibilty that
Heikki wrote:
> I pushed most of these. Except for the below:
> optimisation -> optimization et al.
> Most of our code is written with the American spelling,
> but the British spelling isn't wrong,
> so I don't want to go around changing them all.
Sure
As you'll see, my approach is to aim for c
El 05/02/17 a las 21:57, Tomas Vondra escribió:
>
> +1 to not rushing fixes into releases. While I think we now finally
> understand the mechanics of this bug, the fact that we came up with
> three different fixes in this thread, only to discover issues with each
> of them, warrants some caution.
On Thu, Feb 2, 2017 at 2:41 AM, Robert Haas wrote:
> 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 ne
Last update on the problem.
Using kdb tool (thank's to Tony Reix for advice and help) we get the
following trace of Poastgres backend in existing stack trace:
pvthread+073000 STACK:
[005E1958]slock+000578 (005E1958, 80001032 [??])
[9558].simple_lock+58 ()
[00651DBC]vm_re
On 02/05/2017 01:05 AM, Masahiko Sawada wrote:
I think "laucher" should be "launcher". Attached patch fixes it.
Fixed, thanks!
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacker
On 02/06/2017 04:50 AM, Josh Soref wrote:
It's now split more or less to your suggestion:
https://github.com/jsoref/postgres/commits/spelling
Thanks!
I pushed most of these. Except for the below:
optimisation -> optimization et al.
Most of our code is written with the American spelling, bu
Find attached a small patch to improve tap tests, which also checks that psql
really exited by checking that nothing is printed afterwards.
. It is better with the attachement.
--
Fabien.diff --git a/src/bin/psql/t/001_if.pl b/src/bin/psql/t/001_if.pl
index 68c9b15..a703cab 100644
--- a/src/b
# elif error
"\\if false\n\\elif error\n\\endif\n"
# ignore commands on error (stdout must be empty)
"\\if error\n\\echo NO\n\\else\n\\echo NO\n\\endif\n"
Those are already in the regression (around line 2763 of
expected/psql.out), are you saying we should have them in TAP as well?
Sh
On 2017/01/24 15:35, Amit Langote wrote:
> On 2017/01/24 15:11, Michael Paquier wrote:
>> On Tue, Jan 24, 2017 at 2:14 PM, Amit Langote
>> wrote:
>>> Some contrib functions fail to fail sooner when relations of unsupported
>>> relkinds are passed, resulting in error message like one below:
>>>
>>>
> 6 февр. 2017 г., в 4:57, Peter Geoghegan написал(а):
>
> I meant that I find the fact that there were no user reports in all
> these years to be a good reason to not proceed for now in this
> instance.
Well, we had some strange situations with indexes (see below for example) but I
couldn’t e
97 matches
Mail list logo