On Thu, Mar 27, 2014 at 08:16:13PM -0700, David Johnston wrote:
> Slightly tangential but are the locking operations associated with the
> recent bugfix generated in both (all?) modes or only hot_standby?
All modes.
> I thought
> it strange that transient locking operations were output with WAL t
On Fri, Mar 28, 2014 at 12:16 PM, David Johnston wrote:
>
> Slightly tangential but are the locking operations associated with the
> recent bugfix generated in both (all?) modes or only hot_standby? I thought
> it strange that transient locking operations were output with WAL though I
> get it if
Hi,
> > Went looking for this in the docs...
> >
> > http://www.postgresql.org/docs/9.3/interactive/runtime-config-wal.html#GUC-WAL-LEVEL
> >
> > So I guess, no-restore/offline/online would be good names (and maybe
> > wal_restore_mode instead of wal_level) if we started from scratch. Note
> >
David Johnston wrote
>
> Noah Misch-2 wrote
>> On Thu, Mar 27, 2014 at 03:06:02PM -0700, David Johnston wrote:
>>> shamccoy wrote
>>> > Hello. I've been doing some benchmarks on performance / size
>>> differences
>>> > between actions when wal_level is set to either archive or
>>> hot_standby.
>
Noah Misch-2 wrote
> On Thu, Mar 27, 2014 at 03:06:02PM -0700, David Johnston wrote:
>> shamccoy wrote
>> > Hello. I've been doing some benchmarks on performance / size
>> differences
>> > between actions when wal_level is set to either archive or hot_standby.
>> > I'm not seeing a ton of differe
On Thu, Mar 27, 2014 at 03:06:02PM -0700, David Johnston wrote:
> shamccoy wrote
> > Hello. I've been doing some benchmarks on performance / size differences
> > between actions when wal_level is set to either archive or hot_standby.
> > I'm not seeing a ton of difference. I've read some posts a
On 03/27/2014 03:06 PM, David Johnston wrote:
> As I think both can be used for PITR I don't believe there is much downside,
> technically or with resources, to using hot_standby instead of archive; but
> I do not imagine it having any practical benefit either.
Actually, "hot_standby" does have to
shamccoy wrote
> Hello. I've been doing some benchmarks on performance / size differences
> between actions when wal_level is set to either archive or hot_standby.
> I'm not seeing a ton of difference. I've read some posts about
> discussions as to whether this parameter should be simplified and
Jeff Davis writes:
> Doing "git log tags/REL8_3_6" I see two commits after the one labeled
> "tag for 8.3.6".
> The other tags I checked all seem to match what I would expect. I'm not
> suggesting that anything be done, I just wanted to point this out in
> case something strange happened.
Hmmm
Added to HISTORY:
New pg_get_triggerdef(prettyprint) and pg_constraint_is_visible() functions
---
Christopher Kings-Lynne wrote:
> I think the new pg_get_triggerdef and pg_constraint_is_visible functions
> aren't mention
Rod Taylor wrote:
-- Start of PGP signed section.
> > Allow SQL200X inheritance syntax LIKE , INCLUDING DEFAULTS?
> (Rod)
>
> Yes, it includes defaults.
OK, updated.
> > > Have COMMENT ON DATABASE on non-local database generate a warning
> (Tom)
> > > I think that was someone else's work ... Rod
Joe Conway wrote:
> What about this:
>
> Functions returning multiple rows and/or multiple columns are
> now much easier to use than before. You can call such a
> "table function" in the SELECT FROM clause, treating its output
> like a table. Also, plpgsql functions can now return sets.
Added.
Tom Lane wrote:
> C functions have always been able to return sets too; you don't honestly
> think that a SQL function can do something a C function can't, do you?
The original dblink is an example.
>
> There are really two independent improvements here: one is the ability
> for plpgsql functio
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, now I remember, only SQL functions could return sets. How about
> this:
>PL/PgSQL and C functions can now return sets, with multiple
>rows and multiple columns. You specify these functions in the
>SELECT FROM cl
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't remember every seeing a function returning sets before. Can you
> > give an example?
>
> http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/xfunc-sql.html#AEN26392
>
> Also, the preceding subsection shows SQL funct
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't remember every seeing a function returning sets before. Can you
> give an example?
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/xfunc-sql.html#AEN26392
Also, the preceding subsection shows SQL functions returning rows. So
these
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Please review the HISTORY file.
>
>PostgreSQL now support ALTER TABLE ... DROP COLUMN functionality.
>
> s/support/supports/
>
>Functions can now return sets, with multiple rows
>and multiple col
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Please review the HISTORY file.
PostgreSQL now support ALTER TABLE ... DROP COLUMN functionality.
s/support/supports/
Functions can now return sets, with multiple rows
and multiple columns. You specify these functions
Joe Conway wrote:
> Bruce Momjian wrote:
> > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
> >
> > I used the same HISTORY categories Peter made in 7.2. I liked them.
> >
> > Please review the HISTORY file. I am sure there are improvements that
> > can be made.
> >
Bruce Momjian wrote:
> OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
>
> I used the same HISTORY categories Peter made in 7.2. I liked them.
>
> Please review the HISTORY file. I am sure there are improvements that
> can be made.
>
A few minor comments:
1. suggest
OK, wording updated to add 'applications':
Schemas allow users to create objects in their own namespace
so two people or applications can have tables with the same
name. There is also a public schema for shared tables.
Table/index creation can be restr
Alvaro Herrera wrote:
> Shridhar Daithankar dijo:
>
> > On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
> >
> > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
> >
> > Some minor stuff,
>
> In the schema changes description:
>
> "Schemas allow users to create objects i
Rod Taylor wrote:
> Found this line without a name:
>
> Propagate column or table renaming to foreign key constraints
>
> Is that item complete? pg_constraint follows (as such dump / restore
> will work) but the triggers themselves still break, don't they?
No idea. The item only talks about t
Tatsuo Ishii wrote:
> > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
> >
> > I used the same HISTORY categories Peter made in 7.2. I liked them.
> >
> > Please review the HISTORY file. I am sure there are improvements that
> > can be made.
>
> Please change:
>
> >
> Shridhar Daithankar dijo:
>
> > On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
> >
> > > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
> >
> > Some minor stuff,
>
> In the schema changes description:
>
> "Schemas allow users to create objects in their own namespace
Shridhar Daithankar dijo:
> On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
>
> > OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
>
> Some minor stuff,
In the schema changes description:
"Schemas allow users to create objects in their own namespace
so two people can have
Rod Taylor <[EMAIL PROTECTED]> writes:
> Found this line without a name:
> Propagate column or table renaming to foreign key constraints
> Is that item complete? pg_constraint follows (as such dump / restore
> will work) but the triggers themselves still break, don't they?
Yes, no. There's hack
Found this line without a name:
Propagate column or table renaming to foreign key constraints
Is that item complete? pg_constraint follows (as such dump / restore
will work) but the triggers themselves still break, don't they?
On Wed, 2002-09-04 at 03:24, Bruce Momjian wrote:
> OK, the HISTORY
> OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
>
> I used the same HISTORY categories Peter made in 7.2. I liked them.
>
> Please review the HISTORY file. I am sure there are improvements that
> can be made.
Please change:
> Add CREATE/DROP CONVERSION, allowing lo
I assume you are not looking at the 7.3 release notes. It does take a
while for anon to get the changes.
---
Shridhar Daithankar wrote:
> On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
>
> > OK, the HISTORY file is updated,
On 4 Sep 2002 at 3:24, Bruce Momjian wrote:
> OK, the HISTORY file is updated, and 7.3 is branded and ready for beta1.
>
> I used the same HISTORY categories Peter made in 7.2. I liked them.
>
> Please review the HISTORY file. I am sure there are improvements that
> can be made.
Some minor s
On Tue, 3 Sep 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Yes, I haven't gotten to the release checklist yet. Let's delay a day.
>
> Or at least late in the day tomorrow. I have some loose ends to clean
> up yet as well, but I'm beat and am going to bed.
>
> But I assu
S'alright, I can do the package together tomorrow morning to let you wrap
up the loose ends :)
On Tue, 3 Sep 2002, Bruce Momjian wrote:
> I am still working on the 7.3 HISTORY file. I have extracted the items,
> but I have to worksmith them and write an introduction.
>
> It is midnight here no
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, I haven't gotten to the release checklist yet. Let's delay a day.
Or at least late in the day tomorrow. I have some loose ends to clean
up yet as well, but I'm beat and am going to bed.
But I assume we are now officially in feature freeze, right
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I don't know of any other items holding up the packaging.
>
> Gotta brand the thing as 7.3beta1 not 7.3devel, no?
Yes, I haven't gotten to the release checklist yet. Let's delay a day.
I have a 17k line log file down to 3.5k lines
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't know of any other items holding up the packaging.
Gotta brand the thing as 7.3beta1 not 7.3devel, no?
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked ou
> | Fix for inherited CHECK constraints (Stephan Szabo)
>
> ditto
If this is what I think it is, I think the actual fix was the
following (although I don't know what a particularly good wording
is)
ALTER TABLE ADD CONSTRAINT now properly adds check constraints
to children of the specified tab
Added. I will update the HISTORY file today or tomorrow to add newer
changes than 2001-09-13.
---
> Hi Bruce,
>
> you might add that I did the following useful enhancement to ECPG:
>
> - EXECUTE ... INTO ...implemen
> Could you not include characters other than ASCII in the HISTORY file,
> please.
>
> > Python fix fetchone() (Gerhard H舐ing)
Fixed. Thanks.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a
> Bruce,
>
> I notice HISTORY in CVS doesn't mentioned any development we did
> with GiST. Should we write some info ? Major things we did:
>
> 1. Null-safe interface to GiST
> 2. Support of multi-key GiST indices
I had generic GIST improvements. Updated to:
Allow GIST to handle NULLs and mul
>
> May be it's cosmetic, but:
>
> - "Migration to 7.1" right is "Migration to 7.2"
Fixed.
>
> Be missing:
>
> - information that some parts of interface are translated to
>Swedish, Russian, French, Germany nad Czech.
> (IMHO right place for information about Peter's NLS suppo
Done.
> Bruce, could you update following in HISTORY:
>
> Allow automatic conversion to Unicode (Tatsuo)
>
> to:
>
> Allow automatic conversion to/from Unicode (Tatsuo, Eiji)
>
> Eiji Tokuya <[EMAIL PROTECTED]> has contributed a better
> conversion map for SJIS.
> --
> Tatsuo Ishii
>
--
42 matches
Mail list logo
