(I guess I just volunteered myself to write a draft of that).
Please notice that smallint is too small for tzoffset:
SELECT d AT TIME ZONE 'Europe/Berlin'
- d AT TIME ZONE 'Europe/Paris'
FROM (
VALUES
(date '1815-10-31')
, (date '1897-02-19'
Hi,
It seems there is a typo here:
http://www.postgresql.org/docs/devel/static/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
where we say that we compare XIDs using arithmetic modulo 2^31, which
should instead be 2^32 (as it is with uint32, e.g. xid_age).
Best wishes,
Dr. Gianni Ciolli
Hi Daniel,
On Wed, Sep 05, 2012 at 01:37:59PM +0200, Daniel Bausch wrote:
> Is that, what your bmi-perf-test.tar.gz from 2008 does? I did not
> look into that.
IIRC yes (but it's been a long time and I don't have a copy at hand
now).
Best regards,
Dr. Gianni Ciolli - 2n
rk on the long proposed
> >> on-disk bitmap index implementation. Regarding to the wiki, you,
> >> Jonah and Simon, were the last devs that touched this thing. Unfortunately
> >> I could not find the patch representing your state of that work. I
> >> could only cap
hich references both the point and the polygon table, because
the point <-> polygon relationship is many-to-many. In the aggregated
model, you can easily specify a CHECK constraint that requires each
polygon to have at least three points, while the corresponding
condition cannot be specifie
ms to be wrongly
restricted to the case when get_rel_name can't find a relation.
Is there any objection to the above proposal? I did a little search of
the archives, but I couldn't find any related discussions; I apologise
if I missed something.
Thanks,
Dr. Gianni Ciolli - 2ndQuadrant
taking into
account the changes happened in the review phase. Some comments have
also been added to explain why some choices have been forbidden.
Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it | www.2ndquadrant.it
---8&
On Thu, Feb 23, 2012 at 08:26:47AM +, Thom Brown wrote:
> On 23 February 2012 07:15, Gianni Ciolli wrote:
> > Another complication: anonymous triggers would either have to be
> > alone, or provide a mechanism to manage a sequence of anonymous
> > triggers on the same ta
either have to be
alone, or provide a mechanism to manage a sequence of anonymous
triggers on the same table (such as "replace the third trigger with
..." or "move trigger #4 in position #2", or deciding their order of
execution).
Cheers,
Dr. Gianni Ciolli - 2ndQuadrant Italia
Pos
ining the difference.
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it | www.2ndquadrant.it
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
UBTRANSACTION X and COMMIT/ROLLBACK SUBTRANSACTION X must match,
otherwise an exception is raised (and a bug is detected).
Regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it | www.2ndquadrant.it
--
Sent via pgsql-hackers m
On Mon, Dec 19, 2011 at 05:52:40PM +0200, Marti Raudsepp wrote:
> On Sun, Dec 18, 2011 at 10:28, Gianni Ciolli
> wrote:
> > http://wiki.postgresql.org/wiki/Autonomous_subtransactions
> >
> > It is meant to be an ongoing project, requesting comments and
> > contribut
contributions, rather than a conclusive document.
Thanks,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it | www.2ndquadrant.it
p.s. The reason for the variation on the name is that there is always
a parent transaction.
--
Sent via pgsql
This is
essentially the same difference that we have between ON DELETE ARRAY
CASCADE and ON DELETE CASCADE.
Thanks,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it | www.2ndquadrant.it
--
Sent via pgsql-hackers mailing list (pgsql
Hi,
while measuring NOTIFY execution time, I noticed a significant
performance drop.
Please find a patch attached, together with some tests; more details
are shown below.
Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it
se)
is always true, while
(random_boolean() = true) OR (random_boolean() = false)
is not (has probability 75%). For instance, the first random_boolean()
might return false while the second one returns true.
Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Servic
OK.
Please find attached v2 of the numeric-doc patch, which takes into
account your remarks. In particular, numeric limits are now correct
and documented only in that table.
Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it |
On Fri, Mar 25, 2011 at 08:46:17AM +, Gianni Ciolli wrote:
> On Sun, Mar 20, 2011 at 08:14:21PM -0400, Noah Misch wrote:
> > Agreed. The documentation is suggestive of this limit:
> >
> > # CREATE TABLE n (c numeric(1001,0));
> > ERROR: NUMERIC precision 1001
On Sun, Mar 20, 2011 at 08:14:21PM -0400, Noah Misch wrote:
> On Fri, Mar 11, 2011 at 11:36:14AM +0000, Gianni Ciolli wrote:
> > maybe we should change the "1000 digits" here:
> >
> >
> > http://developer.postgresql.org/pgdocs/postgres/datatype-
On Fri, Mar 11, 2011 at 09:38:03AM -0500, Tom Lane wrote:
> Gianni Ciolli writes:
> > maybe we should change the "1000 digits" here:
>
> >
> > http://developer.postgresql.org/pgdocs/postgres/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL
>
> &
Hi,
maybe we should change the "1000 digits" here:
http://developer.postgresql.org/pgdocs/postgres/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL
because ISTM that up to 2^17 digits are supported (which makes more
sense than 1000).
Best regards,
Dr. Gianni Ciolli - 2ndQuadr
On Wed, Aug 12, 2009 at 12:11:28AM +0300, Peter Eisentraut wrote:
> On Tuesday 11 August 2009 18:16:04 Gianni Ciolli wrote:
> > As for "warm/hot", it depends on what you exactly mean with "get
> > ready":
> >
> > (A) If you mean "it is possible
indexes, which on
PostgreSQL are not WAL safe (anyway, they are currently discouraged
by the documentation).
Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it | www.2ndquadrant.it
--
Sent via pgsql-hackers mailing lis
ual to the
contents of the first node", then Simon's patch is "warm".
But then we have by definition "hot" == "synchronous" and "either
warm or cold" == "asynchronous". IMHO the other case is
preferrable, as the
can read that 9g is the last published version (I know
that Simon is having some difficulties with git).
Thank you for testing,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it | www.2ndquadrant.it
---8<--8<--8<-
ve rules, in order to assess the problem quickly, and then to
get back to pg-hackers soon.
Any comments/warnings/suggestions ?
Thank you,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.it | www.2ndquadrant.it
--
Sent via pgsql-hackers mai
On Fri, Jan 16, 2009 at 06:39:11PM +0100, Gianni Ciolli wrote:
(...)
> During a Warm Standby session using current HEAD I obtained the
> following error on the standby node:
On Fri, Jan 16, 2009 at 12:56:59PM -0500, Tom Lane wrote:
> Gianni Ciolli writes:
> > we found a bug wh
g at both
logfiles. Anyway, since the error was raised by bgwriter when running
with Hot Standby patch applied, is likely to be something to do with
the guts of checkpointing.
Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gianni.cio...@2ndquadrant.i
8.4 release; thus we prefer to withdraw the patch
from the current commitfest.
We will update the corresponding Wiki page as soon as possible,
although not immediately (I am experiencing some connectivity
problems).
Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services
On Tue, Nov 11, 2008 at 02:59:01PM +0100, Magnus Hagander wrote:
> Gianni Ciolli wrote:
> > WARNING: detected write past chunk end in Postmaster 0x9b13650
>
> Yes, that's a stupid bug:
(...)
> Attached is an updated version of the patch that fixes this.
Hi Magnus,
on of the patch, because it seems likely to be an useful
optimization.
Thank you for your comments (also for the useful remarks on the
catalog);
best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
[EMAIL PROTECTED] | www.2ndquadrant.it
--
Sent via pgsq
ake it listen from a different IP address
(actually the other IP address of my machine 192.168...). Then I added
to pg_hba.conf one line enabling ident connections with map=review
from that IP address.
Finally I started the server, and as I connected with psql -h
192.168... the above warning
a chance to validate the
> performance. Unfortunately, I have spent more than a day with almost void
> success.
This can be helpful for us to explain one of the two open issues that
we mentioned at submission time (meanwhile we have just fixed the
other one):
On Sat, Nov 01, 2008 at 01:01:54AM +0
Hi everybody,
me and Gabriele Bartolini have been working on Bitmap Indexes (BMI) in
the last weeks, with advice and guidance from Simon Riggs. We feel
that we are about to approach the point where it is appropriate to ask
for feedback from this list.
Thank you,
Dr. Gianni Ciolli - 2ndQuadrant
34 matches
Mail list logo