m not sure. Here is it: does vacuum
saves ALL deleted data of B block to WAL on step 3 prior deletion? If yes,
it is, of course, a part of the backup. But it wastes space a lot...)
On Tue, May 14, 2013 at 6:05 PM, Jeff Janes wrote:
> On Mon, May 13, 2013 at 4:31 PM, Dmitry Koterov wrote:
&g
May 1, 2013, Jeff Janes wrote:
> On Tue, Apr 30, 2013 at 3:24 PM, Dmitry Koterov
>
> > wrote:
>
>> I think that at
>> http://www.postgresql.org/docs/current/static/functions-admin.html and
>> http://www.postgresql.org/docs/current/static/continuous-archiving.ht
I think that at
http://www.postgresql.org/docs/current/static/functions-admin.html and
http://www.postgresql.org/docs/current/static/continuous-archiving.html two
important points on how pg_start_backup() works are missing:
1. After pg_start_backup() and till pg_stop_backup() VACUUM is denied (e.g
same kernel.)
On Wed, Mar 6, 2013 at 7:51 AM, Merlin Moncure wrote:
> On Tue, Mar 5, 2013 at 3:04 PM, Kevin Grittner wrote:
> > Dmitry Koterov wrote:
> >
> >> LOG: server process (PID 18705) was terminated by signal 7: Bus error
> >
> > So far I have o
Hello.
I have a database dump file (unfortunately with proprietary information)
which leads to the following error in logs during its restoration (even
after initdb - it is stable reproducible, at the same large table, the same
time):
*LOG: server process (PID 18705) was terminated by signal 7:
To me, this is a wonderful feature, thanks! I think many people would be
happy if this patch woud be included to the mainstream (and it is quite
short and simple).
About name ordering - I think that the problem exists for objects:
1. Stored functions.
2. Foreign keys/triggers (objects which has o
>
> Dmitry Koterov writes:
> > No, I meant that in case of the row (1, NULL, NULL, 2, 3, NULL):
> > - the corresponding NULL bitmap is (100110...)
> > - the corresponding tuple is (1, 2, 3)
> > - t_natts=3 (if I am not wrong here)
>
> You are wrong --- t_natt
On Thu, May 21, 2009 at 6:45 PM, Tom Lane wrote:
> Sam Mason writes:
> > On Thu, May 21, 2009 at 12:06:29PM +0400, Dmitry Koterov wrote:
> >> ALTER TABLE ... ADD COLUMN ... NULL;
> >>
> >> (nullable without a default value). This is because of NULL bitm
Hello.
PostgreSQL is very fast when we perform (even on a huge table)
ALTER TABLE ... ADD COLUMN ... NULL;
(nullable without a default value). This is because of NULL bitmap in
tuples. And it's greatest feature for a developer!
But another very common-case query like
ALTER TABLE ... ADD COLUM
Hello.
Here is the SQL to reproduce the server crash:
CREATE SCHEMA bug1 AUTHORIZATION postgres;
SET search_path = bug1, pg_catalog;
CREATE FUNCTION bug1.domain_check (integer) RETURNS boolean
AS
$body$
SELECT $1 <> 0
$body$
LANGUAGE sql IMMUTABLE STRICT;
CREATE DOMAIN bug1."domain" AS intege
Could you please say, if ALTER TYPE ... ADD COLUMN is planned for a future
PostgreSQL version?
On Fri, Dec 5, 2008 at 4:08 PM, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 4, 2008 at 9:53 AM, Dmitry Koterov <[EMAIL PROTECTED]> wrote:
> > Hello.
> >
> &g
Hello.
I can successfully ALTER a NON-EMPTY table (ct) which ROWTYPE is used as a
column type for another table (dt):
CREATE TABLE ct (id INTEGER);
CREATE TABLE dt (id INTEGER, c ct);
INSERT INTO dt VALUES(1, '(666)');
SELECT * FROM dt;
-- (1, '(666)')
ALTER TABLE ct ADD COLUMN n INTEGER;
SELEC
TABLE function
is used in CHECK or INDEX, but does not define search_path ints arguments.
Thanks!
On Fri, Nov 14, 2008 at 7:25 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dmitry Koterov" <[EMAIL PROTECTED]> writes:
> > Thank you for a possible solution.
> > But what
pg_dump has corresponding behaviour CONSTRAINT = FOREIGN
KEY.
For CONSTRAINT = CHECK - it hasn't.
On Thu, Nov 13, 2008 at 9:07 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dmitry Koterov" <[EMAIL PROTECTED]> writes:
> > 3. The function a() calls any OTHER function b
Hello.
Why pg_dump dumps CONSTRAINT ... CHECK together with CREATE TABLE queries,
but NOT at the end of dump file (as FOREIGN KEY)?
Sometimes it causes the generation of invalid dumps which cannot be
restored. Details follow.
1. I use database-dedicated search_path:
ALTER DATABASE d SET search_
No problem, I have time for clearing. But are these functions
guaranteed to be included in the contrib? If there is no guarantee,
seems the time of clearing will be wasted. (5 years ago I have already
cleaned one open-source library on demand and after that it was not
approved for PEAR repository,
Great! Would it be implemented in a next version? Seems it would be
very helpful, especially for people who commit database structure to
CVS/SVN once per minute to track changes history (or similar)...
On Sun, Sep 21, 2008 at 11:57 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "
> I strongly suspect you'd benefit a lot more by learning database best
> practices rather than assuming, as you appear to be doing, that you
> are dealing with a new field and that you know it best. Neither is true.
Of course, you absolutely right. I venerate you! O! :-)
--
Sent via pgsql-h
ECTED]> wrote:
> "Dmitry Koterov" <[EMAIL PROTECTED]> writes:
>> Utility pg_dump dumps the identical database schemas not always
>> identically: sometimes it changes an order of SQL statements.
>
> Please provide a concrete example. The dump order for modern serv
interesting...
On Sun, Sep 21, 2008 at 8:46 AM, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> David Fetter wrote:
>>
>> On Sun, Sep 21, 2008 at 04:38:56AM +0400, Dmitry Koterov wrote:
>>>
>>> Hello.
>>>
>>> Is it possible to create a foreign key constra
Hello.
Utility pg_dump dumps the identical database schemas not always
identically: sometimes it changes an order of SQL statements.
E.g.:
1. Dump of database A:
ALTER TABLE xxx ADD CONSTRAINT ...;
ALTER TABLE yyy ADD CONSTRAINT ...;
2. Dump of database B which has identical structure as A ("pg
Hello.
Is it possible to create a foreign key constraint for ALL elements of
an array field?
CREATE TABLE a(id INTEGER);
CREATE TABLE b(id INTEGER, a_ids INTEGER[]);
Field b.a_ids contains a list of ID's of "a" table. I want to ensure
that each element in b.a_ids exists in a in any time. Is it p
#x27;ve tried to follow the "Review a
> patch" guidelines from the wiki - thanks Simon, that was pretty helpful.
>
> This review covers only the intagg additions.
>
> Dmitry Koterov wrote:
>
>> Here are these functions with detailed documentation:
>> http://
Hello.
Here are these functions with detailed documentation:
http://en.dklab.ru/lib/dklab_postgresql_patch/
intagg.int_array_append_aggregate(int[]): fast merge arrays into one large
list
intarray._int_group_count_sort(int[], bool): frequency-based sorting
intarray.bidx(int[], int): binary search
24 matches
Mail list logo
