On Wed, Jul 11, 2012 at 6:41 AM, Shaun Thomas wrote:
>> Regardless of what DRBD does, I think the problem with the
>> async/sync duality as-is is there is no nice way to manage exposure
>> to transaction loss under various situations and requirements.
>
>
> Which would be handy. With synchronous c
On Mon, Jul 16, 2012 at 10:58 PM, Heikki Linnakangas
wrote:
> BTW, one little detail that I don't think has been mentioned in this thread
> before: Even though the master currently knows whether a standby is
> connected or not, and you could write a patch to act based on that, there
> are other fa
On Mon, Jul 16, 2012 at 5:29 PM, Jeff Davis wrote:
> On Tue, 2012-07-10 at 11:50 -0400, Bruce Momjian wrote:
>> I don't think we can assume that because pg_upgrade was run on the
>> master and standby that they are binary identical, can we? Technically
>> the user file are identical, but the syst
On Tue, Jul 17, 2012 at 11:55 AM, Jeff Davis wrote:
> On Tue, 2012-07-17 at 01:02 -0700, Daniel Farina wrote:
>> Could pg_upgrade emit WAL segment(s) to provide continuity of a
>> timeline? So something like:
>
> By "segments" did you mean "records"?
Y
On Tue, Jul 17, 2012 at 9:16 PM, Bruce Momjian wrote:
> WAL is not guaranteed to be the same between PG major versions, so doing
> anything with WAL is pretty much a no-go.
I understand that the WAL format changes, sometimes dramatically
between versions. What I'm suggesting that the first WAL-re
Hello list,
I just encountered an interesting undesirable behavior in Postgres
9.0's error reporting dealing with (trivially) malformed
recovery.conf, as might be the case when setting up hot standby. In
this case, there were some missing fields, and they were checked as
they are supposed to be in
On Wed, Oct 27, 2010 at 6:44 PM, Jaime Casanova wrote:
> On Wed, Oct 27, 2010 at 6:18 PM, Daniel Farina wrote:
>>
>> As a result, "aborting startup due to startup process failure" is seen
>> in the log, but not the messages seen in
>> xlog.c:readRecoveryC
Hello List,
Is there any reason why Postgres should not support an "ALTER TABLE
tablename [IF EXISTS]" feature? (And similar for other ALTER
OBJECTTYPE)
For example, a hypothetical statement that attempts to drop a
constraint in a *completely* optional manner would look like the
following:
ALT
On Fri, Nov 5, 2010 at 8:44 AM, Tom Lane wrote:
> That spells "large maintenance burden" to me, even if any one command
> would be relatively simple to fix. And we haven't even reached the
> question of whether pg_dump could use these things usefully; I suspect
> that the bottom-line issue there
On Fri, Nov 5, 2010 at 10:04 AM, Tom Lane wrote:
> What you're proposing would maybe be useful for overwriting a database
> that contains portions of what is in the source database, but what's
> the use of that? You could just as well dropdb and start fresh. The
> interesting case here is where
On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane wrote:
> Daniel Farina writes:
>> I am somewhat sympathetic to this argument, except for one thing:
>
>> pg_dump --clean will successfully and silently wipe out a foreign key
>> right now, should it exist,
>
> No, it
On Fri, Nov 5, 2010 at 1:31 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane wrote:
>>> Daniel Farina writes:
>>>> pg_dump --clean will successfully and silently wipe out a foreign key
>>>> right now, should it
On Fri, Nov 5, 2010 at 4:20 PM, Robert Haas wrote:
> Can you give us a self-contained example of the problem you're talking about?
Sure. Consider the following:
CREATE TABLE t1 (
id integer PRIMARY KEY
);
CREATE TABLE t2 (
id integer PRIMARY KEY,
fk integer
);
ALTER TABLE ONLY t2
On Sat, Nov 6, 2010 at 6:09 PM, Robert Haas wrote:
> If we're going to try to fix this, we probably ought to try to make
> sure that we are fixing it fairly completely. How confident are you
> that this is the only problem?
I haven't tried to isolate problems on really complicated schemas yet,
b
On Sat, Nov 6, 2010 at 6:09 PM, Robert Haas wrote:
> Since we now have PL/pgsql by default, we could possibly fix pg_dump
> --clean by emitting a DO block, although the syntax for checking
> existence of a table is none too pretty, and it would make pg_dump
> --clean rely for correctness on plpgsq
On Sat, Nov 13, 2010 at 7:54 PM, Darren Duncan wrote:
> A key component of a good type system is that users can define data types,
> and moreover where possible, system-defined types are defined in the same
> ways as users define types. For example, stuff like temporal types or
> geospatial types
On Fri, Nov 12, 2010 at 4:07 PM, Jeff Davis wrote:
> I think the best we'll do is be able to hack on some of the things that
> we actively want and have clear use cases for, such as type interfaces.
> We might have to give up on some of the more ambitious ideas that
> involve propagating interesti
On Sun, Nov 14, 2010 at 7:47 AM, Tom Lane wrote:
> Daniel Farina writes:
>> Here are some weaknesses in the SUM aggregate that run up against the
>> type system. Maybe they'll help crystallize some discussion:
>
>> SUM(int2) => int4
>> SUM(int4) =&g
On Sun, Nov 14, 2010 at 1:25 PM, Robert Haas wrote:
> Like Tom, I'm not sure this is really a type-system problem. This
> sounds like a complaint that operations on "numeric" are much slower
> than operations on "int4" and "int8", even for values that could be
> represented by either type. I thi
To start at the end of this story: "DETAIL: Could not read from file
"pg_clog/007D" at offset 65536: Success."
This is a message we received on a a standby that we were bringing
online as part of a test. The clog file was present, but apparently
too small for Postgres (or at least I tihnk this i
On Thu, Apr 21, 2011 at 8:19 AM, Robert Haas wrote:
> On Thu, Apr 21, 2011 at 7:15 AM, Daniel Farina wrote:
>> To start at the end of this story: "DETAIL: Could not read from file
>> "pg_clog/007D" at offset 65536: Success."
>>
>> This is a
On Thu, Apr 21, 2011 at 1:26 AM, Simon Riggs wrote:
> Daniel Farina points out to me that the Linux man page for fsync() says
> "Calling fsync() does not necessarily ensure that the entry in the directory
> containing the file has also reached disk. For that an
> expl
On Thu, Apr 21, 2011 at 8:51 PM, Greg Smith wrote:
> There's still the "fsync'd a data block but not the directory entry yet"
> issue as fall-out from this too. Why doesn't PostgreSQL run into this
> problem? Because the exact code sequence used is this one:
>
> open
> write
> fsync
> close
>
>
On Mon, Apr 25, 2011 at 8:26 AM, Greg Smith wrote:
> On 04/24/2011 10:06 PM, Daniel Farina wrote:
>>
>> On Thu, Apr 21, 2011 at 8:51 PM, Greg Smith wrote:
>>
>>>
>>> There's still the "fsync'd a data block but not the directory entry
On Mon, Apr 25, 2011 at 12:07 PM, Peter Eisentraut wrote:
> Another point, as there appear to be diverging camps about
> supertransactional stored procedures vs. autonomous transactions, what
> would be the actual use cases of any of these features? Let's collect
> some, so we can think of ways t
On Tue, Apr 26, 2011 at 11:20 PM, Shiv wrote:
> Dear pgsql-hackers,
> My name is Sivasankar Ramasubramanian (you can call me Shiv).
That's an awesome nickname.
> My project is aimed towards extending
> and hopefully improving upon pgtune. If any of you have some ideas or
> thoughts to share. I
Hello list,
A little while ago time ago I posted about how my ... exciting
backup procedure caused occasional problems starting due to clog not
being big enough.
(http://archives.postgresql.org/pgsql-hackers/2011-04/msg01148.php) I
recently had a reproduction and a little bit of luck, and I t
On Thu, Feb 10, 2011 at 2:34 PM, Joshua D. Drake wrote:
> Hello,
>
> Per:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607109
>
> It seems we may have a problem to consider. As far as I know, we are the
> only major platform that supports libedit but our default is readline.
> Unfortunatel
Hello list,
I split this out of the synchronous replication patch for independent
review. I'm dashing out the door, so I haven't put it on the CF yet or
anything, but I just wanted to get it out there...I'll be around in
Not Too Long to finish any other details.
--
fdr
*** a/doc/src/sgml/config.s
On Fri, Feb 11, 2011 at 11:49 AM, Alvaro Herrera
wrote:
> Why do we have to involve the whole of PostgreSQL? Since the only piece
> that links to libreadline is psql, perhaps we could fix this by having
> only psql optionally use GnuTLS. (I don't know if you can make an
> OpenSSL server talk to
Hello list,
I split this out of the synchronous replication patch for independent
review. I'm dashing out the door, so I haven't put it on the CF yet or
anything, but I just wanted to get it out there...I'll be around in
Not Too Long to finish any other details.
--
fdr
*** a/doc/src/sgml/config.s
On Fri, Feb 11, 2011 at 12:25 PM, Stephen Frost wrote:
> * charles.mcdev...@emc.com (charles.mcdev...@emc.com) wrote:
>> Don't forget that OpenSSL has a FIPS-140 compliant version, and FIPS-140
>> compliance is essential to many Federal users.
>
> Essential? That's a bit much. Yes, it shows up
On Fri, Feb 11, 2011 at 12:11 PM, Robert Haas wrote:
> On Fri, Feb 11, 2011 at 2:02 PM, Daniel Farina wrote:
>> I split this out of the synchronous replication patch for independent
>> review. I'm dashing out the door, so I haven't put it on the CF yet or
>> anythi
On Feb 11, 2011 8:20 PM, "Robert Haas" wrote:
>
> On Fri, Feb 11, 2011 at 4:38 PM, Robert Haas
wrote:
> > On Fri, Feb 11, 2011 at 4:30 PM, Heikki Linnakangas
> > wrote:
> >> On 11.02.2011 22:11, Robert Haas wrote:
> >>>
> >&
This is another bit of the syncrep patch split out.
I will revisit the replication timeout one Real Soon, I promise -- but
I have a couple things to do today that may delay that until the
evening.
https://github.com/fdr/postgres/commit/ad3ce9ac62f0e128d7d1fd20d47184f867056af1
Context diff suppli
On Mon, Feb 14, 2011 at 12:48 AM, Fujii Masao wrote:
> On Sat, Feb 12, 2011 at 8:58 AM, Daniel Farina wrote:
>> Context diff equivalent attached.
>
> Thanks for the patch!
>
> As I said before, the timeout which this patch provides doesn't work well
> when the wals
On Mon, Feb 21, 2011 at 4:35 AM, Tatsuo Ishii wrote:
>> Well, good news all round.
Hello on this thread,
I'm taking a look at replication timeout with non-blocking which would
be "nice" but not required for this patch, in my understanding. But
before that, we're going to put this patch through s
On Tue, Feb 22, 2011 at 5:04 AM, Greg Smith wrote:
> Daniel Farina wrote:
>>
>> As it will be somewhat hard to prove the durability guarantees of
>> commit without special heroics, unless someone can suggest a
>> mechanism.
>
> Could you introduce a hack creating
On Fri, Feb 18, 2011 at 4:06 PM, Simon Riggs wrote:
>
> Well, good news all round.
>
> v17 implements what I believe to be the final set of features for sync
> rep. This one I'm actually fairly happy with. It can be enjoyed best at
> DEBUG3.
I've been messing with this patch and am wondering if t
On Wed, Feb 23, 2011 at 10:39 PM, Daniel Farina wrote:
> On Fri, Feb 18, 2011 at 4:06 PM, Simon Riggs wrote:
>>
>> Well, good news all round.
>>
>> v17 implements what I believe to be the final set of features for sync
>> rep. This one I'm actually fairly
On Tue, Feb 22, 2011 at 11:43 AM, Jaime Casanova wrote:
> On Sat, Feb 19, 2011 at 11:26 PM, Robert Haas wrote:
>>
>> DEBUG: write 0/3027BC8 flush 0/3014690 apply 0/3014690
>> DEBUG: released 0 procs up to 0/3014690
>> DEBUG: write 0/3027BC8 flush 0/3027BC8 apply 0/3014690
>> DEBUG: released 2
With some more fooling around, I have also managed to get this elog(WARNING)
if (proc->lwWaitLink == NULL)
elog(WARNING, "could not locate ourselves on
wait queue");
--
fdr
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith wrote:
> Robert Haas wrote:
>>>
>>> 2. Synchronous replication. Splitting up this patch has allowed some
> On top of 4 listed reviewers I know Dan Farina is poking at the last update,
> so we may see one more larger report on top of what's already show
On Fri, Feb 25, 2011 at 5:25 AM, marcin mank wrote:
> On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina wrote:
>>
>> Right now, as it stands, the syncrep patch will be happy as soon as
>> the data has been fsynced to either B or A-prime; I don't think we can
>> gua
On Fri, Feb 25, 2011 at 4:43 AM, Robert Haas wrote:
> On Fri, Feb 25, 2011 at 3:14 AM, Daniel Farina wrote:
>> On Wed, Feb 23, 2011 at 11:49 AM, Greg Smith wrote:
>>> Robert Haas wrote:
>>>>>
>>>>> 2. Synchronous replication. Splitting up th
On Fri, Feb 25, 2011 at 3:44 PM, Josh Berkus wrote:
>
>> Right now, as it stands, the syncrep patch will be happy as soon as
>> the data has been fsynced to either B or A-prime; I don't think we can
>> guarantee at any point that A-prime can become the leader, and feed B.
>
> Yeah, I think that's
On Fri, Feb 25, 2011 at 4:36 PM, Josh Berkus wrote:
> Daniel,
>
>> Ah, okay, I had missed that discussion, I also did not know it got so
>> specific as to address this case (are you sure?) rather than something
>> more general, say quorum or N-safe durability.
>
> The way we address that case is t
On Fri, Feb 25, 2011 at 4:52 PM, Jeff Davis wrote:
> On Wed, 2011-02-23 at 22:42 -0800, Daniel Farina wrote:
>> Oh, yes, this reproduces past shutdowns/startups, and there's quite a
>> few txids before I catch up. I'm also comfortable poking around with
>> gdb
On Fri, Feb 25, 2011 at 5:21 PM, Josh Berkus wrote:
> On 2/25/11 4:57 PM, Jeff Davis wrote:
>> On Fri, 2011-02-25 at 15:44 -0800, Josh Berkus wrote:
>>> Hmmm, I don't follow this. The user can only disable syncrep for their
>>> own transactions. If they don't care about the persistence of their
On Fri, Feb 25, 2011 at 8:40 AM, Greg Smith wrote:
> I didn't get the Streaming Rep + Hot Standby features I wanted in 9.0 either.
> But committing what was reasonable to include in that version let me march
> forward with very useful new code, doing another year of development on my
> own pro
On Wed, Mar 9, 2011 at 6:02 AM, Alvaro Herrera
wrote:
> I'll send you a perl program we wrote for a customer to check for
> strange issues in btrees. Please give it a spin; it may give you more
> clues. If you find additional checks to add, please let me know!
I have also, coincidentally, encou
Hello List,
I have a couple of use cases that are important to me, but my reading
of xlog.c suggests I'm stuck between a rock and a hard place. Or, I am
missing some commonly used pattern -- forgive me in that case. I am
reading 9.0.3 when making these determinations.
Here is the mechanism: I w
On Fri, Mar 25, 2011 at 12:38 AM, Heikki Linnakangas
wrote:
> On 25.03.2011 03:00, Daniel Farina wrote:
>>
>> Here is the mechanism: I want to author a recovery.conf to perform
>> some amount of restore_command or streaming replication based
>> recovery, but I do *
On Fri, Mar 25, 2011 at 1:00 AM, Heikki Linnakangas
wrote:
> 1. The table has been created or truncated in the same transaction
> 2. We are not in a subtransaction (or the table was created and truncated in
> the same subtransaction)
> 3. There are no open portals
> 4. Executing the COPY doesn't n
On Thu, Nov 14, 2013 at 7:25 PM, Peter Geoghegan wrote:
> On Tue, Nov 5, 2013 at 5:30 AM, Sameer Thakur wrote:
>> Hello,
>> Please find attached pg_stat_statements-identification-v9.patch.
>
> I took a quick look. Observations:
>
> + /* Making query ID dependent on PG version */
> + q
On Tue, Dec 10, 2013 at 3:08 PM, Tom Lane wrote:
> So my objection to what Peter is suggesting is not that it's a bad idea
> in isolation, but that I don't see where he's going to stop, short of
> reinventing every query-normalization behavior that exists in the planner.
> If this particular case
On Wed, Mar 31, 2010 at 9:47 AM, Mike Lewis wrote:
> Thanks. Added it.
>
> https://commitfest.postgresql.org/action/patch_view?id=292
I have reviewed this patch; this is my review:
Regression tests pass with assertions enabled.
Performance gains reported by author confirmed.
The existence and
On Wed, May 26, 2010 at 6:02 PM, Tatsuo Ishii wrote:
> I'm thinking about exporting the raw parser and related modules as a C
> library. Though this will not be an immediate benefit of PostgreSQL
> itself, it will be a huge benefit for any PostgreSQL
> applications/middle ware those need to parse
On Fri, Jun 11, 2010 at 10:19 AM, Magnus Hagander wrote:
>>> Especially if someone has a clue how to do it. The last time I fixed
>>> it by runnin repack, but that didn't work this time. I have no clue
>>> why it's asking for a file that doesn't exist.
>> Does the repo run 'update-server-info' i
On Wed, Jul 21, 2010 at 9:22 AM, Robert Haas wrote:
> On the other hand, if you have technical corrections, or if
> you have suggestions on how to do the same things better (rather than
> suggestions on what to do differently), that would be greatly
> appreciated.
Somewhere in that wiki page ther
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
wrote:
> All those issues can be avoided if you only run "git gc" when all the
> working directories are in a clean state, with no staged but uncommitted
> changes or other funny things. I can live with that gun tied to my ankle
> ;-).
Does even
On Sun, Jul 24, 2011 at 11:48 AM, Tom Lane wrote:
> We could perhaps go a bit further and make pqsecure_write responsible
> for the error message in non-SSL mode too, but it looks to me like
> pqSendSome has to have a switch on the errno anyway to decide whether to
> keep trying or not, so moving
Hello list,
At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
recently when frobbing around some indexes I realized that there is no
equivalent for DROP INDEX, and this is a similar but lesser problem
(as CREATE INDEX takes much longer), as DROP INDEX takes an ACCESS
EXCLUSIVE loc
On Wed, Aug 24, 2011 at 12:38 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Aug 24, 2011 at 1:24 PM, Daniel Farina wrote:
>>> At Heroku we use CREATE INDEX CONCURRENTLY with great success, but
>>> recently when frobbing around some indexes I realized that
Hello list,
This is something that I've only recently somewhat pinned down to a cause...
Some Postgres servers will error out for a while with the following
error message:
"expected authentication request from server, but received c"
If one uses Their Favorite Search Engine, this message is sca
On Sat, Aug 27, 2011 at 1:51 PM, Tom Lane wrote:
> A more long-range point about it is that the next time we make a
> protocol version bump that affects the format of error messages,
> the problem comes right back. It'd be better if the message somehow
> indicated that the server hadn't made any
On Sat, Aug 27, 2011 at 3:30 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Sat, Aug 27, 2011 at 1:51 PM, Tom Lane wrote:
>>> A more long-range point about it is that the next time we make a
>>> protocol version bump that affects the format of error messages,
>&
On Wed, Aug 31, 2011 at 11:12 AM, Ross J. Reedstrom wrote:
> Hmm, this thread seems to have petered out without a conclusion. Just
> wanted to comment that there _are_ non-password storage uses for these
> digests: I use them in a context of storing large files in a bytea
> column, as a means to d
On Tue, Sep 6, 2011 at 12:00 PM, Tom Lane wrote:
> [ Sorry for letting this slip through the cracks ... I think I got
> distracted by collation bugs :-( ]
>
> Noah Misch writes:
>> On Sat, Mar 12, 2011 at 12:44:29PM -0500, Tom Lane wrote:
>>> Noah Misch writes:
A suitably-instrumented run
On Thu, Sep 8, 2011 at 1:56 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Tue, Sep 6, 2011 at 12:00 PM, Tom Lane wrote:
>>> I'm still of the opinion that there's no real need to avoid memcpy with
>>> identical source and destination, so I didn't
On Wed, Aug 24, 2011 at 1:04 PM, Daniel Farina wrote:
> On Wed, Aug 24, 2011 at 12:38 PM, Tom Lane wrote:
>> Assuming the issue really is the physical unlinks (which I agree I'd
>> like to see some evidence for), I wonder whether the problem could be
>> addressed by m
On Fri, Sep 23, 2011 at 9:45 AM, Robert Haas wrote:
> On Fri, Sep 23, 2011 at 11:43 AM, Aidan Van Dyk wrote:
>> On Fri, Sep 23, 2011 at 4:41 AM, Heikki Linnakangas
>> wrote:
>>
Unfortunately, it's impossible, because the error message "Could not read
from file "pg_clog/0001" at offset
On Wed, Sep 28, 2011 at 1:02 PM, Kevin Grittner
wrote:
> Alvaro Herrera wrote:
>
>>> ON_ERROR_ROLLBACK ["on" can be a problem in a script file]
>
>> So set it to "interactive".
>
> I think we have an opportunity for a documentation enhancement there.
In the same vein, I think there may also be s
This patch would appear(?) to have languished:
https://commitfest.postgresql.org/action/patch_view?id=541
I'd really like to see it included. In the last comments of the
review, there seem to be problems in *terminate* backend, but even
just pg_cancel_backend as non-superuser would be just a hug
On Fri, Sep 30, 2011 at 9:30 PM, Tom Lane wrote:
> ISTM it would be reasonably non-controversial to allow users to issue
> pg_cancel_backend against other sessions logged in as the same userID.
> The question is whether to go further than that, and if so how much.
In *every* case -- and there are
On Sat, Oct 1, 2011 at 3:47 PM, Kääriäinen Anssi
wrote:
> I would be a step in the right direction if the DB owner would see all queries
> to the DB in pg_stat_activity.
"All," including that of the superuser? I'd like to pass on that one, please.
In general, I feel there is this problem that on
On Mon, Oct 17, 2011 at 11:30 PM, Chris Redekop wrote:
> Well, on the other hand maybe there is something wrong with the data.
> Here's the test/steps I just did -
> 1. I do the pg_basebackup when the master is under load, hot slave now will
> not start up but warm slave will.
> 2. I start a warm
On Wed, Nov 9, 2011 at 12:58 PM, Daniel Farina wrote:
> On Tue, Nov 8, 2011 at 9:06 PM, Magnus Hagander wrote:
>> I definitely think they are important enough to trigger a release. But as
>> you say, I think we need confirmation that they actually fix the problem...
>
> I ha
On Tue, Nov 8, 2011 at 9:06 PM, Magnus Hagander wrote:
> I definitely think they are important enough to trigger a release. But as
> you say, I think we need confirmation that they actually fix the problem...
I have confirmed that the clog/subtrans fixes allow us to start up
while in hot standby
On Wed, Nov 9, 2011 at 2:24 PM, Greg Smith wrote:
> I think Daniel has run into this problem more than anyone else, so hearing
> it's fixed for him makes me feel a lot better that it's been resolved. I'd
> characterize this problem as a medium grade data corruption issue. It's not
> security iss
On Thu, Nov 10, 2011 at 1:19 PM, Dimitri Fontaine
wrote:
> Now the aim would be to be able to implement the operation you describe
> by using the new segment map, which is an index pointing to sequential
> ranges of on-disk blocks where the data is known to share a common key
> range over the colu
On Wed, Nov 9, 2011 at 1:56 AM, Nikhil Sontakke wrote:
> Hi,
>
> Consider the following sequence of events:
>
> s1 #> CREATE SCHEMA test_schema;
>
> s1 #> CREATE TABLE test_schema.c1(x int);
>
> Now open another session s2 and via gdb issue a breakpoint on
> heap_create_with_catalog() which is cal
On Thu, Nov 10, 2011 at 11:57 PM, Nikhil Sontakke wrote:
> Hi,
>
>>
>> But if it's deemed to be a
>> problem, I want to see a solution that's actually watertight.)
>>
>
> After Daniel's hunch about pg_dump barfing due to such leftover entries
> proving out to be true, we have one credible explanat
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
wrote:
> Edward Muller wrote:
>
>> Looking for comments ...
>>
>> https://gist.github.com/be937d3a7a5323c73b6e
>>
>> We'd like to get this, or something like it, into 9.2
On Wed, Nov 16, 2011 at 12:06 PM, Kevin Grittner
wrote:
> Edward Muller wr
On Mon, Nov 14, 2011 at 12:07 PM, Robert Haas wrote:
> On Mon, Nov 14, 2011 at 2:26 PM, Alvaro Herrera
> wrote:
>> Excerpts from Robert Haas's message of lun nov 14 15:56:43 -0300 2011:
>>
>>> Well, it looks to me like there are three different places that we
>>> need to nail down: RangeVarGetAnd
Reviving a thread that has hit its second birthday:
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00024.php
In our case not being able to restart Postgres when it has been taken
down in the middle of a base backup is starting to manifest as a
serious source of downtime: basically, any b
On Thu, Dec 1, 2011 at 3:47 PM, Robert Haas wrote:
> On Tue, Nov 29, 2011 at 9:10 PM, Daniel Farina wrote:
>> Reviving a thread that has hit its second birthday:
>>
>> http://archives.postgresql.org/pgsql-hackers/2009-11/msg00024.php
>>
>> In our case not being
On Tue, Nov 29, 2011 at 12:02 PM, Alexander Shulgin
wrote:
>
> Excerpts from Alexander Shulgin's message of Sat Nov 26 22:07:21 +0200 2011:
>>
>> So how about this:
>>
>> postgresql:ssl://user:pw@host:port/dbname?sslmode=...
>>
>> The "postgresql:ssl://" designator would assume "sslmode=require"
On Fri, Dec 9, 2011 at 3:03 AM, Alexander Shulgin
wrote:
> The JDBC driver is special in that it intentionally does not use libpq.
> Given every other binding (think Ruby, Python, Perl, Tcl, etc.) does use
> libpq, it makes perfect sense to me to make the syntax compatible with JDBC.
I am wit
On Mon, Dec 12, 2011 at 4:51 PM, Peter van Hardenberg wrote:>
> PL/V8 is fast, it's sandboxed, and while it doesn't provide GIN or
> GIST operators out of the box, maybe those could be motivated by its
> inclusion.
I also feel that a big problem with JSON as a data type is that there
is not a pow
On Mon, Dec 12, 2011 at 5:36 PM, Andrew Dunstan wrote:
> The trouble with using JSON.parse() as a validator is that it's probably
> doing way too much work. PLV8 is cool, and I keep trying to get enough time
> to work on it more, but I don't think it's a substitute for a JSON type with
> a purpose
On Tue, Dec 13, 2011 at 1:13 PM, Merlin Moncure wrote:
> On Tue, Dec 13, 2011 at 2:41 PM, Peter Eisentraut wrote:
>> On tis, 2011-12-13 at 08:44 -0500, Robert Haas wrote:
>>> Just because all our languages are Turing-complete doesn't mean they
>>> are all equally well-suited to every task. Of co
On Wed, Dec 21, 2011 at 5:46 AM, Robert Haas wrote:>
> Assuming the command in
> question can be stuffed inside a function, the most you're gaining is
> a little notational convenience
I can answer that one (why a full-blown mechanism for a notational convenience).
It has occurred to me to use t
On Sat, Dec 3, 2011 at 8:04 AM, Heikki Linnakangas
wrote:
> At the moment, if the situation is ambiguous, the system assumes that you're
> restoring from a backup. What your suggestion amounts to is to reverse tht
> assumption, and assume instead that you're doing crash recovery on a system
> wher
On Sun, Jan 1, 2012 at 5:18 AM, Heikki Linnakangas
wrote:
> That's awfully complicated. If we're going to require co-operation from the
> backup/archiving software, we might as well just change the procedure so
> that backup_label is not stored in the data directory, but returned by
> pg_start/sto
On Sun, Jan 1, 2012 at 6:13 AM, Magnus Hagander wrote:
> It also doesn't affect backups taken through pg_basebackup - but I
> guess you have good reasons for not being able to use that?
Parallel archiving/de-archiving and segmentation of the backup into
pieces and rate limiting are the most clear
I'm not sure if this is an XFS problem, or Postgres. There's enough
suspicious evidence that it's too hard to say.
Today, I get an interesting issue raised whereby a reasonably simple
query fails on a system that does take successful pg_dumps regularly.
To make a short story shorter, I end up wit
I've *finally* gotten around to reviewing this patch.
My first step was to de-bitrot it very slightly. More on that in a moment.
After that, I tried using it. Installation worked nicely -- I did
CREATE EXTENSION and then tried reading from pg_stat_statements. I
was then given an error message
I have been working with xlogdump and noticed that unfortunately it
cannot be installed without access to a postgres build directory,
which makes the exported functionality in src/include/utils/pg_crc.h
useless unless one has access to pg_crc.o -- which would only happen
if a build directory is lyi
On Mon, Jan 16, 2012 at 3:53 PM, Tom Lane wrote:
> Well, short of seeing an acceptable patch for the larger thing, I don't
> want to accept a patch to add that field to Const, because I think it's
> a kluge. I'm still feeling that there must be a better way ...
Hm. Maybe it is tractable to to fi
301 - 400 of 434 matches
Mail list logo
