pá 26. 6. 2020 v 7:29 odesílatel Thomas Kellerer napsal:
> I regularly see people suggesting to use
>
> extract(day from one_timestamp - other_timestamp)
>
> to calculate the difference between two timestamps in days.
>
> But I wonder if the "format" of the resulting interval is guaranteed
I regularly see people suggesting to use
extract(day from one_timestamp - other_timestamp)
to calculate the difference between two timestamps in days.
But I wonder if the "format" of the resulting interval is guaranteed to only
have days
(and not months or years)
The following:
Sorry, I don't know much about postgis at all. I assume you meant to have
THEN 1 in your update statement as well.
I notice b.fid=l.fid and NOT b.fid=l.fid in the two clauses. How about
separate update statements?
UPDATE linesegments l
set edited = 1
WHERE l.gid IN (SELECT li.gid FROM
Matthias Apitz writes:
> On Thursday, 25 June 2020 21:41:54 CEST, Tom Lane
> wrote:
>> regardless of the exact details, it seems like the most likely theory
>> about what is happening is that the dump file is corrupt and the
>> corruption is causing the de-gzipped output to be missing or
>>
On Thursday, 25 June 2020 21:41:54 CEST, Tom Lane
wrote:
Adrian Klaver writes:
On 6/25/20 11:03 AM, Matthias Apitz wrote:
I looked in the dump file after uncompressing it. The 'syntax error'
comes from: one large table contains in a bytea column Perl code wich
our software reads from the
Adrian Klaver writes:
> On 6/25/20 11:03 AM, Matthias Apitz wrote:
>> I looked in the dump file after uncompressing it. The 'syntax error'
>> comes from: one large table contains in a bytea column Perl code wich
>> our software reads from the table and executes it with Perl. But, why
>> the psql
On Thursday, 25 June 2020 21:12:50 CEST, Adrian Klaver
wrote:
acq_vardata where id= order by sel_seq_3
2020-06-25 12:06:42.098 CEST [306] ERROR: syntax error at or
near "q" at character 1
...
If this was coming from the restore of the dump file I would expect to
see a COPY line just
On 6/25/20 11:03 AM, Matthias Apitz wrote:
El día Donnerstag, Juni 25, 2020 a las 08:59:49 -0700, Adrian Klaver escribió:
On 6/25/20 5:54 AM, Matthias Apitz wrote:
El día jueves, junio 25, 2020 a las 01:11:37p. m. +0200, Matthias Apitz
escribió:
Hello
A PG dump file was produced on a
Thanks for your support.
I will try to restore and provide results shortly without restoring pg_xlog
file
Regards,
Sri
On Thu, Jun 25, 2020 at 1:09 PM Stephen Frost wrote:
> Greetings,
>
> * Sri Linux (srilinu...@gmail.com) wrote:
> > Please find the method used. Please recommend me if I have
Greetings,
* Sri Linux (srilinu...@gmail.com) wrote:
> Please find the method used. Please recommend me if I have done
> something wrong...
Yes, you are using 'cp' which is *not* recommended for an archive
command.
> Performing a hot backup using pg_basebackup:
> Create a new folder as the
On Thu, Jun 25, 2020 at 04:20:06PM +0530, Bhalodiya, Chirag wrote:
> Hi Patrick,
>
> Thanks for the information. I was looking for out of box postgre solution so
> wanted to know how to apply following patch on top of my postgre 12
> installation:
> https://www.postgresql.org/message-id/
>
El día Donnerstag, Juni 25, 2020 a las 08:59:49 -0700, Adrian Klaver escribió:
> On 6/25/20 5:54 AM, Matthias Apitz wrote:
> >
> >
> > El día jueves, junio 25, 2020 a las 01:11:37p. m. +0200, Matthias Apitz
> > escribió:
> >
> > >
> > > Hello
> > >
> > > A PG dump file was produced on a
Thank you all for the response,
Please find the method used. Please recommend me if I have done
something wrong...
Thanks and Regards,
sree
On Wed, Jun 24, 2020 at 11:36 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> The version you are running is neither up-to-date for its major
On Thu, Jun 25, 2020 at 7:27 AM Pavel Luzanov
wrote:
> I have tried to increase the statistics target to 5000, and it helps, but
> it reduces the error to 100X. Still crazy high.
>
>
> As far as I know, increasing default_statistics_target will not help. [1]
>
> I have considered these fixes:
>
Erwin Sebastian Andreasen writes:
> Compare the output of:
> select random(), random();
> which will return 2 separate random values with:
> select random(), random() order by random();
> which returns two of the same values (and the same value is also used in
> order by). While I use 9.6, I got
On 6/25/20 5:54 AM, Matthias Apitz wrote:
El día jueves, junio 25, 2020 a las 01:11:37p. m. +0200, Matthias Apitz
escribió:
Hello
A PG dump file was produced on a 11.4. server the usual ways.
When it is loaded with
$ gzip -dc newanna_export.dmp | /usr/local/sisis-pap/pgsql/bin/psql -U
On Thu, Jun 25, 2020 at 8:24 AM Paul Förster
wrote:
> Archived WAL is another thing, but PGDATA and pg_wal should IMHO always be
> located on the same volume, along with tablespaces, if any.
>
My understanding that having such a setup (single volume) eases
administration at the cost of
Hi Ken,
> On 25. Jun, 2020, at 17:15, Wolff, Ken L wrote:
> There's actually a lot of good stuff in that document about Postgres in
> general. I'd be curious to hear what everyone thinks, though, and
> specifically about what NetApp recommends in Section 3.3 about putting data
> and WAL on
>> On 23. Jun, 2020, at 22:59, Wolff, Ken L wrote:
>>
>> https://www.netapp.com/us/media/tr-4770.pdf
> I will check this out. Thank you very much.
There's actually a lot of good stuff in that document about Postgres in
general. I'd be curious to hear what everyone thinks, though, and
Hello,
I got my first hint of why this problem occurs when I looked at the
statistics. For the column in question, "instrument_ref" the
statistics claimed it to be:
The default_statistics_target=500, and analyze has been run.
select * from pg_stats where attname like 'instr%_ref'; --
El día jueves, junio 25, 2020 a las 01:11:37p. m. +0200, Matthias Apitz
escribió:
>
> Hello
>
> A PG dump file was produced on a 11.4. server the usual ways.
> When it is loaded with
>
> $ gzip -dc newanna_export.dmp | /usr/local/sisis-pap/pgsql/bin/psql -U sisis
> sisis
>
> it gives
Hi Michael,
Thanks for taking interest in my problem.
My biggest problem is that I’m not so familiar with SQL, and having problems to
see how I can realize your suggestion.
I’ve been testing in pgAdmin with 2 tables:
linesegments and buffered.
linesegments (splitted line strings into segments)
Hi Patrick,
Thanks for the information. I was looking for out of box postgre solution
so wanted to know how to apply following patch on top of my postgre 12
installation:
https://www.postgresql.org/message-id/CAD21AoBjrbxvaMpTApX1cEsO%3D8N%3Dnc2xVZPB0d9e-VjJ%3DYaRnw%40mail.gmail.com
Regards,
Hello
A PG dump file was produced on a 11.4. server the usual ways.
When it is loaded with
$ gzip -dc newanna_export.dmp | /usr/local/sisis-pap/pgsql/bin/psql -U sisis
sisis
it gives lots of error messages in the server log as:
2020-06-25 12:00:50.333 CEST [31295] ERROR: canceling
## Durumdara (durumd...@gmail.com):
> Do we have chance to log somewhere the connected client's certificate, or
> some info about it?
There's pg_stat_ssl, and if you had an recent version of PostgreSQL
(9.6 is too old for that), you'd even have the serial number of
the certificate in there:
Hi
CYBERTEC provided good installation guide
(https://www.cybertec-postgresql.com/en/products/postgresql-transparent-data-encryption/).
Here is their answer to your question :
Q: Can I upgrade to an encrypted database?
A: In place encryption of existing clusters is currently not supported. A
> If we could increase the sampling ratio beyond the hard coded 300x to get a
> more representative sample and use that to estimate ndistinct (and also the
> frequency of the most common values) but only actually stored the 100 MCVs
> (or whatever the stats target is set to for the system or
On Thu, Jun 25, 2020 at 10:59 AM Rajnish Vishwakarma <
rajnish.nationfi...@gmail.com> wrote:
> I am creating dynamically table in PostgreSQL using psycopg2 by passing
> the below 2 strings as column names:
>
>
>
Le jeu. 25 juin 2020 à 10:59, Rajnish Vishwakarma <
rajnish.nationfi...@gmail.com> a écrit :
> I am creating dynamically table in PostgreSQL using psycopg2 by passing
> the below 2 strings as column names:
>
>
>
I wanted to generate some test data based on a subset of rows in a table,
thus used ORDER BY RANDOM(). I was surprised to see that if RANDOM() is
used in ORDER BY it cannot also be used in column names: the same value is
returned.
Compare the output of:
select random(), random();
which will
Hi,
We are migrating our product to PostGreSQL from Oracle and as part of HIPPA(
https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act)
guidelines, we have a requirement to encrypt entire tablespace/specific
tables using Transparent data encryption(TDE).
I was looking
I am creating dynamically table in PostgreSQL using psycopg2 by passing the
below 2 strings as column names:
'BAF7_X_X_During_soaking-__Temperature__difference_coil_to_coil_with_metal_temp_TC_load_in_PA_load'
and
Thanks for your analysis.
Regards
El mié., 24 jun. 2020 a las 17:17, Tom Lane () escribió:
> I wrote:
> > David Rowley writes:
> >> I don't often do much with pgbench and variables, but there are a few
> >> things that surprise me here.
> >> 1) That pgbench replaces variables within single
Hello!
PGSQL 9.6, Linux, SSL.
We want to change certs to new, but somehow we need to detect which old
cert is in use before the expiration.
So now they could connect with old and new too. We want to warn the clients
with old certs to update, before they will be denied.
Do we have chance to log
I'll look into it. Thanks for the analysis and CC-ing.
--
Fabien.
Hi,
Basically I had the same topic recently and based on observation I would say
that configuration parameter hot_standby_feedback disables no only some
vacuuming operations but something else as well. I played thru the same
scenario where I disabled hot_standby_feedback and and vacuuming, but
36 matches
Mail list logo
