On 12/9/24 20:54, Ron Johnson wrote:
On Mon, Dec 9, 2024 at 11:24 PM David G. Johnston
mailto:david.g.johns...@gmail.com>> wrote:
On Monday, December 9, 2024, Ron Johnson mailto:ronljohnso...@gmail.com>> wrote:
On Sat, Nov 30, 2024 at 10:36 PM Adrian Klaver
mailto:adrian.kl
On Mon, Dec 9, 2024 at 11:24 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Monday, December 9, 2024, Ron Johnson wrote:
>
>> On Sat, Nov 30, 2024 at 10:36 PM Adrian Klaver
>> wrote:
>> [snip]
>>
>>> In future schema qualify all references.
>>>
>>> For now in the dump file you co
On Monday, December 9, 2024, Ron Johnson wrote:
> On Sat, Nov 30, 2024 at 10:36 PM Adrian Klaver
> wrote:
> [snip]
>
>> In future schema qualify all references.
>>
>> For now in the dump file you could search for
>>
>> SELECT pg_catalog.set_config('search_path', '', false);
>>
>> and set to
>>
>
On Sat, Nov 30, 2024 at 10:36 PM Adrian Klaver
wrote:
[snip]
> In future schema qualify all references.
>
> For now in the dump file you could search for
>
> SELECT pg_catalog.set_config('search_path', '', false);
>
> and set to
>
> SELECT pg_catalog.set_config('search_path', 'public', false);
>
On 12/9/24 15:30, PopeRigby wrote:
On 12/9/24 15:23, Tom Lane wrote:
Adrian Klaver writes:
You could file an issue here:
https://www.postgresql.org/account/login/?next=/account/submitbug/
Ask if the developers could use the mechanisms available here:
https://www.postgresql.org/docs/current/ext
On 12/9/24 15:23, Tom Lane wrote:
Adrian Klaver writes:
You could file an issue here:
https://www.postgresql.org/account/login/?next=/account/submitbug/
Ask if the developers could use the mechanisms available here:
https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSION
On 12/9/24 15:23, Tom Lane wrote:
Adrian Klaver writes:
You could file an issue here:
https://www.postgresql.org/account/login/?next=/account/submitbug/
Ask if the developers could use the mechanisms available here:
https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSION
Adrian Klaver writes:
> You could file an issue here:
> https://www.postgresql.org/account/login/?next=/account/submitbug/
> Ask if the developers could use the mechanisms available here:
> https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION
This wouldn't r
On 12/9/24 14:47, Adrian Klaver wrote:
On 12/9/24 14:14, PopeRigby wrote:
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby
wrote:
It actually looks like setting those all to have public fixed
all the
errors, including the one with lldap. So, how
On 12/9/24 14:14, PopeRigby wrote:
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby wrote:
It actually looks like setting those all to have public fixed all the
errors, including the one with lldap. So, how can I get it to not put
public there a
On 12/9/24 14:31, David G. Johnston wrote:
On Mon, Dec 9, 2024 at 3:14 PM PopeRigby wrote:
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby
wrote:
It actually looks like setting those all to have public fixed
all the
er
On Mon, Dec 9, 2024 at 3:14 PM PopeRigby wrote:
> On 12/7/24 11:58, David G. Johnston wrote:
>
> On Sat, Dec 7, 2024 at 12:25 PM PopeRigby wrote:
>
>>
>> It actually looks like setting those all to have public fixed all the
>> errors, including the one with lldap. So, how can I get it to not put
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby wrote:
It actually looks like setting those all to have public fixed all the
errors, including the one with lldap. So, how can I get it to not put
public there automatically for next time?
I assu
Thank you again for your help on this issue.
After looking into the lack of TLS 1.2 support, we were able to figure out what
was going on .
I ran the tsql with TDSDUMP as recommended:
TDSDUMP=stdout tsql -H mysqlservername.domain.net -p 1477 -U 'Someusername' -P
'xx'
And r
On Mon, Dec 9, 2024 at 6:43 AM Joe Wildish wrote:
Overall, your solution seems okay, but:
> a fix has gone in to PG17 that sorts this problem.
>
> However, we can't go to 17 yet, so need a solution for 15 and 16.
Honestly, this would seem like a really, really strong reason to push for
v17.
We maintain c.50 logical replicas. Typically the producer version is 12 or 13,
and the subscriber version is 14. We intend to upgrade the subscribers to 15
using pg_upgrade. However, we ran into an unexpected problem with that
approach. I couldn't find much being mentioned about it on the web,
Hello!
I am running Postgres 16.6 on a primary and several standby servers. I
recently observed 3 queries being cancelled with this error:
ERROR: canceling statement due to conflict with recovery (SQLSTATE 40P01)
There was this detail with the error:
User transaction caused buffer deadlock with
On Fri, Dec 06, 2024 at 04:44:29PM +0100, Erik Wienhold wrote:
> Another possibility is that the session just disabled compute_query_id:
> https://postgr.es/m/472115375.225506.1683812791906%40office.mailbox.org
Or possibly this uses a path where we're not aggressive enough the
query ID while we sh
18 matches
Mail list logo
