Commit ea69a0dead5128c421140dc53fac165ba4af8520 has bumped the hash
index version and obviates the need for backward compatibility code
added by commit 293e24e507838733aba4748b514536af2d39d7f2. The same
has been mentioned in the commit message, please find attached patch
to remove the pre-10 compa
On Fri, May 05, 2017 at 07:07:26AM +, Noah Misch wrote:
> On Wed, May 03, 2017 at 08:28:53AM +0200, Simon Riggs wrote:
> > On 23 April 2017 at 01:10, Petr Jelinek
> > wrote:
> > > Hi,
> > >
> > > The time based lag tracking commit [1] added interface for logging
> > > progress of replication
On Mon, May 8, 2017 at 11:39 AM, David Rowley
wrote:
>
> We really need a machine with good IO concurrency, and not too much
> RAM to test these things out. It could well be that for a suitability
> large enough table we'd want to scan a whole 1GB extent per worker.
>
> I did post a patch to have
On Sat, May 6, 2017 at 12:01 AM, Peter Eisentraut
wrote:
> On 5/2/17 21:44, Noah Misch wrote:
>>> I wonder if we should have an --no-subscriptions option, now that they
>>> are dumped by default, just like we have --no-blobs, --no-owner,
>>> --no-password, --no-privileges, --no-acl, --no-tablespac
Hallo Christoph,
I've relaxed the regexps there. It's still not exactly what the PG
parser accepts, but I think it's a superset now, so we should be safe.
Will it be released with the next pg10dev compilation?
The answer is "yes", and it works as expected.
Vielen Dank again for the fix!
On 5/8/17 23:23, Peter Eisentraut wrote:
> The way this uses RESTRICT and CASCADE appears to be backwards from its
> usual meaning. Normally, CASCADE when dropping an object that is still
> used by others will cause those other objects to be dropped. The
> equivalent here would be DROP REPLICATIO
On 5/1/17 08:10, David Rowley wrote:
> On 20 April 2017 at 07:29, Euler Taveira wrote:
>> 2017-04-19 1:32 GMT-03:00 Michael Paquier :
>>>
>>> I vote for "location" -> "lsn". I would expect complains about the
>>> current inconsistency at some point, and the function names have been
>>> already cha
On 5/8/17 17:55, Petr Jelinek wrote:
> On 08/05/17 22:55, Peter Eisentraut wrote:
>> On 5/5/17 13:01, Petr Jelinek wrote:
>>> What do you think of attached. I actually did add RESTRICT/CASCADE, in a
>>> way that if there is slot RESTRICT will refuse to drop subscription and
>>> CASCADE will try to
On 2017/05/08 12:42, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> Thanks for committing the patch after improving it quite a bit, and sorry
>> that I couldn't reply promptly during the last week due to vacation.
>
> No worries, hopefully you have an op
On Tue, May 9, 2017 at 1:26 AM, Petr Jelinek
wrote:
> On 08/05/17 17:52, Masahiko Sawada wrote:
>> On Fri, May 5, 2017 at 8:13 PM, Petr Jelinek
>> wrote:
>>> On 03/05/17 13:23, Erik Rijkers wrote:
On 2017-05-03 08:17, Petr Jelinek wrote:
> On 02/05/17 20:43, Robert Haas wrote:
>> On
On 2017-05-05 02:00, Andres Freund wrote:
Could you have a look?
Running tests with these three patches:
0001-WIP-Fix-off-by-one-around-GetLastImportantRecPtr.patch+
0002-WIP-Possibly-more-robust-snapbuild-approach.patch +
fix-statistics-reporting-in-logical-replication-work.patch
(
On 08/05/17 22:55, Peter Eisentraut wrote:
> On 5/5/17 13:01, Petr Jelinek wrote:
>> What do you think of attached. I actually did add RESTRICT/CASCADE, in a
>> way that if there is slot RESTRICT will refuse to drop subscription and
>> CASCADE will try to drop it. Still all errors.
>>
>> The new wa
On Sat, May 06, 2017 at 07:54:51PM -0400, Stephen Frost wrote:
> Greetings!
>
> I am very pleased to be able to announce that the PostgreSQL project has
> been approved for 4 GSoC projects this year!
Thanks for the hard work!
Google's process has gotten a lot more rigorous over the years, and in
Hello,
st->cnt -- number of transactions finished successed or failed, right?
Or *skipped*. That is why I changed the declaration comment.
one iteration of for(;;) is for one transaction or really less. Right?
No, under -R -L late schedules are simply skipped.
We can't process two tansac
On 5/7/17 04:21, Noah Misch wrote:
> The above-described topic is currently a PostgreSQL 10 open item. Peter,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is more relevant or if this does not belong as a
> v10 open item, please let us
On 5/5/17 13:01, Petr Jelinek wrote:
> What do you think of attached. I actually did add RESTRICT/CASCADE, in a
> way that if there is slot RESTRICT will refuse to drop subscription and
> CASCADE will try to drop it. Still all errors.
>
> The new way to not drop slot is to set slot_name to NONE wh
В письме от 8 мая 2017 22:08:51 пользователь Fabien COELHO написал:
> >while (thread->throttle_trigger < now_us -
> >latency_limit &&
> >
> > /* with -t, do not overshoot */
> > (nxacts
On Thu, May 4, 2017 at 4:40 PM, Sven R. Kunze wrote:
> It yields
>
> CREATE TABLE p1 PARTITION OF test DEFAULT PARTITION BY LIST(b);
>
> This reads to me like "DEFAULT PARTITION".
>
> I can imagine a lot of confusion when those queries are encountered in the
> wild. I know this thread is about cre
Hello Alvaro,
Here is a v3, with less files. I cannot say I find it better, but it
still works.
The "command_likes" function has been renamed "command_checks".
Do parts of this need to be backpatched?
I would not bother too much about backpatching.
I notice that you're patching pgbench.
Hallo Christoph,
password_encryption = scram-sha-256
Hmm. Naïvely I would have assumed this would be missing quotes :)
That what I thought at first, but the comments, documentation and code
were saying otherwise, so I dug into debian packaging instead.
I've relaxed the regexps there.
Hi Robert,
Thanks for your explnation.
On Mon, May 8, 2017 at 9:56 PM, Robert Haas wrote:
> On Thu, May 4, 2017 at 4:28 PM, Jeevan Ladhe
> wrote:
> > While reviewing the code I was trying to explore more cases, and I here
> > comes an
> > open question to my mind:
> > should we allow the defau
On 5/6/17 08:44, Petr Jelinek wrote:
>> We could check validity of the connection string though to complain
>> immediately like we do in CREATE.
>
> The attached does exactly that.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remot
Re: Fabien COELHO 2017-05-08
> Thus I naïvely added:
>
> password_encryption = scram-sha-256
Hmm. Naïvely I would have assumed this would be missing quotes :)
> The result is:
>
> Error: Invalid line 88 in /etc/postgresql/10/main/postgresql.conf:
> »password_encryption = scram-sha-256«
Hello Peter,
Although this is really a small debian packaging issue, I cc to pgdev
because it illustrates unintended consequences of trivial changes.
Thanks (again!) to the great and up-to-date apt.postgresql.org repository,
I've tried to test the new scram-sha-256 feature. For that I looked
Fabien COELHO wrote:
>
> Here is a v3, with less files. I cannot say I find it better, but it still
> works.
>
> The "command_likes" function has been renamed "command_checks".
Do parts of this need to be backpatched? I notice that you're patching
pgbench.c, probably to fix some bug(s); is the
On 2017-05-08 12:28:38 -0400, Peter Eisentraut wrote:
> On 5/8/17 02:58, Noah Misch wrote:
> > IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is long past due
> > for your status update. Please reacquaint yourself with the policy on open
> > item ownership[1] and then reply immediatel
On 5/8/17 02:58, Noah Misch wrote:
> IMMEDIATE ATTENTION REQUIRED. This PostgreSQL 10 open item is long past due
> for your status update. Please reacquaint yourself with the policy on open
> item ownership[1] and then reply immediately. If I do not hear from you by
> 2017-05-09 07:00 UTC, I wil
On 08/05/17 18:12, Peter Eisentraut wrote:
> On 5/5/17 07:13, Petr Jelinek wrote:
>> Yes that's different thing that we've been discussing a bit in snapbuild
>> woes thread.
>>
>>> the 'TRAP: FailedAssertion in pgstat.c' anymore.
>>>
>>> (If there is any other configuration of patches worth testing
On 08/05/17 17:52, Masahiko Sawada wrote:
> On Fri, May 5, 2017 at 8:13 PM, Petr Jelinek
> wrote:
>> On 03/05/17 13:23, Erik Rijkers wrote:
>>> On 2017-05-03 08:17, Petr Jelinek wrote:
On 02/05/17 20:43, Robert Haas wrote:
> On Thu, Apr 20, 2017 at 2:58 PM, Peter Eisentraut
>>>
>> cod
On Thu, May 4, 2017 at 4:28 PM, Jeevan Ladhe
wrote:
> While reviewing the code I was trying to explore more cases, and I here
> comes an
> open question to my mind:
> should we allow the default partition table to be partitioned further?
I think yes. In general, you are allowed to partition a pa
On 5/6/17 14:50, Noah Misch wrote:
>> I consider this item low priority and don't plan to work on it before
>> all the other open items under logical replication are addressed.
>>
>> (Here, working on it would include thinking further about whether it is
>> necessary at all or what alternatives mig
On 5/5/17 07:13, Petr Jelinek wrote:
> Yes that's different thing that we've been discussing a bit in snapbuild
> woes thread.
>
>> the 'TRAP: FailedAssertion in pgstat.c' anymore.
>>
>> (If there is any other configuration of patches worth testing please let
>> me know)
>
> Thanks, so the patch
On Fri, May 5, 2017 at 8:13 PM, Petr Jelinek
wrote:
> On 03/05/17 13:23, Erik Rijkers wrote:
>> On 2017-05-03 08:17, Petr Jelinek wrote:
>>> On 02/05/17 20:43, Robert Haas wrote:
On Thu, Apr 20, 2017 at 2:58 PM, Peter Eisentraut
>>
> code path that calls CommitTransactionCommand() should
On Fri, May 5, 2017 at 11:13 AM, Alexander Korotkov
wrote:
> Incremental sort is faster in vast majority of cases. It appears to be
> slower only when whose dataset is one sort group. In this case incremental
> sort is useless, and it should be considered as misuse of incremental sort.
> Slowdow
On 5/5/17 03:09, Noah Misch wrote:
> [Action required within three days. This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 10 open item. Peter,
> since you committed the patch believed to have created it, you own this open
> item. If some other commit is m
I'm not sure about some of the details.
I think it would make more sense to reset ApplyMessageContext in
apply_dispatch(), so that it is done consistently after every message
(as the name implies), not only some messages.
Also, perhaps ApplyMessageContext should be a child of
TopTransactionContex
> + else \
> + (snapshotdata).xmin = \
> + TransactionIdLimitedForOldSnapshots(RecentGlobalDataXmin, \
> + relation); \
>
> I think we don't need to use TransactionIdLimitedForOldSnapshots() as
> that is required to override xmin for table vacuum/pruning purposes.
>
>> Maybe we need
>> to use Ge
On Mon, May 8, 2017 at 10:50 PM, Bruce Momjian wrote:
> On Mon, May 8, 2017 at 12:18:54PM +0900, Masahiko Sawada wrote:
>> On Fri, May 5, 2017 at 8:38 AM, Bruce Momjian wrote:
>> > On Fri, Apr 28, 2017 at 01:12:34PM +0900, Masahiko Sawada wrote:
>> >> On Tue, Apr 25, 2017 at 10:31 AM, Bruce Momj
On Mon, May 8, 2017 at 10:12 PM, Tom Lane wrote:
> Simon Riggs writes:
>> So rearranged code a little to keep it lean.
>
> Didn't you break it with that? As it now stands, the memcpy will
> copy the nonzero value.
>
Right, I'd missed it. That code should be placed before first memcpy.
Regards,
On Mon, May 8, 2017 at 12:18:54PM +0900, Masahiko Sawada wrote:
> On Fri, May 5, 2017 at 8:38 AM, Bruce Momjian wrote:
> > On Fri, Apr 28, 2017 at 01:12:34PM +0900, Masahiko Sawada wrote:
> >> On Tue, Apr 25, 2017 at 10:31 AM, Bruce Momjian wrote:
> >> > I have committed the first draft of the P
On Mon, May 8, 2017 at 6:30 PM, Dmitriy Sarafannikov
wrote:
>
> I think we can use RecentGlobalDataXmin for non-catalog relations and
> RecentGlobalXmin for catalog relations (probably a check similar to
> what we have in heap_page_prune_opt).
>
>
> I took check from heap_page_prune_opt (Maybe thi
On Sat, May 6, 2017 at 7:27 PM, David Rowley
wrote:
>
> I've also noticed that both the atomics patch and unpatched master do
> something that looks a bit weird with synchronous seq-scans. If the
> parallel seq-scan piggybacked on another scan, then subsequent
> parallel scans will start at the sa
Hi,
On Tue, Apr 4, 2017 at 3:56 PM, Amit Kapila wrote:
> On Sun, Apr 2, 2017 at 4:14 AM, Ashutosh Sharma wrote:
>>
>> Please note that these patches needs to be applied on top of [1].
>>
>
> Few more review comments:
>
> 1.
> - page = BufferGetPage(so->hashso_curbuf);
> + blkno = so->currPos.cu
On Mon, May 8, 2017 at 3:48 AM, Craig Ringer
wrote:
> Sounds like you're reimplementing pglogical
> (http://2ndquadrant.com/pglogical) on top of a json protocol.
The fact the protocol is JSON is more a detail, but it's a good start
as it's human-readable.
> [...]
> I have no reason to object to
Simon Riggs writes:
> So rearranged code a little to keep it lean.
Didn't you break it with that? As it now stands, the memcpy will
copy the nonzero value.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
I think we can use RecentGlobalDataXmin for non-catalog relations andRecentGlobalXmin for catalog relations (probably a check similar towhat we have in heap_page_prune_opt).I took check from heap_page_prune_opt (Maybe this check must be present as separate function?)But it requires to initialize sn
On Fri, May 5, 2017 at 6:08 AM, Mark Dilger wrote:
> Hackers,
>
> just FYI, I cannot find any regression test coverage of this part of the
> grammar, not
> even in the contrib/ directory or TAP tests. I was going to submit a patch
> to help out,
> and discovered it is not so easy to do, and per
On Sat, May 6, 2017 at 4:09 PM, Tom Lane wrote:
> Noah Misch writes:
> > On Fri, May 05, 2017 at 03:36:39AM +1200, David Rowley wrote:
> >> Do any of the committers who voted for this change feel inclined to
> >> pick this patch up?
>
> > I'll echo that question. This open item lacks a clear ow
2017-05-08 12:59 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> After giving it some thoughts, I see three possible solutions:
>>>
>>> 0. Do nothing about it.
>>>I would prefer the prepare is cleaned up.
>>>
>>> 1. assign a special name, eg "_psql_gdesc_", so that
>>>DEALLOCATE "_psql_gdes
On Mon, May 8, 2017 at 8:53 PM, Erik Rijkers wrote:
> On 2017-05-08 13:13, Masahiko Sawada wrote:
>>
>> On Mon, May 8, 2017 at 7:14 PM, Erik Rijkers wrote:
>>>
>>> On 2017-05-08 11:27, Masahiko Sawada wrote:
>
>>>
>>> FWIW, running
>>>
0001-WIP-Fix-off-by-one-around-GetLastImportan
On 2017-05-08 13:13, Masahiko Sawada wrote:
On Mon, May 8, 2017 at 7:14 PM, Erik Rijkers wrote:
On 2017-05-08 11:27, Masahiko Sawada wrote:
FWIW, running
0001-WIP-Fix-off-by-one-around-GetLastImportantRecPtr.patch+
0002-WIP-Possibly-more-robust-snapbuild-approach.patch +
fix-statist
On 08/05/17 01:17, Jeff Janes wrote:
> After dropping a subscription, it says it succeeded and that it dropped
> the slot on the publisher.
>
> But the publisher still has the slot, and a full-tilt process described
> by ps as
>
> postgres: wal sender process jjanes [local] idle in transaction
>
On 08/05/17 11:27, Masahiko Sawada wrote:
> Hi,
>
> I encountered a situation where DROP SUBSCRIPTION got stuck when
> initial table sync is in progress. In my environment, I created
> several tables with some data on publisher. I created subscription on
> subscriber and drop subscription immediat
Hello Jan,
Please give a number to submitted patches. I think that this was v3.
The patch does NOT fix various issues I pointed out in my previous review:
- tabs introduced in "doc/src/sgml/ref/psql-ref.sgml"
- too long help line in "src/bin/psql/help.c"
- spurious space after a comma in "s
On Mon, May 8, 2017 at 7:14 PM, Erik Rijkers wrote:
> On 2017-05-08 11:27, Masahiko Sawada wrote:
>>
>> Hi,
>>
>> I encountered a situation where DROP SUBSCRIPTION got stuck when
>> initial table sync is in progress. In my environment, I created
>> several tables with some data on publisher. I cre
Hello Pavel,
After giving it some thoughts, I see three possible solutions:
0. Do nothing about it.
I would prefer the prepare is cleaned up.
1. assign a special name, eg "_psql_gdesc_", so that
DEALLOCATE "_psql_gdesc_" can be issued afterwards.
[...]
The doc says about unnamed prep
Hello Jan,
Please give a number to submitted patches. I think that this was v3.
The patch does NOT fix various issues I pointed out in my previous review:
- tabs introduced in "doc/src/sgml/ref/psql-ref.sgml"
- too long help line in "src/bin/psql/help.c"
- spurious space after a comma in
Heikki Linnakangas writes:
> On 05/06/2017 01:56 PM, Gavin Flower wrote:
>> On 06/05/17 22:44, Vik Fearing wrote:
>>> On 05/05/2017 02:42 PM, Michael Paquier wrote:
+This option is obsolete but still accepted for backwards
+compatibility.
Isn't that incorrect Englis
On 2017-05-08 11:27, Masahiko Sawada wrote:
Hi,
I encountered a situation where DROP SUBSCRIPTION got stuck when
initial table sync is in progress. In my environment, I created
several tables with some data on publisher. I created subscription on
subscriber and drop subscription immediately afte
On 06/05/17 19:38, Tom Lane wrote:
> Petr Jelinek writes:
>> On 06/05/17 19:15, Tom Lane wrote:
>>> (Or, wait a minute. That documentation only applies to v10, but we
>>> need to be writing this relnote for 9.6 users. What terminology should
>>> we be using anyway?)
>
>> Yeah we need to somehow
Hi,
I encountered a situation where DROP SUBSCRIPTION got stuck when
initial table sync is in progress. In my environment, I created
several tables with some data on publisher. I created subscription on
subscriber and drop subscription immediately after that. It doesn't
always happen but I often e
Hi,
On 2017/05/05 17:26, 甄明洋 wrote:
> The function of initializing rel-cache is RelationCacheInitializePhase3 and
> in src/backend/utils/cache/relcache.c file.
> When initializing the partition description information, we forget to check
> if partition key or descriptor is NULL.
> Therefore, a
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Craig Ringer
> On 13 April 2017 at 14:59, Tsunakawa, Takayuki
> wrote:
>
> > 2. Make transaction_read_only GUC_REPORT This is to avoid the added
> > round-trip by SHOW command. It also benefits cl
On 05/05/2017 03:42 PM, Michael Paquier wrote:
+This option is obsolete but still accepted for backwards
+compatibility.
Isn't that incorrect English? It seems to me that this be non-plural,
as "for backward compatibility".
I changed most cases to "backward compatibility", excep
>I am not able add a new partition if default partition is further
partitioned
>with default partition.
Thanks for reporting. I will fix this.
>pg_restore is failing for default partition, dump file still storing old
syntax of default partition.
Thanks for reporting . I will fix this once the syn
On Mon, May 8, 2017 at 4:57 PM, Simon Riggs wrote:
> On 8 May 2017 at 06:28, Masahiko Sawada wrote:
>> Hi,
>>
>> Attached patch for $subject.
>>
>> s/recovey/recovery/
>
> There was a typo, but the comment itself was slightly wrong and also
> duplicated with another comment further down.
>
> So r
On 8 May 2017 at 06:28, Masahiko Sawada wrote:
> Hi,
>
> Attached patch for $subject.
>
> s/recovey/recovery/
There was a typo, but the comment itself was slightly wrong and also
duplicated with another comment further down.
So rearranged code a little to keep it lean.
Thanks
--
Simon Riggs
On 05/06/2017 01:56 PM, Gavin Flower wrote:
On 06/05/17 22:44, Vik Fearing wrote:
On 05/05/2017 02:42 PM, Michael Paquier wrote:
+This option is obsolete but still accepted for backwards
+compatibility.
Isn't that incorrect English?
No.
It seems to me that this be non-plural,
Hi
2017-05-08 9:08 GMT+02:00 Fabien COELHO :
>
> Hello Pavel,
>
> A complement to my previous comments:
>
> Also, maybe it would be better if the statement is cleaned up server side
>> at the end of the execution. Not sure how to achieve that, though, libpq
>> seems to lack the relevant function:
On Fri, May 5, 2017 at 8:29 AM, Thomas Munro
wrote:
> On Fri, May 5, 2017 at 2:40 AM, Robert Haas wrote:
>> On Thu, May 4, 2017 at 4:46 AM, Thomas Munro
>> wrote:
>>> On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera
>>> wrote:
Robert Haas wrote:
> I suspect that most users would find it
On May 3, 2017 10:45:16 PM PDT, Noah Misch wrote:
>On Thu, Apr 27, 2017 at 09:42:58PM -0700, Andres Freund wrote:
>>
>>
>> On April 27, 2017 9:34:44 PM PDT, Noah Misch
>wrote:
>> >On Fri, Apr 21, 2017 at 10:36:21PM -0700, Andres Freund wrote:
>> >> On 2017-04-17 21:16:57 -0700, Andres Freund
Hello Pavel,
A complement to my previous comments:
Also, maybe it would be better if the statement is cleaned up server side at
the end of the execution. Not sure how to achieve that, though, libpq seems
to lack the relevant function:-(
"""although there is no libpq function for deleting a
On Sat, May 06, 2017 at 11:50:16AM -0700, Noah Misch wrote:
> On Fri, May 05, 2017 at 11:01:57AM -0400, Peter Eisentraut wrote:
> > On 5/2/17 21:44, Noah Misch wrote:
> > >> I wonder if we should have an --no-subscriptions option, now that they
> > >> are dumped by default, just like we have --no-b
On 2017/05/03 6:30, Robert Haas wrote:
> On Tue, May 2, 2017 at 2:51 AM, Amit Langote
> wrote:
>> Per an off-list report from Olaf Gawenda (thanks Olaf), it seems that the
>> range partition's constraint is sometimes incorrect, at least in the case
>> of multi-column range partitioning. See below
On Sat, May 06, 2017 at 06:58:35PM +, Noah Misch wrote:
> On Tue, May 02, 2017 at 06:06:47PM -0500, Kevin Grittner wrote:
> > On Fri, Apr 28, 2017 at 10:56 PM, Tom Lane wrote:
> >
> > > They will fire if you have an INSTEAD OF row-level trigger; the existence
> > > of that trigger is what det
75 matches
Mail list logo
