> No, I don't see any particular risk there. The places that might throw
> ERRCODE_INVALID_XML_DOCUMENT are sufficiently few (as in, exactly one,
> in this usage) that we can have reasonable confidence we know what the
> system state is when we catch that error.
>
>
Hmmm, I was writing some code i
se_dontneed on other kernels.
> >
> OK, updated patch attached. sync_file_range() is preferred,
> posix_fadvise() is a fallback.
>
Rebased patch attached. No other changes.
Regards,
Jeff Davis
initdb-fsync-20120612.patch.gz
Description: GNU Zip compressed data
--
Sent via pg
Bruce Momjian writes:
> Stupid question, but why are we not just setting a boolean variable in
> shared memory if we WAL-write a non-XLOG_RUNNING_XACTS record, and only
> checkpoint if that is true?
Well, (1) we are trying to avoid adding such logic to the critical
section inside XLogInsert, and
> Why not 'dblink'?
We can do for dblink as well. I just wanted to check before implementing in
dblink.
I have checked the dblink_connect() function, it receives the connect string
and used in most cases that string to
call libpq connect which is different from pgbench and oid2name where
connect
On Thu, Jun 07, 2012 at 02:52:04PM -0400, Tom Lane wrote:
> > So you can pretty much kiss goodbye to the idea of pg_upgrade.
>
> And that is certainly nonsense. I don't think pg_upgrade even knows
> about this, and if it does we can surely fix it.
pg_upgrade doesn't know anything about xlog file
Does it make sense to have a comment on function's arguments? Of course
it is possible to include these comments in a function's comment, but
may be better to have them in more formalized way like comments on
columns of a table. IDEs may use this information when providing hints
for a function
On Wed, Jun 06, 2012 at 06:46:37PM -0400, Tom Lane wrote:
> I wrote:
> > Actually, it looks like there is an extremely simple way to handle this,
> > which is to move the call of LogStandbySnapshot (which generates the WAL
> > record in question) to before the checkpoint's REDO pointer is set, but
On Tue, 2012-06-12 at 22:06 -0400, Robert Haas wrote:
> > How much of a savings did we get from PD_ALL_VISIBLE when it was added
> > into the page-at-a-time visibility check?
> >
> > >From 608195a3a3656145a7eec7a47d903bc684011d73:
> >
> > "In addition to the visibility map, there's a new PD_ALL_VIS
On Sun, 2012-02-19 at 21:49 +, Simon Riggs wrote:
> On Thu, Feb 16, 2012 at 11:16 AM, Simon Riggs wrote:
>
> > v8 attached
>
> v10 attached.
>
> This patch covers all the valid concerns discussed and has been
> extensively tested.
>
> I expect to commit this in about 24 hours, so last call
On 06/13/2012 01:19 AM, Sachin Srivastava wrote:
On Tue, Jun 12, 2012 at 7:43 PM, Dave Page mailto:dp...@pgadmin.org>> wrote:
On Tue, Jun 12, 2012 at 2:57 PM, Robert Haas mailto:robertmh...@gmail.com>> wrote:
> What we need is to display a different dialogue based on the
situati
On Tue, Jun 12, 2012 at 9:52 PM, Tom Lane wrote:
> The code for this is as attached. Note that I'd rip out the normal-path
> tracking of line boundaries; it seems better to have a second scan of
> the data in the error case and save the cycles in non-error cases.
Really?!
--
Robert Haas
Enterp
On Tue, Jun 12, 2012 at 6:26 PM, Jeff Davis wrote:
> On Tue, 2012-06-12 at 18:02 -0400, Tom Lane wrote:
>> Or (d) it's not a problem, since the inserting XID is still busy
>> according to the readers' snapshots.
>
> How much of a savings did we get from PD_ALL_VISIBLE when it was added
> into the
On Tue, Jun 12, 2012 at 6:02 PM, Tom Lane wrote:
> The part I think is actually hard is how to clean up if the inserting
> xact doesn't reach commit. I think what we're basically looking at here
> is pushing more cost into that path in order to avoid cost in successful
> cases. The first design
I wrote:
> Alvaro Herrera writes:
>> I am not sure about the idea of letting the detail run to the end of the
>> line; that would be problematic should the line be long (there might not
>> be newlines in the literal at all, which is not that unusual). I think
>> it should be truncated at, say, 76
On 06/12/2012 08:08 PM, Dave Page wrote:
Some background: By default the installer will use 'postgres' for both
the service (OS) account, and the database superuser account. It will
use the same password for both (though, users have complete control at
the command line if they want it, which is w
On 06/12/2012 08:48 PM, Dave Page wrote:
I'm not keen on adding additional user accounts - that's a security
problem imho.
It's also an issue for add-ons like PgAgent that aren't necessarily tied
to one exact version of Pg.
That makes sense. I just think we should try very hard to make the
ins
hackers,
A while back I made an effort implementing a backend local hint bit
cache with the intention of mitigating i/o impact for scan heavy
workloads that involve moving a lot of records around per transaction.
The basic concept was to keep some backend private memory that
tracked the resolutio
On Tue, 2012-06-12 at 18:02 -0400, Tom Lane wrote:
> Or (d) it's not a problem, since the inserting XID is still busy
> according to the readers' snapshots.
How much of a savings did we get from PD_ALL_VISIBLE when it was added
into the page-at-a-time visibility check?
>From 608195a3a3656145a7eec
"Kevin Grittner" writes:
> "Kevin Grittner" wrote:
>> I'm working on getting all of our triggers to behave with Tom's v8
>> patch for bug 6123 and hope to be able to post a positive result
>> tomorrow. I think this is considered a bug and still subject to
>> inclusion, but it doesn't really caus
On Tue, 2012-06-12 at 17:53 -0400, Bruce Momjian wrote:
> Well, truncating tables that were empty on the load would certainly be
> a easy to do --- not sure if that helps us, though.
This goes back to the single-loader-into-an-empty-table case, which I'd
like to get away from. I think we already h
Jeff Davis writes:
> In those terms, we can reframe the questions as: what do we do about
> reads during the load?
> Answers could include:
> (a) nothing -- reads during a load are potentially dirty
> (b) readers ignore hint bits during the load, and pay the penalty
> (c) allow only INSERT/
On Tue, Jun 12, 2012 at 05:48:58PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Jun 06, 2012 at 10:38:42AM -0400, Tom Lane wrote:
> >> We already support multiple TCP sockets, so multiple Unix sockets
> >> shouldn't be that much extra trouble.
>
> > We do? I didn't think listening
On Tue, 2012-06-12 at 13:10 -0400, Robert Haas wrote:
> I don't think it's going to solve the problem in general, but TBH I
> don't think Jeff's proposal is, either. I mean, ignoring
> xmin-committed, xmax-committed, and all-visible bits is going to come
> with a pretty steep performance penalty a
On Tue, Jun 12, 2012 at 01:31:05PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > I don't think it's going to solve the problem in general, but TBH I
> > don't think Jeff's proposal is, either. I mean, ignoring
> > xmin-committed, xmax-committed, and all-visible bits is going to come
> > with a
On Tue, 2012-06-12 at 13:31 -0400, Tom Lane wrote:
> Yeah; the notion of adding cycles to the visibility-check code paths,
> which would add cost even for users who have no use at all for this
> feature, is close to being a deal-breaker for me. I would rather see
> us designing this around the ide
Bruce Momjian writes:
> On Wed, Jun 06, 2012 at 10:38:42AM -0400, Tom Lane wrote:
>> We already support multiple TCP sockets, so multiple Unix sockets
>> shouldn't be that much extra trouble.
> We do? I didn't think listening on multiple interfaces meant we
> listened on multiple sockets. Is th
"Kevin Grittner" wrote:
> I'm working on getting all of our triggers to behave with Tom's v8
> patch for bug 6123 and hope to be able to post a positive result
> tomorrow. I think this is considered a bug and still subject to
> inclusion, but it doesn't really cause my shop any pain if it is
>
On Tue, 2012-06-12 at 08:42 -0400, Robert Haas wrote:
> Instead of trying to maintain MVCC semantics, maybe we should just
> have something like COPY (FROZEN) that just writes frozen tuples into
> the table and throws MVCC out the window. Seems like that would be a
> lot easier to implement and sa
On Wed, Jun 06, 2012 at 10:38:42AM -0400, Tom Lane wrote:
> Florian Pflug writes:
> > Couldn't you simply tell postgres to put it's socket in, say, /var/run, and
> > create a symlink to that socket in the global /tmp directory?
>
> FYI, this proposal emerged out of a discussion between Honza and
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> (In other words, it's not that hard to build
>> a "RUN AS other-user" feature into a C function, even without any support
>> from the rest of the system.)
> I was considering this and a bit concerned about what would happen if
> th
Tom Lane wrote:
> I'm not entirely following here. If the function is coded in C,
> then it can pretty much do what it pleases independently of what
> user ID is thought to be executing it at the SQL level. That
> would really only matter if you were doing some SQL stuff via the
> SPI interfac
Alvaro Herrera writes:
> I am not sure about the idea of letting the detail run to the end of the
> line; that would be problematic should the line be long (there might not
> be newlines in the literal at all, which is not that unusual). I think
> it should be truncated at, say, 76 chars or so.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> (In other words, it's not that hard to build
> a "RUN AS other-user" feature into a C function, even without any support
> from the rest of the system.)
I was considering this and a bit concerned about what would happen if
the C function actually did this a
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm not exactly sure who should be allowed to
> apply the "RUN AS other-user" option to a function, but I can see the
> possible value of separating the right to modify the function's
> definition from the user the function runs as.
When it comes to '
Excerpts from Kevin Grittner's message of mar jun 12 17:08:09 -0400 2012:
> >Stephen Frost wrote:
>
> > If we had an independent way to have the function run as a
> > specific user, where that user DIDN'T own the function, I think
> > Kevin's use case would be satisfied.
>
> I agree. I'm no
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Could you provide more details about that?
> We have a capture_replication_data() trigger function that we attach
> to each table which is to be replicated as the first AFTER EACH ROW
> trigger for INSERT OR UPDATE OR DELETE. It records the data
>
Excerpts from Tom Lane's message of mar jun 12 16:52:20 -0400 2012:
> Robert Haas writes:
> >> I notice that there's an unfinished attempt to maintain a line_start
> >> pointer; if that were carried through, we could imagine printing the
> >> current line up to the point of an error, which might
>Stephen Frost wrote:
> If we had an independent way to have the function run as a
> specific user, where that user DIDN'T own the function, I think
> Kevin's use case would be satisfied.
I agree. I'm not sure quite what that would look like, but maybe
SECURITY ROLE or some such could be an
Stephen Frost writes:
> What I believe Kevin is getting at here is this:
> There's no way to say "run this function as user X" except by making it
> SECURITY DEFINER and owned by the user you want the function to run as.
> If we had an independent way to have the function run as a specific
> use
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "Kevin Grittner" writes:
> > It's not too hard
> > to come up with other use cases where you want to grant one class of
> > users rights to do something only through a certain function, not
> > directly.
>
> Generally I'd imagine that that has something to
Tom Lane wrote:
> "Kevin Grittner" writes:
>> We have C replication trigger functions where this would be a bad
>> thing. They can't work properly as SECURITY INVOKER, and I see
>> it as a big step backwards in security to make the only other
>> option SECURITY DEFINER with a superuser as the
Robert Haas writes:
> On Tue, Jun 12, 2012 at 2:40 PM, Tom Lane wrote:
>> I'm not thrilled with the "line %d:" prefixes. That seems to me to
>> violate the letter and spirit of the guideline about making errdetail
>> messages be complete sentences. Furthermore, the line number is not
>> the mos
"Kevin Grittner" writes:
> Tom Lane wrote:
>> A less bizarre and considerably more future-proof restriction,
>> IMO, would simply refuse any attempt to give ownership of a C
>> function to a non-superuser.
> We have C replication trigger functions where this would be a bad
> thing. They can't
Tom Lane wrote:
> A less bizarre and considerably more future-proof restriction,
> IMO, would simply refuse any attempt to give ownership of a C
> function to a non-superuser.
We have C replication trigger functions where this would be a bad
thing. They can't work properly as SECURITY INVOKER
On 12.6.2012 21:33, David Johnston wrote:
On Jun 12, 2012, at 15:21, Dusan Misic wrote:
Is this normal Postgres / psql behavior?
griffindb=# \d system.user;
Table "system.user"
Column | Type | Modifiers
---+
On Jun 12, 2012, at 15:21, Dusan Misic wrote:
> Is this normal Postgres / psql behavior?
>
> griffindb=# \d system.user;
> Table "system.user"
> Column | Type | Modifiers
>
> ---+---+-
On Tue, Jun 12, 2012 at 9:21 PM, Dusan Misic wrote:
> Is this normal Postgres / psql behavior?
>
> griffindb=# \d system.user;
> Table "system.user"
> Column | Type | Modifiers
>
> ---+---+--
Is this normal Postgres / psql behavior?
griffindb=# \d system.user;
Table "system.user"
Column | Type | Modifiers
---+---+
username | char
Robert Haas writes:
> On Tue, Jun 12, 2012 at 11:31 AM, Noah Misch wrote:
>>> This seems bizarre and largely unnecessary. As you stated to begin
>>> with, granting ownership of a function implies some degree of trust.
>> Yes, but I would never expect that level of trust to include access to cra
On Tue, Jun 12, 2012 at 11:31 AM, Noah Misch wrote:
>> > Here's a patch implementing that restriction. To clarify, I see no need to
>> > repeat *all* the CREATE-time checks; for example, there's no need to
>> > recheck
>> > permission to use the return type. The language usage check is enough.
On Tue, Jun 12, 2012 at 2:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> Mark JSON error detail messages for translation.
>> Per gripe from Tom Lane.
>
> OK, that was one generically bad thing about json.c's error messages.
> The other thing that was bothering me was the style of the errdetail
>
On Mon, Jun 11, 2012 at 5:30 AM, Amit Kapila wrote:
> As per the previous discussion in link below, it seems that fallback
> application name needs to be provided for only
>
> pgbench and oid2name.
>
> http://archives.postgresql.org/message-id/w2g9837222c1004070216u3bc46b3ahbddfdffdbfb46...@mail.g
Robert Haas writes:
> Mark JSON error detail messages for translation.
> Per gripe from Tom Lane.
OK, that was one generically bad thing about json.c's error messages.
The other thing that was bothering me was the style of the errdetail
strings, eg
ereport(ERROR,
On Tue, Jun 12, 2012 at 2:02 PM, Bruce Momjian wrote:
> On Tue, Jun 12, 2012 at 01:50:48PM -0400, Noah Misch wrote:
>> On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote:
>> > What about something like this in the root of the tree:
>> > find . -name \*.pl -o -name \*.pm | xargs perltid
On Tue, Jun 12, 2012 at 1:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane wrote:
>>> I still think it's sufficient to do what I suggested initially:
... The simplest, least risky change that I can think of is to
copy-and-paste the relevant #if
On Wed, Jun 6, 2012 at 8:42 PM, Jeff Davis wrote:
> On Wed, 2012-06-06 at 15:08 -0400, Robert Haas wrote:
>> On Mon, Jun 4, 2012 at 9:26 PM, Jeff Davis wrote:
>> > Thoughts?
>>
>> Simon already proposed a way of doing this that doesn't require
>> explicit user action, which seems preferable to a
On Tue, Jun 12, 2012 at 01:50:48PM -0400, Noah Misch wrote:
> On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote:
> > What about something like this in the root of the tree:
> > find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws
> > -l=100 -ole=unix
> >
> > There ar
On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote:
> What about something like this in the root of the tree:
> find . -name \*.pl -o -name \*.pm | xargs perltidy -b -bl -nsfs -naws -l=100
> -ole=unix
>
> There are files all over the place. The file that would most be
> affected with
On Tue, Jun 12, 2012 at 6:28 AM, Peter Eisentraut wrote:
> On sön, 2012-06-10 at 13:43 +0200, Magnus Hagander wrote:
>> On Mon, Jun 4, 2012 at 2:14 PM, Peter Eisentraut wrote:
>> > On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
>> >> Yeah, good arguments all around, i agree too :-) Nex
Robert Haas writes:
> I don't think it's going to solve the problem in general, but TBH I
> don't think Jeff's proposal is, either. I mean, ignoring
> xmin-committed, xmax-committed, and all-visible bits is going to come
> with a pretty steep performance penalty all of its own. I don't doubt
> t
On Tue, Jun 12, 2012 at 7:43 PM, Dave Page wrote:
> On Tue, Jun 12, 2012 at 2:57 PM, Robert Haas
> wrote:
> > On Tue, Jun 12, 2012 at 8:53 AM, Dave Page wrote:
> >>> Oh, I certainly wouldn't do it without *informing* and verifying it
> >>> with the user.
> >>
> >> That'll add additional steps f
On Tue, Jun 12, 2012 at 12:41 PM, Merlin Moncure wrote:
>>> -1: The situation with hint bit i/o patterns on many workloads is
>>> untenable but it's not safe to assume MVCC can be ditched in those
>>> workloads. Also, COPY does nothing about deletes. Neither does the
>>> proposal as stated but I
Robert Haas writes:
> On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane wrote:
>> I still think it's sufficient to do what I suggested initially:
>>> ... The simplest, least risky change that I can think of is to
>>> copy-and-paste the relevant #ifdef code block in fork_process.c.
> I think my position
On Tue, Jun 12, 2012 at 5:41 PM, Merlin Moncure wrote:
> Also it's not safe to assume that insertion heavy clients
> can be migrated to COPY. For example, JDBC bulk loading AFAIK does
> not use COPY and even if it did wouldn't be able to decorate the
> command for a long time for most production
On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane wrote:
> I was reminded today that we still haven't done anything about this:
>
> Tom Lane writes:
>> While testing 9.1 RPMs on Fedora 15 (2.6.40 kernel), I notice
>> messages like these in the kernel log:
>> Sep 11 13:38:56 rhl kernel: [ 415.308092] po
On Tue, Jun 12, 2012 at 11:12 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Tue, Jun 12, 2012 at 7:42 AM, Robert Haas wrote:
>>> Instead of trying to maintain MVCC semantics, maybe we should just
>>> have something like COPY (FROZEN) that just writes frozen tuples into
>>> the table and thr
I was reminded today that we still haven't done anything about this:
Tom Lane writes:
> While testing 9.1 RPMs on Fedora 15 (2.6.40 kernel), I notice
> messages like these in the kernel log:
> Sep 11 13:38:56 rhl kernel: [ 415.308092] postgres (18040):
> /proc/18040/oom_adj is deprecated, pleas
Tom Lane wrote:
> I think Robert's idea has a fair amount of merit: mainly because
> it will probably satisfy 90% of use cases for 1% of the work.
+1, especially if we include a pg_dump option to write the COPY
statements with that option.
-Kevin
--
Sent via pgsql-hackers mailing list (pgs
Nikhil Sontakke writes:
> Consider:
> SELECT xml 'barfoo' IS DOCUMENT;
> And I was looking at xml_is_document() source code. It calls xml_parse
> which throws an error with code set to ERRCODE_INVALID_XML_DOCUMENT. The
> catch block of xml_parse then rethrows.
> Now xml_is_document does a selec
Merlin Moncure writes:
> On Tue, Jun 12, 2012 at 7:42 AM, Robert Haas wrote:
>> Instead of trying to maintain MVCC semantics, maybe we should just
>> have something like COPY (FROZEN) that just writes frozen tuples into
>> the table and throws MVCC out the window. Seems like that would be a
>> l
On Tue, Jun 12, 2012 at 7:42 AM, Robert Haas wrote:
> On Mon, Jun 11, 2012 at 2:16 AM, Jeff Davis wrote:
>> On Wed, 2012-06-06 at 22:16 -0400, Noah Misch wrote:
>>> Note that, currently, only VACUUM sets PD_ALL_VISIBLE and visibility map
>>> bits.
>>> Would you make something else like heap_mult
Folks,
Per discussion at the PGCon developers meeting, everyone who submitted
patches to the upcoming CommitFest should also sign up to review an
equal number of patches (of roughly comparable complexity). Of
course, we also need people who haven't submitted anything to
volunteer to review patche
> But if we believe we've taken care of all known open issues fairly
> soon, getting an RC out rather than a beta before people go on
> vacation would probably be a good thing...
Yeah, that's the other reason I'm not so wild about a June release; I
have a whole list of tests I want to do against
On Mon, Jun 11, 2012 at 11:03:10PM -0400, Tom Lane wrote:
> Noah Misch writes:
> >> CREATE FUNCTION + ALTER FUNCTION OWNER TO is useful for creating another
> >> user's untrusted-language SECURITY DEFINER function. ALTER FUNCTION
> >> CALLED ON
> >> NULL INPUT ought to require that the user be e
On Mon, Jun 11, 2012 at 05:57:41PM -0400, Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of lun jun 11 15:44:16 -0400 2012:
> >
> > On Mon, Jun 11, 2012 at 12:20:13PM -0400, Alvaro Herrera wrote:
> > > > > Hm, does this touch stuff that would also be modified by perltidy? I
> >
On Tue, Jun 12, 2012 at 4:08 PM, Tom Lane wrote:
> Simon Riggs writes:
>> Let me put it this way: is there a benefit to changing the plan?
>
> The plan is, and always has been, "we'll release when it's ready".
> We generally suppose that a release is ready when the rate of bug
> reports against t
On Tue, Jun 12, 2012 at 2:57 PM, Robert Haas wrote:
> On Tue, Jun 12, 2012 at 8:53 AM, Dave Page wrote:
>>> Oh, I certainly wouldn't do it without *informing* and verifying it
>>> with the user.
>>
>> That'll add additional steps for all users, and likely confuse the
>> novices even more.
>
> The
Simon Riggs writes:
> Let me put it this way: is there a benefit to changing the plan?
The plan is, and always has been, "we'll release when it's ready".
We generally suppose that a release is ready when the rate of bug
reports against the beta has dropped off substantially. It's certainly
absur
On Tue, Jun 12, 2012 at 8:53 AM, Dave Page wrote:
>> Oh, I certainly wouldn't do it without *informing* and verifying it
>> with the user.
>
> That'll add additional steps for all users, and likely confuse the
> novices even more.
The real issue here is that it's nuts to tell the user "please ent
Tom Lane writes:
> I am pleased to announce that Kevin Grittner has accepted the core
> committee's invitation to become our newest committer.
I'm hesitant whether to congratulate more the community for gaining
Kevin or Kevin for joining as a commiter :) In short, +1 !
Regards,
--
Dimitri Fonta
On Tue, Jun 12, 2012 at 1:49 PM, Magnus Hagander wrote:
>
>>
>> I'm not keen on adding additional user accounts - that's a security
>> problem imho. It'll leave the unaware user with multiple accounts on
>> the system, and may cause those that do understand what's going on
>> pain because they'll
On Mon, Jun 11, 2012 at 1:02 PM, Joshua Berkus wrote:
> If we decide to do June, then PR will be minimal because I was assuming I had
> another 7 weeks to prepare it. Not that that should be the deciding factor
> (it would be great to get out an early release and get it out of the way) but
> i
On Tue, Jun 12, 2012 at 2:48 PM, Dave Page wrote:
> On Tue, Jun 12, 2012 at 1:35 PM, Kevin Grittner
> wrote:
>> Magnus Hagander wrote:
>>> Kevin Grittner wrote:
>>
Are they running the installation as a system administrator? If
so, rather than throwing up an error message and telling
On Tue, Jun 12, 2012 at 1:35 PM, Kevin Grittner
wrote:
> Magnus Hagander wrote:
>> Kevin Grittner wrote:
>
>>> Are they running the installation as a system administrator? If
>>> so, rather than throwing up an error message and telling them to
>>> go use other tools to reset the password, is it
On 06/11/2012 11:47 PM, Peter Eisentraut wrote:
On sön, 2012-06-10 at 17:24 -0400, Robert Haas wrote:
and also affects the naming of any UNIX sockets created.
Why would that matter? If you configure M ports and N Unix socket
locations, you get M*N actual sockets created.
...I *seriously* do
On Mon, Jun 11, 2012 at 2:16 AM, Jeff Davis wrote:
> On Wed, 2012-06-06 at 22:16 -0400, Noah Misch wrote:
>> Note that, currently, only VACUUM sets PD_ALL_VISIBLE and visibility map
>> bits.
>> Would you make something else like heap_multi_insert() be able to do so?
>
> That was the plan (roughly
On Tue, Jun 12, 2012 at 09:38:54AM +0100, Simon Riggs wrote:
> On 11 June 2012 18:02, Joshua Berkus wrote:
>
> > Hmmm. I was assuming September, given how late the beta came out,
> > and that nobody has previously talked seriously about a June
> > release. I'll also point out that while there's
Magnus Hagander wrote:
> Kevin Grittner wrote:
>> Are they running the installation as a system administrator? If
>> so, rather than throwing up an error message and telling them to
>> go use other tools to reset the password, is it possible for the
>> administrator account to force a password
On Tue, Jun 12, 2012 at 2:26 PM, Kevin Grittner
wrote:
> Dave Page wrote:
>
>> Probably the most common issue we see from Windows users of
>> PostgreSQL is confusion over the passwords the installer asks for
>> during installation and upgrade.
>
> Yeah, I think so.
>
>> Attached are some screensh
Dave Page wrote:
> Probably the most common issue we see from Windows users of
> PostgreSQL is confusion over the passwords the installer asks for
> during installation and upgrade.
Yeah, I think so.
> Attached are some screenshots of the current installation and
> upgrade steps in question,
Hello, Thank you to head me the previous discussion. I'll
consider them from now.
> > I want the standby to start to serve as soon as possible even by
> > a few seconds on failover in a HA cluster.
>
> Please implement a prototype and measure how many seconds we
> are discussing.
I'm sorry to ha
Hi,
Consider:
SELECT xml 'barfoo' IS DOCUMENT;
And I was looking at xml_is_document() source code. It calls xml_parse
which throws an error with code set to ERRCODE_INVALID_XML_DOCUMENT. The
catch block of xml_parse then rethrows.
Now xml_is_document does a selective rethrow only if the error i
On 11 June 2012 22:40, Magnus Hagander wrote:
> On Mon, Jun 11, 2012 at 11:28 PM, Peter Eisentraut wrote:
>> On sön, 2012-06-10 at 13:43 +0200, Magnus Hagander wrote:
>>> On Mon, Jun 4, 2012 at 2:14 PM, Peter Eisentraut wrote:
>>> > On tis, 2012-05-29 at 22:31 +0200, Magnus Hagander wrote:
>>> >
On 12 June 2012 03:38, Kyotaro HORIGUCHI
wrote:
> Hello, sorry for vague understanding.
>
>> > I depend on this and suppose we can omit it if latest checkpoint
>> > has been taken so as to be able to do crash recovery thereafter.
>>
>> I don't see any reason to special case this. If a checkpoint h
On 11 June 2012 18:02, Joshua Berkus wrote:
> Hmmm. I was assuming September, given how late the beta came out, and that
> nobody has previously talked seriously about a June release. I'll also point
> out that while there's a beta2 tarball, there was no announcement and no
> packages for it
95 matches
Mail list logo
