On Fri, Nov 15, 2024 at 9:57 AM Aleksander Alekseev
wrote:
> I'm working with the TimescaleDB dev team to fix these issues on the
> TimescaleDB side.
I looked a bit at this out of interest. I see an assert failure in the
lines below when running tests with TimescaleDB compiled against 17.0
with 1
On Sun, Jun 2, 2024, 02:08 Jelte Fennema-Nio wrote:
> This patch adds a new "owned_schema" option to the extension control
> file that can be set to true to indicate that this extension wants to
> own the schema in which it is installed.
Huge +1
Many managed PostgreSQL services block superuser a
On Mon, Jan 9, 2023 at 11:37 PM Tom Lane wrote:
> Anyway, to get back to the point at hand: if we do have a REPLICA IDENTITY
> FULL situation then we can make use of any unique index over a subset of
> the transmitted columns, and if there's more than one candidate index
> it's unlikely to matter
On Fri, Dec 23, 2022 at 11:43 AM Will Mortensen wrote:
> We'd like to be able to call the lock manager's WaitForLockers() and
> WaitForLockersMultiple() from SQL. Below I describe our use case, but
> basically I'm wondering if this:
>
> 1. Seems like a reasonable thing to do
>
> 2. Would b
On Wed, Aug 11, 2021 at 1:37 PM Amit Kapila wrote:
> I think it is and the context is generated via
> output_plugin_error_callback. Is this reproducible for you and if so,
> can you share a test case or some steps to reproduce this? Does this
> work and suddenly start giving errors or it happens t
On Mon, Jul 18, 2022 at 8:29 AM Amit Kapila wrote:
> IIUC, this proposal is to optimize cases where users can't have a
> unique/primary key for a relation on the subscriber and those
> relations receive lots of updates or deletes?
I think this patch optimizes for all non-trivial cases of update/d
I've been running into a similar issue and am a little puzzled by it,
especially since it survives restarts.
On Fri, Dec 20, 2019 at 2:39 AM Tomas Vondra
wrote:
> Yeah, I don't see this error message anywhere in our sources on 11 or
> 12, so perhaps debezium does something funny? It's not clear t
On Thu, Mar 12, 2020 at 11:31 AM Julien Rouhaud wrote:
> There's at least the current version of IVM patchset that lacks the
> querytext. Looking at various extensions, I see that pg_background
> and pglogical call pg_plan_query internally but shouldn't have any
> issue providing the query text.
On Wed, Dec 25, 2019, 11:28 Maksim Milyutin wrote:
> But in this case locally committed data becomes visible to new incoming
> transactions that is bad side-effect of this issue.
>
Your application should be prepared for that in any case.
At the point where synchronous replication waits, the co
On Fri, Dec 20, 2019 at 11:07 AM Andrey Borodin wrote:
> I think changing synchronous_standby_names to some available standbys will
> resume all backends waiting for synchronous replication.
> Do we need to check necessity of synchronous replication in any other case?
The GUCs are not re-checked
On Fri, Dec 20, 2019 at 6:04 AM Andrey Borodin wrote:
> I think proper solution here would be to add GUC to disallow cancellation of
> synchronous replication. Retry step 3 will wait on locks after hanging 1 and
> data will be consistent.
> Three is still a problem when backend is not canceled,
On Thu, Nov 28, 2019 at 6:18 AM Amit Langote wrote:
> Interesting. Still, I think you'd be in better position than anyone
> else to come up with reproduction steps for vanilla PostgreSQL by
> analyzing the stack trace if and when the crash next occurs (or using
> the existing core dump). It's ha
We're seeing a segmentation fault when creating a partition of a
partitioned table with a primary key when there is a sql_drop trigger on
Postgres 11beta4.
We discovered it because the Citus extension creates a sql_drop trigger,
but it's otherwise unrelated to the Citus extension:
https://github.c
13 matches
Mail list logo
