On Mon, Oct 31, 2011 at 5:23 PM, Simon Riggs wrote:
> On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao wrote:
>
>>> In 9.2 the presence of recovery.conf can and therefore should continue
>>> to act as it does in 9.1.
>>
>> This means that recovery.conf is renamed to recovery.done at the end of
>> rec
On Sat, 2011-10-29 at 21:12 +0200, Erik Rijkers wrote:
> Would it be possible to remove of the double quotes in the daterange display
> of BC dates?
>
> select '[0001-10-29 BC,2011-10-29)'::daterange;
> daterange
> --
> ["0001-10-29 BC",2011-10-29)
> (1 row)
On 2011-11-01 00:53, Merlin Moncure wrote:
On Mon, Oct 31, 2011 at 12:49 PM, Mark Hills wrote:
Furthermore, in most apps it'd be a serious PITA to keep track of which
reply is for which query, so I doubt that such a feature is of general
usefulness.
In our UI case, we already have a queue.
On Tue, Nov 1, 2011 at 3:08 AM, Magnus Hagander wrote:
> On Fri, Oct 28, 2011 at 08:46, Fujii Masao wrote:
>> On Thu, Oct 27, 2011 at 11:14 PM, Magnus Hagander
>> wrote:
>>> Here's a version that does this. Turns out this requires a lot less
>>> code than what was previously in there, which is
I wrote:
> I have often found myself wanting that psql automatically switch between
> normal and \x mode depending on the width of the output. Would others
> find this useful?
>
> Attached is a crude demo patch. Enable with \pset expanded auto.
Here is a finalized patch for this. The first hun
On Mon, Oct 31, 2011 at 7:18 PM, Scott Mead wrote:
>
>
> On Mon, Oct 31, 2011 at 6:13 PM, Robert Haas wrote:
>
>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
>> wrote:
>> > Actually, for the future, it might be useful to have a "state" column,
>> > that holds the idle/in transaction/running
On Mon, Oct 31, 2011 at 6:13 PM, Robert Haas wrote:
> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander
> wrote:
> > Actually, for the future, it might be useful to have a "state" column,
> > that holds the idle/in transaction/running status, instead of the
> > tools having to parse the query tex
On 10/31/2011 06:54 AM, Marcin Mańk wrote:
On Sun, Oct 30, 2011 at 8:50 PM, Eric Ridge wrote:
Well, it's a "display thing" as much as any SELECT statement
(especially via psql) is a "display thing". It's more like "I want
all 127 columns, except the giant ::xml column, and I'm too lazy to
type
On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander wrote:
> Actually, for the future, it might be useful to have a "state" column,
> that holds the idle/in transaction/running status, instead of the
> tools having to parse the query text to get that information...
+1 for doing it this way. Splitti
On Mon, Oct 31, 2011 at 3:19 PM, Simon Riggs wrote:
> On Mon, Oct 31, 2011 at 7:05 PM, Josh Berkus wrote:
>
>> If it's possible to run a replica without having a recovery.conf file,
>> then I'm fine with your solution. If it's not, then I find your
>> solution not to be a solution at all.
>
> Th
On Mon, Oct 31, 2011 at 4:45 PM, Magnus Hagander wrote:
>
> Actually, for the future, it might be useful to have a "state" column,
> that holds the idle/in transaction/running status, instead of the
> tools having to parse the query text to get that information...
>
if we are going to create the
On Mon, Oct 31, 2011 at 22:37, Scott Mead wrote:
> Hey all,
>
> So, I'm dealing with a a big ol' java app that has multiple roads on the
> way to in transaction. We can reproduce the problem in a test
> environment, but the lead dev always asks "can you just tell me the last
> query that it r
Heikki Linnakangas writes:
> I think a common use for this would be doing multiple inserts or updates on
> one go. Like, insert into a parent table, then more details into child
> tables. You don't care about getting the results back in that case, as long
> as you get an error on failure.
As of 9
Hey all,
So, I'm dealing with a a big ol' java app that has multiple roads on the
way to in transaction. We can reproduce the problem in a test
environment, but the lead dev always asks "can you just tell me the last
query that it ran?"
So I wrote the attached patch, it just turns in tra
Simon Riggs writes:
> My list of things to do included optimising
> GetRunningTransactionLocks(), run once per checkpoint.
> I was thinking I needed to try harder to avoid acquiring LWlocks on
> all the lock partitions.
> ISTM that I don't need to do this - lwlocks on lock partitions are
> almos
My list of things to do included optimising
GetRunningTransactionLocks(), run once per checkpoint.
I was thinking I needed to try harder to avoid acquiring LWlocks on
all the lock partitions.
ISTM that I don't need to do this - lwlocks on lock partitions are
almost never contended now, so this sh
On Mon, Oct 31, 2011 at 7:54 PM, Robert Haas wrote:
> Revised patch attached. I think it would be useful to assert this
> both at process startup time and at process shutdown, since it would
> really be much nicer to have the process that didn't clean up fail the
> assertion, rather than the new
Simon Riggs writes:
> On Mon, Oct 31, 2011 at 7:54 PM, Robert Haas wrote:
>> Revised patch attached. I think it would be useful to assert this
>> both at process startup time and at process shutdown, since it would
>> really be much nicer to have the process that didn't clean up fail the
>> asse
Robert Haas writes:
> Revised patch attached. I think it would be useful to assert this
> both at process startup time and at process shutdown, since it would
> really be much nicer to have the process that didn't clean up fail the
> assertion, rather than the new one that innocently inherited it
On Mon, Oct 31, 2011 at 20:58, Tom Lane wrote:
> Magnus Hagander writes:
>> So once again I forgot about the fact that you can specify multiple
>> LDAP server in our ldapserver parameter (because both openldap and
>> winldap accept a space separated list).
>
>> Any objections to just applying the
Magnus Hagander writes:
> So once again I forgot about the fact that you can specify multiple
> LDAP server in our ldapserver parameter (because both openldap and
> winldap accept a space separated list).
> Any objections to just applying the attached docs patch?
"space-separated list" is more i
On Sun, Oct 30, 2011 at 11:26 PM, Robert Haas wrote:
> On Sun, Oct 30, 2011 at 11:13 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> I'd like to propose the attached patch, which initializes each
>>> PGPROC's myProcLocks just once at postmaster startup, rather than
>>> every time the PGPROC is ha
On Mon, Oct 31, 2011 at 3:11 PM, Magnus Hagander wrote:
> So once again I forgot about the fact that you can specify multiple
> LDAP server in our ldapserver parameter (because both openldap and
> winldap accept a space separated list).
>
> Any objections to just applying the attached docs patch?
On Mon, Oct 31, 2011 at 7:05 PM, Josh Berkus wrote:
> If it's possible to run a replica without having a recovery.conf file,
> then I'm fine with your solution. If it's not, then I find your
> solution not to be a solution at all.
Then you are fine with the solution - not mine alone, just the s
So once again I forgot about the fact that you can specify multiple
LDAP server in our ldapserver parameter (because both openldap and
winldap accept a space separated list).
Any objections to just applying the attached docs patch?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://
Simon,
> Everybody agrees a neater way of invoking standby mode would be good.
I don't think this goes far enough. The whole
recovery.conf/recovery.done thing is a serious problem for automated
management of servers and automated failover. So it's not just "a
neater way would be good" but "usin
On Mon, Oct 31, 2011 at 1:08 PM, Merlin Moncure wrote:
> On Mon, Oct 31, 2011 at 12:49 PM, Merlin Moncure wrote:
>> On Mon, Oct 31, 2011 at 12:09 PM, Tom Lane wrote:
>>> Heikki Linnakangas writes:
On 31.10.2011 17:44, Mark Hills wrote:
> Could libpq be reasonably modified to allow this
On Mon, Oct 31, 2011 at 12:49 PM, Merlin Moncure wrote:
> On Mon, Oct 31, 2011 at 12:09 PM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> On 31.10.2011 17:44, Mark Hills wrote:
Could libpq be reasonably modified to allow this?
>>
>>> I believe it's doable in theory, no-one has just gott
On Fri, Oct 28, 2011 at 08:46, Fujii Masao wrote:
> On Thu, Oct 27, 2011 at 11:14 PM, Magnus Hagander wrote:
>> Here's a version that does this. Turns out this requires a lot less
>> code than what was previously in there, which is always nice.
>>
>> We still need to solve the other part which is
On Mon, Oct 31, 2011 at 12:49 PM, Mark Hills wrote:
> On Mon, 31 Oct 2011, Tom Lane wrote:
>
>> Heikki Linnakangas writes:
>> > On 31.10.2011 17:44, Mark Hills wrote:
>> >> Could libpq be reasonably modified to allow this?
>>
>> > I believe it's doable in theory, no-one has just gotten around to
On Mon, 31 Oct 2011, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 31.10.2011 17:44, Mark Hills wrote:
> >> Could libpq be reasonably modified to allow this?
>
> > I believe it's doable in theory, no-one has just gotten around to it.
> > Patches are welcome.
>
> Can't you do that today w
On Mon, Oct 31, 2011 at 12:09 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 31.10.2011 17:44, Mark Hills wrote:
>>> Could libpq be reasonably modified to allow this?
>
>> I believe it's doable in theory, no-one has just gotten around to it.
>> Patches are welcome.
>
> Can't you do that t
On 31.10.2011 19:09, Tom Lane wrote:
Heikki Linnakangas writes:
On 31.10.2011 17:44, Mark Hills wrote:
Could libpq be reasonably modified to allow this?
I believe it's doable in theory, no-one has just gotten around to it.
Patches are welcome.
Can't you do that today with a multi-command
Heikki Linnakangas writes:
> On 31.10.2011 17:44, Mark Hills wrote:
>> Could libpq be reasonably modified to allow this?
> I believe it's doable in theory, no-one has just gotten around to it.
> Patches are welcome.
Can't you do that today with a multi-command string submitted to
PQsendQuery, f
I just noticed a warning in pg_upgrade:
option.c: In function *parseCommandLine*:
option.c:96:8: warning: ignoring return value of *getcwd*,
declared
with attribute warn_unused_result
It looks like it might be worth testing the return value here for
NULL, which would indicate an error accessing
I have nothing of substance to add, but
On Mon, Oct 31, 2011 at 17:44, Mark Hills wrote:
> Instead, it would be preferable to send multiple requests (down the TCP
> socket), and then receive multiple responses (in order).
HTTP calls this "pipelining". I think it's helpful to adopt this term
sinc
On 31.10.2011 17:44, Mark Hills wrote:
We have a user interface which fetches and displays many small pieces of
distinct information from a PostgreSQL database.
* fetches are simple lookups across a diverse set of tables,
in response to events on another data source
* uses PQsendQuery() on a
We have a user interface which fetches and displays many small pieces of
distinct information from a PostgreSQL database.
* fetches are simple lookups across a diverse set of tables,
in response to events on another data source
* uses PQsendQuery() on a non-blocking socket
But data fetches vi
Tristan Wright writes:
> I am interested in this item on the list and its exact meaning:
> (Under "Data Types")
> - Fix data types where equality comparison is not intuitive, e.g. box
> Can you elaborate on this item, I particularly fail to see what is
> non-intuitive about box comparisons (and
On Mon, Oct 31, 2011 at 9:51 AM, Anssi Kääriäinen
wrote:
> Stupid question, but why not keep the whole VM pinned?
It might be that keeping more than one VM page pinned is a good idea,
but we'd have to think carefully about it. For example, if we pin too
many pages in shared_buffers, other querie
On 10/31/2011 02:44 PM, Robert Haas wrote:
What I think you're probably measuring here (oprofile would tell us
for sure) is that once the size of the table goes beyond about half a
gigabyte, it will have more than one page in the visibility map. The
index-only scan code keeps the most recently u
On 10/30/2011 10:00 PM, Christopher Browne wrote:
There is legitimate reason to reject this on the basis of nondeterminism.
While we are surely obliged to "hold our noses" and support "SELECT
*", as:
A) The SQL standard obliges us, and
B) People already use it a lot,
Neither of those facto
On Sun, Oct 30, 2011 at 8:02 AM, Kääriäinen Anssi
wrote:
> Table size is around 600MB, index size is around 350MB and VM on-disk
> size is 16kB with default fillfactor. With fillfactor = 10, the VM size is 104
> KB, and table size is around 6GB. The index size is the same.
What I think you're pr
2011/10/31 Shigeru Hanada :
> (2011/10/30 11:34), Shigeru Hanada wrote:
>> 2011/10/30 Tom Lane:
>>> I think we have to. Even if we estimate that a given scan will return
>>> only a few rows, what happens if we're wrong? We don't want to blow out
>>> memory on the local server by retrieving gigaby
On Sun, Oct 30, 2011 at 8:50 PM, Eric Ridge wrote:
> Well, it's a "display thing" as much as any SELECT statement
> (especially via psql) is a "display thing". It's more like "I want
> all 127 columns, except the giant ::xml column, and I'm too lazy to
> type each column name out by hand".
>
How
On Mon, Oct 31, 2011 at 7:38 AM, Fujii Masao wrote:
>> In 9.2 the presence of recovery.conf can and therefore should continue
>> to act as it does in 9.1.
>
> This means that recovery.conf is renamed to recovery.done at the end of
> recovery. IOW, all settings in recovery.conf are reset when reco
I am interested in this item on the list and its exact meaning:
(Under "Data Types")
- Fix data types where equality comparison is not intuitive, e.g. box
Can you elaborate on this item, I particularly fail to see what is
non-intuitive about box comparisons (and I suppose other types where equal
On Sat, Oct 29, 2011 at 7:54 PM, Simon Riggs wrote:
> On Fri, Sep 9, 2011 at 10:56 AM, Fujii Masao wrote:
>
>> In previous discussion, we've reached the consensus that we should unite
>> recovery.conf and postgresql.conf. The attached patch does that. The
>> patch is WIP, I'll have to update the
2011/10/30 Martijn van Oosterhout :
> On Sat, Oct 29, 2011 at 08:28:57PM +, Mr. Aaron W. Swenson wrote:
>> > If /tmp is the only decent place where to put the socket file on Unix
>> > when security and other concerns are considered, then sure, making
>> > distro life difficult is a good thing t
49 matches
Mail list logo
