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
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 remove or merge these
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
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.
Regards,
Jeff Davis
--
S
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
I think the new pg_get_triggerdef and pg_constraint_is_visible functions
aren't mentioned.
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
> Allow SQL200X inheritance syntax LIKE , INCLUDING DEFAULTS?
(Rod)
Yes, it includes defaults.
> > Have COMMENT ON DATABASE on non-local database generate a warning
(Tom)
> > I think that was someone else's work ... Rod maybe?
> Name removed. Anyone know?
I sent in a patch, but it was pretty t
I have updated /HISTORY for 7.3beta2. Looking at the open items list, I
think we are ready for beta2 now.
---
P O S T G R E S Q L
7 . 3 O P E NI T E M S
Curre
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
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| http://candle.pha.pa.us
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
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 now. I don't think I can finish before ~3am and at
that point, I am not sure I will know what I am writing.
Basically, one day of feature freeze w
> | 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
I find the HISTORY file to be distressingly poor to peruse. Reasons:
A large proportion of the items don't convey any useful information.
Examples:
| PLpgSQL fix for SELECT... FOR UPDATE (Tom)
What did this fix? Does SELECT FOR UDPATE now work whereas it didn't use
to? => "SELECT ... FOR UPDA
I have updated the HISTORY file to be current as of today. Marc, it may
be nice to repackage beta1 with that one file changed, but my guess is
that we will have a beta2 soon enough.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 8
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
Hi Bruce,
you might add that I did the following useful enhancement to ECPG:
- EXECUTE ... INTO ...implemented
- multiple row descriptor support (e.g. CARDINALITY)
I don't feel that my humble contribution of a few lines is important but
the improvement made really is important (n times perf
> 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
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
TODO
Adding concurrency for GiST
Regards,
Oleg
__
Could you not include characters other than ASCII in the HISTORY file,
please.
> Python fix fetchone() (Gerhard H舐ing)
--
Tatsuo Ishii
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
>
> 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
May be it's cosmetic, but:
- "Migration to 7.1" right is "Migration to 7.2"
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 support is
"Major changes in th
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
>
--
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
56 matches
Mail list logo
