On 8/1/24 15:13, Jim Vanns wrote:
PG 15.4
Community edition or some variant?
--
Adrian Klaver
adrian.kla...@aklaver.com
PG 15.4
On Thu, 1 Aug 2024 at 22:27, Ron Johnson wrote:
> PG 15.0 or 15.7?
>
> On Thu, Aug 1, 2024 at 3:58 PM Jim Vanns wrote:
>
>> Sorry, PG15.
>>
>> Jim
>>
>> On Thu, 1 Aug 2024 at 20:25, Adrian Klaver
>> wrote:
>>
>>> On 8/1/24 12:12, Tom Lane wrote:
>>> > Jim Vanns writes:
>>> >> I have t
PG 15.0 or 15.7?
On Thu, Aug 1, 2024 at 3:58 PM Jim Vanns wrote:
> Sorry, PG15.
>
> Jim
>
> On Thu, 1 Aug 2024 at 20:25, Adrian Klaver
> wrote:
>
>> On 8/1/24 12:12, Tom Lane wrote:
>> > Jim Vanns writes:
>> >> I have two sessions, each creating a temporary table of the same name -
>> >> 'foob
I don't at hand, but the query I used to identify this was;
SELECT state, pid, pg_blocking_pids(pid), query
FROM pg_stat_activity
WHERE backend_type='client backend';
On Thu, 1 Aug 2024 at 20:12, Tom Lane wrote:
> Jim Vanns writes:
> > I have two sessions, each creating a temporary table of th
Sorry, PG15.
Jim
On Thu, 1 Aug 2024 at 20:25, Adrian Klaver
wrote:
> On 8/1/24 12:12, Tom Lane wrote:
> > Jim Vanns writes:
> >> I have two sessions, each creating a temporary table of the same name -
> >> 'foobar'. Why would a vacuum of 'foobar' from one session block the
> vacuum
> >> of 'fo
On 8/1/24 12:12, Tom Lane wrote:
Jim Vanns writes:
I have two sessions, each creating a temporary table of the same name -
'foobar'. Why would a vacuum of 'foobar' from one session block the vacuum
of 'foobar' in the other session?
That's fairly hard to believe. Can you provide a self-contai
Jim Vanns writes:
> I have two sessions, each creating a temporary table of the same name -
> 'foobar'. Why would a vacuum of 'foobar' from one session block the vacuum
> of 'foobar' in the other session?
That's fairly hard to believe. Can you provide a self-contained test
case?
I have two sessions, each creating a temporary table of the same name -
'foobar'. Why would a vacuum of 'foobar' from one session block the vacuum
of 'foobar' in the other session? They're in separate tablespaces
(pg_temp_NN) and effectively distinct with respect to the sessions.
Cheers,
Jim
--
That´s a great point. Thank you.
Piotr Andreassen Blasiak
> On 1 Aug 2024, at 12:03, Torsten Förtsch wrote:
>
> A COMMIT record in the WAL has an LSN. I don't know much about debezuim but
> wal2json can give you this LSN. Then there is this function,
> pg_last_wal_replay_lsn(). I think you
sorry ignore the previous paste , was in complete
Here the full one. https://pastecode.io/s/hya0fyvo
On Thu, Aug 1, 2024 at 4:02 PM KK CHN wrote:
> The logs are here.
>
> https://pastecode.io/s/s5dp8ur1
>
>
>
> On Thu, Aug 1, 2024 at 3:30 PM Kashif Zeeshan
> wrote:
>
>> Hi
>>
>> On Thu, Aug
When you are performing PITR you need to configure a timestamp before your
last committed transaction. In your case you provided timestamp after your
last commit.
When postgtes is restoring until a specified point, it restores a
transaction from WAL, and checking if next transaction is before or a
The logs are here.
https://pastecode.io/s/s5dp8ur1
On Thu, Aug 1, 2024 at 3:30 PM Kashif Zeeshan
wrote:
> Hi
>
> On Thu, Aug 1, 2024 at 2:54 PM KK CHN wrote:
>
>> List,
>>
>> *Not working (start EPAS server always fails):*
>>
>> 1. Testing PTR using PgBackRest(2.52.1) on RHEL9 EPAS-16, an
A COMMIT record in the WAL has an LSN. I don't know much about debezuim but
wal2json can give you this LSN. Then there is this
function, pg_last_wal_replay_lsn(). I think you could run it on the replica
to see if you are after the point of commit. If you are, you should be able
to see the changes m
Hi
On Thu, Aug 1, 2024 at 2:54 PM KK CHN wrote:
> List,
>
> *Not working (start EPAS server always fails):*
>
> 1. Testing PTR using PgBackRest(2.52.1) on RHEL9 EPAS-16, and RHEL9 (
> Repo Server)
>
> When I do a PTR
>
> 1. After doing a table drop and then
> 2. Noting down the time
List,
*Not working (start EPAS server always fails):*
1. Testing PTR using PgBackRest(2.52.1) on RHEL9 EPAS-16, and RHEL9 (
Repo Server)
When I do a PTR
1. After doing a table drop and then
2. Noting down the time stamp and then
3. Taking an incremental backup in hope that If I do a
Piotr Andreassen Blasiak schrieb am 01.08.2024 um 10:42:
> I know that currently logical replication slots are available only
> for primary servers. Is there any plan to add this feature to read
> slaves as well? My problem is this:
>
> I want to use debezium to stream changes from postgresql. But,
Hi,
I know that currently logical replication slots are available only for primary
servers. Is there any plan to add this feature to read slaves as well? My
problem is this:
I want to use debezium to stream changes from postgresql. But, if I stream
changes from the master I can not query my re
17 matches
Mail list logo
