Thanks Adrian.
I am aware about the functions. Here need is, can we use this?.or is there
any known effects after firing the functions?.
Thanks,
Postgann.
On Sat, Feb 22, 2020 at 10:47 PM Adrian Klaver
wrote:
> On 2/22/20 12:26 AM, postggen2020 s wrote:
> > Hi Team,
> >
> > Good Afternoon,
> >
On 2/22/20 3:28 PM, Ron wrote:
On 2/22/20 5:12 PM, Adrian Klaver wrote:
On 2/22/20 2:39 PM, Andrus wrote:
[snip]
This is a different issue and involves a product VFP that is EOL 5-10
years depending on support package. I'm going to say the hand writing
is on the wall and it is time to
On 2/22/20 5:12 PM, Adrian Klaver wrote:
On 2/22/20 2:39 PM, Andrus wrote:
[snip]
This is a different issue and involves a product VFP that is EOL 5-10
years depending on support package. I'm going to say the hand writing is
on the wall and it is time to upgrade software.
I don't know where
On 2/22/20 2:37 PM, Andrus wrote:
Hi!
I'm looking for a way to fix psqlODBC driver regression.
Starting at psqlODBC 09.05.0100 when psqlODBC driver uses libpq for all
operations (earlier versions used libpg only for authentication) ODBC
client
does not show error message details.
For
De: Adrian Klaver
Enviado: sábado, 22 de fevereiro de 2020 18:12
Para: Edson Richter ; pgsql-general
Assunto: Re: Replication: slave server has 3x size of production server?
On 2/22/20 11:23 AM, Edson Richter wrote:
>
Hi!
I have no idea.
I changed application not to send ; before select.
This solves issues in both servers.
So using ; as first character before select in ODBC command like
;SELECT * from mytable
Causes C5 is Postgres 9.0 and ODBC client hangup with "connection reset by
peer" message in log
Hi!
I'm looking for a way to fix psqlODBC driver regression.
Starting at psqlODBC 09.05.0100 when psqlODBC driver uses libpq for all
operations (earlier versions used libpg only for authentication) ODBC client
does not show error message details.
For example, users got only generic error
> On Feb 22, 2020, at 14:36, Tom Lane wrote:
> The problem that I'm worried about is premature evaluation of the
> "immutable" function, causing the NOTICE to come out once during
> query planning, independently of whether/how many times it should
> come out during execution.
Ah, good point.
Christophe Pettus writes:
>> On Feb 22, 2020, at 14:02, Tom Lane wrote:
>> It's a really bad idea to mark a function that has side-effects
>> (i.e., emitting a NOTICE) as immutable, especially if the occurrence
>> of the side-effect at well-defined times is exactly what you're
>> desirous of.
>
On 2020-02-17 10:17:41 -0500, Jason Swails wrote:
> I then added "network.target", "networking.service", and
> "network-online.target" to the After line of the postgresql.service systemd
> file, but it still didn't fix the problem.
After=network-online.target should be correct.
However, see
Hi Michael!
Am 21.02.2020 um 21:24 schrieb Michael Lewis:
I am very interested in this discussion. We settled a table with a
single timestamp field that a script updates every minute with NOW() so
that we can check the timestamp of that table on the replica, assuming
the clocks are synced,
> On Feb 22, 2020, at 14:02, Tom Lane wrote:
> It's a really bad idea to mark a function that has side-effects
> (i.e., emitting a NOTICE) as immutable, especially if the occurrence
> of the side-effect at well-defined times is exactly what you're
> desirous of.
True, and it doesn't actually
Christophe Pettus writes:
> Something like this:
> create function supply_default() returns int as $$
> begin
>raise notice 'Supplied default';
>return 1;
> end;
> $$ immutable language plpgsql;
It's a really bad idea to mark a function that has side-effects
(i.e., emitting a NOTICE) as
> On Feb 22, 2020, at 13:33, stan wrote:
> I suppose you are suggesting that the function try the original SELECT, and
> if it returns a NULL then retun the default AND do the raise NOTICE?
Something like this:
create function supply_default() returns int as $$
begin
raise notice
On Sat, Feb 22, 2020 at 01:06:57PM -0800, Christophe Pettus wrote:
>
>
> > On Feb 22, 2020, at 13:05, Adrian Klaver wrote:
> >
> > On 2/22/20 1:02 PM, stan wrote:
> >> I have a case where if a value does not exist, I am going to use a default,
> >> which is easy with coalesce. But I would like
On 2/22/20 11:23 AM, Edson Richter wrote:
*De:* Adrian Klaver
*Enviado:* sábado, 22 de fevereiro de 2020 16:16
*Para:* Edson Richter ; pgsql-general
*Assunto:* Re: Replication: slave server has 3x
On 2/21/20 11:43 PM, Andrus wrote:
Hi!
To me the relevant part of the log is below. Not sure what it means
though:
[3604-0.187] execute.c[Exec_with_parameters_resolved]444:
stmt_with_params = ';SELECT * FROM temptulemus offset 0 limit 900'
[3604-0.187]
> On Feb 22, 2020, at 13:05, Adrian Klaver wrote:
>
> On 2/22/20 1:02 PM, stan wrote:
>> I have a case where if a value does not exist, I am going to use a default,
>> which is easy with coalesce. But I would like to warn the user that a
>> default has been supplied. The default value is
On 2/22/20 1:02 PM, stan wrote:
I have a case where if a value does not exist, I am going to use a default,
which is easy with coalesce. But I would like to warn the user that a
default has been supplied. The default value is reasonable, and could
actually come from the source table, so I can't
I have a case where if a value does not exist, I am going to use a default,
which is easy with coalesce. But I would like to warn the user that a
default has been supplied. The default value is reasonable, and could
actually come from the source table, so I can't just check the value.
I'd like to
De: Adrian Klaver
Enviado: sábado, 22 de fevereiro de 2020 16:16
Para: Edson Richter ; pgsql-general
Assunto: Re: Replication: slave server has 3x size of production server?
On 2/22/20 11:03 AM, Edson Richter wrote:
>
On 2/22/20 11:03 AM, Edson Richter wrote:
Streaming replication. Initiated via pg_basebackup.
Settings on master server:
# - Sending Server(s) -
# Set these on the master and on any standby that will send
De: Adrian Klaver
Enviado: sábado, 22 de fevereiro de 2020 15:50
Para: Edson Richter ; pgsql-general
Assunto: Re: Replication: slave server has 3x size of production server?
On 2/22/20 10:05 AM, Edson Richter wrote:
>
On 2/22/20 10:05 AM, Edson Richter wrote:
*De:* Adrian Klaver
*Enviado:* sábado, 22 de fevereiro de 2020 14:33
*Para:* Edson Richter ; pgsql-general
*Assunto:* Re: Replication: slave server has 3x
On 2/22/20 10:34 AM, Daulat Ram wrote:
Hi team,
how to find a tablespace for the table?
See my comments below:
I have created a database with default tablespace like below:
edb=# CREATE DATABASE conndb WITH TABLESPACE = conn_s_tables;
After that I have created a table
CREATE TABLE
Hi team,
how to find a tablespace for the table?
See my comments below:
I have created a database with default tablespace like below:
edb=# CREATE DATABASE conndb WITH TABLESPACE = conn_s_tables;
After that I have created a table
CREATE TABLE COMPANY_new(
ID INT PRIMARY KEY NOT NULL,
De: Adrian Klaver
Enviado: sábado, 22 de fevereiro de 2020 14:33
Para: Edson Richter ; pgsql-general
Assunto: Re: Replication: slave server has 3x size of production server?
On 2/22/20 9:25 AM, Edson Richter wrote:
> Hi!
>
> I've a database cluster created at
On Sat, Feb 22, 2020 at 9:34 AM Tom Lane wrote:
>
> Um. At that point I'd agree with your concern about developing hardware
> problems. Both of these symptoms could be easily explained by dropped
> bits in PG's shared memory area. Do you happen to know if the server
> has ECC RAM?
>
> Yes, it
Mark Fletcher writes:
> Thanks for the response. I did restart the postmaster yesterday. Earlier
> this morning, a query that normally completes fine started to error out
> with 'invalid memory alloc request size 18446744073709551613'. Needless to
> say our database isn't quite that size. This
On 2/22/20 9:25 AM, Edson Richter wrote:
Hi!
I've a database cluster created at 9.6.10 linux x64 server rhel. I made
progressive upgrades, first upgrading slave and then upgrading master.
Actually both are running 9.6.17.
Current production server has 196Gb in size.
Nevertheless, the
On Fri, Feb 21, 2020 at 2:53 PM Tom Lane wrote:
>
> Personally, I'd restart the postmaster, but not do more than that unless
> the error recurs.
>
Thanks for the response. I did restart the postmaster yesterday. Earlier
this morning, a query that normally completes fine started to error out
Hi!
I've a database cluster created at 9.6.10 linux x64 server rhel. I made
progressive upgrades, first upgrading slave and then upgrading master.
Actually both are running 9.6.17.
Current production server has 196Gb in size.
Nevertheless, the replicated (slave) server has 598 Gb in size.
On 2/22/20 12:26 AM, postggen2020 s wrote:
Hi Team,
Good Afternoon,
We have seen some deadlocks and tempfile count in pg_stat_database view.
We are trying to reset the stats.
Can we use pg_stat_reset() function to reset these stats without any
impact stats of databases.
Please advise the
Hi Team,
Good Afternoon,
We have seen some deadlocks and tempfile count in pg_stat_database view. We
are trying to reset the stats.
Can we use pg_stat_reset() function to reset these stats without any impact
stats of databases.
Please advise the process to reset the stats.
Thanks.
Postggen.
34 matches
Mail list logo
