Hello,
The following page says:
https://www.postgresql.org/docs/devel/static/ecpg-connect.html#ecpg-set-connection
--
EXEC SQL AT connection-name SELECT ...;
If your application uses multiple threads of execution, they cannot share a
connection c
On Wed, May 31, 2017 at 2:20 PM, Michael Paquier
wrote:
> Yeah, see 0e0f43d6 for example. A simple fix is to look at
> IsUnderPostmaster when creating, altering or dropping a subscription
> in subscriptioncmds.c.
Yeah, below patch fixes that.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.ent
Hi, hackers!
2017-06-01 1:50 GMT+05:00 Kevin Grittner :
> > The main difference between b-tree and gist index while searching for a
> > target tuple is that in gist index, we can determine if there is a match or
> > not at any level of the index.
>
> Agreed. A gist scan can fail at any level, but
Hi,
While using psql, I found that tab completion for subscription and
publication baskslash commands are not supported. After investigated
other backslash command that is not supported, I found \if, \elif,
\else, \endif and \?.
Attached patch tweaks tab completion for some backslash commands.
Re
On 1 June 2017 at 04:16, Teodor Sigaev wrote:
> I found an example where v10 chooses extremely non-optimal plan:
> select
> i::int as a,
> i::int + 1 as b,
> 0 as c
> into t
> from
> generate_series(1,32) as i;
>
> create unique index i on t (c, a);
>
> explain analyze
> SELECT
>
On Wed, May 31, 2017 at 7:19 PM, Andres Freund wrote:
> At the moment $subject doesn't allow parallelism, because copy.c's
> pg_plan_query() invocation doesn't set the CURSOR_OPT_PARALLEL_OK
> flag.
>
> To me that appears to be an oversight rather than intentional. A
> somewhat annoying one at th
On 2017-05-31 23:51:08 -0400, Peter Eisentraut wrote:
> I think the easiest and safest thing to do now is to just prevent
> parallel plans in the walsender. See attached patch. This prevents the
> hang in the select_parallel tests run under your new test setup.
I'm not quite sure I can buy this.
On 5/31/17 02:51, Noah Misch wrote:
> On Tue, May 30, 2017 at 01:30:35AM +, Noah Misch wrote:
>> On Thu, May 18, 2017 at 10:27:51PM -0400, Peter Eisentraut wrote:
>>> On 5/18/17 11:11, Noah Misch wrote:
IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is past due for
your s
On 1 June 2017 at 11:51, Peter Eisentraut
wrote:
> Unifying the signal handling and query processing further seems like a
> good idea, but the patches are pretty involved, so I suggest to put them
> into the next commit fest.
I had a quick look a the idea of just getting rid of walsenders as a
s
On 5/29/17 22:01, Noah Misch wrote:
> On Tue, May 23, 2017 at 01:45:59PM -0400, Andres Freund wrote:
>> On May 23, 2017 1:42:41 PM EDT, Petr Jelinek
>> wrote:
>>> Hi,
>>>
>>> so this didn't really move anywhere AFAICS, do we think the approach
>>> I've chosen is good or do we want to do something
On 5/23/17 13:57, Petr Jelinek wrote:
> On 23/05/17 19:45, Andres Freund wrote:
>>
>>
>> On May 23, 2017 1:42:41 PM EDT, Petr Jelinek
>> wrote:
>>> Hi,
>>>
>>> so this didn't really move anywhere AFAICS, do we think the approach
>>> I've chosen is good or do we want to do something else here?
>>
On 1 June 2017 at 08:15, Andres Freund wrote:
> Hi,
>
> when using
> $ cat ~/.proverc
> -j9
>
> some tests fail for me in 9.4 and 9.5. E.g. src/bin/script's tests
> yields a lot of fun like:
> $ (cd ~/build/postgres/9.5-assert/vpath/src/bin/scripts/ && make check)
> ...
> # LOG: received immedia
On Thu, May 25, 2017 at 4:14 AM, Petr Jelinek
wrote:
> Hi,
>
> I finally had time to properly analyze this, and turns out we've been
> all just trying to fix symptoms and the actual problems.
>
> All the locking works just fine the way it is in master. The issue with
> deadlock with apply comes fr
On 2017/06/01 11:13, Mark Dilger wrote:
>> On May 31, 2017, at 6:32 PM, Amit Langote
>> wrote:
>>
>> On 2017/06/01 4:50, Robert Haas wrote:
>>> On Wed, May 31, 2017 at 3:40 PM, Mark Dilger
>>> wrote:
recent changes have introduced the :location field to the partboundspec
in pg_catalog
On 5/31/17 09:40, Robert Haas wrote:
> On Tue, May 30, 2017 at 3:01 PM, Peter Eisentraut
> wrote:
>> On 5/25/17 17:26, Peter Eisentraut wrote:
>>> Another way to fix this particular issue is to not verify the
>>> replication slot name before doing the drop. After all, if the name is
>>> not valid
On 31 May 2017 at 08:43, Craig Ringer wrote:
> Hi all
>
> More and more I'm finding it useful to extend PostgresNode for project
> specific helper classes. But PostgresNode::get_new_node is a factory
> that doesn't provide any mechanism for overriding, so you have to
> create a PostgresNode then r
On 5/30/17 13:25, Masahiko Sawada wrote:
> I think this cause is that the relation status entry could be deleted
> by ALTER SUBSCRIPTION REFRESH before corresponding table sync worker
> starting. Attached patch fixes issues reported on this thread so far.
This looks like a reasonable change, but i
On 5/31/17 05:16, Petr Jelinek wrote:
> I've been running tests on this overnight on another machine where I was
> able to reproduce the original issue within few runs (once I found what
> causes it) and so far looks good.
I'll give people another day or so to test this before committing.
--
Pe
> On May 31, 2017, at 6:32 PM, Amit Langote
> wrote:
>
> On 2017/06/01 4:50, Robert Haas wrote:
>> On Wed, May 31, 2017 at 3:40 PM, Mark Dilger wrote:
>>> recent changes have introduced the :location field to the partboundspec
>>> in pg_catalog.pg_class. This means that if two identical table
On 1 June 2017 at 09:23, Andres Freund wrote:
> Even if we decide this is necessary, I *strongly* suggest trying to get
> the existing standby decoding etc wrapped up before starting something
> nontrival afresh.
Speaking of such, I had a thought about how to sync logical slot state
to physical
On 2017/06/01 10:26, Peter Eisentraut wrote:
> On 5/31/17 02:17, Kuntal Ghosh wrote:
>> On Wed, May 31, 2017 at 12:58 AM, Masahiko Sawada
>> wrote:
>>>
>>> I'd say we can fix this issue by just changing the query. Attached
>>> patch changes the query so that it can handle publication name
>>> cor
On 2017-05-31 21:27:56 -0400, Stephen Frost wrote:
> Craig,
>
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
> > TL;DR: replication origins track LSN without timeline. This is
> > ambiguous when physical failover is present since /
> > can now represent more than one state due to
On 1 June 2017 at 09:36, Andres Freund wrote:
> On 2017-05-31 21:33:26 -0400, Stephen Frost wrote:
>> > This only starts becoming an issue once logical replication slots can
>> > exist on replicas and be maintained to follow the master's slot state.
>> > Which is incomplete in Pg10 (not exposed to
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 1 June 2017 at 09:27, Stephen Frost wrote:
> > * Craig Ringer (cr...@2ndquadrant.com) wrote:
> >> TL;DR: replication origins track LSN without timeline. This is
> >> ambiguous when physical failover is present since /
> >>
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-05-31 21:33:26 -0400, Stephen Frost wrote:
> > > This only starts becoming an issue once logical replication slots can
> > > exist on replicas and be maintained to follow the master's slot state.
> > > Which is incomplete in Pg10 (not e
On 2017-05-31 21:33:26 -0400, Stephen Frost wrote:
> > This only starts becoming an issue once logical replication slots can
> > exist on replicas and be maintained to follow the master's slot state.
> > Which is incomplete in Pg10 (not exposed to users) but I plan to
> > finish getting in for pg11
On 1 June 2017 at 09:23, Andres Freund wrote:
> Hi,
>
> On 2017-06-01 09:12:04 +0800, Craig Ringer wrote:
>> TL;DR: replication origins track LSN without timeline. This is
>> ambiguous when physical failover is present since /
>> can now represent more than one state due to timelin
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2017-05-31 21:27:56 -0400, Stephen Frost wrote:
> > Uh, TL;DR, wow? Why isn't this something which needs to be addressed
> > before PG10 can be released?
>
> Huh? Slots are't present on replicas, ergo there's no way for the whole
> issue
On 1 June 2017 at 09:27, Stephen Frost wrote:
> Craig,
>
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>> TL;DR: replication origins track LSN without timeline. This is
>> ambiguous when physical failover is present since /
>> can now represent more than one state due to timeline
On 2017/06/01 4:50, Robert Haas wrote:
> On Wed, May 31, 2017 at 3:40 PM, Mark Dilger wrote:
>> recent changes have introduced the :location field to the partboundspec
>> in pg_catalog.pg_class. This means that if two identical tables with
>> identical partitioning scheme are created, but one is
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> TL;DR: replication origins track LSN without timeline. This is
> ambiguous when physical failover is present since /
> can now represent more than one state due to timeline forks with
> promotions. Replication origins should tr
On 5/31/17 02:17, Kuntal Ghosh wrote:
> On Wed, May 31, 2017 at 12:58 AM, Masahiko Sawada
> wrote:
>>
>> I'd say we can fix this issue by just changing the query. Attached
>> patch changes the query so that it can handle publication name
>> correctly, the query gets complex, though.
>>
> In is_pu
Hi,
On 2017-06-01 09:12:04 +0800, Craig Ringer wrote:
> TL;DR: replication origins track LSN without timeline. This is
> ambiguous when physical failover is present since /
> can now represent more than one state due to timeline forks with
> promotions. Replication origins should t
Hi all
TL;DR: replication origins track LSN without timeline. This is
ambiguous when physical failover is present since /
can now represent more than one state due to timeline forks with
promotions. Replication origins should track timelines so we can tell
the difference, I propose
David,
* David G. Johnston (david.g.johns...@gmail.com) wrote:
> On Tue, May 30, 2017 at 8:41 PM, Stephen Frost wrote:
> > * David G. Johnston (david.g.johns...@gmail.com) wrote:
> > > On Fri, May 26, 2017 at 7:47 AM, Stephen Frost
> > wrote:
> > > > * Robins Tharakan (thara...@gmail.com) wrote:
On 1 June 2017 at 08:15, Andres Freund wrote:
> Hi,
>
> when using
> $ cat ~/.proverc
> -j9
>
> some tests fail for me in 9.4 and 9.5. E.g. src/bin/script's tests
> yields a lot of fun like:
> $ (cd ~/build/postgres/9.5-assert/vpath/src/bin/scripts/ && make check)
> ...
> # LOG: received immedia
On 1 June 2017 at 01:13, Tom Lane wrote:
> Alvaro Herrera writes:
>> My main concern is how widely is the buildfarm going to test the new
>> test frameworks. If we backpatch PostgresNode-based tests to 9.2, are
>> buildfarm animals going to need to be reconfigured to use
>> --enable-tap-tests?
>
Hi,
when using
$ cat ~/.proverc
-j9
some tests fail for me in 9.4 and 9.5. E.g. src/bin/script's tests
yields a lot of fun like:
$ (cd ~/build/postgres/9.5-assert/vpath/src/bin/scripts/ && make check)
...
# LOG: received immediate shutdown request
# WARNING: terminating connection because of c
On 2017-05-31 14:24:38 -0700, Andres Freund wrote:
> On 2017-05-24 10:52:37 -0400, Robert Haas wrote:
> > On Wed, May 24, 2017 at 10:32 AM, Andres Freund wrote:
> > > Well, but then we should just remove minval/maxval if we can't rely on
> > > it.
> >
> > That seems like a drastic overreaction to
Simplifying $subject. There are typos in xlogfuncs.c. So Either
s/pg_xlog_switch/pg_switch_wal
Or
Remove "pg_xlog_switch" from the comments.
Attached patches both ways.
Regards,
Neha
On Sat, May 20, 2017 at 1:08 AM, Neha Khatri wrote:
> While reading some code, noticed that the headers of
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 30, 2017 at 11:49 PM, Stephen Frost wrote:
> > ... and I don't believe that we should be asking the
> > implementors of channel binding to also implement support for multiple
> > TLS libraries in PostgreSQL in order to test that t
Hi,
At the moment $subject doesn't allow parallelism, because copy.c's
pg_plan_query() invocation doesn't set the CURSOR_OPT_PARALLEL_OK
flag.
To me that appears to be an oversight rather than intentional. A
somewhat annoying one at that, because it's not uncommong to use COPY to
execute reports
> On May 31, 2017, at 4:00 PM, Alvaro Herrera wrote:
>
> Mark Dilger wrote:
>
relpartbound
|
Mark Dilger wrote:
> >>
> >> relpartbound
> >> |
> >>
> On May 31, 2017, at 3:42 PM, Andres Freund wrote:
>
> On 2017-05-31 15:38:58 -0700, Mark Dilger wrote:
>>> Normal users aren't going to make sense of node trees in the first
>>> place. You should use pg_get_expr for it:
>>> postgres[3008][1]=# SELECT pg_get_expr(relpartbound, oid) FROM pg_cla
On 2017-05-31 15:38:58 -0700, Mark Dilger wrote:
> > Normal users aren't going to make sense of node trees in the first
> > place. You should use pg_get_expr for it:
> > postgres[3008][1]=# SELECT pg_get_expr(relpartbound, oid) FROM pg_class
> > WHERE relpartbound IS NOT NULL;
> > ┌──
> On May 31, 2017, at 3:17 PM, Andres Freund wrote:
>
> On 2017-05-31 15:06:06 -0700, Mark Dilger wrote:
>> That's cold comfort, given that most users will be looking at the pg_class
>> table and not writing C code that compares Node objects. I wrote a bit of
>> regression test logic that check
On 2017-05-31 15:06:06 -0700, Mark Dilger wrote:
> That's cold comfort, given that most users will be looking at the pg_class
> table and not writing C code that compares Node objects. I wrote a bit of
> regression test logic that checks, and sure enough the relpartbound field
> shows up as unequa
> On May 31, 2017, at 2:49 PM, Alvaro Herrera wrote:
>
> Mark Dilger wrote:
>> Hackers,
>>
>> recent changes have introduced the :location field to the partboundspec
>> in pg_catalog.pg_class. This means that if two identical tables with
>> identical partitioning scheme are created, but one is
On Fri, May 26, 2017 at 10:51 AM, Magnus Hagander wrote:
> I would definitely suggest putting it in HEAD (and thus, v10) for a while to
> get some real world exposure before backpatching. But if it does work out
> well in the end, then we can certainly consider backpatching it. But given
> the dif
On Mon, May 29, 2017 at 5:26 AM, Amit Kapila wrote:
>> But I think, we can also take step-by-step approach even for v11. If
>> we agree that it is ok to silently do the updates as long as we
>> document the behaviour, we can go ahead and do this, and then as a
>> second step, implement error handl
Mark Dilger wrote:
> Hackers,
>
> recent changes have introduced the :location field to the partboundspec
> in pg_catalog.pg_class. This means that if two identical tables with
> identical partitioning scheme are created, but one is done before a change
> to gram.y, and the other after a change t
On 2017-05-24 10:52:37 -0400, Robert Haas wrote:
> On Wed, May 24, 2017 at 10:32 AM, Andres Freund wrote:
> > Well, but then we should just remove minval/maxval if we can't rely on
> > it.
>
> That seems like a drastic overreaction to me.
Well, either they work, or they don't. But since it turns
On Wed, May 31, 2017 at 3:02 PM, Shubham Barai wrote:
> I have been accepted as GSoC student for the project "Explicitly support
> predicate locks in index access methods besides b-tree". I want to share my
> approach for implementation of page level predicate locking in gist index.
For the bene
On 05/31/2017 07:49 AM, Robert Haas wrote:
On Tue, May 30, 2017 at 9:12 PM, Craig Ringer wrote:
Thoughts? Backpatch new TAP methods, etc, into back branches routinely?
[...]
When customers start to doubt that, then they
become reluctant to apply new minor versions in their entirety and ask
Hello everyone,
I have been accepted as GSoC student for the project "Explicitly support
predicate locks in index access methods besides b-tree". I want to share my
approach for implementation of page level predicate locking in gist index.
Any suggestions will be appreciated.
Proposal
The
On Tue, May 30, 2017 at 6:50 PM, Álvaro Hernández Tortosa
wrote:
> Actually this Python patch seems to ultimately rely on the same OpenSSL
> functions as your implementation.
Yup. My point is that even if those APIs are undocumented, I think
that they are not going to disappear either.
>
On Wed, May 31, 2017 at 3:40 PM, Mark Dilger wrote:
> recent changes have introduced the :location field to the partboundspec
> in pg_catalog.pg_class. This means that if two identical tables with
> identical partitioning scheme are created, but one is done before a change
> to gram.y, and the ot
Hackers,
recent changes have introduced the :location field to the partboundspec
in pg_catalog.pg_class. This means that if two identical tables with
identical partitioning scheme are created, but one is done before a change
to gram.y, and the other after a change to gram.y, the relpartbound fiel
On Wed, May 31, 2017 at 8:18 PM, Andres Freund wrote:
> On 2017-05-31 18:22:18 +0200, Magnus Hagander wrote:
> > However, the client can't access the pid of the server as it is now,
> > and its the client that has to create the name.
>
> I don't think that's actually true? Doesn't the wire proto
On Wed, May 31, 2017 at 11:18 AM, Andres Freund wrote:
> On 2017-05-31 18:22:18 +0200, Magnus Hagander wrote:
>> However, the client can't access the pid of the server as it is now,
>> and its the client that has to create the name.
>
> I don't think that's actually true? Doesn't the wire protoco
Tom, Alvaro,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Alvaro Herrera writes:
> > My main concern is how widely is the buildfarm going to test the new
> > test frameworks. If we backpatch PostgresNode-based tests to 9.2, are
> > buildfarm animals going to need to be reconfigured to use
> > --enab
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On the other hand, we tell our users that we only back-patch security
> and stability fixes.
Perhaps I missed where this changed, but my recollection is that we also
back-patch bug-fixes, and I don't think we should change that.
> When cus
On May 31, 2017 11:28:18 AM PDT, Robert Haas wrote:
>On Wed, May 31, 2017 at 1:46 PM, Andres Freund
>wrote:
>> On 2017-05-31 13:27:28 -0400, Dilip Kumar wrote:
>>> On Wed, May 31, 2017 at 12:53 PM, Robert Haas
> wrote:
>>> > Well, SH_TYPE's members SH_ELEMENT_TYPE *data and void
>*private_data
On Wed, May 31, 2017 at 1:46 PM, Andres Freund wrote:
> On 2017-05-31 13:27:28 -0400, Dilip Kumar wrote:
>> On Wed, May 31, 2017 at 12:53 PM, Robert Haas wrote:
>> > Well, SH_TYPE's members SH_ELEMENT_TYPE *data and void *private_data
>> > are not going to work in DSM, because they are pointers.
On Tue, May 30, 2017 at 7:43 PM, Masahiko Sawada wrote:
> There is an incomplete sentence at top of subtrans.c file. I think the
> commit 88e66d19 removed the whole line mistakenly.
Thanks for the patch. Sorry for the mistake that made it necessary. Committed.
--
Robert Haas
EnterpriseDB: htt
On Wed, May 31, 2017 at 7:01 AM, Dilip Kumar wrote:
> On Wed, May 31, 2017 at 7:54 AM, tushar wrote:
>> centos@centos-cpula bin]$ ./postgres --single postgres -D m1data
>> PostgreSQL stand-alone backend 10beta1
>> backend> create subscription sub connection 'dbname=postgres port=5433
>> user=cent
On 2017-05-31 18:22:18 +0200, Magnus Hagander wrote:
> However, the client can't access the pid of the server as it is now,
> and its the client that has to create the name.
I don't think that's actually true? Doesn't the wire protocol always
include the PID, which is then exposed with PQbackendP
On Wed, May 31, 2017 at 9:22 AM, Magnus Hagander wrote:
> Moving this one over to -hackers to discuss the fix, as this is clearly an
> issue.
>
> Right now, pg_basebackup will use the pid of the *client* process to
> generate it's ephemeral slot name. Per this report that seems like it can
> defin
On 05/31/2017 11:36 AM, Tom Lane wrote:
> However, I grant your point that some extensions may have outside
> constraints that mandate using -Wconversion, so to the extent that
> we can keep key headers like postgres.h from triggering those warnings,
> it's probably worth doing. I suspect you're
On 2017-05-31 11:57:16 -0400, Alvaro Herrera wrote:
> My vote would be to backpatch it all the way.
+1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-05-31 13:27:28 -0400, Dilip Kumar wrote:
> On Wed, May 31, 2017 at 12:53 PM, Robert Haas wrote:
> > Well, SH_TYPE's members SH_ELEMENT_TYPE *data and void *private_data
> > are not going to work in DSM, because they are pointers. You can
> > doubtless come up with a way around that proble
On Wed, May 31, 2017 at 12:53 PM, Robert Haas wrote:
> Well, SH_TYPE's members SH_ELEMENT_TYPE *data and void *private_data
> are not going to work in DSM, because they are pointers. You can
> doubtless come up with a way around that problem, but I guess the
> question is whether that's actually
On Fri, Mar 17, 2017 at 6:49 PM, Thomas Munro
wrote:
> Right. If I temporarily hack neqjoinsel() thus:
>
> result = 1.0 - result;
> +
> + if (jointype == JOIN_SEMI)
> + result = 1.0;
> +
> PG_RETURN_FLOAT8(result);
> }
I was looking into this problem. IMHO, t
Alvaro Herrera writes:
> My main concern is how widely is the buildfarm going to test the new
> test frameworks. If we backpatch PostgresNode-based tests to 9.2, are
> buildfarm animals going to need to be reconfigured to use
> --enable-tap-tests?
Yes. The animals that are doing it at all are u
Alvaro Herrera writes:
> My vote would be to backpatch it all the way.
That's my thought too. Otherwise it'll be five years before extension
authors can stop worrying about this issue.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Wed, May 31, 2017 at 11:16 AM, Dilip Kumar wrote:
> I agree with you. But, if I understand the use case correctly we need
> to store the TupleDesc for the RECORD in shared hash so that it can be
> shared across multiple processes. I think this can be achieved with
> the simplehash as well.
>
>
On Tue, May 30, 2017 at 8:15 AM, Mithun Cy wrote:
> On Tue, May 30, 2017 at 10:16 AM, Mithun Cy
> wrote:
>> Thanks Robert,
>
> Sorry, there was one more mistake ( a typo) in dump_now() instead of
> using pfree I used free corrected same in the new patch v10.
+ *contrib/autoprewarm.c
Wr
On 05/30/2017 09:52 PM, Stephen Frost wrote:
Tom,
Um ... but we still have 2 live pre-9.4 branches. If your proposal
doesn't extend to back-porting all of this stuff as far as 9.2,
I don't see what this is really buying. We'd still need version cutoff
checks in the tests.
I don't believe t
Hi!
I found an example where v10 chooses extremely non-optimal plan:
select
i::int as a,
i::int + 1 as b,
0 as c
into t
from
generate_series(1,32) as i;
create unique index i on t (c, a);
explain analyze
SELECT
t1.a, t1.b,
t2.a, t2.b,
t3.a, t3.b,
t4.a, t4.b,
On Wed, May 31, 2017 at 12:20 AM, Ludovic Vaugeois-Pepin <
ludovi...@gmail.com> wrote:
> On Tue, May 30, 2017 at 9:32 PM, Magnus Hagander
> wrote:
> > On Tue, May 30, 2017 at 9:14 PM, Ludovic Vaugeois-Pepin
> > wrote:
> >>
> >> I ran into the issue described below with 10.0 beta. The error I got
On Wed, May 31, 2017 at 6:53 PM, Tom Lane wrote:
> Alexander Korotkov writes:
> > I've discovered that PostgreSQL is able to run following kind of queries
> in
> > order to change statistic-gathering target for an indexed expression.
>
> > ALTER INDEX index_name ALTER COLUMN expr SET STATISTICS
Robert Haas wrote:
> On Tue, May 30, 2017 at 9:12 PM, Craig Ringer wrote:
> > Thoughts? Backpatch new TAP methods, etc, into back branches routinely?
>
> So, on the one hand, it is certainly useful to be able to commit tests
> to back-branches as well as to master, and it's hard to do that if the
Christoph Berg wrote:
> Re: Tom Lane 2017-05-31 <28752.1496238...@sss.pgh.pa.us>
> > Next question: should we back-patch this change, or just do it in HEAD?
>
> Debian "needs" it for 9.6, but I've already pushed the s390x patch in
> the original posting, so I could just live with it being just in
Alexander Korotkov writes:
> I've discovered that PostgreSQL is able to run following kind of queries in
> order to change statistic-gathering target for an indexed expression.
> ALTER INDEX index_name ALTER COLUMN expr SET STATISTICS stat_target;
> It's been previously discussed in [1].
> I th
Hackers,
I've discovered that PostgreSQL is able to run following kind of queries in
order to change statistic-gathering target for an indexed expression.
ALTER INDEX index_name ALTER COLUMN expr SET STATISTICS stat_target;
It's been previously discussed in [1].
I think this should be fixed not
Chapman Flack writes:
> On 05/31/17 01:26, Tom Lane wrote:
>> Hm. I think it would be better to use DatumGetInt32 here. Arguably,
>> direct use of GET_4_BYTES and its siblings should only appear in
>> DatumGetFoo macros.
> Like so? These are the 4 sites where {GET,SET}_n_BYTES got introduced
>
> On May 31, 2017, at 7:58 AM, Bruce Momjian wrote:
>
> On Wed, May 31, 2017 at 07:53:22AM -0700, Mark Dilger wrote:
>>> Just to clarify, the TEMPORARY clause would allow the tablespace to
>>> start up empty, while normal tablespaces can't do that, right? One big
>>> problem is that we don't ha
Andres Freund wrote:
> On 2017-05-30 18:21:10 -0400, Alvaro Herrera wrote:
> > Alexander Sosna wrote:
> > > Hi,
> > >
> > > I can reproduce a segmentation fault when creating a BRIN concurrently
> > > with set pages_per_range and autosummarize.
> >
> > Pushed fix just now. Please give it a try.
On Wed, May 31, 2017 at 10:57 AM, Robert Haas wrote:
>> Simplehash provides an option to provide your own allocator function
>> to it. So in the allocator function, you can allocate memory from DSA.
>> After it reaches some threshold it expands the size (double) and it
>> will again call the alloc
Re: Tom Lane 2017-05-31 <28752.1496238...@sss.pgh.pa.us>
> OK, this looks good to me. Just to make sure everyone's on the
> same page, what I propose to do is simplify all our platform-specific
> Makefiles that use either -fpic or -fPIC to use -fPIC unconditionally.
> This affects the netbsd, linu
On Wed, May 31, 2017 at 07:53:22AM -0700, Mark Dilger wrote:
> > Just to clarify, the TEMPORARY clause would allow the tablespace to
> > start up empty, while normal tablespaces can't do that, right? One big
> > problem is that we don't have any way to prevent non-temporary
> > tablespaces from be
On Tue, May 30, 2017 at 2:45 AM, Dilip Kumar wrote:
> On Tue, May 30, 2017 at 1:09 AM, Thomas Munro
> wrote:
>>> * Perhaps simplehash + an LWLock would be better than dht, but I
>>> haven't looked into that. Can it be convinced to work in DSA memory
>>> and to grow on demand?
>
> Simplehash prov
> On May 31, 2017, at 6:04 AM, Bruce Momjian wrote:
>
> On Wed, May 31, 2017 at 07:53:53AM -0400, Robert Haas wrote:
>> On Tue, May 30, 2017 at 6:50 PM, Mark Dilger wrote:
On May 29, 2017, at 11:53 AM, Bruce Momjian wrote:
Right now we don't document that temp_tablespaces can use
>>>
On Wed, May 31, 2017 at 2:35 AM, Ashutosh Bapat
wrote:
> AFAIK, work_mem comes from memory private to the process whereas this
> memory will come from the shared memory pool.
I don't think that really matters. The point of limits like work_mem
is to avoid driving the machine into swap. Allocati
On Tue, May 30, 2017 at 9:12 PM, Craig Ringer wrote:
> Thoughts? Backpatch new TAP methods, etc, into back branches routinely?
So, on the one hand, it is certainly useful to be able to commit tests
to back-branches as well as to master, and it's hard to do that if the
infrastructure isn't there.
On 2017-05-31 11:16, Petr Jelinek wrote:
[...]
Thanks to Mark's offer I was able to study the issue as it happened and
found the cause of this.
[0001-Improve-handover-logic-between-sync-and-apply-worker.patch]
This looks good:
-- out_20170531_1141.txt
100 -- pgbench -c 90 -j 8 -T 60 -P 12
On Wed, May 31, 2017 at 1:44 AM, Noah Misch wrote:
> IMMEDIATE ATTENTION REQUIRED.
I should be able to complete review and testing by Friday. If there
are problems I might not take action until Monday; otherwise I
should be able to do so on Friday.
--
Kevin Grittner
VMware vCenter Server
https
On Wed, May 31, 2017 at 7:54 AM, tushar wrote:
> centos@centos-cpula bin]$ ./postgres --single postgres -D m1data
> PostgreSQL stand-alone backend 10beta1
> backend> create subscription sub connection 'dbname=postgres port=5433
> user=centos' publication p with (create_slot=0,enabled=off);
> 2017-
Christoph Berg writes:
> Re: Tom Lane 2017-05-30 <1564.1496176...@sss.pgh.pa.us>
>> It'd be interesting if people could gather similar numbers on other
>> platforms of more real-world relevance, such as ppc64. But based on
>> this small sample, I wouldn't object to just going to -fPIC across
>> t
1 - 100 of 113 matches
Mail list logo
