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 ach
On Fri, Jul 29, 2011 at 7:41 AM, Nikhil Sontakke 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 sim
> 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 descript
On Fri, Jul 29, 2011 at 8:30 AM, Nikhil Sontakke 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 definition itse
Nikhil Sontakke 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 as
> part of t
Robert Haas writes:
> On Fri, Jul 29, 2011 at 8:30 AM, Nikhil Sontakke 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 o
> > 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 w
> > 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 splitti
Robert Haas 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 of work
>
daveg 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 by
>> REI
> 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 no
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 :
> 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 2011-09.
I did a
On Thu, 2011-07-28 at 20:14 -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 7:54 PM, Ants Aasma wrote:
> > On Thu, Jul 28, 2011 at 11:54 PM, Kevin Grittner
> > wrote:
> >> (4) We communicate acceptable snapshots to the replica to make the
> >> order of visibility visibility match the master
On Fri, Jul 29, 2011 at 10:20 AM, Hannu Krosing 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.
>
> Why do you t
On Fri, 2011-07-29 at 10:23 -0400, Robert Haas wrote:
> On Fri, Jul 29, 2011 at 10:20 AM, Hannu Krosing 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
On Fri, Jul 29, 2011 at 9:55 AM, Tom Lane wrote:
> daveg 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 p
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 USECS_
Robert Haas writes:
> On Fri, Jul 29, 2011 at 9:55 AM, 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 was thinking more alo
On Fri, Jul 29, 2011 at 11:27 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 29, 2011 at 9:55 AM, 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
Robert Haas writes:
> On Fri, Jul 29, 2011 at 11:27 AM, Tom Lane 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 have guessed to start with, except t
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 whic
>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 cat
Kohei Kaigai 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? The latter's output i
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 th
On Fri, Jul 29, 2011 at 1:49 PM, Tom Lane 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 type name (e.g "ta
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.co
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 t
On Fri, Jul 29, 2011 at 2:44 PM, Peter Eisentraut 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. we did bo
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 writes
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
> CON
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
> > DETAI
Alvaro Herrera 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 sounds like way too much w
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);
__li
Robert Haas 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 gratifying) results of that
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'
On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane wrote:
> Robert Haas 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 attac
On Fri, Jul 29, 2011 at 11:18 AM, Johann 'Myrkraverk' Oskarsson
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 USECS_PER_DAY
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.
http://pgexperts.co
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
> wrote:
> > That looks wrong to me, because a NOT NULL constraint is a column
> > constraint not a table constraint. The CREATE TABLE syntax explicitly
> > distinguishes these 2
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 onc
>> 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 f
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.
--
B
Robert Haas writes:
> On Fri, Jul 29, 2011 at 5:25 PM, Tom Lane wrote:
>> Portability, or rather lack of it. What about using erand48, which we
>> already have a dependency on (and substitute code for)?
> Neither our implementation nor glibc's appears to be thread-safe,
I think you're confusin
46 matches
Mail list logo
