A couple of questions about auto-assigned identifier columns,
forgive my ignorance, I'm used to other methods to create IDs...
1. If creating a new application [i.e. no "legacy" reasons to do
anything] using PostgreSQL 10, when creating an "auto-assigned
integer ID" column, what are the
On Mon, Aug 13, 2018 at 5:19 PM, Don Seiler wrote:
> On Mon, Aug 13, 2018 at 4:15 PM, Alvaro Herrera
> wrote:
>
>>
>> Maybe you had a cursor that was not fully scanned before the session was
>> left idle -- as I recall, those can leave buffers pinned.
>>
>
> I don't quite follow this. What
On Mon, Aug 13, 2018 at 4:04 PM, Don Seiler wrote:
>
>
> Anyway, my next step is getting the OK to terminate those idle in
> transaction sessions to see if that gets my vacuum job moving. Meanwhile
> I'll ask a dev to sort out why they might be sitting idle in transaction,
> there's no reason for
On Mon, Aug 13, 2018 at 4:15 PM, Alvaro Herrera
wrote:
>
> Maybe you had a cursor that was not fully scanned before the session was
> left idle -- as I recall, those can leave buffers pinned.
>
I don't quite follow this. What circumstances would lead to this situation?
For what its worth,
On 2018-Aug-13, Don Seiler wrote:
> This afternoon I discovered an autovacuum process that had been running for
> over 6 days. It was waiting on BufferPin event. I kicked off a manual
> vacuum+analyze of the table, which automatically killed that autovacuum.
> This ran for a few minutes before it
Postgres 9.6.6 on CentOS 7
This afternoon I discovered an autovacuum process that had been running for
over 6 days. It was waiting on BufferPin event. I kicked off a manual
vacuum+analyze of the table, which automatically killed that autovacuum.
This ran for a few minutes before it too was
On 08/13/2018 12:11 PM, Tom Lane wrote:
Merlin Moncure writes:
On Mon, Aug 13, 2018 at 12:56 PM mrcasa bengaluru wrote:
Thanks! However, this involves writing the entire JSON in the schema file looks
inconvenient. I was hoping I would be able to reference to an external JSON
file which
Merlin Moncure writes:
> On Mon, Aug 13, 2018 at 12:56 PM mrcasa bengaluru wrote:
>> Thanks! However, this involves writing the entire JSON in the schema file
>> looks inconvenient. I was hoping I would be able to reference to an external
>> JSON file which could be used for the default value.
On Mon, Aug 13, 2018 at 12:56 PM mrcasa bengaluru wrote:
>>
>> I assume that you could declare the column as
>>
>> address jsonb not null default 'your json here'::jsonb;
>
>
> Thanks! However, this involves writing the entire JSON in the schema file
> looks inconvenient. I was hoping I would be
Hi
---
Charles Clavadetscher
Neugasse 84
CH - 8005 Zürich
Tel: +41-79-345 18 88
-
> On 13.08.2018, at 19:40, mrcasa bengaluru wrote:
>
> All,
>
> I'm new to JSONB datatype. We would like to store a nested JSON file in this
All,
I'm new to JSONB datatype. We would like to store a nested JSON file in
this field. Since the JSON is nested, we wanted to create JSON with default
value from an external JSON file.
My address table looks like,
CREATE TABLE address (
id CHAR(36) UNIQUE NOT NULL,
address JSONB NOT NULL
);
On Mon, Aug 13, 2018 at 10:00:56AM -0400, Tom Lane wrote:
> The only likely reason I can guess at is that you want vim to make its
> own connection to the database for some purpose like autocompletion.
That's precisely what I'm looking for.
> That's a cute idea, but from a security standpoint it
On Mon, Aug 13, 2018 at 03:32:21PM +0200, Laurenz Albe wrote:
> hubert depesz lubaczewski wrote:
> > I'm trying to work on some extension to vim when invoked as \e from
> > psql.
> >
> > To make it fully work, I need to know connection details that psql was
> > using while it invoked \e.
> >
> >
On 08/13/2018 04:24 PM, Ashu Pachauri wrote:
+ pgsql-general
Thanks and Regards,
Ashu Pachauri
-- Forwarded message -
From: *Ashu Pachauri* mailto:ashu210...@gmail.com>>
Date: Mon, Aug 13, 2018 at 7:53 PM
Subject: Re: is there any adverse effect on DB if I set autovacuum scale
+ pgsql-general
Thanks and Regards,
Ashu Pachauri
-- Forwarded message -
From: Ashu Pachauri
Date: Mon, Aug 13, 2018 at 7:53 PM
Subject: Re: is there any adverse effect on DB if I set autovacuum scale
factor to zero?
To:
The way I see *autovacuum_vacuum_scale_factor* is not
Adrian Klaver wrote:
"If you set up a WAL archive that's accessible from the standby, these
solutions are not required, since the standby can always use the archive
to catch up provided it retains enough segments. *This is dependent on
verification that the archiving is working properly. A
On 08/13/2018 05:08 AM, Phil Endecott wrote:
Adrian Klaver wrote:
On 08/12/2018 02:56 PM, Phil Endecott wrote:
Anyway. Do others agree that my issue was the result of
wal_keep_segments=0 ?
Only as a sub-issue of the slave losing contact with the master. The
basic problem is maintaining two
On 08/13/2018 03:41 PM, Raghavendra Rao J S V wrote:
Hi Tomas,
Thank you very much for your response.
As we know table becomes a candidate for autovacuum process based on
below formula.
*Autovacuum VACUUM thresold for a table = autovacuum_vacuum_scale_factor
* number of tuples +
Greetings,
* Adrian Klaver (adrian.kla...@aklaver.com) wrote:
> On 08/13/2018 05:39 AM, Stephen Frost wrote:
> >* Phil Endecott (spam_from_pgsql_li...@chezphil.org) wrote:
> >>Adrian Klaver wrote:
> >>>On 08/12/2018 02:56 PM, Phil Endecott wrote:
> Anyway. Do others agree that my issue was
On 08/13/2018 05:39 AM, Stephen Frost wrote:
Greetings,
* Phil Endecott (spam_from_pgsql_li...@chezphil.org) wrote:
Adrian Klaver wrote:
On 08/12/2018 02:56 PM, Phil Endecott wrote:
Anyway. Do others agree that my issue was the result of
wal_keep_segments=0 ?
Only as a sub-issue of the
Hi Tomas,
Thank you very much for your response.
As we know table becomes a candidate for autovacuum process based on
below formula.
*Autovacuum VACUUM thresold for a table = autovacuum_vacuum_scale_factor *
number of tuples + autovacuum_vacuum_threshold*
*Current settings in my database
Greetings,
* Phil Endecott (spam_from_pgsql_li...@chezphil.org) wrote:
> Adrian Klaver wrote:
> >On 08/12/2018 02:56 PM, Phil Endecott wrote:
> >>Anyway. Do others agree that my issue was the result of
> >>wal_keep_segments=0 ?
> >
> >Only as a sub-issue of the slave losing contact with the
On 08/13/2018 11:07 AM, Raghavendra Rao J S V wrote:
Hi All,
We are using postgres *9.2* version on *Centos *operating system. We
have around *1300+* tables.We have following auto vacuum settings are
enables. Still few of the tables(84 tables) which are always busy are
not vacuumed.Dead
Greetings,
* Phil Endecott (spam_from_pgsql_li...@chezphil.org) wrote:
> Adrian Klaver wrote:
> >On 08/12/2018 03:54 PM, Stephen Frost wrote:
> >>Greetings,
> >>
> >>* Phil Endecott (spam_from_pgsql_li...@chezphil.org) wrote:
> >>>OK. I think this is perhaps a documentation bug, maybe a missing
Adrian Klaver wrote:
On 08/12/2018 03:54 PM, Stephen Frost wrote:
Greetings,
* Phil Endecott (spam_from_pgsql_li...@chezphil.org) wrote:
OK. I think this is perhaps a documentation bug, maybe a missing
warning when the master reads its configuration, and maybe (as you say)
a bad default
Adrian Klaver wrote:
On 08/12/2018 02:56 PM, Phil Endecott wrote:
Anyway. Do others agree that my issue was the result of
wal_keep_segments=0 ?
Only as a sub-issue of the slave losing contact with the master. The
basic problem is maintaining two separate operations, archiving and
Greetings,
* Adrian Klaver (adrian.kla...@aklaver.com) wrote:
> On 08/12/2018 03:54 PM, Stephen Frost wrote:
> >* Phil Endecott (spam_from_pgsql_li...@chezphil.org) wrote:
> >>OK. I think this is perhaps a documentation bug, maybe a missing
> >>warning when the master reads its configuration,
Hi,
I'm trying to work on some extension to vim when invoked as \e from
psql.
To make it fully work, I need to know connection details that psql was
using while it invoked \e.
Is it possible to do in any way, or if not, any chance it could be added
to wishlist for next versions of Pg?
Best
Complete URL for npgsql is : https://github.com/npgsql/npgsql
On Mon, Aug 13, 2018 at 2:43 PM Sachin Kotwal wrote:
> Hi
>
> On Mon, Aug 13, 2018 at 1:37 PM Darnie Graceline
> wrote:
>
>> Hi,
>> Iam looking into a process of migrating from SQLServer to Postgresql, and
>> I see that DBMigration
Hi
On Mon, Aug 13, 2018 at 1:37 PM Darnie Graceline
wrote:
> Hi,
> Iam looking into a process of migrating from SQLServer to Postgresql, and
> I see that DBMigration is one of the tools you have offered, however when
> analysed DBMigration does not support migrating all components under free
>
Hi All,
We are using postgres *9.2* version on *Centos *operating system. We have
around *1300+* tables.We have following auto vacuum settings are enables.
Still few of the tables(84 tables) which are always busy are not
vacuumed.Dead tuples in those tables are more than 5000. Due to that
Hi,
Iam looking into a process of migrating from SQLServer to Postgresql, and I
see that DBMigration is one of the tools you have offered, however when
analysed DBMigration does not support migrating all components under free
version.
1.Could you help suggest a free tool that we can use to
Thanks everyone for your prompt help. It sounds like a rename operation is
almost never an issue unless you literally had millions of indexes. Thanks
for all the follow on questions and answers, it was most helpful and
interesting to learn a bit more about PG internals.
On Mon, 13 Aug 2018 at
33 matches
Mail list logo
