At Sun, 2 May 2021 22:43:44 +0200, Adrien Nayrat
wrote in
> I also dumped 000100AA00A1 on the secondary and it
> contains all the records until AA/A1004018.
>
> It is really weird, I don't understand how the secondary can miss the
> last 2 records of A0? It seems he did not received
On 5/5/21 3:20 PM, Ashwin Kini wrote:
Thank you very much
Just be aware that these are archived packages, they will not be updated
with security/bug fixes.
Regards,
Ashwin Kini
--
Adrian Klaver
adrian.kla...@aklaver.com
On 5/5/21 11:42 AM, Ashwin Kini wrote:
Hi all,
We were able to download trusty postrgres-9.5* debians until today
morning. I don’t seem them anymore upstream. We are aware support for
trusty (14.04) is discontinued.
Does this mean we wont have debians anymore in the upstream path
See here:
Hi all,
We were able to download trusty postrgres-9.5* debians until today morning. I
don’t seem them anymore upstream. We are aware support for trusty (14.04) is
discontinued.
Does this mean we wont have debians anymore in the upstream path
http://apt.postgresql.org/pub/repos/apt/pool/main/p/p
On 05.05.2021 17:11, Tom Lane wrote:
Tomas Vondra writes:
On 5/5/21 3:23 PM, Pavel Luzanov wrote:
It is very likely that the date_trunc function in the following
example is executed for each line of the query. Although it marked
as a STABLE and could only be called once.
It could, but that's
Hello All,
I am trying to build a postgres extension and I have installed the following
hooks using this document
https://wiki.postgresql.org/images/e/e3/Hooks_in_postgresql.pdf
The hooks that I have installed in my extension are the followings:
- shmem_startup_hook
- post_parse_analyze
Hello,
On 05.05.2021 16:55, Tomas Vondra wrote:
Well, it'd not like date_trunc is executed for each row while now() is
executed only once. The functions are executed for each row in both
cases, but now() is simply much cheaper - it just returns a value that
is already calculated, while date_tr
Tomas Vondra writes:
> On 5/5/21 3:23 PM, Pavel Luzanov wrote:
>> It is very likely that the date_trunc function in the following example
>> is executed for each line of the query. Although it marked as a STABLE
>> and could only be called once.
> It could, but that's just an option - the datab
On Wed, May 5, 2021 at 01:26:43PM +0200, Arne Henrik Segtnan wrote:
> Hi,
>
> Thanks a lot for the feedback, which actually solved the problem. After
> executing the below command, upgrade from 10 to 12 worked perfectly fine.
>
> pgsqldb=# DROP EXTENSION pg_repack CASCADE;
Great to hear, than
On 5/5/21 3:23 PM, Pavel Luzanov wrote:
Hello,
It is very likely that the date_trunc function in the following example
is executed for each line of the query. Although it marked as a STABLE
and could only be called once.
It could, but that's just an option - the database may do that, bu
Hello,
It is very likely that the date_trunc function in the following example
is executed for each line of the query. Although it marked as a STABLE
and could only be called once.
EXPLAIN (ANALYZE)
SELECT * FROM generate_series('2021-01-01', '2021-06-01', '1
s'::interval) AS g(x) WHERE g.x
Hi,
Thanks a lot for the feedback, which actually solved the problem. After
executing the below command, upgrade from 10 to 12 worked perfectly fine.
pgsqldb=# DROP EXTENSION pg_repack CASCADE;
Med vennlig hilsen / Best regards,
___
Arne Henrik Segtnan
> 4. mai 2021 kl
12 matches
Mail list logo
