On 07/17/2013 02:08 PM, Josh Berkus wrote:
There shouldn't be any major problems with implementing LISTEN on the
slaves since LISTEN is done in memory.
Actually, that's not the hard part. Listeners need to be registered on
the standby, which requires a write to a system catalog, currently.
On 07/16/2013 07:16 PM, Andreas Karlsson wrote:
> I guess one problem is to implement writing to the WAL with the smallest
> possible performance hit. As far as I can see there are two possible
> approaches: either write to WAL when NOTIFY is run or write to WAL on
> commit. The former seems more
On 07/15/2013 04:10 PM, Greg Jaskiewicz wrote:
In terms of features, apart from separating LISTEN so that it can be actually
used on Standbys, wouldn't it be a matter of including the notifications in the
WAL stream, as simple packets ?
This would guarantee same behaviour as on the master.
I
On 10 Jul 2013, at 19:26, Josh Berkus wrote:
>
>
> Huh? LISTEN/NOTIFY across replication has been a desired feature since
> we introduced streaming replication. We want it, there's just no
> obvious way to do it.
>
> Your email kinda implies that it's not desirable.
Thanks Josh. I was unde
On 07/10/2013 09:27 AM, Christopher Browne wrote:
> The act of requesting to LISTEN requires doing a sort of update to the
> database. In elder versions, it put tuple(s) into pg_catalog.pg_listener,
> and that's Right Well Disallowed on a WAL-based replica.
>
> I would think that if you're keen o
Shouldn't be possible.
The act of requesting to LISTEN requires doing a sort of update to the
database. In elder versions, it put tuple(s) into pg_catalog.pg_listener,
and that's Right Well Disallowed on a WAL-based replica.
I would think that if you're keen on building an "event detection
subst
Hi masters of PostgreSQL,
I recently got asked about possibility of listening to notifications on warm
standby.
So question, how hard would that be to implement ?
Is it even possible without major changes to the architecture ?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
