; table sync worker process.
>
I don't think solution is quite this simple. This will cause all table
sync workers to be delayed which means concurrency will suffer and the
initial sync of all tables will take much longer especially if there is
little data. We need a way to either d
s well
> that for correctness errno should be saved as SetLatch() is called and
> restored afterwards. Please find attached a patch to address all that.
>
Looks good to me. Just as a note, we'll have to handle this newly
supported config rereads in the async commit patch where we overri
h, but it's actually taken from max_logical_replication_workers
so the patch should look more like attached IMHO.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/backend/utils/misc/postgresql.conf.sa
On 10/04/17 14:40, Tom Lane wrote:
> Petr Jelinek writes:
>> Looks good to me. Just as a note, we'll have to handle this newly
>> supported config rereads in the async commit patch where we override
>> synchronous_commit GUC, but the config reread will change it back.
Thanks for looking at this!
On 13/04/17 02:29, Andres Freund wrote:
> Hi,
> On 2017-03-03 01:30:11 +0100, Petr Jelinek wrote:
>
>> From 7d5b48c8cb80e7c867b2096c999d08feda50b197 Mon Sep 17 00:00:00 2001
>> From: Petr Jelinek
>> Date: Fri, 24 Feb 2017 21:39:03 +
7;ll do that shortly. Please observe the
>> policy on
>> open item ownership[1] and send a status update within three calendar
>> days of
>> this message. Include a date for your subsequent status update.
>>
>> [1]
>> https://www.postgresql.org/message-id/20
e-id/CAD21AoBt_XUdppddFak661_LBM2t3CfK52aLKHG%2Bekd7SkzLmg%40mail.gmail.com
>
>> This resolves the problem but, if I understand correctly, the
>> many pallocs in process_syncing_tables_for_apply() is working on
>> ApplyContext and the context is reset before the next visit here
&g
On 12/04/17 06:10, Peter Eisentraut wrote:
> On 3/24/17 10:49, Petr Jelinek wrote:
>> Rebase after table copy patch got committed.
>
> You could please sent another rebase of this, perhaps with some more
> documentation, as discussed downthread.
>
> Also, I wonder why
wondering if we could store
the last start timestamp in the worker shared memory and do some magic
with that (ie, not clearing subid and relid and try to then do rate
limiting based on subid+relid+timestamp stored in shmem). That would
then work same way for the main apply workers as well. It would ha
-no-owner,
> --no-password, --no-privileges, --no-acl, --no-tablespaces, and
> --no-security-labels. It seems like there is probably a fairly large
> use case for excluding subscriptions even if you have sufficient
> permissions to dump them.
>
+1, I'll look into writing pa
f the partitions would
be sent as if the change was for that partitioned table so that the
partitioning scheme on subscriber does not need to be same as on
publisher. That's nontrivial to do though probably.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24
On 14/04/17 12:18, Masahiko Sawada wrote:
> On Fri, Apr 14, 2017 at 7:09 AM, Petr Jelinek
> wrote:
>> On 13/04/17 12:23, Masahiko Sawada wrote:
>>> On Thu, Apr 13, 2017 at 11:53 AM, Masahiko Sawada
>>> wrote:
>>>> On Wed, Apr 12, 2017 at 11:46 PM, Pete
name the
wal_receiver_timeout and wal_retrieve_retry_interval to something that
makes more sense for both physical and logical replication though.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsq
On 14/04/17 06:14, Amit Langote wrote:
> On 2017/04/14 10:57, Petr Jelinek wrote:
>> I don't think inheritance and partitioning should behave the same in
>> terms of logical replication.
>
> I see.
>
>>
>> For me the current behavior with inherited ta
et cstate->range_table
externally. I wonder if tablesync should just construct CopyStmt instead
of calling the lower level API.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (
On 14/04/17 14:30, Michael Paquier wrote:
> On Fri, Apr 14, 2017 at 9:19 PM, Petr Jelinek
> wrote:
>> I am not quite sure adding more GUCs is all that great option. When
>> writing the patches I was wondering if we should perhaps rename the
>> wal_receiver_timeout and wal
) but I think it's important to identify what exactly causes
the WAL activity in your case - if it's one of the replication commands
and not SQL then we'll need to backpatch any solution we come up with to
9.4, if it's not replication command, we only need to fix 10.
--
Pe
gic behind that is to be able to identify
>> easily the logical replication launcher in pg_stat_activity, so using
>> the query field instead sounds fine for me as we need another way than
>> backend_type to guess what is this bgworker.
>
> Wait, why do we need two ways?
>
W
On 14/04/17 17:33, Peter Eisentraut wrote:
> On 4/14/17 08:49, Petr Jelinek wrote:
>>> Are we prepared to support different schemas in v10? Or should we
>>> disallow it for v10 and add a TODO?
>>>
>>
>> Ah nuts, yes it's supposed to be supported, w
esync was faster
than apply) then the commit handler is never called so all the changes
made by copy would be forgotten. Also the tablesync worker might exit
from process_syncing_tables() call which is called before we report
stats in the commit handler so again some changes might be forgotten.
I
On 14/04/17 19:33, Fujii Masao wrote:
> On Fri, Apr 14, 2017 at 10:33 PM, Petr Jelinek
> wrote:
>> On 12/04/17 15:55, Fujii Masao wrote:
>>> Hi,
>>>
>>> When I shut down the publisher while I repeated creating and dropping
>>> the subscript
On 14/04/17 21:05, Peter Eisentraut wrote:
> On 4/14/17 14:23, Petr Jelinek wrote:
>> Ah yes looking at the code, it does exactly that (on master only). Means
>> that backport will be necessary.
>
> I think these two sentences are contradicting each other.
>
Hehe, didn&
e slot as used.
>
> So if another logicalrep_worker_launch() starts after LogicalRepWorkerLock
> is released before the slot is marked as used, it can pick up the same slot
> because that slot looks unused.
>
Yeah I think it's less of a problem of that comment than the
On 14/04/17 17:33, Peter Eisentraut wrote:
> On 4/14/17 08:49, Petr Jelinek wrote:
>>> Are we prepared to support different schemas in v10? Or should we
>>> disallow it for v10 and add a TODO?
>>>
>>
>> Ah nuts, yes it's supposed to be supported, we s
Hi, here is updated patch (details inline).
On 13/04/17 20:00, Petr Jelinek wrote:
> Thanks for looking at this!
>
> On 13/04/17 02:29, Andres Freund wrote:
>> Hi,
>> On 2017-03-03 01:30:11 +0100, Petr Jelinek wrote:
>>
>>> From 7d5b48c8cb80e7c867b2096c999d0
On 15/04/17 06:01, Tom Lane wrote:
> Petr Jelinek writes:
>> So this is what I came up with on plane. Generalized the loading
>> functionality into load_library_function which that can load either
>> known postgres functions or call load_external_function.
>
> I'v
commit, do things work again?
>
> - Andres
>
Yeah it is, it needs to be fenced to happen only after commit, which is
not guaranteed at the point of code, we probably need to put the
pgstat_report_stat() inside the if above after the
CommitTransactionCommand() (that will make it report stats for change
o that they are reported more like other builtin
processes. We could also try to add api for bgworker processes to change
how they are reported so that any future workers (and all the external
workers) can be reported properly as well, but that seems better fit for
v11 at this point since it would be g
p the subscription and recreate it it works.
>
No that's a result of how logical decoding/slots work. We see catalogs
as what they looked like at the specific point in time. If you create
slot (by creating subscription) it will not see publication that was
created after until decoding
advance of shipping v10. Consequently, I will appreciate your efforts
> toward speedy resolution. Thanks.
>
Just FYI this is not new in 10, the issue exists since the 9.4
introduction of logical replication slots.
--
Petr Jelinek http://www.2ndQuadrant.
On 17/04/17 18:02, Andres Freund wrote:
> On 2017-04-15 02:33:59 +0900, Fujii Masao wrote:
>> On Fri, Apr 14, 2017 at 10:33 PM, Petr Jelinek
>> wrote:
>>> On 12/04/17 15:55, Fujii Masao wrote:
>>>> Hi,
>>>>
>>>> When I shut down t
gt;
Hmm if we create hashtable for this, I'd say create hashtable for the
whole table_states then. The reason why it's list now was that it seemed
unnecessary to have hashtable when it will be empty almost always but
there is no need to have both hashtable + list IMHO.
--
Petr Jelin
27;s
IMHO only needed because default tcp keepalive settings are usually too
generous. As for apply_worker_launch_interval, I think we want different
name so that it can be used for tablesync rate limiting as well.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Develo
On 16/04/17 22:27, Petr Jelinek wrote:
> On 16/04/17 18:47, Tom Lane wrote:
>> Craig Ringer writes:
>>> On 12 April 2017 at 13:34, Kuntal Ghosh wrote:
>>>> For backend_type=background worker, application_name shows the name of
>>>> the background worke
(&MyLogicalRepWorker->relmutex);
>>>>>>> MyLogicalRepWorker->relstate =
>>>>>>> GetSubscriptionRelState(MyLogicalRepWorker->subid,
>>>>>>> MyLogicalRepWorker->relid,
>>>>>>>
On 18/04/17 18:14, Peter Eisentraut wrote:
> On 4/18/17 11:59, Petr Jelinek wrote:
>> Hmm if we create hashtable for this, I'd say create hashtable for the
>> whole table_states then. The reason why it's list now was that it seemed
>> unnecessary to have hashtab
On 18/04/17 18:24, Peter Eisentraut wrote:
> On 4/18/17 12:13, Petr Jelinek wrote:
>> We can definitely easily detect that the bgworker is internal one by
>> library_name equals 'postgres' so we can easily remove the usesysid and
>> usename based on that.
>
&g
On 18/04/17 19:18, Tom Lane wrote:
> Petr Jelinek writes:
>> On 18/04/17 18:24, Peter Eisentraut wrote:
>>> I don't see why we need to do that. It is showing the correct
>>> information, isn't it?
>
>> It does, but it's also one of the things
f to
shmem so it could be used across processes instead of having to reinvent
it every time.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 6d32379cda7d9f69c42185b9684d32570554f4e3 Mon Sep 17 00:00:00 2001
Fr
On 18/04/17 19:27, Fujii Masao wrote:
> On Wed, Apr 19, 2017 at 1:35 AM, Petr Jelinek
> wrote:
>> Thank you for working on this!
>>
>> On 18/04/17 10:16, Masahiko Sawada wrote:
>>> On Tue, Apr 18, 2017 at 12:24 PM, Kyotaro HORIGUC
use sync commit which improves performance there (because we
also replicate only very few transactions in the tests).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From a4cebdf95d1f8a58d12f2f3824dffaae1dbf435d Mon Se
On 19/04/17 10:25, Kyotaro HORIGUCHI wrote:
> At Wed, 19 Apr 2017 04:18:18 +0200, Petr Jelinek
> wrote in
>
>> On 18/04/17 19:27, Fujii Masao wrote:
>>> On Wed, Apr 19, 2017 at 1:35 AM, Petr Jelinek
>>> wrote:
>>>> Thank you for working on this!
On 19/04/17 10:45, Kyotaro HORIGUCHI wrote:
> At Wed, 19 Apr 2017 17:43:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20170419.174317.114509231.horiguchi.kyot...@lab.ntt.co.jp>
>> At Wed, 19 Apr 2017 10:33:29 +0200, Petr Jelinek
>> wrote in
>
idn’t spotted any measurable difference in speed.
>
> Problem spotted by Mikhail Shurutov.
>
Hmm we also do replication protocol handling inside the ApplyContext
(LogicalRepApplyLoop), are you sure this change is safe in that regard?
--
Petr Jelinek http://www.2ndQuad
On 19/04/17 11:55, Stas Kelvich wrote:
>
>> On 19 Apr 2017, at 12:37, Petr Jelinek wrote:
>>
>> On 18/04/17 13:45, Stas Kelvich wrote:
>>> Hi,
>>>
>>> currently logical replication worker uses ApplyContext to decode received
>>> da
On 19/04/17 12:46, Stas Kelvich wrote:
>
>> On 19 Apr 2017, at 13:34, Simon Riggs wrote:
>>
>> On 19 April 2017 at 11:24, Petr Jelinek wrote:
>>
>>> I'd still like you to add comment to the ApplyContext saying that it's
>>> cleaned after
On 19/04/17 14:42, Masahiko Sawada wrote:
> On Wed, Apr 19, 2017 at 5:12 PM, Kyotaro HORIGUCHI
> wrote:
>> At Tue, 18 Apr 2017 18:40:56 +0200, Petr Jelinek
>> wrote in
>>
>>> On 18/04/17 18:14, Peter Eisentraut wrote:
>>>> On 4/18/17 11:59, Petr Je
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 Wed, Apr 19, 2017 at 5:12 PM, Kyotaro HORIGUCHI
>>> wrote:
>>>> At Tue, 18 Apr 2017 18:40:56 +0200, Pe
sible to provoke via isolation tester (or
anything similar that would give us control over timing) unless we
expose a lot of guts of xlog/xact as a UDFs as well. So I think simple
function that does what you said and pgbench are reasonable solutions. I
guess you plan to make that as one of the tes
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 Jelinek
>>> wrote:
>>>> On 19/04/17 14:42, Masahiko Sawada wr
created either, so there
> is nothing that the user can do except drop manually the slot on the
> publisher. It seems to me that the moment where the slot is created
> should be a point of no-return: the subcription has to be dropped on
> the replication slot is dropped on the remot
mysub" already exists
> LOCATION: libpqrcv_create_slot, libpqwalreceiver.c:776
>
CREATE SUBSCRIPTION mysub CONNECTION 'port=5432' PUBLICATION mypub,
insert_only WITH(NOCREATE SLOT);
Or you can drop the slot manually on upstream.
--
Petr Jelinek
tdown checkpoint may have already begun. Here is an
> idea: add a new state in WalSndState, say WALSNDSTATE_STOPPING, and
> the shutdown checkpoint does not run as long as all WAL senders still
> running do not reach such a state.
>
+1 to this solution
--
Petr Jelinek h
On 20/04/17 14:57, Peter Eisentraut wrote:
> On 4/18/17 22:25, Petr Jelinek wrote:
>> The commit 887227a1c changed the defaults for subscriptions to do async
>> commit. But since the tests often wait for disk flush and there is no
>> concurrent activity this has increased the
On 20/04/17 14:41, Michael Paquier wrote:
> On Thu, Apr 20, 2017 at 8:47 PM, Petr Jelinek
> wrote:
>> Or you can drop the slot manually on upstream.
>
> Sure, but the point here is that if for example users have
> client_min_messages set at least at warning, they may h
patch review (it's also probably why this has
slipped through).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From d7038474012769c9c3b50231af76dd7796fe593f Mon Sep 17 00:00:00 2001
From: Petr Jelinek
Date: Sat, 2
o with
> "create implicit index for table") but I prefer to rip it out.
>
I agree with Peter here, the reason why we show this is that there is
implicit action which reserves resources on different server and is not
transactional. If we only did it when explicitly asked for,
le the subscription
on them (although we need to be able to modify the catalog for that
which may not be possible in an unrecoverable error) but it's not clear
to me how to reasonably produce such a list.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 30/05/17 15:44, Petr Jelinek wrote:
> On 30/05/17 11:02, Kyotaro HORIGUCHI wrote:
>>
>> +TimestampTz now = GetCurrentTimestamp();
>>
>> I think it is not recommended to read the current time too
>> frequently, especially within a loop that hates slownes
> +
> rstate->relid, rstate->state,
> +
> rstate->lsn);
>
>
> Should we commit the transaction if we started a new transaction
> before update the subscription relation state, or it could be deadlock
> risk.
We only lock
mplicated
> interprocess signaling.
>
Hmm, I don't understand what you mean here. The "letting any extra
catchup happen later" would never happen if the sync is behind apply as
apply has already skipped relevant transactions.
--
Petr Jelinek http://ww
On 30/06/17 04:46, Tom Lane wrote:
> Petr Jelinek writes:
>> On 30/06/17 02:07, Tom Lane wrote:
>>> I'm also kind of wondering why the "behind the apply" path out of
>>> LogicalRepSyncTableStart exists at all; as far as I can tell we'd be much
>
ng and missing something... I confirmaed it.
> The documentation is right. Sorry for the noise.
>
It will only fail if the remote site is not reachable during the drop
(but then it should hint about the ALTER), maybe that's what happened to
you?
--
Petr Jelinek htt
lock queue though because the
replication slots don't use normal catalog access so there is no object
locking with wait queue. We could use some latch wait with small timeout
but that seems ugly as that function can be called by user without
having dropped the slot before so the wait can be
On 06/07/17 17:33, Petr Jelinek wrote:
> On 03/07/17 01:54, Tom Lane wrote:
>> I noticed a recent failure that looked suspiciously like a race condition:
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2017-07-02%2018%3A02%3A07
>>
>>
-c606-985c-6d6239097...@2ndquadrant.com
[2]
https://www.postgresql.org/message-id/flat/cad21aobd4t2rwtiwd8yfxd+q+m9swx50yjqt5ibj2mzebvn...@mail.gmail.com
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 4c1ef64493ee930dfde3aa78
On 06/07/17 18:20, Petr Jelinek wrote:
> On 06/07/17 17:33, Petr Jelinek wrote:
>> On 03/07/17 01:54, Tom Lane wrote:
>>> I noticed a recent failure that looked suspiciously like a race condition:
>>>
>>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm
t in the beginning of ConditionVariableSleep(). But that's not
true, it's essential for preventing race conditions like the one above
because it puts the current process into waiting list so we can be sure
it will be signaled on broadcast once ConditionVariablePrepareToSleep()
has been c
revents?
We should do CHECK_FOR_INTERRUPTS() independently of pq_is_send_pending
so that it's possible to stop walsender while it's processing large
transaction.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
c update)
which allows doing that when pg_dumping from PG10+.
I also wonder if it should be mentioned in release notes. If the
attached patch would make it into PG10 it would be no brainer to mention
it as feature under pg_dump section, but exporting snapshots alone I am
not sure about.
--
Petr J
On 20/04/17 18:58, Peter Eisentraut wrote:
> On 4/18/17 22:13, Petr Jelinek wrote:
>> So my idea was to add some kind of inuse flag. This turned out to be bit
>> more complicated in terms of how to clean it than I would have hoped.
>> This is due to the fact that there is no
x27;t just
the SetLatch be enough (they both end up calling sendSelfPipeByte()
eventually)?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
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 simply do that before we create the
>> slot as there is no expectancy of consistency betwe
On 21/04/17 04:32, Craig Ringer wrote:
> On 21 April 2017 at 10:20, Petr Jelinek wrote:
>> On 21/04/17 03:40, Andres Freund wrote:
>>>
>>> Since [1] walsender (not receiver as commit message says) can execute
>>> SQL queries. While doing some testing of [
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 wro
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 1
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
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)
>
On 21/04/17 04:37, Petr Jelinek wrote:
> On 21/04/17 04:32, Craig Ringer wrote:
>> On 21 April 2017 at 10:20, Petr Jelinek wrote:
>>> On 21/04/17 03:40, Andres Freund wrote:
>>>>
>>>> Since [1] walsender (not receiver as commit message says) can execute
&
is patch to fix that - I also removed the individual
settings of everything to NULL/0/InvalidOid etc and just replaced it all
with memset.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 4993487f5e8750b708e76181bb
On 21/04/17 16:31, Petr Jelinek wrote:
> 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 w
L
interface just does not implement it at all. This seems like cleaner way
of doing it.
Thoughts?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Add-support-for-time-based-lag-tracking-to-logical-r.patch
Description:
Hi,
Seems like couple of declarations for couple of functions we never
actually implemented and are not used got past review of logical
replication support for initial copy path (commit 7c4f52409).
Attached patch gets rid of them.
--
Petr Jelinek http://www.2ndQuadrant.com
On 21/04/17 06:11, Michael Paquier wrote:
> On Fri, Apr 21, 2017 at 12:29 AM, Peter Eisentraut
> wrote:
>> On 4/20/17 07:52, Petr Jelinek wrote:
>>> On 20/04/17 05:57, Michael Paquier wrote:
>>>> 2nd thoughts here... Ah now I see your point. True that there
On 22/04/17 21:16, Andres Freund wrote:
> Hi,
>
> On 2017-04-22 21:08:18 +0200, Petr Jelinek wrote:
>> Thanks, here is patch to fix that - I also removed the individual
>> settings of everything to NULL/0/InvalidOid etc and just replaced it all
>> with memset.
>
On 24/04/17 01:59, Andres Freund wrote:
> Hi,
>
> On 2017-04-22 17:53:19 +0200, Petr Jelinek wrote:
>> Here is patch. I changed both SIGINT and SIGUSR1 handlers, afaics it
>> does not break anything for existing walsender usage.
>
>> diff --git a/src/backend/replic
t;h=59f71a0d0b56b2df48db4bf1738aece5551f7a47
>
Okay, but why call both SetLatch and latch_sigusr1_handler? What does
that buy us?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailin
don't want to rerun whole regression suite against
walsender given the time it would take in normal tests (although I could
see doing that optionally somehow) but then what to pick from there.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, T
On 24/04/17 07:42, Andres Freund wrote:
>
>
> On April 23, 2017 10:31:18 PM PDT, Petr Jelinek
> wrote:
>> On 24/04/17 04:31, Petr Jelinek wrote:
>> So actually maybe running regression tests through it might be
>> reasonable approach if we add new make target f
BREL_STATE_READY in a hash_seq_search loop
> the table sync worker which is changed to SUBREL_STATE_READY by the
> apply worker before updating the subrel_local_state could be remained
> in the hash table. I think that we should scan pg_subscription_rel by
> using only a condition &qu
On 24/04/17 20:00, Andres Freund wrote:
> On 2017-04-24 18:29:51 +0200, Petr Jelinek wrote:
>> On 24/04/17 07:42, Andres Freund wrote:
>>>
>>>
>>> On April 23, 2017 10:31:18 PM PDT, Petr Jelinek
>>> wrote:
>>>> On 24/04/17 04:31, Petr
On 25/04/17 00:59, Andres Freund wrote:
> Hi,
>
> On 2017-04-15 05:18:49 +0200, Petr Jelinek wrote:
>> Hi, here is updated patch (details inline).
>
> I'm not yet all that happy, sorry:
>
> Looking at 0001:
> - GetOldestSafeDecodingTransactionId() only guara
On 25/04/17 01:25, Andres Freund wrote:
> Hi,
>
> On 2017-04-24 07:31:18 +0200, Petr Jelinek wrote:
>> The previous coding tried to run the unknown string throur lexer which
>> could fail for some valid SQL statements as the replication command
>> parser is t
n=database kind of connection).
Or the ability of logical decoding to follow timeline switches.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
g was really more than a proof-of-concept
> until now.
>
Huh?
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
On 22/04/17 22:09, Petr Jelinek wrote:
> On 21/04/17 16:31, Petr Jelinek wrote:
>> 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
efulness if much lower without the
initial copy. The original patch for this added new commands to
replication protocol, adding generic SQL interface was result of request
in the reviews.
I personally don't mind moving back my original idea of special commands
if that was the consensus, but p
>> not false wakeups, but 'possible delay of launching new workers
>> by 3 minutes at most' (this is centainly a kind of false wakeups,
>> though). We can live with this failure when using two-paase
>> commmit, but I think it shouldn't happen silently.
>>
>>
>> How about providing AtPrepare_ApplyLauncher(void) like the
>> follows and calling it in PrepareTransaction?
>
> Or we should apply the attached patch and handle the 2PC case properly?
> I was thinking that it's overkill more than necessary, but that seems not true
> as far as I implement that.
>
Looks like it does not even increase size of the 2pc file, +1 for this.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o finish is your transaction. It can be worked around by
creating the slot manually via the SQL interface for example and create
the subscription using WITH (NOCREATE SLOT, SLOT NAME = 'your slot') .
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development
via SQL and I'd rather not hide even more errors in the log.
Note that the workaround for all of this is not all that complex, you do
same thing (create slot manually) you'd do for physical replication with
slots.
Thoughts?
--
Petr Jelinek http://www.2ndQuadrant.c
301 - 400 of 1163 matches
Mail list logo
