On Fri, Apr 1, 2011 at 11:31 PM, Magnus Hagander wrote:
> On Fri, Apr 1, 2011 at 16:56, Rushabh Lathia
> wrote:
> >
> >
> > On Fri, Apr 1, 2011 at 8:23 PM, Rushabh Lathia >
> > wrote:
> >>
> >>
> >> On Fri, Apr 1, 2011 at 6:51 PM, Magnus Hagander
> >> wrote:
> >>>
> >>> On Fri, Apr 1, 2011 at 1
On Thu, Mar 31, 2011 at 6:39 PM, Stephen Frost wrote:
> Going just integer->money, with the "1" -> "$1.00", seems completely
> reasonable to me. As for being too late in the cycle.. if someone's
> willing to do the work, I can't imagine it breaking anything, so I
> wouldn't be against putting it
I was under the impression that QUEL was actually a good language in some ways,
and that it was more relational and better than SQL in some ways.
http://en.wikipedia.org/wiki/QUEL_query_languages
Maybe bringing it back would be a good idea, but as an alternative to SQL rather
than a replacem
Bruce Momjian wrote:
> > > I am not so concerned about this case but about other cases where we are
> > > computing xid distances across the invalid range.
> >
> > Such as?
>
> Not sure. I have not had time to research this, but there might be
> cases where this backward movement matters --- rem
Robert Haas wrote:
> On Fri, Apr 1, 2011 at 5:48 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Excerpts from Bruce Momjian's message of vie abr 01 16:50:29 -0300 2011:
> >>
> >> > To do the right thing every computation that passes over the xid
> >> > wraparound bounary should subtract F
Robert Haas wrote:
> On Fri, Apr 1, 2011 at 5:48 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> Excerpts from Bruce Momjian's message of vie abr 01 16:50:29 -0300 2011:
> >>
> >> > To do the right thing every computation that passes over the xid
> >> > wraparound bounary should subtract F
On Fri, Apr 1, 2011 at 5:48 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> Excerpts from Bruce Momjian's message of vie abr 01 16:50:29 -0300 2011:
>>
>> > To do the right thing every computation that passes over the xid
>> > wraparound bounary should subtract FirstNormalTransactionId, not ju
On Mar 27, 2011, at 9:43 PM, Tom Lane wrote:
>> 1) move the truncating to a new transaction just like we currently do
>> toast tables in a separate transaction from the main vacuum.
>
> +1 if we are going to continue the behavior of allowing other
> transactions to kick autovac off the exclusive l
On Apr 1, 2011, at 4:48 PM, Bruce Momjian wrote:
> I am not so concerned about this case but about other cases where we are
> computing xid distances across the invalid range.
Bruce, I think you hit the nail on the head earlier:
> To do the right thing every computation that passes over the xid
>
Bruce Momjian wrote:
> > I think this should be left alone. As you said, it isn't worth it.
>
> Agreed it is not worth it but I think we should at least C comment
> something. I think at a minimum we should set it to
> FirstNormalTransactionId.
>
> I am not so concerned about this case but abo
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie abr 01 16:50:29 -0300 2011:
>
> > To do the right thing every computation that passes over the xid
> > wraparound bounary should subtract FirstNormalTransactionId, not just
> > those that fall in the boundry. That would prevent
Jeff Davis wrote:
> On Fri, 2011-04-01 at 13:00 -0400, Dan Ports wrote:
>> While looking into a SSI bug, I noticed that we don't actually
>> display the pid of the holding transaction, even though we have
>> that information available.
>
> Is there a chance that the PID will reference a backend t
On Fri, 2011-04-01 at 13:00 -0400, Dan Ports wrote:
> While looking into a SSI bug, I noticed that we don't actually display
> the pid of the holding transaction, even though we have that
> information available.
Is there a chance that the PID will reference a backend that has either
terminated or
"Following a great deal of discussion, I'm pleased to announce that the
PostgreSQL Core team has decided that the major theme for the 9.1
release, due in 2011, will be 'NoSQL'.
"... the intention is to remove SQL support from
Postgres, and replace it with a language called 'QUEL'. This will
provid
Excerpts from Bruce Momjian's message of vie abr 01 16:50:29 -0300 2011:
> To do the right thing every computation that passes over the xid
> wraparound bounary should subtract FirstNormalTransactionId, not just
> those that fall in the boundry. That would prevent the value from going
> backward
Robert Haas wrote:
> On Fri, Apr 1, 2011 at 11:18 AM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> Oh, quite right. ?Sorry I missed that. ?I suppose if we wanted to fix
> >> this for real, we'd want to get:
> >>
> >> 105->5
> >> 104->4
> >> 103->3
> >> 102->max_xid
> >> 101->max_xid-1
> >> 100
On 3/28/2011 12:35 PM, Jan Wieck wrote:
On 3/27/2011 10:43 PM, Tom Lane wrote:
In particular, I thought the direction Jan was headed was to release and
reacquire the lock between truncating off limited-size chunks of the
file. If we do that, we probably *don't* want or need to allow autovac
Dan Ports wrote:
> There's no urgent need to have this, although it's obviously more
> correct than the current behavior. It might be useful for
> debugging.
Agreed all around. For the benefit of the more casual follower of
the thread, attached is a simple example of the output. For the
SIRe
On Fri, Apr 01, 2011 at 12:20:25PM -0500, Kevin Grittner wrote:
> I thought we already had that, but clearly I was mistaken.
Yeah, so did I. Turns out we had the vxid but not the pid. IIRC, we
weren't tracking a SERIALIZABLEXACT's pid yet, at the time we wrote the
code for pg_locks.
> I guess the
On 4/1/11 11:34 AM, Dann Corbit wrote:
> Smells like April first to me.
> http://en.wikipedia.org/wiki/April_Fools'_Day
Actually, someone recycled Dave's April 1 announcement from last year.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgs
Smells like April first to me.
http://en.wikipedia.org/wiki/April_Fools'_Day
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Rajasekhar Yakkali
Sent: Friday, April 01, 2011 10:08 AM
To: dp...@postgresql.org
Cc: pgsql-gene...@postgresql.org; pgsql
On Fri, Apr 1, 2011 at 16:56, Rushabh Lathia wrote:
>
>
> On Fri, Apr 1, 2011 at 8:23 PM, Rushabh Lathia
> wrote:
>>
>>
>> On Fri, Apr 1, 2011 at 6:51 PM, Magnus Hagander
>> wrote:
>>>
>>> On Fri, Apr 1, 2011 at 15:14, Rushabh Lathia
>>> wrote:
>>> > Problem:
>>> >
>>> >
>>> > On windo
All,
As a reminder, the Cluster Hackers meeting, for current developers of
clustering and replication solutions, will be on Tuesday during pgCon,
concurrent with the first day of tutorials.
If you are planning on attending this meeting, I need to have your RSVP
now. If you were planning to atten
On Fri, Apr 1, 2011 at 11:57 AM, Thom Brown wrote:
> On 1 April 2011 16:28, Robert Haas wrote:
>> Support comments on FOREIGN DATA WRAPPER and SERVER objects.
>>
>> This mostly involves making it work with the objectaddress.c framework,
>> which does most of the heavy lifting. In that vein, chan
Dan Ports wrote:
> While looking into a SSI bug, I noticed that we don't actually
> display the pid of the holding transaction, even though we have
> that information available.
I thought we already had that, but clearly I was mistaken.
> The attached patch fixes that.
>
> One note is that it
On Fri, Apr 1, 2011 at 9:40 AM, Shigeru HANADA
wrote:
> - pg_dump support for comment on fdw and server
Applied, good catch, thanks.
> - psql describe commands (\dew+ and \des+)
Not sure if we want this behavior change or not. Any other opinions?
It doesn't look like there's any particular c
On Fri, Apr 1, 2011 at 12:43 PM, Joshua D. Drake wrote:
> On Fri, 2011-04-01 at 08:13 -0400, Andrew Dunstan wrote:
>
>> >> That said, I do support adding this in the future, if only to keep up
>> >> with the Jones'.
>> > So are the ones out there *already* even compatible, before we start
>> > add
On Fri, 2011-04-01 at 12:04 -0500, Kevin Grittner wrote:
> "Joshua D. Drake" wrote:
>
> > Well I would argue that if compatibility (as opposed to
> > familiarity) is our goal, we need to focus on one and only one
> > syntax, JDBC. It doesn't matter our particular bent, JDBC is the
> > one that i
"Joshua D. Drake" wrote:
> Well I would argue that if compatibility (as opposed to
> familiarity) is our goal, we need to focus on one and only one
> syntax, JDBC. It doesn't matter our particular bent, JDBC is the
> one that is in the most use.
The start of a URI defines the protocol so that
While looking into a SSI bug, I noticed that we don't actually display
the pid of the holding transaction, even though we have that
information available.
The attached patch fixes that.
One note is that it will show the pid of the backend that executed the
transaction, even if that transaction ha
On Fri, 2011-04-01 at 08:13 -0400, Andrew Dunstan wrote:
> >> That said, I do support adding this in the future, if only to keep up
> >> with the Jones'.
> > So are the ones out there *already* even compatible, before we start
> > adding our own? For example, for JDBC I beleive it has to be
> > jd
On Thu, Mar 31, 2011 at 5:38 PM, Merlin Moncure wrote:
> On Thu, Mar 31, 2011 at 5:33 PM, Merlin Moncure wrote:
>> On Wed, Mar 30, 2011 at 2:35 PM, Merlin Moncure wrote:
>>> On Wed, Mar 30, 2011 at 11:23 AM, Heikki Linnakangas
>>> wrote:
On 30.03.2011 18:02, Robert Haas wrote:
>
>
On Fri, Apr 1, 2011 at 11:18 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> Oh, quite right. Sorry I missed that. I suppose if we wanted to fix
>> this for real, we'd want to get:
>>
>> 105->5
>> 104->4
>> 103->3
>> 102->max_xid
>> 101->max_xid-1
>> 100->max_xid-2
>> 99->max_xid-3
>> 98->max_x
Hackers,
I wanted to get a (ok, not so) quick note in about this before the beta
dropped. I've been thinking about the "requires" parameter on extensions
control files. Right now it just lists the names of extensions that are
required for the extension to run:
requires = 'foo, bar'
But I'
On Fri, Apr 1, 2011 at 9:40 AM, Shigeru HANADA
wrote:
> On Thu, 31 Mar 2011 11:24:27 -0400
> Robert Haas wrote:
>> Attached. Foreign tables are already OK, I believe; it's only foreign
>> data wrappers and foreign servers that appear to need fixing.
>
> The patch seems good for basic functionari
Robert Haas wrote:
> Oh, quite right. Sorry I missed that. I suppose if we wanted to fix
> this for real, we'd want to get:
>
> 105->5
> 104->4
> 103->3
> 102->max_xid
> 101->max_xid-1
> 100->max_xid-2
> 99->max_xid-3
> 98->max_xid-4
>
> But it doesn't seem worth getting excited about.
I think
On Fri, Apr 1, 2011 at 8:23 PM, Rushabh Lathia wrote:
>
>
> On Fri, Apr 1, 2011 at 6:51 PM, Magnus Hagander wrote:
>
>> On Fri, Apr 1, 2011 at 15:14, Rushabh Lathia
>> wrote:
>> > Problem:
>> >
>> >
>> > On windows when we run postgres.exe without any command line args, its
>> > getting
On Fri, Apr 1, 2011 at 6:51 PM, Magnus Hagander wrote:
> On Fri, Apr 1, 2011 at 15:14, Rushabh Lathia
> wrote:
> > Problem:
> >
> >
> > On windows when we run postgres.exe without any command line args, its
> > getting crash or its showing error into Application logs of Event Viewer.
>
On Fri, Apr 1, 2011 at 7:24 AM, Heikki Linnakangas
wrote:
> My common sense says that that transformation
> is not legal.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Thu, Mar 31, 2011 at 11:12 PM, Fujii Masao wrote:
> Another simple fix is to make walsender send SIGUSR1 to postmaster
> so that it calls PostmasterStateMachine() in sigusr1_handler(), when it
> marks itself as walsender. The attached patch does this. Thought?
That looks OK to me. Have you te
On Thu, Mar 31, 2011 at 5:59 PM, Bruce Momjian wrote:
> OK, just keep going below 100:
>
> 105 -> 5
> 104 -> 4
> 103 -> 3
> 102 -> max_xid
> 101 -> max_xid - 1
> 100 -> max_xid - 2
> 99 -> max_id
> 98 -> max_id -1
>
> Wouldn't you rather:
>
On Fri, Apr 1, 2011 at 7:26 PM, Robert Haas wrote:
> On Fri, Apr 1, 2011 at 9:14 AM, Rushabh Lathia
> wrote:
> > On windows when we run edb-postgres.exe ...
>
> Did you intend to send this to an EDB-internal mailing list?
>
Oops sorry, initially we found this bug with EDB.
But after looking in
Greg Stark wrote:
> On Thu, Mar 31, 2011 at 10:59 PM, Bruce Momjian wrote:
> > OK, just keep going below 100:
> >
> > ? ? ? ?105 -> 5
> > ? ? ? ?104 -> 4
> > ? ? ? ?103 -> 3
> > ? ? ? ?102 -> max_xid
> > ? ? ? ?101 -> max_xid - 1
> > ? ? ? ?100 -> max_xid - 2
> > ? ? ? ? 99 -> max_id
> > ? ? ? ? 9
On 01.04.2011 16:56, Robert Haas wrote:
On Fri, Apr 1, 2011 at 9:14 AM, Rushabh Lathia wrote:
On windows when we run edb-postgres.exe ...
Did you intend to send this to an EDB-internal mailing list?
I think he just forgot to search & replace edb-postgres.exe to
postgres.exe ;-). The issue
On Fri, Apr 1, 2011 at 9:14 AM, Rushabh Lathia wrote:
> On windows when we run edb-postgres.exe ...
Did you intend to send this to an EDB-internal mailing list?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (p
On Fri, Apr 1, 2011 at 15:14, Rushabh Lathia wrote:
> Problem:
>
>
> On windows when we run edb-postgres.exe without any command line args, its
> getting crash or its showing error into Application logs of Event Viewer.
>
> Analysis:
> ==
>
> For any stderr we call the write_stder
Problem:
On windows when we run edb-postgres.exe without any command line args, its
getting crash or its showing error into Application logs of Event Viewer.
Analysis:
==
For any stderr we call the write_stderr() and write_stderr() calls the
write_console() for stderr. Now here
On 1 April 2011 12:57, Shigeru HANADA wrote:
> NOT NULL constraint on foreign table is just declaration and can't
> force data integrity. And I noticed that CREATE FOREIGN TABLE
> document doesn't mention that serial and bigserial can't be used in
> foreign table. Please see foreign_table_doc.pa
On 04/01/2011 04:34 AM, Magnus Hagander wrote:
On Fri, Apr 1, 2011 at 10:24, Dave Page wrote:
On Fri, Apr 1, 2011 at 1:10 AM, Joshua Berkus wrote:
I would think it would be purely syntatic sugar really, which does
incorporate a familiar interface for those who are working in
different
world
On Fri, Apr 01, 2011 at 02:24:53PM +0300, Heikki Linnakangas wrote:
> I tried to read the SQL spec to see if it has anything to say about
> that, but I couldn't find anything. My common sense says that that
> transformation is not legal.
Your feeling is correct; I would motivate it as follows.
On Fri, 1 Apr 2011 01:24:20 +0100
Thom Brown wrote:
> Also, there probably needs to be some elaboration of how a NOT NULL
> declaration operates on a foreign table column on the CREATE FOREIGN
> TABLE reference page. From what I can see, if the foreign table
> cannot be modified such as those def
On Fri, Apr 01, 2011 at 11:44:23AM +0100, Gianni Ciolli wrote:
> 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.
This version looks sound to me. Thank you.
--
Sent via p
We sometimes transform IN-clauses to a list of ORs:
postgres=# explain SELECT * FROM foo WHERE a IN (b, c);
QUERY PLAN
--
Seq Scan on foo (cost=0.00..39.10 rows=19 width=12)
Filter: ((a = b) OR (a = c))
(2 rows)
But w
On Fri, Apr 01, 2011 at 03:52:22AM -0400, Noah Misch wrote:
> NumericLong has a 14-bit count of decimal digits for the dscale, giving that
> fractional digit limit. It stores the weight as a 16-bit signed count of
> base-1 "digits" after the first. For example, 10^4-1 has weight 0, 10^4
> th
On Fri, Apr 1, 2011 at 10:24, Dave Page wrote:
> On Fri, Apr 1, 2011 at 1:10 AM, Joshua Berkus wrote:
>>
>>> I would think it would be purely syntatic sugar really, which does
>>> incorporate a familiar interface for those who are working in
>>> different
>>> worlds (.Net/Drupal/JAVA) etc...
>>
>
On Fri, 1 Apr 2011 00:54:18 +0100
Thom Brown wrote:
> I've noticed some weirdness when trying to grant various types of
> permissions on a foreign table and thought I'd report it here:
>
> postgres=# \d stuff
> Foreign table "public.stuff"
> Column | Type | Modifiers
> +-+---
On Fri, Apr 1, 2011 at 1:10 AM, Joshua Berkus wrote:
>
>> I would think it would be purely syntatic sugar really, which does
>> incorporate a familiar interface for those who are working in
>> different
>> worlds (.Net/Drupal/JAVA) etc...
>
> I wouldn't mind having something more standard supporte
On Fri, Mar 25, 2011 at 06:09:54PM +, Gianni Ciolli wrote:
> 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
Heyho!
On Friday 01 April 2011 02.39:25 Christopher Browne wrote:
> An advantage to this uri form is that it allows applications to be
> configured uniformly - I do not need to ask "is this using libpq, needing
> one sort of configuration, or Java, needing another?"
>
> Rather, I may say, "here i
59 matches
Mail list logo
