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
On Fri, Mar 28, 2014 at 12:16 PM, David Johnston pol...@yahoo.com 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
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
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
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
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 about
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 difference. I've
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.
I'm not seeing a
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
that
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
--
Sent
Jeff Davis pg...@j-davis.com 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
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
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
Rod Taylor wrote:
-- Start of PGP signed section.
Allow SQL200X inheritance syntax LIKE subtable, 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
Allow SQL200X inheritance syntax LIKE subtable, 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
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
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|
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 stuff,
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,
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 loadable
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
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 hackery
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 the
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
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:
Add CREATE/DROP
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 the
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 in their own
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
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. suggested
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.
A few minor
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 columns. You
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:
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
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 clause,
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 functions
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.
--
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 now.
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 assume we are
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
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 our
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, but
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?
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
| 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
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)
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
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 ...implemented
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 hard
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
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 multi-key
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 support is
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 this
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
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 Momjian
55 matches
Mail list logo
