Background process is initialized at server start and when trying to run
the tests i get the following error.
$ make installcheck
(using postmaster on Unix socket, default port)
== dropping database "contrib_regression" ==
ERROR: DROP DATABASE cannot be executed from a fun
On Tue, 21 Jun 2016, 4:03 a.m. Johan Thomsen,
wrote:
> Hi,
>
> In relation to this thread:
>
> https://www.postgresql.org/message-id/0B4197B9-5DB8-4475-A83C-38DA5965782A%40etasseo.com
>
> > I ran the pg_dump process again this morning, ensuring that the standby
> > parameters were set, and it com
On Mon, Jun 20, 2016 at 3:18 AM, Job wrote:
>
> Hello,
>
> we have a table with an heavy traffic of pg_bulkload and delete of records.
> The size pass, in only one day, for example for 1Gb to 4Gb and then 1Gb back.
>
> We have important problems on size and the only way to gain free space is
> is
On Fri, Jun 17, 2016 at 5:05 PM, Erdmann, Markus @ Bellevue <
markus.erdm...@cbre.com> wrote:
> Thank you Tom and David for your very helpful replies. We dumped and
> restored the RDS staging database on a local installation of pg and were
> not able to reproduce the issue in 9.5.2, which led us t
On Sun, Jun 19, 2016 at 5:09 PM, Allan Kamau wrote:
> I have an xml document from which I would like to extract the contents of
> several elements.
>
> I would like to use xpath to extract the contents of "name" from the xml
> document shown below.
>
> WITH x AS
> (
> SELECT
> '
> http://uniprot.
Hi,
In relation to this thread:
https://www.postgresql.org/message-id/0B4197B9-5DB8-4475-A83C-38DA5965782A%40etasseo.com
> I ran the pg_dump process again this morning, ensuring that the standby
> parameters were set, and it completed successfully with the
> hot_standby_feedback enabled.
In case
I have an xml document from which I would like to extract the contents of
several elements.
I would like to use xpath to extract the contents of "name" from the xml
document shown below.
WITH x AS
(
SELECT
'
http://uniprot.org/uniprot"; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"; xsi:
Hi,
My postgresql-fu is not good enough to write a query to achieve this
(some may well say r is a better suited tool to achieve this !).
I need to calculate what I would call a correlation window on a time
series of data, my table looks like this :
create table data(data_date date,data_measurem
Thank you Tom and David for your very helpful replies. We dumped and
restored the RDS staging database on a local installation of pg and were
not able to reproduce the issue in 9.5.2, which led us to try running a
VACUUM ANALYZE and recreating indexes. After this we no longer saw a
discrepancy betw
On Mon, Jun 20, 2016 at 1:53 PM, Vik Fearing wrote:
> On 20/06/16 17:25, Melvin Davidson wrote:
> >>And you haven't read Vik's reply. :)
> >
> > Yes I have. Vacuum wll not lock all tables at once, only the ones it is
> > currently working on, so the planner may have a slight delay,
> > but it wil
On 20/06/16 17:25, Melvin Davidson wrote:
>>And you haven't read Vik's reply. :)
>
> Yes I have. Vacuum wll not lock all tables at once, only the ones it is
> currently working on, so the planner may have a slight delay,
> but it will not be gigantic.
I think you should try it.
> I have proposed
On 6/20/2016 8:51 AM, David G. Johnston wrote:
incorrect. in fact, an update is performed identically to an
INSERT + DELETE(old)
Except for heap-only-tuple optimization, right? We cannot build a HOT
chain if the user requests a delete separately since their is no
longer an associ
On Monday, June 20, 2016, John R Pierce wrote:
> On 6/20/2016 8:03 AM, Scott Mead wrote:
>
>>
>> I believe that free space is only available to UPDATE, not INSERT.
>>
>
> incorrect. in fact, an update is performed identically to an INSERT +
> DELETE(old)
>
>
Except for heap-only-tuple optimizat
On Mon, Jun 20, 2016 at 7:23 AM, Martín Marqués wrote:
> El 20/06/16 a las 09:50, Melvin Davidson escribió:
>>
>>
>>>but it won't let it grow too (or am I missing something).
>>
>> Yes, you are missing something. By partioning and {Vacuum Full only the
>> table with data no longer needed}, the res
On 06/20/2016 03:18 AM, Job wrote:
> Hello,
>
> we have a table with an heavy traffic of pg_bulkload and delete of records.
> The size pass, in only one day, for example for 1Gb to 4Gb and then 1Gb back.
>
> We have important problems on size and the only way to gain free space is
> issueing a v
On 6/20/2016 8:03 AM, Scott Mead wrote:
I believe that free space is only available to UPDATE, not INSERT.
incorrect. in fact, an update is performed identically to an INSERT +
DELETE(old)
--
john r pierce, recycling bits in santa cruz
--
Sent via pgsql-general mailing list (pgsql-gen
El 20/06/16 a las 11:52, Jeff Janes escribió:
> On Mon, Jun 20, 2016 at 3:13 AM, Andreas Kretschmer
> wrote:
>>
>>
>> Am 20.06.2016 um 11:43 schrieb Job:
>>>
>>> Hi Andreas,
>>>
I would suggest run only autovacuum, and with time you will see a not
more growing table. There is no need for
On Mon, Jun 20, 2016 at 11:18 AM, Martín Marqués
wrote:
> El 20/06/16 a las 12:06, Melvin Davidson escribió:
> >
> > Martin and Vik,
> >
> >>...Think about a SELECT which has to scan all child tables.
> >
> > You are really digging for a corner case.
> > If a scan has to scan all child tables, th
El 20/06/16 a las 12:06, Melvin Davidson escribió:
>
> Martin and Vik,
>
>>...Think about a SELECT which has to scan all child tables.
>
> You are really digging for a corner case.
> If a scan has to scan all child tables, then
> A. it negates the ability to make partitions which are not used
>
2016-06-20 17:03 GMT+02:00 Scott Mead :
>
>
> On Mon, Jun 20, 2016 at 6:13 AM, Andreas Kretschmer <
> andr...@a-kretschmer.de> wrote:
>
>>
>>
>> Am 20.06.2016 um 11:43 schrieb Job:
>>
>>> Hi Andreas,
>>>
>>> I would suggest run only autovacuum, and with time you will see a not
more growing ta
On Mon, Jun 20, 2016 at 11:03 AM, Scott Mead wrote:
>
>
> On Mon, Jun 20, 2016 at 6:13 AM, Andreas Kretschmer <
> andr...@a-kretschmer.de> wrote:
>
>>
>>
>> Am 20.06.2016 um 11:43 schrieb Job:
>>
>>> Hi Andreas,
>>>
>>> I would suggest run only autovacuum, and with time you will see a not
mo
On Mon, Jun 20, 2016 at 6:13 AM, Andreas Kretschmer wrote:
>
>
> Am 20.06.2016 um 11:43 schrieb Job:
>
>> Hi Andreas,
>>
>> I would suggest run only autovacuum, and with time you will see a not
>>> more growing table. There is no need for vacuum full.
>>>
>> So new record, when will be pg_bulkloa
On Mon, Jun 20, 2016 at 3:13 AM, Andreas Kretschmer
wrote:
>
>
> Am 20.06.2016 um 11:43 schrieb Job:
>>
>> Hi Andreas,
>>
>>> I would suggest run only autovacuum, and with time you will see a not
>>> more growing table. There is no need for vacuum full.
>>
>> So new record, when will be pg_bulkloa
2016-06-20 11:30 GMT-03:00 Vik Fearing :
> On 20/06/16 16:23, Martín Marqués wrote:
>>
>> That's not entirely true. Think about a SELECT which has to scan all
>> child tables.
>
> Or any SELECT on the parent at all. The planner needs to examine the
> CHECK constraints on the children and can't do
On 20.06.2016 17:30, Vik Fearing wrote:
On 20/06/16 16:23, Martín Marqués wrote:
El 20/06/16 a las 09:50, Melvin Davidson escribió:
but it won't let it grow too (or am I missing something).
Yes, you are missing something. By partioning and {Vacuum Full only the
table with data no longer nee
On 20/06/16 16:23, Martín Marqués wrote:
> El 20/06/16 a las 09:50, Melvin Davidson escribió:
>>
>>
>>> but it won't let it grow too (or am I missing something).
>>
>> Yes, you are missing something. By partioning and {Vacuum Full only the
>> table with data no longer needed}, the rest of the data
El 20/06/16 a las 09:50, Melvin Davidson escribió:
>
>
>>but it won't let it grow too (or am I missing something).
>
> Yes, you are missing something. By partioning and {Vacuum Full only the
> table with data no longer needed}, the rest of the data remains
> available to the users
> AND space is
Artur, thanks for help. I managed to add the new strategy to the index.
Hurray! I also discovered a bug in the process that I reported via the form.
I still have a few questions:
1. Naming - pg_trgm_match, match, threshold, trgm_check_match,
ThresholdStrategyNumber - are these good names?
2. I ma
On Mon, Jun 20, 2016 at 6:20 PM, Melvin Davidson
wrote:
>
> On Mon, Jun 20, 2016 at 8:29 AM, Rakesh Kumar
> wrote:
>
>> But then autovaccum avoids this. Granted it won't give back free space to
>> OS, but it won't let it grow too (or am I missing something).
>>
>>
>>
On Mon, Jun 20, 2016 at 8:29 AM, Rakesh Kumar
wrote:
> But then autovaccum avoids this. Granted it won't give back free space to
> OS, but it won't let it grow too (or am I missing something).
>
>
> --
> *From:* Job
> *To:* Rakesh Kumar ; "
> pgsql-general@postgresql.
But then autovaccum avoids this. Granted it won't give back free space to OS,
but it won't let it grow too (or am I missing something).
From: Job
To: Rakesh Kumar ; "pgsql-general@postgresql.org"
Sent: Monday, June 20, 2016 5:39 AM
Subject: R: [GENERAL] Vacuum full: alternatives?
On Mon, Jun 20, 2016 at 6:13 AM, Andreas Kretschmer wrote:
>
>
> Am 20.06.2016 um 11:43 schrieb Job:
>
>> Hi Andreas,
>>
>> I would suggest run only autovacuum, and with time you will see a not
>>> more growing table. There is no need for vacuum full.
>>>
>> So new record, when will be pg_bulkloa
Am 20.06.2016 um 11:43 schrieb Job:
Hi Andreas,
I would suggest run only autovacuum, and with time you will see a not
more growing table. There is no need for vacuum full.
So new record, when will be pg_bulkloaded, will replace "marked-free" location?
exactly, that's the task for vacuum
On Mon, 2016-06-20 at 11:43 +0200, Job wrote:
> Hi Andreas,
>
> >I would suggest run only autovacuum, and with time you will see a not
> >more growing table. There is no need for vacuum full.
>
> So new record, when will be pg_bulkloaded, will replace "marked-free"
> location?
Yes, but you may
Hi Andreas,
>I would suggest run only autovacuum, and with time you will see a not
>more growing table. There is no need for vacuum full.
So new record, when will be pg_bulkloaded, will replace "marked-free" location?
Thank you!
Francesco
Da: pgsql-gen
Hi Rakesh,
if i do not free disk space, after some days disk can become full.
Everyday we have a lot of pg_bulkload and delete.
Thank you!
Francesco
Da: pgsql-general-ow...@postgresql.org [pgsql-general-ow...@postgresql.org] per
conto di Rakesh Kumar [rakeshkuma
Am 20.06.2016 um 11:18 schrieb Job:
Hello,
we have a table with an heavy traffic of pg_bulkload and delete of records.
The size pass, in only one day, for example for 1Gb to 4Gb and then 1Gb back.
We have important problems on size and the only way to gain free space is issueing a
vacuum ful
Any reason why you need the space back? What is wrong with space remaining
constant at 4GB.
From: Job
To: "pgsql-general@postgresql.org"
Sent: Monday, June 20, 2016 5:18 AM
Subject: [GENERAL] Vacuum full: alternatives?
Hello,
we have a table with an heavy traffic of pg_bulkload
Hello,
we have a table with an heavy traffic of pg_bulkload and delete of records.
The size pass, in only one day, for example for 1Gb to 4Gb and then 1Gb back.
We have important problems on size and the only way to gain free space is
issueing a vacuum full .
But the operation is very slow, some
39 matches
Mail list logo
