On Thu, Jul 28, 2011 at 07:45:01PM -0400, Robert Haas wrote:
On Thu, Jul 28, 2011 at 5:46 PM, daveg da...@sonic.net wrote:
On Thu, Jul 28, 2011 at 09:46:41AM -0400, Robert Haas wrote:
On Wed, Jul 27, 2011 at 8:28 PM, daveg da...@sonic.net wrote:
My client has been seeing regular instances
On Jul28, 2011, at 22:51 , Peter Eisentraut wrote:
On ons, 2011-07-27 at 23:21 +0200, Florian Pflug wrote:
On Jul27, 2011, at 23:08 , Peter Eisentraut wrote:
Well, offhand I would expect that passing an XML value to XMLATTRIBUTES
would behave as in
SELECT XMLELEMENT(NAME t,
Hi,
Any preferences for the name?
connoinh
conisonly
constatic or confixed
I'd probably pick conisonly from those choices.
The use of \d inside psql will show ONLY constraints without any
embellishments similar to normal constraints. E.g.
ALTER TABLE ONLY a ADD CONSTRAINT achk CHECK
On Fri, Jul 29, 2011 at 7:41 AM, Nikhil Sontakke nikkh...@gmail.com wrote:
Hi,
Any preferences for the name?
connoinh
conisonly
constatic or confixed
I'd probably pick conisonly from those choices.
The use of \d inside psql will show ONLY constraints without any
embellishments similar
psql=# \d a
Table public.a
Column | Type | Modifiers
+-+---
b | integer |
Check constraints:
achk CHECK (false)
bchk CHECK (b 0)
Is this acceptable? Or we need to put in work into psql to show ONLY
somewhere in the description? If yes, ONLY
On Fri, Jul 29, 2011 at 8:30 AM, Nikhil Sontakke nikkh...@gmail.com wrote:
Yeah, I have already hacked it a bit. This constraint now needs to be
spit out later as an ALTER command with ONLY attached to it
appropriately. Earlier all CHECK constraints were generally emitted as
part of the table
Nikhil Sontakke nikkh...@gmail.com writes:
(Also, don't forget you need to hack pg_dump, too.)
Yeah, I have already hacked it a bit. This constraint now needs to be
spit out later as an ALTER command with ONLY attached to it
appropriately. Earlier all CHECK constraints were generally emitted
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 29, 2011 at 8:30 AM, Nikhil Sontakke nikkh...@gmail.com wrote:
Yeah, I have already hacked it a bit. This constraint now needs to be
spit out later as an ALTER command with ONLY attached to it
appropriately. Earlier all CHECK constraints
Yeah, I have already hacked it a bit. This constraint now needs to be
spit out later as an ALTER command with ONLY attached to it
appropriately. Earlier all CHECK constraints were generally emitted as
part of the table definition itself.
Hrm. That doesn't seem so good. Maybe we've got
Yeah, I have already hacked it a bit. This constraint now needs to be
spit out later as an ALTER command with ONLY attached to it
appropriately. Earlier all CHECK constraints were generally emitted as
part of the table definition itself.
IIRC, there's already support for splitting out a
Robert Haas robertmh...@gmail.com wrote:
(4) We communicate acceptable snapshots to the replica to make
the order of visibility visibility match the master even when
that doesn't match the order that transactions returned from
commit.
I (predictably) like (4) -- even though it's a lot
daveg da...@sonic.net writes:
On Thu, Jul 28, 2011 at 07:45:01PM -0400, Robert Haas wrote:
Ah, OK, sorry. Well, in 9.0, VACUUM FULL is basically CLUSTER, which
means that a REINDEX is happening as part of the same operation. In
9.0, there's no point in doing VACUUM FULL immediately followed
We could imagine doing something like CHECK ONLY (foo), but that seems
quite non-orthogonal with (a) everything else in CREATE TABLE, and
(b) ALTER TABLE ONLY.
Yeah, I thought about CHECK ONLY support as part of table definition, but as
you say - it appears to be too non-standard right now
Hi,
I have read all information about checkpoints in PostgreSQL I have found.
I think that current implementation of checkpoints is not good for huge
shared buffer cache and for many WAL segments. If there is more buffers
and if buffers can be written rarely more updates of buffers can be
combined
2011/7/29 Shigeru Hanada shigeru.han...@gmail.com:
Here is a rebased version of per-column FDW options patch. I've
proposed this patch in last CF, but it was marked as returned with
feedback. So I would like to propose in next CF 2011-09. I already
moved CF item into new topic SQL/MED of CF
On Thu, 2011-07-28 at 20:14 -0400, Robert Haas wrote:
On Thu, Jul 28, 2011 at 7:54 PM, Ants Aasma ants.aa...@eesti.ee wrote:
On Thu, Jul 28, 2011 at 11:54 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
(4) We communicate acceptable snapshots to the replica to make the
order of
On Fri, Jul 29, 2011 at 10:20 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
An additional point to think about: if we were willing to insist on
streaming replication, we could send the commit sequence numbers via a
side channel rather than writing them to WAL, which would be a lot
cheaper.
On Fri, 2011-07-29 at 10:23 -0400, Robert Haas wrote:
On Fri, Jul 29, 2011 at 10:20 AM, Hannu Krosing ha...@2ndquadrant.com wrote:
An additional point to think about: if we were willing to insist on
streaming replication, we could send the commit sequence numbers via a
side channel rather
On Fri, Jul 29, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
daveg da...@sonic.net writes:
On Thu, Jul 28, 2011 at 07:45:01PM -0400, Robert Haas wrote:
Ah, OK, sorry. Well, in 9.0, VACUUM FULL is basically CLUSTER, which
means that a REINDEX is happening as part of the same operation.
Hi all,
I just noticed that the USECS_* constants are not defined when the server
is compiled without integer dates and timestamps.
Explicitly, timestamp.h is
#ifdef HAVE_INT64_TIMESTAMP
#define USECS_PER_DAY INT64CONST(864)
#define USECS_PER_HOUR INT64CONST(36)
#define
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 29, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The thing that was bizarre about the one instance in the buildfarm was
that the error was persistent, ie, once a session had failed all its
subsequent attempts to access pg_class
On Fri, Jul 29, 2011 at 11:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 29, 2011 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The thing that was bizarre about the one instance in the buildfarm was
that the error was persistent, ie, once a
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 29, 2011 at 11:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, no, because the ScanPgRelation call is not failing internally.
It's performing a seqscan of pg_class and not finding a matching tuple.
SnapshotNow race?
That's what I would
Robert Haas wrote:
| I think that get_object_namespace() needs to be rethought. If you
| take a look at AlterObjectNamespace() and its callers, you'll notice
| that we already have, encoded in those call sites, the knowledge of
| which object types can be looked up in which system caches, and
I honestly do not mean any offence, just out of curiosity.
If you guys care about money and time why would you spend the best years of
your life basically copying commercial products for free?
1) For the same reasons commercial vendors build competing products: different
tools in the same
Kohei Kaigai kohei.kai...@emea.nec.com writes:
In addition to this suggestion, I think the big static array also contains
the following items:
- Text form of the object type (e.g, table, function, ...)
What will you do with that that wouldn't be better done by calling
getObjectDescription?
Hi all,
PFA, patch which implements non-inheritable ONLY constraints. This
has been achieved by introducing a new column conisonly in
pg_constraint catalog. Specification of 'ONLY' in the ALTER TABLE ADD
CONSTRAINT CHECK command is used to set this new column to true.
Constraints which have this
On Fri, Jul 29, 2011 at 1:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It would likely be better to not expose the struct type, just individual
lookup functions.
I'm not sure about that... I think that's just going to introduce a
lot of excess notation.
And, a translation from ObjectType to
On tis, 2011-07-19 at 14:17 -0400, Robert Haas wrote:
I think it would be less confusing to write the IP address as the main
piece of information, and put the hostname in parentheses only if we
accepted it as valid (i.e. we did both lookups, and everything
matched).
ERROR: no pg_hba.conf
On lör, 2011-07-16 at 21:55 +0300, Heikki Linnakangas wrote:
I think I would prefer something like this:
ERROR: could not serialize access due to read/write dependencies
among
transactions
DETAIL: Reason code: %s
HINT: The transaction might succeed if retried.
Where %s gets the
On Fri, Jul 29, 2011 at 2:44 PM, Peter Eisentraut pete...@gmx.net wrote:
On tis, 2011-07-19 at 14:17 -0400, Robert Haas wrote:
I think it would be less confusing to write the IP address as the main
piece of information, and put the hostname in parentheses only if we
accepted it as valid (i.e.
On 07/29/2011 11:04 AM, jord...@go-link.net wrote:
I think that current implementation of checkpoints is not good for huge
shared buffer cache and for many WAL segments. If there is more buffers
and if buffers can be written rarely more updates of buffers can be
combined so total number of
Excerpts from Nikhil Sontakke's message of vie jul 29 14:12:37 -0400 2011:
Hi all,
PFA, patch which implements non-inheritable ONLY constraints. This
has been achieved by introducing a new column conisonly in
pg_constraint catalog. Specification of 'ONLY' in the ALTER TABLE ADD
CONSTRAINT
Excerpts from Peter Eisentraut's message of vie jul 29 14:46:20 -0400 2011:
On lör, 2011-07-16 at 21:55 +0300, Heikki Linnakangas wrote:
I think I would prefer something like this:
ERROR: could not serialize access due to read/write dependencies
among
transactions
DETAIL: Reason
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Peter Eisentraut's message of vie jul 29 14:46:20 -0400 2011:
On lör, 2011-07-16 at 21:55 +0300, Heikki Linnakangas wrote:
Do you have an idea how to address this case:
Call sprintf to expand the %u before ereport()?
That
On machines with lots of CPU cores, pgbench can start eating up a lot
of system time. Investigation reveals that the problem is with
random(), which glibc implements like this:
long int
__random ()
{
int32_t retval;
__libc_lock_lock (lock);
(void) __random_r (unsafe_state, retval);
Robert Haas robertmh...@gmail.com writes:
On machines with lots of CPU cores, pgbench can start eating up a lot
of system time. Investigation reveals that the problem is with
random(),
Interesting.
I patched it to use random_r() - the patch is attached - and here are
the (rather
On Fri, Jul 29, 2011 at 09:55:46AM -0400, Tom Lane wrote:
The thing that was bizarre about the one instance in the buildfarm was
that the error was persistent, ie, once a session had failed all its
subsequent attempts to access pg_class failed too. I gather from Dave's
description that it's
On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On machines with lots of CPU cores, pgbench can start eating up a lot
of system time. Investigation reveals that the problem is with
random(),
Interesting.
I patched it to use
On Fri, Jul 29, 2011 at 11:18 AM, Johann 'Myrkraverk' Oskarsson
joh...@2ndquadrant.com wrote:
Hi all,
I just noticed that the USECS_* constants are not defined when the server
is compiled without integer dates and timestamps.
Explicitly, timestamp.h is
#ifdef HAVE_INT64_TIMESTAMP
#define
All,
Where are we on RC1 or Beta4 for PostgreSQL 9.1?
While I know we're doing going to do a final release in August due to the
europeans, it would be nice to move things along before then. There don't seem
to be any blockers open.
--
Josh Berkus
PostgreSQL Experts Inc.
Excerpts from Robert Haas's message of sáb jul 23 07:40:12 -0400 2011:
On Sat, Jul 23, 2011 at 4:37 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
That looks wrong to me, because a NOT NULL constraint is a column
constraint not a table constraint. The CREATE TABLE syntax explicitly
Attached is revision of this patch that now treats the latch in
PGPROC, waitLatch, as the generic process latch, rather than just
using it for sync rep; It is initialised appropriately as a shared
latch generically, within InitProcGlobal(), and ownership is
subsequently set within InitProcess().
If you make writes go out more often, they will be less efficient
I think fsync is more important. But many writes + fsync is no good too.
Let suppose that 30 WAL segments are good for performance (to be written
at once). In incremental approach we can have 60 segments and we can write
30 at
Comments and further feedback, if any, appreciated.
Did you look at how this conflicts with my patch to add not null
rows to pg_constraint?
https://commitfest.postgresql.org/action/patch_view?id=601
I was certainly not aware of this patch in the commitfest. Your patch
has a larger
Based on EnterpriseDB testing, I have applied the attached patch to fix
a pg_upgrade bug on Win32 on 9.1 and 9.2. The problem is that on Win32
you can't stat() a directory with a trailing slash --- this is already
mentioned in our src/port/path.c. The patch removes a lone trailing
slash.
--
46 matches
Mail list logo
