On 2017-04-21 23:50:41 -0400, Tom Lane wrote:
> Attached are a couple of patches that represent a plausible Plan B.
> The first one changes the postmaster to run its signal handlers without
> specifying SA_RESTART. I've confirmed that that seems to fix the
> select_parallel-test-takes-a-long-time
On Sat, Apr 22, 2017 at 9:04 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Simon Riggs wrote:
>>> Replication lag tracking for walsenders
>>>
>>> Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication.
>
>> Did anyone notice that this seems to be causing buildfarm member 'tern'
>>
On 2017-04-17 21:16:57 -0700, Andres Freund wrote:
> I've since the previous update reviewed Petr's patch, which he since has
> updated over the weekend. I'll do another round tomorrow, and will see
> how it looks. I think we might need some more tests for this to be
> committable, so it might no
On 2017-04-20 13:32:10 +0200, Petr Jelinek wrote:
> On 20/04/17 02:09, Andres Freund wrote:
> > On 2017-04-17 21:16:57 -0700, Andres Freund wrote:
> > I'm working on some infrastructure around this. Not sure if it needs to
> > be committed, but it's certainly useful for evaluation. Basically it's
Here is a v3 with a more precise comment.
Looks good to me. I have marked the patch status as "Ready for
committer".
Ok. Thanks. When/if committed, it might trigger a few rebase of other
pending patches. I'll see about that then.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-
I wrote:
> Attached is a lightly-tested draft patch that converts the postmaster to
> use a WaitEventSet for waiting in ServerLoop. I've got mixed emotions
> about whether this is the direction to proceed, though.
Attached are a couple of patches that represent a plausible Plan B.
The first one c
On 22 Apr. 2017 4:23 am, "Tom Lane" wrote:
Peter Eisentraut writes:
> On 4/21/17 14:49, Andrew Dunstan wrote:
>> I'll add a comment, but doing it in PostgresNode.pm would mean jacana
>> (for instance) couldn't run any of the TAP tests. I'mm looking at
>> installing a sufficiently modern Test::Si
On 2017-04-22 09:14:50 +0800, Craig Ringer wrote:
> 2) if the answer to the previous question is negative, is it possible to
> send asynchronous queries in one thread while reading results in another
> thread?
>
>
> Not right now. libpq's state tracking wouldn't cope.
>
> I imagine it could be m
On 22 Apr. 2017 6:04 am, "Ilya Roublev" wrote:
1) is it possible technically (possibly by changing some part of libpq
code) to ignore results (especially for this sort of queries like insert),
processing somehow separately the situation when some error occurs?
There is a patch out there to all
Alvaro Herrera writes:
> Tom Lane wrote:
>> It also appears to me that do_start_bgworker's treatment of fork
>> failure is completely brain dead. Did anyone really think about
>> that case?
> Hmm, I probably modelled it on autovacuum without giving that case much
> additional consideration.
Att
On Fri, Apr 21, 2017 at 1:43 AM, Stephen Frost wrote:
>> + Once
>> + partitions exist, we do not support using ONLY to
>> + add or drop constraints on only the partitioned table.
>>
>> I wonder if the following sounds a bit more informative: Once partitions
>> exist, using ONLY will re
On Fri, Apr 21, 2017 at 12:10 PM, David Rowley
wrote:
> This probably ended up here because there's a bunch of other functions
> named get_cheapest* in that file, but all of those relate to getting a
> path for specific PathKeys. get_cheapest_parallel_safe_total_inner()
> does not do that.
Yes, I
On Fri, Apr 21, 2017 at 8:41 AM, Ashutosh Bapat
wrote:
> I don't see how is that fixed. For a join relation we need to come up
> with one set of partition bounds by merging partition bounds of the
> joining relation and in order to understand how to interpret the
> datums in the partition bounds,
On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas wrote:
> I'll continue reviewing the rest of the patch on Monday, but one glaring
> issue is that we cannot add an argument to the existing libpq
> PQencryptPassword() function, because that's part of the public API. It
> would break all applicat
Hello,
I'm investigating Batch/pipelining mode for libpq connected to this thread:
https://www.postgresql.org/message-id/flat/CADT4RqA6XoDCVY-G13ME1oRVshE2oNk4fRHKZC0K-jJymQJV0Q%40mail.gmail.com#cadt4rqa6xodcvy-g13me1orvshe2onk4frhkzc0k-jjymqj...@mail.gmail.com
And I'm wondering, what are the po
On 2017-04-21 17:04:08 -0400, Tom Lane wrote:
> Some excavation in the buildfarm database says that the coverage for
> the recovery-check test has been mighty darn thin up until just
> recently.
Hm, not good. Just enabled it for most of my animals (there seems to be
no point in having it on the C8
Alvaro Herrera writes:
> Simon Riggs wrote:
>> Replication lag tracking for walsenders
>>
>> Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication.
> Did anyone notice that this seems to be causing buildfarm member 'tern'
> to fail the recovery check? See here:
> https://buildfa
Peter Eisentraut writes:
> On 4/21/17 14:49, Andrew Dunstan wrote:
>> I'll add a comment, but doing it in PostgresNode.pm would mean jacana
>> (for instance) couldn't run any of the TAP tests. I'mm looking at
>> installing a sufficiently modern Test::Simple package (includes
>> Test::More and test
Tom Lane writes:
> Andres Freund writes:
>> On 2017-04-21 14:08:21 -0400, Tom Lane wrote:
>>> but I see that SUSv2
>>> mandates that fcntl.h provide both F_SETFD and FD_CLOEXEC, so by our own
>>> coding rules it ought to be okay to assume they're there. I'm tempted to
>>> rip out the quoted bit,
On 04/10/2017 08:42 AM, Michael Paquier wrote:
As there have been some conflicts because of the commit of SASLprep,
here is a rebased set of patches.
I've committed a modified version of the first patch, to change the
on-disk format to RFC 5803, as mentioned on the other thread
(https://www.p
On 04/21/2017 05:33 PM, Simon Riggs wrote:
On 21 April 2017 at 14:42, Heikki Linnakangas wrote:
SCRAM-SHA-256$:$:
Could you explain where you are looking? I don't see that in RFC5803
>From 1. Overview:
Yeah, it's not easy to see, I missed it earlier too. You have to look at RFC 5803 and
On 4/21/17 14:49, Andrew Dunstan wrote:
> I'll add a comment, but doing it in PostgresNode.pm would mean jacana
> (for instance) couldn't run any of the TAP tests. I'mm looking at
> installing a sufficiently modern Test::Simple package (includes
> Test::More and test::Build) there, but other oldish
Simon Riggs wrote:
> Replication lag tracking for walsenders
>
> Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication.
Did anyone notice that this seems to be causing buildfarm member 'tern'
to fail the recovery check? See here:
https://buildfarm.postgresql.org/cgi-bin/show_stag
On Fri, Apr 21, 2017 at 4:02 PM, Masahiko Sawada wrote:
> On Fri, Apr 21, 2017 at 1:19 AM, Fujii Masao wrote:
>> On Tue, Apr 18, 2017 at 5:16 PM, Masahiko Sawada
>> wrote:
>>> On Tue, Apr 18, 2017 at 12:24 PM, Kyotaro HORIGUCHI
>>> wrote:
Hi,
Thank you for the revised version.
>
Andres Freund writes:
> On 2017-04-21 14:08:21 -0400, Tom Lane wrote:
>> but I see that SUSv2
>> mandates that fcntl.h provide both F_SETFD and FD_CLOEXEC, so by our own
>> coding rules it ought to be okay to assume they're there. I'm tempted to
>> rip out the quoted bit, as well as the #ifdef F_
On 04/21/2017 10:45 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> As we discovered yesterday via jacana, very old versions of Test::More
>> don't support the note() function. It therefore seems prudent to specify
>> a minimum version number for the module in those scripts that use the
>> funct
Oleg, Teodor, folks:
I was demo'ing phrase search for a meetup yesterday, and the user
feedback I got showed that there's a missing feature with phrase search.
Let me explain by example:
'fix <-> error' will match 'fixed error', 'fixing error'
but not 'fixed language error' or 'fixed a small er
Tom,
On 2017-04-21 13:49:27 -0400, Tom Lane wrote:
> >> * If we are in PM_WAIT_DEAD_END state, then we don't want to accept
> >> - * any new connections, so we don't call select(), and just
> >> sleep.
> >> + * any new connections, so we don't call WaitEventSetWait(),
> >> an
On 2017-04-21 14:08:21 -0400, Tom Lane wrote:
> but I see that SUSv2
> mandates that fcntl.h provide both F_SETFD and FD_CLOEXEC, so by our own
> coding rules it ought to be okay to assume they're there. I'm tempted to
> rip out the quoted bit, as well as the #ifdef F_SETFD, from libpq and see
> i
I wrote:
> Andres Freund writes:
>> On 2017-04-21 12:50:04 -0400, Tom Lane wrote:
>>> +#ifndef FD_CLOEXEC
>>> +#define FD_CLOEXEC 1
>>> +#endif
>> Hm? Are we sure this is portable? Is there really cases that have
>> F_SETFD, but not CLOEXEC?
> Copied-and-pasted from our only existing use of FD_
Andres Freund writes:
> On 2017-04-21 12:50:04 -0400, Tom Lane wrote:
>> Attached is a lightly-tested draft patch that converts the postmaster to
>> use a WaitEventSet for waiting in ServerLoop. I've got mixed emotions
>> about whether this is the direction to proceed, though. It adds at least
>
Alvaro Herrera writes:
> Tom Lane wrote:
>> I'm coming back to the idea that at least in the back branches, the
>> thing to do is allow maybe_start_bgworker to start multiple workers.
>>
>> Is there any actual evidence for the claim that that might have
>> bad side effects?
> Well, I ran tests w
Hi,
On 2017-04-21 12:50:04 -0400, Tom Lane wrote:
> Attached is a lightly-tested draft patch that converts the postmaster to
> use a WaitEventSet for waiting in ServerLoop. I've got mixed emotions
> about whether this is the direction to proceed, though. It adds at least
> a couple of kernel cal
Hi, Jeff!
I'm planning to provide the review for this patch in future. I've done
some performance tesing (see attachment).
All in all, nothing important, everything works fine.
Tests were executed under current HEAD on Ubuntu 16 over MacBook Air.
I observe that:
1. Patch brings performance improv
Attached is a lightly-tested draft patch that converts the postmaster to
use a WaitEventSet for waiting in ServerLoop. I've got mixed emotions
about whether this is the direction to proceed, though. It adds at least
a couple of kernel calls per postmaster signal delivery, and probably to
every po
Tom Lane wrote:
> After sleeping and thinking more, I've realized that the
> slow-bgworker-start issue actually exists on *every* platform, it's just
> harder to hit when select() is interruptable. But consider the case
> where multiple bgworker-start requests arrive while ServerLoop is
> activel
Andres Freund writes:
> On 2017-04-20 00:50:13 -0400, Tom Lane wrote:
>> My first reaction was that that sounded like a lot more work than removing
>> two lines from maybe_start_bgworker and adjusting some comments. But on
>> closer inspection, the slow-bgworker-start issue isn't the only problem
Andrew Dunstan writes:
> As we discovered yesterday via jacana, very old versions of Test::More
> don't support the note() function. It therefore seems prudent to specify
> a minimum version number for the module in those scripts that use the
> function. According to the changelog, version 0.82 (r
On 04/21/2017 10:36 AM, Daniel Gustafsson wrote:
>> On 21 Apr 2017, at 15:08, Andrew Dunstan
>> wrote:
>>
>> As we discovered yesterday via jacana, very old versions of Test::More
>> don't support the note() function. It therefore seems prudent to specify
>> a minimum version number for the mod
> On 21 Apr 2017, at 15:08, Andrew Dunstan
> wrote:
>
> As we discovered yesterday via jacana, very old versions of Test::More
> don't support the note() function. It therefore seems prudent to specify
> a minimum version number for the module in those scripts that use the
> function. According
On 21 April 2017 at 14:42, Heikki Linnakangas wrote:
SCRAM-SHA-256$:$:
>>>
>>> Could you explain where you are looking? I don't see that in RFC5803
>>
> >From 1. Overview:
>
> Yeah, it's not easy to see, I missed it earlier too. You have to look at RFC
> 5803 and RFC 3112 together. RFC 311
On 21/04/17 16:23, Peter Eisentraut wrote:
> On 4/21/17 10:11, Petr Jelinek wrote:
>> On 21/04/17 16:09, Peter Eisentraut wrote:
>>> On 4/20/17 14:29, Petr Jelinek wrote:
+ /* Find unused worker slot. */
+ if (!w->in_use)
{
- worker
On 4/21/17 10:11, Petr Jelinek wrote:
> On 21/04/17 16:09, Peter Eisentraut wrote:
>> On 4/20/17 14:29, Petr Jelinek wrote:
>>> + /* Find unused worker slot. */
>>> + if (!w->in_use)
>>> {
>>> - worker = &LogicalRepCtx->workers[slot];
>>> -
On Fri, Apr 21, 2017 at 5:33 PM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 20 Apr 2017 13:21:14 +0900, Masahiko Sawada
> wrote in
>> On Thu, Apr 20, 2017 at 12:30 AM, Petr Jelinek
>> wrote:
>> > On 19/04/17 15:57, Masahiko Sawada wrote:
>> >> On Wed, Apr 19, 2017 at 10:07 PM, Petr Jelinek
On 4/6/17 08:24, Kyotaro HORIGUCHI wrote:
> Hello. I found dubious behavior while playing with logical
> replication.
>
> When we disable a subscription, replication worker immediately stops.
>
> =# ALTER SUBSCRIPTION s1 DISABLE;
>
> On the other hand even if we enable a subscription, worker
> d
On 21/04/17 16:09, Peter Eisentraut wrote:
> On 4/20/17 14:29, Petr Jelinek wrote:
>> +/* Find unused worker slot. */
>> +if (!w->in_use)
>> {
>> -worker = &LogicalRepCtx->workers[slot];
>> -break;
>> +
On 4/20/17 22:24, Noah Misch wrote:
> On Mon, Apr 17, 2017 at 02:09:54PM -0400, Peter Eisentraut wrote:
>> I think we're not really sure yet what to do about this. Discussion is
>> ongoing. I'll report back on Wednesday.
>
> This PostgreSQL 10 open item is past due for your status update, and th
On 4/20/17 14:29, Petr Jelinek wrote:
> + /* Find unused worker slot. */
> + if (!w->in_use)
> {
> - worker = &LogicalRepCtx->workers[slot];
> - break;
> + worker = w;
> + slot = i;
On 21/04/17 10:33, Kyotaro HORIGUCHI wrote:
> Hello,
>
> At Thu, 20 Apr 2017 13:21:14 +0900, Masahiko Sawada
> wrote in
>> On Thu, Apr 20, 2017 at 12:30 AM, Petr Jelinek
>> wrote:
>>> On 19/04/17 15:57, Masahiko Sawada wrote:
On Wed, Apr 19, 2017 at 10:07 PM, Petr Jelinek
wrote:
>>>
On 21/04/17 04:38, Masahiko Sawada wrote:
> On Thu, Apr 20, 2017 at 8:43 PM, Petr Jelinek
> wrote:
>> On 20/04/17 06:21, Masahiko Sawada wrote:
>>> On Thu, Apr 20, 2017 at 12:30 AM, Petr Jelinek
>>> wrote:
On 19/04/17 15:57, Masahiko Sawada wrote:
> On Wed, Apr 19, 2017 at 10:07 PM, Petr
On 21.04.2017 16:29, Merlin Moncure wrote:
On Fri, Apr 21, 2017 at 5:08 AM, Egor Rogov wrote:
Hello,
It seams that tiggers don't fire on subscriber's tables during logical
replication. Is it a bug?
Reading the documentation (which is TBH a bit hard to follow) it
appears that it is expected beh
Moin,
On Fri, April 21, 2017 7:04 am, David Rowley wrote:
> On 21 April 2017 at 22:30, Tels wrote:
>> I'd rather see:
>>
>> CREATE STATISTICS stats_name ON table(col);
>>
>> as this both mirrors CREATE INDEX and foreign keys with REFERENCES. It
>> could also be extended to both more columns, exp
Michael Paquier writes:
> On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs wrote:
>> On 21 April 2017 at 10:20, Heikki Linnakangas wrote:
>>> But looking more closely, I think I misunderstood RFC 5803. It *does* in
>>> fact specify a single string format to store the verifier in. And the format
>>
On 21 April 2017 16:20:56 EEST, Michael Paquier
wrote:
>On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs
>wrote:
>> On 21 April 2017 at 10:20, Heikki Linnakangas
>wrote:
>>> But looking more closely, I think I misunderstood RFC 5803. It
>*does* in
>>> fact specify a single string format to store
On 21 April 2017 at 14:20, Michael Paquier wrote:
> On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs wrote:
>> On 21 April 2017 at 10:20, Heikki Linnakangas wrote:
>>> But looking more closely, I think I misunderstood RFC 5803. It *does* in
>>> fact specify a single string format to store the verif
On Fri, Apr 21, 2017 at 5:08 AM, Egor Rogov wrote:
> Hello,
> It seams that tiggers don't fire on subscriber's tables during logical
> replication. Is it a bug?
Reading the documentation (which is TBH a bit hard to follow) it
appears that it is expected behavior.
https://www.postgresql.org/docs/
On Fri, Apr 21, 2017 at 9:25 PM, Stephen Frost wrote:
> * Heikki Linnakangas (hlinn...@iki.fi) wrote:
>> I think we should adopt that exact format, so that our verifiers are
>> compatible with RFC 5803. It doesn't make any immediate difference,
>> but since there is a standard out there, might as
On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs wrote:
> On 21 April 2017 at 10:20, Heikki Linnakangas wrote:
>> But looking more closely, I think I misunderstood RFC 5803. It *does* in
>> fact specify a single string format to store the verifier in. And the format
>> looks like:
>>
>> SCRAM-SHA-25
As we discovered yesterday via jacana, very old versions of Test::More
don't support the note() function. It therefore seems prudent to specify
a minimum version number for the module in those scripts that use the
function. According to the changelog, version 0.82 (released in Oct
2008) should be
On 21 April 2017 at 10:20, Heikki Linnakangas wrote:
> But looking more closely, I think I misunderstood RFC 5803. It *does* in
> fact specify a single string format to store the verifier in. And the format
> looks like:
>
> SCRAM-SHA-256$:$:
Could you explain where you are looking? I don't see
On 4/20/17 22:57, Michael Paquier wrote:
> On Fri, Apr 21, 2017 at 11:34 AM, Petr Jelinek
> wrote:
>> On 20/04/17 23:30, Peter Eisentraut wrote:
>>> On 4/20/17 10:19, Petr Jelinek wrote:
Hmm well since this only affects the synchronization of table
states/names, I guess we could just sim
On 04/20/2017 10:30 AM, Jesper Pedersen wrote:
I think this fix is harmless and has some value in terms of
consistency. One minor suggestion is that you should leave a space
after typecasting.
- TRACE_POSTGRESQL_LWLOCK_WAIT_DONE(T_NAME(lock), mode);
+ TRACE_POSTGRESQL_LWLOCK_WAIT_DONE(T_NAME(lo
Heikki,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> I think we should adopt that exact format, so that our verifiers are
> compatible with RFC 5803. It doesn't make any immediate difference,
> but since there is a standard out there, might as well follow it.
+1
> And just in case we get supp
On 21 April 2017 at 22:30, Tels wrote:
> I'd rather see:
>
> CREATE STATISTICS stats_name ON table(col);
>
> as this both mirrors CREATE INDEX and foreign keys with REFERENCES. It
> could also be extended to both more columns, expressions or other tables
> like so:
>
> CREATE STATISTICS stats ON
Moin,
On Thu, April 20, 2017 8:21 pm, Tomas Vondra wrote:
> On 04/21/2017 12:13 AM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Simon just pointed out that having the WITH clause appear in the middle
>>> of the CREATE STATISTICS command looks odd; apparently somebody else
>>> already complained
This probably ended up here because there's a bunch of other functions
named get_cheapest* in that file, but all of those relate to getting a
path for specific PathKeys. get_cheapest_parallel_safe_total_inner()
does not do that.
Maybe allpaths.c is a better home for it?
It seems to have been adde
Hello,
It seams that tiggers don't fire on subscriber's tables during logical
replication. Is it a bug?
#
# publisher: simple table and publication
#
postgres@publisher=# SELECT version();
version
The current format for SCRAM verifiers in pg_authid is:
scram-sha-256
While reviewing Michael's patch to change that so that StoredKey and
ServerKey are stored base64-encoded, rather than hex-encoded as they are
currently [1], I looked again at RFC 5803. RFC 5803 specifies the format
to u
Hello,
At Thu, 20 Apr 2017 13:21:14 +0900, Masahiko Sawada
wrote in
> On Thu, Apr 20, 2017 at 12:30 AM, Petr Jelinek
> wrote:
> > On 19/04/17 15:57, Masahiko Sawada wrote:
> >> On Wed, Apr 19, 2017 at 10:07 PM, Petr Jelinek
> >> wrote:
> >>> On 19/04/17 14:42, Masahiko Sawada wrote:
> On
Hi,
I have observed below with the statement triggers.
I am able to create statement triggers at root partition, but these
triggers, not getting fired on updating partition.
CREATE TABLE pt (a INT, b INT) PARTITION BY RANGE(a);
CREATE TABLE pt1 PARTITION OF pt FOR VALUES FROM (1) to (7);
CREATE
On Fri, Apr 21, 2017 at 11:55 AM, Masahiko Sawada wrote:
> On Fri, Apr 21, 2017 at 4:41 AM, Peter Eisentraut
> wrote:
>> On 4/20/17 12:30, Fujii Masao wrote:
>>> I've pushed several patches, and there is now only one remaining patch.
>>> I posted the review comment on that patch, and I'm expectin
On Fri, Apr 21, 2017 at 1:19 AM, Fujii Masao wrote:
> On Tue, Apr 18, 2017 at 5:16 PM, Masahiko Sawada
> wrote:
>> On Tue, Apr 18, 2017 at 12:24 PM, Kyotaro HORIGUCHI
>> wrote:
>>> Hi,
>>>
>>> Thank you for the revised version.
>>>
>>> At Mon, 17 Apr 2017 23:29:28 +0900, Masahiko Sawada
>>> w
72 matches
Mail list logo
