Ants,
the more I think about this, the more I start to like it.
On 06/07/2013 02:50 PM, Ants Aasma wrote:
> On Fri, Jun 7, 2013 at 2:59 PM, Markus Wanner wrote:
>> Agreed. Postgres-R uses a CommitOrderId, which is very similar in
>> concept, for example.
>
> Do you think having this snapshot sc
On 11 June 2013 01:45, Tatsuo Ishii wrote:
>> On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs wrote:
>>
>>> On 7 June 2013 20:23, Tom Lane wrote:
>>>
>>> > As for other databases, I suspect that ones that have parallel execution
>>> > are probably doing it with a thread model not a process model.
>>
On 06/11/2013 06:17 AM, Pavel Stehule wrote:
> 2013/6/10 Hannu Krosing :
>> On 06/10/2013 09:45 PM, Pavel Stehule wrote:
>>> 2013/6/10 David Fetter :
On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
> 2013/6/10 Hannu Krosing :
>> Hallo Everybody
>>
>> As far as I
> Recently we got a complain about server side large object function
> names described in the doc:
> http://www.postgresql.org/message-id/51b2413f.8010...@gmail.com
>
> In the doc:
> http://www.postgresql.org/docs/9.3/static/lo-funcs.html
>
> "There are server-side functions callable from SQL tha
> I was able to get a hold of someone over at rackspace and bring the box
> back up on an older kernel. Looks like this ancient DL585 doesn't
> particularly like the new 3.2 kernels.
>
> Everything should be back up in a few more minutes. We're checking to
> see if there are any firmware updates
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> Stephen Frost writes:
> > While having one place to put everything sounds great, it doesn't do a
> > whole lot of good if you consider conflicts- either because you want
> > multiple versions available or because there just happens to be some
>
* Tatsuo Ishii (is...@postgresql.org) wrote:
> >> dekendi (the server hosting gitmaster) is currently offline. We're
> >> aware and are working on it.
> >>
> > You can still fetch the latest code from github if you cannot wait:
> > https://github.com/postgres/postgres
>
> Thanks but I need to com
>> dekendi (the server hosting gitmaster) is currently offline. We're
>> aware and are working on it.
>>
> You can still fetch the latest code from github if you cannot wait:
> https://github.com/postgres/postgres
Thanks but I need to commit/push something.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Eng
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2013/6/10 Stephen Frost :
> > What are the different concepts..? We already have set returning
> > functions, why would set returning anonymous functions be any different?
>
> 1. DO as function
> 2. DO as batch
We already have set return
On Tue, Jun 11, 2013 at 1:29 PM, Stephen Frost wrote:
> * Tatsuo Ishii (is...@postgresql.org) wrote:
> > $ git pull
> > ssh: connect to host gitmaster.postgresql.org port 22: Connection timed
> out
> > fatal: The remote end hung up unexpectedly
>
> dekendi (the server hosting gitmaster) is curren
* Tatsuo Ishii (is...@postgresql.org) wrote:
> $ git pull
> ssh: connect to host gitmaster.postgresql.org port 22: Connection timed out
> fatal: The remote end hung up unexpectedly
dekendi (the server hosting gitmaster) is currently offline. We're
aware and are working on it.
Thanks,
2013/6/10 Hannu Krosing :
> On 06/10/2013 09:45 PM, Pavel Stehule wrote:
>> 2013/6/10 David Fetter :
>>> On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
2013/6/10 Hannu Krosing :
> Hallo Everybody
>
> As far as I can see, currently you can not return
> anything o
On Mon, Jun 10, 2013 at 09:05:40AM +0100, Simon Riggs wrote:
> Your earlier comments argue that it is OK to make an early check. The
> above seems to argue the opposite, not sure.
I'll attempt to summarize. If we execute a traditional error-throwing FK
check any earlier than we execute it today,
$ git pull
ssh: connect to host gitmaster.postgresql.org port 22: Connection timed out
fatal: The remote end hung up unexpectedly
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hack
2013/6/10 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> not too much. Two different concepts in one statement is not good
>> idea.
>
> What are the different concepts..? We already have set returning
> functions, why would set returning anonymous functions be any different?
On Mon, Jun 10, 2013 at 11:20:13AM -0400, Andrew Dunstan wrote:
>
> On 06/10/2013 10:18 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> After thinking about this some more I have come to the conclusion that
>>> we should only do any de-escaping of \u sequences, whether or not
>>> they are fo
On Sun, Jun 09, 2013 at 11:39:18AM -0400, Tom Lane wrote:
> The key point for me is that if tolower() actually does anything in the
> previous state of the code, it's more than likely going to produce
> invalidly encoded data. The consequences of that can't be good.
> You can argue that there migh
> Not a bad idea. One that supports rsync and another that supports
> robocopy. That should cover every platform we support.
Example script:
=
#!/usr/bin/env bash
# Simple script to copy WAL archives from one server to another
# to be called as archive_command (call
On Tue, Jun 11, 2013 at 9:45 AM, Tatsuo Ishii wrote:
> > On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs
> wrote:
> >
> >> On 7 June 2013 20:23, Tom Lane wrote:
> >>
> >> > As for other databases, I suspect that ones that have parallel
> execution
> >> > are probably doing it with a thread model no
> On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs wrote:
>
>> On 7 June 2013 20:23, Tom Lane wrote:
>>
>> > As for other databases, I suspect that ones that have parallel execution
>> > are probably doing it with a thread model not a process model.
>>
>> Separate processes are more common because it
On Sat, Jun 8, 2013 at 5:04 AM, Simon Riggs wrote:
> On 7 June 2013 20:23, Tom Lane wrote:
>
> > As for other databases, I suspect that ones that have parallel execution
> > are probably doing it with a thread model not a process model.
>
> Separate processes are more common because it covers th
On Mon, Jun 10, 2013 at 11:06 PM, Dimitri Fontaine
wrote:
> Andres Freund writes:
> > I haven't looked at the patch in detail, but I am very, very much in
> > favor of the feature in general… I have wished for this more than once,
>
> +1
>
+1. It will be useful.
--
Michael
Sorry for my late reply.
On Sun, Jun 9, 2013 at 6:45 PM, Dean Rasheed wrote:
> I called it updatable rather than "writable" or "read-only" because it
> might perhaps be extended in the future with separate options for
> "insertable" and "deletable". It could also be extended to give
> column-leve
On 06/10/2013 04:42 PM, Josh Berkus wrote:
Actually we describe what archive_command needs to fulfill, and tell them
to use something that accomplishes that. The example with cp is explicitly
given as an example, not a recommendation.
If we offer cp as an example, we *are* recommending it.
On Mon, Jun 10, 2013 at 4:42 PM, Josh Berkus wrote:
> Daniel, Jeff,
>
>> I don't doubt this, that's why I do have a no-op fallback for
>> emergencies. The discussion was about defaults. I still think that
>> drop-wal-from-archiving-whenever is not a good one.
>
> Yeah, we can argue defaults for
Daniel, Jeff,
> I don't doubt this, that's why I do have a no-op fallback for
> emergencies. The discussion was about defaults. I still think that
> drop-wal-from-archiving-whenever is not a good one.
Yeah, we can argue defaults for a long time. What would be better is
some way to actually det
On Mon, Jun 10, 2013 at 11:59 AM, Josh Berkus wrote:
> Anyway, what I'm pointing out is that this is a business decision, and
> there is no way that we can make a decision for the users what to do
> when we run out of WAL space. And that the "stop archiving" option
> needs to be there for users,
On Sat, Jun 8, 2013 at 11:07 AM, Joshua D. Drake wrote:
>
> On 06/08/2013 07:36 AM, MauMau wrote:
>
> 1. If the machine or postgres crashes while archive_command is copying a
>> WAL file, later archive recovery fails.
>> This is because cp leaves a file of less than 16MB in archive area, and
>> p
On 06/10/2013 06:07 PM, Robert Haas wrote:
On Mon, Jun 10, 2013 at 10:18 AM, Tom Lane wrote:
Well, if we have to break backwards compatibility when we try to do
binary storage, we're not going to be happy either. So I think we'd
better have a plan in mind for what will happen then.
Who says
On 06/11/2013 12:07 AM, Robert Haas wrote:
> On Mon, Jun 10, 2013 at 10:18 AM, Tom Lane wrote:
>> Well, if we have to break backwards compatibility when we try to do
>> binary storage, we're not going to be happy either. So I think we'd
>> better have a plan in mind for what will happen then.
> W
On Mon, Jun 10, 2013 at 4:48 PM, Simon Riggs wrote:
> Well done, looks like good progress.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Mon, Jun 10, 2013 at 10:18 AM, Tom Lane wrote:
> Well, if we have to break backwards compatibility when we try to do
> binary storage, we're not going to be happy either. So I think we'd
> better have a plan in mind for what will happen then.
Who says we're ever going to do any such thing? T
Here is submission v9 based on your v8 version.
- the tps is global, with a mutex to share the global stochastic process
- there is an adaptation for the "fork" emulation
- I do not know wheter this works with Win32 pthread stuff.
- reduced multiplier ln(100) -> ln(1000)
- avg & max thr
On Sun, Jun 9, 2013 at 8:16 PM, Tatsuo Ishii wrote:
> Recently we got a complain about server side large object function
> names described in the doc:
> http://www.postgresql.org/message-id/51b2413f.8010...@gmail.com
>
> In the doc:
> http://www.postgresql.org/docs/9.3/static/lo-funcs.html
>
> "Th
On Sat, Jun 8, 2013 at 5:00 PM, Simon Riggs wrote:
> While fiddling with FK tuning, Noah suggested batching trigger
> executions together to avoid execution overhead.
>
> It turns out there is no easy way to write triggers that can take
> advantage of the knowledge that they are being executed as
On Sat, Jun 8, 2013 at 10:00 PM, Greg Smith wrote:
>> But I have neither any firsthand experience nor any
>> empirical reason to presume that the write limit needs to be lower
>> when the read-rate is high.
>
> No argument from me that that this is an uncommon issue. Before getting
> into an exam
On 6/7/13 12:57 PM, Tom Lane wrote:
> Hm. Throwing a NOTICE saying "btw, this won't be of any value until the
> user has CREATE rights in that schema" might be a reasonable compromise.
Seems like a can of worms to me. There are many other cases where you
need to do something else in order to mak
On 6/9/13 7:39 PM, Robins Tharakan wrote:
> F202TRUNCATE TABLE: identity column restart option NO
We don't support identity columns.
> F263Comma-separated predicates in simple CASE expressionNO
We don't support that.
> T041Basic LOB data type support 01 BLO
Hi,
> >> I asked a while ago in this group about the possibility to implement a
> >> parallel planner in a multithread way, and the replies were that the
> >> proposed approach couldn't be implemented, because the postgres is not
> >> thread-safe. With the new feature Background Worker Processes
On 10 June 2013 19:58, Heikki Linnakangas wrote:
> On 01.06.2013 23:21, Robert Haas wrote:
>>
>> On Sat, Jun 1, 2013 at 2:48 PM, Heikki Linnakangas
>> wrote:
We define a new page-level bit, something like PD_RECENTLY_FROZEN.
When this bit is set, it means there are no unfrozen tup
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> not too much. Two different concepts in one statement is not good
> idea.
What are the different concepts..? We already have set returning
functions, why would set returning anonymous functions be any different?
> What using a cursors as tempora
On 06/10/2013 09:45 PM, Pavel Stehule wrote:
> 2013/6/10 David Fetter :
>> On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
>>> 2013/6/10 Hannu Krosing :
Hallo Everybody
As far as I can see, currently you can not return
anything out of a DO (anonymous code) block.
On 06/10/2013 09:34 PM, David Fetter wrote:
> If I understand the proposal correctly, the idea is only to try to
> return something when DO is invoked with RETURNING.
>
> 1. Did I understand correctly, Hannu?
Yes.
Of course we could default it to "RETURNS SETOF RECORD" :)
> 2. If I did, does thi
On 10 June 2013 11:51, KONDO Mitsumasa wrote:
> I create patch which is improvement of checkpoint IO scheduler for stable
> transaction responses.
Looks like good results, with good measurements. Should be an
interesting discussion.
--
Simon Riggs http://www.2ndQuadrant.com/
On 10 June 2013 00:39, Robins Tharakan wrote:
> While reviewing sql_features.txt, found a few items marked NO ('Not
> supported') whereas, at the outset, they seemed to be supported. Apologies,
> if this is already considered and / or still marked 'NO' for a reason, but a
> list of such items men
2013/6/10 David Fetter :
> On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
>> 2013/6/10 Hannu Krosing :
>> > Hallo Everybody
>> >
>> > As far as I can see, currently you can not return
>> > anything out of a DO (anonymous code) block.
>> >
>> > Something like
>> >
>> > DO LANGUAGE pl
On Mon, Jun 10, 2013 at 09:23:19PM +0200, Pavel Stehule wrote:
> 2013/6/10 Hannu Krosing :
> > Hallo Everybody
> >
> > As far as I can see, currently you can not return
> > anything out of a DO (anonymous code) block.
> >
> > Something like
> >
> > DO LANGUAGE plpythonu RETURNS TABLE (name text, ui
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2013/6/10 Hannu Krosing :
> > If there was then what were the arguments against doing this ?
I don't recall offhand, but it would be *extremely* useful to have.
> > Or was this just that it was not thought important at that time ?
For my part, w
2013/6/10 Hannu Krosing :
> Hallo Everybody
>
> As far as I can see, currently you can not return
> anything out of a DO (anonymous code) block.
>
> Something like
>
> DO LANGUAGE plpythonu RETURNS TABLE (name text, uid int, gid int) $$
> with open('/etc/passwd') as f:
> fields = f.readline().s
Hallo Everybody
As far as I can see, currently you can not return
anything out of a DO (anonymous code) block.
Something like
DO LANGUAGE plpythonu RETURNS TABLE (name text, uid int, gid int) $$
with open('/etc/passwd') as f:
fields = f.readline().split(':')
while fields:
name, u
>> *I* don't want that at all. All I'd like to have is a postgresql.conf
>> option specifying additional locations.
>
> Same from me. I think I would even take non-plural location.
I don't personally see a reason for plural locations, but it would be
nice if it recursed (that is, looked for .so
>> Agreed.
>
> Seems reasonable.
Yy!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Tom Lane wrote:
it supposes that rolvaliduntil represents an expiration date for the
user, but really it's only an expiration date for the password.)
Does anyone think the docs for CREATE ROLE/VALID UNTIL should mention
this more clearly? Currently, it is described as
The VALID UN
Josh, Daniel,
>> Right now, what we're telling users is "You can have continuous backup
>> with Postgres, but you'd better hire and expensive consultant to set it
>> up for you, or use this external tool of dubious provenance which
>> there's no packages for, or you might accidentally cause your d
On 01.06.2013 23:21, Robert Haas wrote:
On Sat, Jun 1, 2013 at 2:48 PM, Heikki Linnakangas
wrote:
We define a new page-level bit, something like PD_RECENTLY_FROZEN.
When this bit is set, it means there are no unfrozen tuples on the
page with XIDs that predate the current half-epoch. Whenever
> I suspect vacuum, autovacuum, autovacuum tuning, table and index bloat,
> etc is just too complicated for a lot of people running Pg installs to
> really understand. I'd really, really love to see some feedback-based
> auto-tuning of vacuum.
Heck, it's hard for *me* to understand, and I helped
On Mon, Jun 3, 2013 at 2:14 AM, Fujii Masao wrote:
> Sorry for the delay in responding to you.
>
> On Mon, Feb 11, 2013 at 6:03 AM, Phil Sorber wrote:
>> On Fri, Feb 8, 2013 at 1:07 PM, Phil Sorber wrote:
>>> On Fri, Feb 8, 2013 at 12:46 PM, Fujii Masao wrote:
No maybe. But I think that al
Alvaro Herrera writes:
> Jeff Davis wrote:
>> The CRC implementation is entirely in header files. Do you think we need
>> to go that far, or is it fine to just put it in libpgport and link that
>> to pg_filedump?
> If a lib is okay, use libpgcommon please, not libpgport. But I think a
> .h would
Jeff Davis wrote:
> On Mon, 2013-06-10 at 11:38 -0400, Tom Lane wrote:
> > The thing I'm not too happy about is having to copy the checksum code
> > into pg_filedump. We just got rid of the need to do that for the CRC
> > code, and here it is coming back again. Can't we rearrange the core
> > che
On Mon, 2013-06-10 at 11:38 -0400, Tom Lane wrote:
> The thing I'm not too happy about is having to copy the checksum code
> into pg_filedump. We just got rid of the need to do that for the CRC
> code, and here it is coming back again. Can't we rearrange the core
> checksum code similarly to what
On 06/10/2013 11:43 AM, Tom Lane wrote:
Andrew Dunstan writes:
Or we could abandon the conversion altogether, but that doesn't seem
very friendly either. I suspect the biggest case for people to use these
sequences is where the database is UTF8 but the client encoding is not.
Well, if that's
Teodor Sigaev writes:
>> Thoughts?
> Give me some time to play around it. Will think.
I experimented a bit with the idea of taking a heavyweight lock to
represent the right to alter an inner tuple. The results were pretty
grim: an spgist index build example went from 225 ms to 380 ms, and
a tes
Andrew Dunstan writes:
> Or we could abandon the conversion altogether, but that doesn't seem
> very friendly either. I suspect the biggest case for people to use these
> sequences is where the database is UTF8 but the client encoding is not.
Well, if that's actually the biggest use-case, then
On 7 June 2013 02:32, Tom Lane wrote:
> Hm, good point. That reinforces my feeling that the page-number-based
> approach isn't workable as a guarantee; though we might want to keep
> that layout rule as a heuristic that would help reduce contention.
Can the locks just be taken in, say, numeric
Alvaro Herrera writes:
> Jeff Davis wrote:
>> I was hesitant to do too much interpretation of the bits. Do you think
>> it would be better to just remove the test for XMAX_SHR_LOCK?
> I don't know, but then I'm biased because I know what that specific bit
> combination means. I guess someone tha
That would work fine as long as the invariant is maintained accurately.
However, there are at least two cases where the existing code fails to
maintain the invariant:
Hmm. Didn't catch that during development.
Thoughts?
Give me some time to play around it. Will think.
--
Teodor Sigaev
On 06/10/2013 10:18 AM, Tom Lane wrote:
Andrew Dunstan writes:
After thinking about this some more I have come to the conclusion that
we should only do any de-escaping of \u sequences, whether or not
they are for BMP characters, when the server encoding is utf8. For any
other encoding, whi
Stephen Frost writes:
> While having one place to put everything sounds great, it doesn't do a
> whole lot of good if you consider conflicts- either because you want
> multiple versions available or because there just happens to be some
> overlap in function names (or similar). There are also ext
Jeff Davis wrote:
> I was hesitant to do too much interpretation of the bits. Do you think
> it would be better to just remove the test for XMAX_SHR_LOCK?
I don't know, but then I'm biased because I know what that specific bit
combination means. I guess someone that doesn't know is going to be
s
* Greg Stark (st...@mit.edu) wrote:
> > I'd prefer that we let the
> > admins control both where extensions get installed to and what schemas
> > are added to the end of the search_path.
>
> This I object to. That's like having /usr/local/{apache,pgsql,kde,gnome}/bin.
... or it's like giving the
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> My opinion is that a pg_extension schema with a proper and well
> documented set of search_path properties would be good to have. A way to
> rename it per-database doesn't strike me as that useful as long as we
> have ALTER EXTENSION … SET SCHEMA
Andres Freund writes:
> On 2013-06-10 10:13:45 -0400, Tom Lane wrote:
>> More generally, it seems pretty insane to me to want to configure a
>> "trusted" PG installation so that it can load C code from an untrusted
>> place. The trust level cannot be any higher than the weakest link.
>> Thus, I d
Andres Freund writes:
>> In any case, no packager is going to ship an insecure-by-default
>> configuration, which is what Dimitri seems to be fantasizing would
>> happen. It would have to be local option to relax the permissions
>> on the directory, no matter where it is.
>
> *I* don't want that
Stephen Frost writes:
> Having a schema that isn't pg_catalog doesn't necessairly mean we need a
> schema per extension. Just a 'pg_extensions' schema, which is added to
> search_path behind the scenes (just like pg_catalog..) would be better
> than having everything go into pg_catalog. I'd pref
On 2013-06-10 10:39:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-06-10 10:13:45 -0400, Tom Lane wrote:
> >> More generally, it seems pretty insane to me to want to configure a
> >> "trusted" PG installation so that it can load C code from an untrusted
> >> place. The trust level
On 2013-06-10 10:13:45 -0400, Tom Lane wrote:
> Dimitri Fontaine writes:
> > For sites where they don't have in-house system packagers, it would be
> > very welcome to be able to setup PostgreSQL in a way that allows it to
> > LOAD the extension's binary code (.so, .dll, .dylib) from a non-root
>
Andrew Dunstan writes:
> After thinking about this some more I have come to the conclusion that
> we should only do any de-escaping of \u sequences, whether or not
> they are for BMP characters, when the server encoding is utf8. For any
> other encoding, which is already a violation of the
Dimitri Fontaine writes:
> For sites where they don't have in-house system packagers, it would be
> very welcome to be able to setup PostgreSQL in a way that allows it to
> LOAD the extension's binary code (.so, .dll, .dylib) from a non-root
> owned place even if you installed it from official pac
Andres Freund writes:
> I haven't looked at the patch in detail, but I am very, very much in
> favor of the feature in general… I have wished for this more than once,
+1
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers maili
From: "Craig Ringer"
The problem is that WAL for all tablespaces is mixed together in the
archives. If you lose your tablespace then you have to keep *all* WAL
around and replay *all* of it again when the tablespace comes back
online. This would be very inefficient, would require a lot of tricks
On Mon, Jun 10, 2013 at 2:03 PM, Stephen Frost wrote:
> Having a schema that isn't pg_catalog doesn't necessairly mean we need a
> schema per extension. Just a 'pg_extensions' schema, which is added to
> search_path behind the scenes (just like pg_catalog..) would be better
> than having everythi
Greg Stark writes:
> On Tue, May 14, 2013 at 11:59 AM, Stephen Frost wrote:
>> For my part, I'd still prefer to have those go into a different schema
>> than into pg_catalog. Perhaps that's overkill but I really do like the
>> seperation of system tables from extensions which can be added and
>>
Greg,
* Greg Stark (st...@mit.edu) wrote:
> On Tue, May 14, 2013 at 11:59 AM, Stephen Frost wrote:
> > * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> >> I'm not sure I agree with that view about pg_catalog. Sometimes we talk
> >> about moving some parts of core in pre-installed extensions i
Tom Lane writes:
> Andres Freund writes:
>> I don't really care much about Oliver's usecase TBH, but I would very much
>> welcome making it easier for application developers to package part of
>> ther in-database application code as extensions without either requiring
>> a selfcompiled postgres w
Hi,
I create patch which is improvement of checkpoint IO scheduler for stable
transaction responses.
* Problem in checkpoint IO schedule in heavy transaction case
When heavy transaction in database, I think PostgreSQL checkpoint scheduler
has two problems at start and end of checkpoint. One
Hello Greg,
Thanks for this very detailed review and the suggestions!
I'll submit a new patch
Question 1: should it report the maximum lang encountered?
I haven't found the lag measurement to be very useful yet, outside of
debugging the feature itself. Accordingly I don't see a reason to
On Mon, Jun 10, 2013 at 3:43 AM, Jeff Davis wrote:
>> We wouldn't need to do a FPW when a hint changes, we would only need
>> to take a copy of the ItemId array, which is much smaller. And it
>> could be protected by its own checksum.
>
> I like the direction of this idea.
One of the previous pro
On 04.06.2013 09:39, Martin Schäfer wrote:
Can't really blame Windows on that. On Windows, we don't require that the
encoding and LC_CTYPE's charset match. The OP used UTF-8 encoding in the
server, but LC_CTYPE="English_United Kingdom.1252", ie. LC_CTYPE implies
WIN1252 encoding. We allow that an
Joe Conway writes:
> OK, done this way and committed.
Thanks,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
Il 3/6/2013 11:46 PM, Andrew Dunstan ha scritto:
Excellent. Will test it out soon.
cheers
andrew
Andrew,
please find attached a full patch for cygwin relative to 9.3beta1 :
- DLLTOLL/DLLWRAP are not used anymore, replaced
by gcc also for postgres.exe (*)
- DLL versioning is added
Check
On 10 June 2013 07:06, Noah Misch wrote:
> On Sun, Jun 09, 2013 at 10:51:43AM +0100, Simon Riggs wrote:
>> On 9 June 2013 02:12, Noah Misch wrote:
>> > On Sat, Jun 08, 2013 at 08:20:42PM -0400, Robert Haas wrote:
>> >> On Sat, Jun 8, 2013 at 5:41 PM, Noah Misch wrote:
>> >> > Likewise; I don't s
Thanks Andrew. I will test the next release.
Martin
> -Original Message-
> From: Andrew Dunstan [mailto:and...@dunslane.net]
> Sent: 08 June 2013 16:43
> To: Tom Lane
> Cc: Heikki Linnakangas; k...@rice.edu; Martin Schäfer; pgsql-
> hack...@postgresql.org
> Subject: Re: [HACKERS] UTF-8 en
92 matches
Mail list logo
