On Fri, May 23, 2014 at 11:06 PM, Vik Fearing wrote:
> On 05/24/2014 12:03 AM, Jaime Casanova wrote:
>> On Fri, May 23, 2014 at 10:53 PM, Vik Fearing wrote:
>>> It was suggested to me that these options should either error out if
>>> there are existing connections or terminate said connections.
On 05/24/2014 12:03 AM, Jaime Casanova wrote:
> On Fri, May 23, 2014 at 10:53 PM, Vik Fearing wrote:
>> It was suggested to me that these options should either error out if
>> there are existing connections or terminate said connections. I don't
>> agree with that because there is no harm in conn
On Fri, May 23, 2014 at 10:53 PM, Vik Fearing wrote:
>
> It was suggested to me that these options should either error out if
> there are existing connections or terminate said connections. I don't
> agree with that because there is no harm in connecting to a template
> database (how else do you
We try to tell our clients not to update the catalogs directly, but
there are at least two instances where it's not possible to do otherwise
(pg_database.datistemplate and .datallowconn). This patch aims to
remedy that.
For example, it is now possible to say
ALTER DATABASE d ALLOW CONNECTIONS
On Sat, May 24, 2014 at 3:13 AM, Tom Lane wrote:
> David Rowley writes:
> > I've just had a bit of a look at implementing checks allowing subqueries
> > with unique indexes on the join cols being removed,
>
> I'm a bit confused by this statement of the problem. I thought the idea
> was to recog
On Fri, May 23, 2014 at 3:24 PM, Simon Riggs wrote:
> PostgreSQL already chose to follow the Oracle syntax when we
> implemented NOWAIT. So my proposal is that we follow the Oracle syntax
> again and use the words SKIP LOCKED.
>
> I don't see any advantage in inventing new syntax that leaves us
>
2014-05-23 21:24 GMT+02:00 Simon Riggs :
> On 23 May 2014 10:40, Tom Lane wrote:
>
> > If we're pulling syntax out of the air it'd be nice if we could avoid
> > adding new keywords to the grammar.
>
> Oracle, SQLServer and DB2 have this capability. MySQL does not.
>
> SQLServer implements that us
On 23 May 2014 10:40, Tom Lane wrote:
> If we're pulling syntax out of the air it'd be nice if we could avoid
> adding new keywords to the grammar.
Oracle, SQLServer and DB2 have this capability. MySQL does not.
SQLServer implements that using the table hint of READPAST. Since that
whole syntax
On Fri, May 23, 2014 at 10:11:37AM +0900, Tomonari Katsumata wrote:
> Hi,
>
> I have two comments about 9.4 release notes.
>
> 1. typo
> >Pg_upgrade now uses -U to specify the user name (Bruce Momjian)
>
> It should be pg_upgrade.
>
> 2. undesirable link
> >Allow pg_recvlogical to receive data
On Fri, May 23, 2014 at 03:36:20PM +0200, Andres Freund wrote:
> On 2014-05-22 09:20:38 -0600, Jeff Ross wrote:
> > On 5/21/14, 2:37 PM, Bruce Momjian wrote:
> > >The only item I can think of that would cause this is someone changing
> > >the length of a string. Did someone modify pg_attribute dir
On Fri, May 23, 2014 at 08:32:35AM -0600, Jeff Ross wrote:
>
> On 5/23/14, 7:21 AM, Bruce Momjian wrote:
> >
> >On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote:
> >>>I just tested ALTER TABLE in 8.4 and it does create a toast table for
> >>>this case in 9.4:
> >>>
> >>> CREATE TABLE te
On Fri, May 23, 2014 at 06:28:28AM -0700, David G Johnston wrote:
> Bruce Momjian wrote
> > On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote:
> >> >I just tested ALTER TABLE in 8.4 and it does create a toast table for
> >> >this case in 9.4:
> >> >
> >> > CREATE TABLE test (x CHAR(10));
>
On 23 May 2014 15:40, Tom Lane wrote:
> A different concern is that this patch adds not one but two new unreserved
> keywords, ie SKIP and LOCKED. That bloats our parser tables, which are
> too darn large already, and it has a nonzero compatibility cost (since
> we only allow AS-less column alias
On Fri, Jan 31, 2014 at 3:24 PM, Andres Freund
wrote:
> I've pushed a rebased version of the patchset to
> http://git.postgresql.org/gitweb/?p=users/andresfreund/postgres.git
> branch rwlock contention.
> 220b34331f77effdb46798ddd7cca0cffc1b2858 actually was the small problem,
> ea9df812d8502fff74
On 23/05/2014 10:05, Matteo Beccati wrote:
> You can find the code here:
> https://github.com/mbeccati/uuid # NetBSD variant
> https://github.com/mbeccati/uuid/tree/linux # Ubuntu variant
>
> For now, I've forked just RhodiumToad's uuid-freebsd extension, but I've
> made sure make works fine when
David Rowley writes:
> I've just had a bit of a look at implementing checks allowing subqueries
> with unique indexes on the join cols being removed,
I'm a bit confused by this statement of the problem. I thought the idea
was to recognize that subqueries with DISTINCT or GROUP BY clauses produce
On Fri, May 23, 2014 at 11:13:50AM -0300, Fabrízio de Royes Mello wrote:
> On Fri, May 23, 2014 at 8:09 AM, Sandro Santilli wrote:
> >
> > I'm evaluating use of the postgres FDW to keep in sync a central database
> > to changes made in thousand other databases, via triggers.
> >
> > But as long as
Robert Haas writes:
> On Sat, May 17, 2014 at 1:02 AM, Craig Ringer wrote:
>> We have a long tradition of trying to allow noise keywords where it's
>> harmless.
>>
>> So the clause should probably be
>>
>> SKIP LOCKED [DATA]
>>
>> in much the same way we have
>>
>> BEGIN [ WORK | TRANSACTION
On Fri, May 23, 2014 at 6:29 PM, Shigeru Hanada
wrote:
> I noticed that contrib/worker_spi can't run as non-dynamic background
> worker (IOW, load via shared_preload_libraries), because of
> uninitialized bgw_notify_pid.
That's actually the case of all the bgworkers that have been developed
with 9
On 5/23/14, 7:21 AM, Bruce Momjian wrote:
On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote:
I just tested ALTER TABLE in 8.4 and it does create a toast table for
this case in 9.4:
CREATE TABLE test (x CHAR(10));
ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000);
I jus
Congrats Andres!
Mike
__
*Mike Blackwell | Technical Analyst, Distribution Services/Rollout
Management | RR Donnelley*
1750 Wallace Ave | St Charles, IL 60174-3401
Office: 630.313.7818
mike.blackw...@rrd.com
http://
On 5/23/14, 7:36 AM, Andres Freund wrote:
Any chance you could, *before* you create the toast table, do a:
SELECT attrelid::regclass, attname, attnum, attlen, *
FROM pg_attribute
WHERE attrelid = 'a'::regclass
ORDER BY attnum ASC;
Where 'a' is replaced by the affected table?
Greetings,
Andr
On Fri, May 23, 2014 at 8:09 AM, Sandro Santilli wrote:
>
> I'm evaluating use of the postgres FDW to keep in sync a central database
> to changes made in thousand other databases, via triggers.
>
> But as long as postgres_fdw keeps connections open for the whole lifetime
> of a session this confl
Sergey Muraviov wrote:
> I found some new bugs and fix them.
> And I had to make many changes.
This version fixes some bugs I had noticed in expanded mode too. For instance,
the original looked like this (five lines plus header):
-[ RECORD 49
]-+-
On Thu, May 22, 2014 at 09:55:10AM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Moving forward, I think you need to add a dummy column to each problem
> > table and drop the column that will create a toast table and allow
> > you to do the upgrade. I could have pg_upgrade detect
Andres Freund writes:
> The next question is whether to wait till after the branching with this?
+1 for waiting (it's only a couple weeks anyway). This isn't a
user-facing feature in any way, so I feel no urgency to ship it in 9.4.
regards, tom lane
--
Sent via pgsql-
On 2014-05-23 09:56:03 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Fri, May 23, 2014 at 8:15 AM, Andres Freund
> > wrote:
> >> That means you're for a (differently named) disable macro? Or is it not
> >> recent enough that you don't care?
>
> > I'm leaning toward thinking we should just
Robert Haas writes:
> On Fri, May 23, 2014 at 8:15 AM, Andres Freund wrote:
>> That means you're for a (differently named) disable macro? Or is it not
>> recent enough that you don't care?
> I'm leaning toward thinking we should just rip it out. The fact that
> 3 out of the 4 people commenting
Heikki Linnakangas wrote:
> On 05/15/2014 04:15 PM, Michael Paquier wrote:
> >On Thu, May 15, 2014 at 6:20 PM, Heikki Linnakangas
> > wrote:
> >>Ok, I committed #undefs. I don't have a Mingw(-w64) environment to test
> >>with, so let's see if the buildfarm likes it.
> >There does not seem to be a b
On 2014-05-22 09:20:38 -0600, Jeff Ross wrote:
> On 5/21/14, 2:37 PM, Bruce Momjian wrote:
> >The only item I can think of that would cause this is someone changing
> >the length of a string. Did someone modify pg_attribute directly to
> >increase the length of one of the character columns?
> I d
Bruce Momjian wrote
> On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote:
>> >I just tested ALTER TABLE in 8.4 and it does create a toast table for
>> >this case in 9.4:
>> >
>> >CREATE TABLE test (x CHAR(10));
>> >ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000);
>> >
>> I just tried
On Thu, May 22, 2014 at 09:20:38AM -0600, Jeff Ross wrote:
> >I just tested ALTER TABLE in 8.4 and it does create a toast table for
> >this case in 9.4:
> >
> > CREATE TABLE test (x CHAR(10));
> > ALTER TABLE test ALTER COLUMN x TYPE CHAR(8000);
> >
> I just tried this on the problem table
Heikki Linnakangas wrote:
> On 05/18/2014 12:23 AM, Tom Lane wrote:
> >A larger issue is that we evidently have no buildfarm animals that are
> >picky about alignment, or at least none that are running a modern-enough
> >buildfarm script to be running the contrib/logical_decoding test.
> >That seem
On Fri, May 23, 2014 at 8:15 AM, Andres Freund wrote:
>> >> I've used it once or twice to avoid having to recompile postgres when I
>> >> wanted things not to be *that* slow (AtEOXactBuffers() I am looking at
>> >> you). But I wouldn't be very sad if it'd go.
>> >>
>> >> Anybody against that?
>> >
On Tue, May 20, 2014 at 4:02 AM, Yuto HAYAMIZU wrote:
> The failing assertion is for prohibiting memory allocation in a critical
> section, which is introduced by commit 4a170ee9 on 2014-04-04.
>
> In my understanding, the root cause of the assertion failure is on-demand
> allocation of lwlock_s
On 2014-05-23 07:20:12 -0400, Robert Haas wrote:
> On Thu, May 22, 2014 at 5:00 PM, Alvaro Herrera
> wrote:
> > Andres Freund wrote:
> >> On 2014-05-22 16:37:35 -0400, Tom Lane wrote:
> >> > We could do that ... but I wonder if we shouldn't remove assert_enabled
> >> > altogether. What's the use
On Fri, May 23, 2014 at 8:28 PM, Dilip kumar wrote:
> On 23 May 2014 12:43 David Rowley Wrote,
>
>
>
> >I'm hitting a bit of a roadblock on point 1. Here's a snipped from my
> latest attempt:
>
>
>
> > if (bms_membership(innerrel->relids) ==
> BMS_SINGLETON)
>
> >
On Sat, May 17, 2014 at 1:02 AM, Craig Ringer wrote:
> We have a long tradition of trying to allow noise keywords where it's
> harmless.
>
> So the clause should probably be
>
> SKIP LOCKED [DATA]
>
> in much the same way we have
>
> BEGIN [ WORK | TRANSACTION ] ...
>
> There won't be an
On Thu, May 22, 2014 at 5:00 PM, Alvaro Herrera
wrote:
> Andres Freund wrote:
>> On 2014-05-22 16:37:35 -0400, Tom Lane wrote:
>> > We could do that ... but I wonder if we shouldn't remove assert_enabled
>> > altogether. What's the use case for turning it off? Not matching the
>> > speed of a no
I'm evaluating use of the postgres FDW to keep in sync a central database
to changes made in thousand other databases, via triggers.
But as long as postgres_fdw keeps connections open for the whole lifetime
of a session this conflicts with large use of poolers which make sessions
virtually never e
Hi all,
I noticed that contrib/worker_spi can't run as non-dynamic background
worker (IOW, load via shared_preload_libraries), because of
uninitialized bgw_notify_pid.
I got log lines below when starting PostgreSQL with
shared_preload_libraries = 'worker_spi'.
$ pg_ctl start -w
waiting for serve
On 23 May 2014 12:43 David Rowley Wrote,
>I'm hitting a bit of a roadblock on point 1. Here's a snipped from my latest
>attempt:
> if (bms_membership(innerrel->relids) == BMS_SINGLETON)
> {
> int subqueryrelid =
> bms_si
On 22/05/2014 21:55, Matteo Beccati wrote:
> On 22/05/2014 17:07, Tom Lane wrote:
>> Well, *I* don't want to do that work. I was hoping to find a volunteer,
>> but the silence has been notable. I think deprecation is the next step.
>
> This sounds an easy enough task to try and submit a patch, i
On Mon, May 19, 2014 at 5:47 PM, Dilip kumar wrote:
>
>
> So I think now when you are considering this join removal for subqueries
> then this can consider other case also like unique index inside subquery,
>
> because in attached patch unique index is considered only if its
> RTE_RELATION
>
>
44 matches
Mail list logo
