On Tue, Jun 11, 2024 at 5:29 PM David G. Johnston
wrote:
> On Tuesday, June 11, 2024, Dominique Devienne wrote:
>> Are Stored PROCs running in a different backend?
>> Are Triggers running in a different backend?
> No to both. Whatever backend the SQL to invoke those was sent on is the
> backend
On Tue, Jun 11, 2024 at 2:53 PM veem v wrote:
>
> On Tue, 11 Jun 2024 at 17:03, hubert depesz lubaczewski
> wrote:
>
>> On Tue, Jun 11, 2024 at 12:47:14AM +0530, veem v wrote:
>> > to be called from ~50 triggers? or any other better approach exists to
>> > handle this?
>>
>> pgaudit extension?
>
First post to this list, and am sure it won't be my last, but you guys rock!
Took a bit from all three replies and got the transformation working
seamlessly.
Created temp table.
Copied data into temp from original (just in case!)
Created partitioned table using modulus 8.
Imported the data into th
> If there are any errors during the replay of WAL such as missing indexes
for Replica Identities during an Update or Delete this will cause the main
subscriber worker slot on the publisher to start backing up WAL files
And also if the connection breaks, from what I understand, is that correct?
A
> Have you looked at pg_upgrade?:
I have, but I want to keep downtime to a minimum and from my understanding
the switching of a fully synced logical replica only requires updating your
sequences. Which should be possible in less than 60 seconds.
> 1 GB each?
Yes, each. Roughly around there.
On
Dear list members,
maybe a naive question but I was unable to find an answer in
the fine manual (sv_SE being an example)
Does running
DROP COLLATION IF EXISTS pg_catalog."sv_SE"
also remove the corresponding row from pg_collation (assuming
nothing depends on collation sv_SE) ?
Experime
On Wed, Jun 12, 2024 at 12:50:27AM +0530, veem v wrote:
> My apology, if interpreting it wrong way. It doesn't make much difference
> though, but do you mean something like below?
if you really have totally different structures across all tables, and
you don't want to use pgaudit (which is the bes
On 6/11/24 12:20, veem v wrote:
On Wed, 12 Jun 2024 at 00:26, hubert depesz lubaczewski
mailto:dep...@depesz.com>> wrote:
No, I meant building dynamic queries and then EXECUTE-ing, like docs
show:
https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMEN
On Wed, 12 Jun 2024 at 00:26, hubert depesz lubaczewski
wrote:
>
>
> No, I meant building dynamic queries and then EXECUTE-ing, like docs
> show:
>
> https://www.postgresql.org/docs/current/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN
>
> Best regards,
>
> depesz
>
>
My apology, if in
On Wed, Jun 12, 2024 at 12:19:55AM +0530, veem v wrote:
> CREATE OR REPLACE FUNCTION log_deletes()
> RETURNS TRIGGER AS $$
> BEGIN
> IF TG_TABLE_NAME = 'source_table1' THEN
> INSERT INTO delete_audit1 ( col1, col2, col3)
> VALUES (OLD.col1, OLD.col2, OLD.col3);
> ELSIF TG_TA
On Tue, 11 Jun 2024 at 17:03, hubert depesz lubaczewski
wrote:
> On Tue, Jun 11, 2024 at 12:47:14AM +0530, veem v wrote:
> > to be called from ~50 triggers? or any other better approach exists to
> > handle this?
>
> pgaudit extension?
>
> Or just write all the changes to single table?
>
> Or use
On Sun, Jun 9, 2024 at 1:40 PM Lok P wrote:
> On Sun, Jun 9, 2024 at 10:39 AM Lok P wrote:
>
>>
>>
>> On Sun, Jun 9, 2024 at 10:36 AM sud wrote:
>>
>>>
>>> You can first create the index on the table using the "On ONLY"keyword,
>>> something as below.
>>>
>>> CREATE INDEX idx ON ONLY tab(col1)
On Tuesday, June 11, 2024, Dominique Devienne wrote:
>
> Are Stored PROCs running in a different backend?
> Are Triggers running in a different backend?
>
No to both. Whatever backend the SQL to invoke those was sent on is the
backend that executes them.
David J.
On 6/11/24 08:05, Dominique Devienne wrote:
Hi. I have a unit test using a single connection, that simulates a
client interacting with a server via a PostgreSQL "queue", i.e. a
non-writable table with SECURITY DEFINER procedures to mediate writes
to that table, with those PROC-initiated updates t
Hi. I have a unit test using a single connection, that simulates a
client interacting with a server via a PostgreSQL "queue", i.e. a
non-writable table with SECURITY DEFINER procedures to mediate writes
to that table, with those PROC-initiated updates triggering
pg_notify() messages (via an UPDATE
On Mon, 10 Jun 2024, Christophe Pettus wrote:
The sequence functions are documented here:
https://www.postgresql.org/docs/current/functions-sequence.html
setval is the function you want. You can use a SELECT so you don't have to
copy values around:
select setval('t_pk_seq', (sele
On Tue, Jun 11, 2024 at 12:47:14AM +0530, veem v wrote:
> to be called from ~50 triggers? or any other better approach exists to
> handle this?
pgaudit extension?
Or just write all the changes to single table?
Or use dynamic queries that will build the insert based on the name of
table the event
Tom:
On Tue, 11 Jun 2024 at 01:49, Tom Lane wrote:
> I think if we're going to change anything at all here, we should
> define the external API in microseconds not milliseconds. The lesson
> we need to be taking from this is that system calls come and go,
> but libpq API is forever ;-). Somebo
18 matches
Mail list logo
