Hi All,
Please forward this mail to the correct mailing list if this is not a right
place,
Please send me the link or white papers from where i can get information
like.
1. Feature comparison in between PostgreSQL 9.x with MySql or MariaDB
2. if possible specially with DBaaS
3. Feature comparison
2012/5/2 Robert Haas :
> On Tue, May 1, 2012 at 4:09 PM, Tom Lane wrote:
>> I continue to maintain that the SQLSTATE is a much better basis for
>> solving this problem. Its categories are already pretty close to
>> what Peter needs: basically, IIUC, he wants to know about classes
>> 53, 58, maybe
Robert Haas writes:
> One fairly major obstacle to using quex for anything is that it
> doesn't appear to be packaged on either Fedora or Ubuntu (I tried
> apt-cache search quex on my Ubuntu laptop, and yum install quex on an
> F16 machine). 'port install quex' on my MacOS X doesn't find it
> eit
On Tue, May 1, 2012 at 8:53 PM, Peter Geoghegan wrote:
> I'm certainly not suggesting that this isn't something that, in order
> to be adopted, will have to be carefully considered from many angles,
> of which the performance of the resulting lexer is only one, but at
> the same time I dare say th
Peter Geoghegan writes:
> Quite apart from the practical difficulties that we have with Flex
> (the fact that the authors are non-responsive and possibly retired,
btw, as far as that goes, a look into their sourceforge SCM shows
evidence of continued activity. I dunno why it's been so long since
Peter Geoghegan writes:
> ... I have heard people complain about Postgres
> parser overhead for "pgbench -S" style use-cases where it is
> unreasonably high, and I've heard them do so more than once.
I was under the impression that those cycles were mostly in bison not
flex...
On May 1, 2012, at 20:41, Hannu Krosing wrote:
>
> Most people don't work in strongly-typed environment, and thus would
> work around such restriction if they need a simple JSON value at the
> other end of the interchange.
>
>
>> My personal take it is have it fail since any arbitrary decision
On 2 May 2012 01:13, Tom Lane wrote:
> I don't deny that we probably need to reclassify a few error cases, and
> fix some elogs that should be ereports, before this approach would be
> really workable. My point is that it's *close*, whereas "let's invent
> some new error severities" is not close
Quite apart from the practical difficulties that we have with Flex
(the fact that the authors are non-responsive and possibly retired,
that annoying compiler warning, and the fact that we are forced to
maintain our own Windows binaries of 2.5.35), it has some notable
disadvantages. I am aware that
On Tue, 2012-05-01 at 18:35 -0400, David Johnston wrote:
> > -Original Message-
> > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> > ow...@postgresql.org] On Behalf Of Hannu Krosing
> > Sent: Tuesday, May 01, 2012 5:29 PM
> >
> > The reason I am whining now is that with
On May 1, 2012, at 20:05, Robert Haas wrote:
> On Tue, May 1, 2012 at 4:09 PM, Tom Lane wrote:
>> I continue to maintain that the SQLSTATE is a much better basis for
>> solving this problem. Its categories are already pretty close to
>> what Peter needs: basically, IIUC, he wants to know about
Robert Haas writes:
> On Tue, May 1, 2012 at 4:09 PM, Tom Lane wrote:
>> I continue to maintain that the SQLSTATE is a much better basis for
>> solving this problem. Its categories are already pretty close to
>> what Peter needs: basically, IIUC, he wants to know about classes
>> 53, 58, maybe F
On Tue, May 1, 2012 at 4:09 PM, Tom Lane wrote:
> I continue to maintain that the SQLSTATE is a much better basis for
> solving this problem. Its categories are already pretty close to
> what Peter needs: basically, IIUC, he wants to know about classes
> 53, 58, maybe F0, and XX.
This is really
Peter Geoghegan writes:
> There is another advantage to doing this within the core system that I
> have not touched upon, which is that in this way we can expose another
> useful GUC to reduce log noise, beyond log_min_messages.
Yeah, that one is actually a pretty compelling argument. A *lot* of
Andrew Dunstan writes:
> On Tue, May 1, 2012 at 9:56 AM, Joey Adams wrote:
>> No, the RFC says (emphasis mine):
>>
>> A JSON *text* is a serialized object or array.
>>
>> If we let the JSON type correspond to a *value* instead, this
>> restriction does not apply, and the JSON type has a useful r
On 1 May 2012 22:09, Kevin Grittner wrote:
> That doesn't seem necessary or desirable. The thing to do is to
> somewhere define a list of what is "severe". It seems likely that
> different shops may have different opinions on what constitutes a
> "severe" problem, or may have more than a "severe
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Hannu Krosing
> Sent: Tuesday, May 01, 2012 5:29 PM
>
> The reason I am whining now is that with minor adjustments in
> implementation it could all be made much more
On Tue, May 1, 2012 at 1:48 AM, Kevin Grittner
wrote:
> My biggest complaint is related to setting the threshold for the %
> operator. It seems to me that there should be a GUC to control the
> default, and that there should be a way to set the threshold for
> each % operator in a query (if there
On Mon, Apr 30, 2012 at 10:07 PM, Robert Haas wrote:
> On Sun, Apr 29, 2012 at 8:12 AM, Erik Rijkers wrote:
> > Perhaps I'm too early with these tests, but FWIW I reran my earlier test
> program against three
> > instances. (the patches compiled fine, and make check was without
> problem).
>
>
Hi Erik
On Sun, Apr 29, 2012 at 4:12 PM, Erik Rijkers wrote:
> Perhaps I'm too early with these tests, but FWIW I reran my earlier test
> program against three
> instances. (the patches compiled fine, and make check was without
> problem).
>
> -- 3 instances:
> HEAD port 6542
>
On Tue, 2012-05-01 at 09:22 -0700, Andrew Dunstan wrote:
>
>
> On Tue, May 1, 2012 at 9:05 AM, Merlin Moncure
> wrote:
> On Tue, May 1, 2012 at 10:49 AM, Joey Adams
> wrote:
> > On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing
> wrote:
> >> Hi hackers
>
On Fri, Apr 27, 2012 at 3:05 PM, Noah Misch wrote:
> On Thu, Apr 26, 2012 at 09:25:25PM +0300, Peter Eisentraut wrote:
>> On m??n, 2012-04-23 at 12:30 -0400, Noah Misch wrote:
>> > I've been enjoying "\x auto" in .psqlrc, but I noticed the row count footer
>> > missing when it chooses ordinary out
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Peter Geoghegan
> Sent: Tuesday, May 01, 2012 4:37 PM
> To: Tom Lane
> Cc: Pavel Stehule; PostgreSQL Hackers
> Subject: Re: [HACKERS] proposal: additional error fields
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 1, 2012 at 3:48 PM, Stephen Frost wrote:
> > I'd be happy to help construct that case, as well as test any changes in
> > this area which might help address it (on a 10G SSD-backed SAN..).
>
> Hmm, can you ship me one of those 10
Peter Geoghegan wrote:
> The argument could be made that what I've characterised as severe
> (which is, as I've said, not entirely clear-cut) could be deduced
> from SQLSTATE if we were to formalise the "can't happen errors are
> only allowed to use elog()" convention into a hard rule.
That do
Magnus Hagander writes:
> On Tue, May 1, 2012 at 10:25 PM, Tom Lane wrote:
>> Are there, or might there be in the future, any "port" files that only
>> exist in server flavor and not client-side flavor?
> Isn't that what backend/port/* is for?
Ah, good point. Nevermind then.
On Tue, 2012-05-01 at 11:11 -0700, Andrew Dunstan wrote:
> On Tue, May 1, 2012 at 9:56 AM, Joey Adams
> wrote:
...
> No, the RFC says (emphasis mine):
>
>A JSON *text* is a serialized object or array.
>
> If we let the JSON type corres
On Tue, May 1, 2012 at 10:25 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:
>>> Instead, I thought this could easily be fixed by writing this:
>>>
>>> %_srv.o: %.c %.o
>>> $(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPF
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mar may 01 16:25:07 -0400 2012:
>> Are there, or might there be in the future, any "port" files that only
>> exist in server flavor and not client-side flavor?
> Now, there is someone with a patch that duplicates some libpq code into
>
On Tue, May 1, 2012 at 3:48 PM, Stephen Frost wrote:
> Try loading the TIGER 2011 data into a single table, where you load each
> county (or perhaps state) in a separate, parallel, process. That's what
> I was doing when I hit this lock full-force and bitched about it on this
> list.
>
> I'd be h
On Tue, Apr 24, 2012 at 09:29:39PM +0300, Peter Eisentraut wrote:
> I propose that we remove support for the following OS ports from our
> source tree. They are totally dead, definitely don't work, and/or
> probably no one remembers what they even were. The code just bit rots
> and is in the way
On 1 May 2012 21:14, Tom Lane wrote:
> Peter Geoghegan writes:
>> Maybe no one is convinced by any of this, but the fact is that the
>> SQLSTATE argument falls down when one considers that we aren't using
>> it in many cases of errors that clearly are severe.
>
> The reason that argument isn't co
Excerpts from Tom Lane's message of mar may 01 16:25:07 -0400 2012:
>
> Alvaro Herrera writes:
> > Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:
> >> Instead, I thought this could easily be fixed by writing this:
> >>
> >> %_srv.o: %.c %.o
> >>$(CC) $(CFLAGS) $
Alvaro Herrera writes:
> Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:
>> Instead, I thought this could easily be fixed by writing this:
>>
>> %_srv.o: %.c %.o
>> $(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $< -o $@
>>
>> A bit hacky, but should get qu
On 4/25/12 6:15 PM, Jaime Casanova wrote:
On Wed, Apr 25, 2012 at 5:46 PM, Merlin Moncure wrote:
>
> I don't know how GTT play inside the Oracle stack such that they
> aren't super popular, but if they work in the standby they will
> quickly become a killer feature. IMNSHO it's annoying but
On Tue, 2012-05-01 at 12:54 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > Let me just point out two things. First, we are approaching a beta release.
> > The time for changing this is long since gone, IMNSHO.
>
> This is our last chance to get it right, so that argument doesn't seem
> to me
Peter Geoghegan writes:
> Maybe no one is convinced by any of this, but the fact is that the
> SQLSTATE argument falls down when one considers that we aren't using
> it in many cases of errors that clearly are severe.
The reason that argument isn't convincing is that we *are* using a
SQLSTATE for
On 1 May 2012 20:36, Noah Misch wrote:
> I agree that some means to mechanically distinguish these cases would
> constitute a significant boon for admin monitoring. Note, however, that the
> same split appears at other severity levels:
>
> FATAL, routine: terminating connection due to conflict wi
On 4/25/12 6:16 AM, Simon Riggs wrote:
The way standard-like temporary tables work is exactly why I assume
> Noah proposes to implement them: because they work nicely with HS.
Well, following a standard that no other major DBMS has followed is
not great, especially if it leads to a non-useful
Noah Misch writes:
> I agree that some means to mechanically distinguish these cases would
> constitute a significant boon for admin monitoring. Note, however, that the
> same split appears at other severity levels:
> FATAL, routine: terminating connection due to conflict with recovery
> FATAL,
On 4/17/12 7:19 AM, Greg Stark wrote:
On Mon, Apr 16, 2012 at 10:42 PM, Peter Geoghegan wrote:
> All but 4 regression tests pass, but they don't really count
> as failures, since they're down to an assumption in the tests that the
> order certain tuples appear should be the same as our curre
Excerpts from Noah Misch's message of mar may 01 15:36:22 -0400 2012:
> On Tue, May 01, 2012 at 02:19:16PM +0100, Peter Geoghegan wrote:
> > The first category of error is something that the DBA will often see
> > very frequently. The latter 3 are situations which I'd like to be
> > woken up in t
On Wed, Apr 18, 2012 at 05:08:06PM +0300, Peter Eisentraut wrote:
> On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote:
> > Maybe I'm confused - Magnus et al, are we talking spammy issues/issue
> > comments/etc, or are we talking more about exposed email addresses?
>
> My github.com account curr
Excerpts from Peter Eisentraut's message of mar may 01 15:30:25 -0400 2012:
> Instead, I thought this could easily be fixed by writing this:
>
> %_srv.o: %.c %.o
> $(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $< -o $@
>
> A bit hacky, but should get quite robust results.
So bas
* Robert Haas (robertmh...@gmail.com) wrote:
> I think the first thing we need here is a good test case, so we're
> clear on what we're trying to solve. I was just hoping to make file
> extension *faster* and what you and Simon are talking about is making
> it scale better in the face of heavy par
On Tue, May 01, 2012 at 02:19:16PM +0100, Peter Geoghegan wrote:
> Currently the following informal categories of error are bunched
> together at ERROR severity:
>
> * Integrity constraint violations
> * Very serious situations, like running out of disk space
> * Serious disasters that often relat
On Tue, May 1, 2012 at 3:01 PM, Alvaro Herrera
wrote:
>> The system is supposed to be designed to avoid that; we try to hand out
>> pages with free space to different backends. One of the advantages of
>> the current page-at-a-time setup is that when there is *no* free space
>> according to the F
There is this rule in src/port/Makefile:
%_srv.o: %.c
$(CC) $(CFLAGS) $(subst -DFRONTEND,, $(CPPFLAGS)) -c $< -o $@
But this rule doesn't observe dependency tracking, so if you change a
header file, these files won't get build as necessary. This is the only
case in the source tree where
Excerpts from Tom Lane's message of mar may 01 13:19:48 -0400 2012:
> Christopher Browne writes:
> > Try to make sure that one of the scenarios involves there being
> > multiple writers.
>
> > One of the relevant cases is where there are multiple writers, where
> > they may wind up fighting over
"Kevin Grittner" writes:
> Brian Weaver wrote:
>> The restore appears to have finished without a problem. The issue
>> I have is a running instance of postgres is still active in a COPY
>> state after the restore. The process is running full tilt, almost
>> like it's in a tight loop condition.
Brian Weaver wrote:
> The restore appears to have finished without a problem. The issue
> I have is a running instance of postgres is still active in a COPY
> state after the restore. The process is running full tilt, almost
> like it's in a tight loop condition.
It's probably dumping all that
On Tue, May 1, 2012 at 9:56 AM, Joey Adams wrote:
> On Tue, May 1, 2012 at 12:22 PM, Andrew Dunstan
> wrote:
> > Second, RFC 4627 is absolutely clear: a valid JSON value can only be an
> > object or an array, so this thing about converting arbitrary datum
> values to
> > JSON is a fantasy. If any
Tom,
The restore appears to have finished without a problem. The issue I
have is a running instance of postgres is still active in a COPY state
after the restore. The process is running full tilt, almost like it's
in a tight loop condition.
-- Brian
On Tue, May 1, 2012 at 1:44 PM, Tom Lane wrot
On 1 May 2012 17:22, Robert Haas wrote:
> Yeah. I also noticed in my benchmarking that sprintf() seemed to be
> very slow, to the point where I wondered whether we ought to have our
> own minimal version of sprintf() just for error strings.
Which sprintf()? You're probably aware that we already
Brian Weaver writes:
> Doh! I missed a script that was run by cron that does a nightly
> backup. That's the likely offender for the 'copy-to-stdout'
> I've removed it from the nightly run. I'll see if have any better luck
> with this run. Still not sure about the best way to debug the issue
> tho
Doh! I missed a script that was run by cron that does a nightly
backup. That's the likely offender for the 'copy-to-stdout'
I've removed it from the nightly run. I'll see if have any better luck
with this run. Still not sure about the best way to debug the issue
though. Any pointers would be appre
Here's the steps I'm taking
# pg_restore -l database.dump > database.list
Edit the database.list file and comment out the 'PROCEDURAL LANGUAGE -
plpgsql' item. Because the dump comes from an 8.4 system without
PL/PgSQL installed by default the create language emitted during
pg_restore causes the
Christopher Browne writes:
> Try to make sure that one of the scenarios involves there being
> multiple writers.
> One of the relevant cases is where there are multiple writers, where
> they may wind up fighting over the last page in the table. If free
> space is in that one page, they might ser
>
> Yeah. I also noticed in my benchmarking that sprintf() seemed to be
> very slow, to the point where I wondered whether we ought to have our
> own minimal version of sprintf() just for error strings.
>
> Another idea would be to pass a flag indicating whether the context
> that's going to recei
On Tue, May 1, 2012 at 10:22 AM, Simon Riggs wrote:
> On Tue, May 1, 2012 at 3:08 PM, Robert Haas wrote:
>
>> We've previously discussed the possible desirability of extending
>> relations in larger increments, rather than one block at a time, for
>> performance reasons. I attempted to determine
Brian Weaver writes:
> I think I've discovered an issue with multi-job pg_restore on a 700 GB
> data file created with pg_dump.
Just to clarify, you mean parallel restore, right? Are you using any
options beyond -j, that is any sort of selective restore?
> The problem occurs during the restore
On Tue, May 1, 2012 at 12:22 PM, Andrew Dunstan wrote:
> Second, RFC 4627 is absolutely clear: a valid JSON value can only be an
> object or an array, so this thing about converting arbitrary datum values to
> JSON is a fantasy. If anything, we should adjust the JSON input routines to
> disallow a
Andrew Dunstan writes:
> Let me just point out two things. First, we are approaching a beta release.
> The time for changing this is long since gone, IMNSHO.
This is our last chance to get it right, so that argument doesn't seem
to me to carry a lot of weight ...
> Second, RFC 4627 is absolutely
On Tue, May 1, 2012 at 11:22 AM, Andrew Dunstan wrote:
>
>
> On Tue, May 1, 2012 at 9:05 AM, Merlin Moncure wrote:
>>
>> On Tue, May 1, 2012 at 10:49 AM, Joey Adams
>> wrote:
>> > On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing
>> > wrote:
>> >> Hi hackers
>> >>
>> >> After playing around with ar
On Tue, May 1, 2012 at 12:02 PM, Pavel Stehule wrote:
>> I have some concerns about the performance cost of this. Now, you may
>> think that this is a dumb thing to be concerned about, but some
>> testing I've done seems to indicate that MOST of the cost of rolling
>> back a subtransaction is the
On Tue, May 1, 2012 at 9:05 AM, Merlin Moncure wrote:
> On Tue, May 1, 2012 at 10:49 AM, Joey Adams
> wrote:
> > On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing
> wrote:
> >> Hi hackers
> >>
> >> After playing around with array_to_json() and row_to_json() functions a
> >> bit it I have a question
On Tue, May 1, 2012 at 11:42 AM, Andres Freund wrote:
>> > There is the question whether this should be done in the background
>> > though, so the relation extension lock is never hit in anything
>> > time-critical...
>> Yeah, although I'm fuzzy on how and whether that can be made to work,
>> whic
On Tue, 2012-05-01 at 11:49 -0400, Joey Adams wrote:
> On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing wrote:
> > Hi hackers
> >
> > After playing around with array_to_json() and row_to_json() functions a
> > bit it I have a question - why do we even have 2 variants *_to_json()
>
> Here's the discu
On Tue, May 1, 2012 at 10:49 AM, Joey Adams wrote:
> On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing wrote:
>> Hi hackers
>>
>> After playing around with array_to_json() and row_to_json() functions a
>> bit it I have a question - why do we even have 2 variants *_to_json()
>
> Here's the discussion
2012/5/1 Robert Haas :
> On Tue, May 1, 2012 at 8:21 AM, Pavel Stehule wrote:
>> I have to goals for 9.3. First goal is plpgsql_check_function, second
>> goal is enhancing ErrorData and error management to support new
>> fields: COLUMN_NAME, CONSTRAINT_NAME, CONSTRAINT_SCHEMA, SCHEMA_NAME,
>> TABL
On Tue, May 1, 2012 at 8:02 AM, Hannu Krosing wrote:
> Hi hackers
>
> After playing around with array_to_json() and row_to_json() functions a
> bit it I have a question - why do we even have 2 variants *_to_json()
Here's the discussion where that decision was made:
http://archives.postgresql.org
On Tuesday, May 01, 2012 05:06:11 PM Robert Haas wrote:
> On Tue, May 1, 2012 at 10:31 AM, Andres Freund wrote:
> >> efficient than our current method - I'm guessing that it actually
> >> writes the updated metadata back to disk, where write() does not (this
> >> makes one wonder how safe it is to
On 1 May 2012 14:55, Tom Lane wrote:
> The last time you complained about this I suggested that looking at
> SQLSTATE would resolve most of your concern. Have you pursued that
> angle?
Sure, I did consider that at the time.
I think that a new severity level (equivalent to ERROR in all but
name)
On Tue, May 1, 2012 at 10:31 AM, Andres Freund wrote:
>> efficient than our current method - I'm guessing that it actually
>> writes the updated metadata back to disk, where write() does not (this
>> makes one wonder how safe it is to count on write to have the behavior
>> we need here in the firs
On Tue, 2012-05-01 at 08:18 -0500, Merlin Moncure wrote:
> On Tue, May 1, 2012 at 7:02 AM, Hannu Krosing wrote:
> > Hi hackers
> >
> > After playing around with array_to_json() and row_to_json() functions a
> > bit it I have a question - why do we even have 2 variants *_to_json()
> >
> > Collapsin
On Tue, May 1, 2012 at 10:22 AM, Simon Riggs wrote:
> Fair enough, but my understanding was that tests showed that the
> extension lock was a bottleneck, so doing extensions in larger chunks
> should reduce the time we spend waiting for a lock and thus improve
> performance. So while your results
On Tuesday, May 01, 2012 04:08:27 PM Robert Haas wrote:
> We've previously discussed the possible desirability of extending
> relations in larger increments, rather than one block at a time, for
> performance reasons. I attempted to determine how much performance we
> could possibly buy this way,
On Tue, May 1, 2012 at 8:21 AM, Pavel Stehule wrote:
> I have to goals for 9.3. First goal is plpgsql_check_function, second
> goal is enhancing ErrorData and error management to support new
> fields: COLUMN_NAME, CONSTRAINT_NAME, CONSTRAINT_SCHEMA, SCHEMA_NAME,
> TABLE_NAME, ROUTINE_NAME, ROUTINE
On Tue, May 1, 2012 at 3:08 PM, Robert Haas wrote:
> We've previously discussed the possible desirability of extending
> relations in larger increments, rather than one block at a time, for
> performance reasons. I attempted to determine how much performance we
> could possibly buy this way, and
Peter Geoghegan wrote:
> Currently the following informal categories of error are bunched
> together at ERROR severity:
>
> * Integrity constraint violations
> * Very serious situations, like running out of disk space
> * Serious disasters that often relate to hardware failure, like
> "xlog flu
We've previously discussed the possible desirability of extending
relations in larger increments, rather than one block at a time, for
performance reasons. I attempted to determine how much performance we
could possibly buy this way, and found that, as far as I can see, the
answer is, basically, n
Peter Geoghegan writes:
> Currently the following informal categories of error are bunched
> together at ERROR severity:
> * Integrity constraint violations
> * Very serious situations, like running out of disk space
> * Serious disasters that often relate to hardware failure, like "xlog
> flush
On Tue, May 1, 2012 at 2:09 PM, Robert Haas wrote:
> One thing I am a bit uncomfortable with about this whole discussion is
> that it seems like a lot of the design and research is happening
> off-list, with intent to report results back here later. While that
> is obviously fine at some level,
I think I've discovered an issue with multi-job pg_restore on a 700 GB
data file created with pg_dump. Before anyone points out that the
preferred procedure is to use the newest pg_dump to backup a database
before doing pg_restore let just say, "Yes I'm aware of that advice
and unfortunately it jus
On 1 May 2012 14:01, Pavel Stehule wrote:
> What I'd also like to see, which is
>> something that I've agitated about in the past without much luck, is
>> for a new severity level, along the lines of a "severe error". The
>> idea of this is to make a representation that the error in question is
>
On Tue, May 1, 2012 at 7:02 AM, Hannu Krosing wrote:
> Hi hackers
>
> After playing around with array_to_json() and row_to_json() functions a
> bit it I have a question - why do we even have 2 variants *_to_json()
>
> Collapsing array_to_json() and row_to_json() into just to_json()
I asked the sa
On Mon, Apr 30, 2012 at 6:43 PM, Josh Berkus wrote:
> Well, this *is* the purpose of the cluster-hackers group, to add backend
> support which would make external replication systems easier to build
> and more efficient. So far the only real feature to come out of that
> has been the Command Trig
2012/5/1 Peter Geoghegan :
> On 1 May 2012 13:21, Pavel Stehule wrote:
>> COLUMN_NAME - contains missing or inaccessible column name or empty string
>> CONSTRAINT_NAME - a name of constraint caused error
>> CONSTRAINT_SCHEMA - a name of schema where constraint is defined -
>> usually same as table
On 1 May 2012 13:21, Pavel Stehule wrote:
> COLUMN_NAME - contains missing or inaccessible column name or empty string
> CONSTRAINT_NAME - a name of constraint caused error
> CONSTRAINT_SCHEMA - a name of schema where constraint is defined -
> usually same as table schema in PostgreSQL
> SCHEMA_NA
Hello
I have to goals for 9.3. First goal is plpgsql_check_function, second
goal is enhancing ErrorData and error management to support new
fields: COLUMN_NAME, CONSTRAINT_NAME, CONSTRAINT_SCHEMA, SCHEMA_NAME,
TABLE_NAME, ROUTINE_NAME, ROUTINE_SCHEMA, TRIGGER_NAME and
TRIGGER_SCHEMA
previous disc
Hi hackers
After playing around with array_to_json() and row_to_json() functions a
bit it I have a question - why do we even have 2 variants *_to_json()
Collapsing array_to_json() and row_to_json() into just to_json()
As the functi
On Tue, May 1, 2012 at 1:10 AM, Tatsuo Ishii wrote:
>> Those are the basic requirements that I am trying to address. There
>> are a great many important details, but the core of this is probably
>> what I would call "logical replication", that is shipping changes to
>> other nodes in a way that do
92 matches
Mail list logo
