On Tue, May 12, 2009 at 2:21 AM, Pavel Stehule wrote:
>> Moreover, I guess you don't even need to buffer tuples to aggregate by
>> different keys. What you have to do is only to prepare more than one
>> hash tables (, or set up sort order if the plan detects hash table is
>> too large to fit in th
On Mon, May 11, 2009 at 21:18, Tom Lane wrote:
> However, he can do that anyway via ALTER TABLE, which
> will happily take out AccessExclusiveLock before it checks any
> permissions. So I'm not seeing the point of risking unsafe behavior
> in LOCK TABLE.
I would rather fix ALTER TABLE to do som
On Tue, May 12, 2009 at 14:40, Alex Hunsaker wrote:
> Hrm on second thought I think your right. They only get the lock
> until the permission check, and I have a hard time seeing how someone
> can take real advantage of that. The owner that is trying to lock
> table should get the lock almost im
After taking look at our monitoring system i think some hint about previous
SQL might be useful.
dbadb70db_nameWARNING1long transactions, duration >
2690min user=postgres pid=7887 waiting=False query= in transaction
Currently i have no idea what exactly did i kill without digg
Hi,
On Tue, May 12, 2009 at 8:15 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas
>> wrote:
>>>
>>> This is getting complicated, though. I guess it would be enough to
>>> document
>>> that you mustn't copy any extra files into pg_xlog i
Fujii Masao wrote:
On Tue, May 12, 2009 at 8:15 PM, Heikki Linnakangas
wrote:
Here's another idea: Let's modify xlog.c so that when the server asks for
WAL file X, and restore_command returns "not found", the server will not ask
for any WAL files >= X again (in that recovery session). Presumabl
Hello,
I posted to the general list, and didn't receive any replies. Therefore, I am
trying this list now, hopefully this is the right mailing list for this type of
questions.
I am trying to compute the no of pages of a table. I am using the formula :
pages = ( columns width + 28) * no. o
Hi,
In pgsql/src/interfaces/libpq/fe-exec.c, there are two variables:
-
static int static_client_encoding = PG_SQL_ASCII;
static bool static_std_strings = false;
If enable_thread_safety is "no", how to insure libpq(dll/so) for
thread-safety?
thanks
wjzeng
--
Sent via pgsql-hacke
Robert Haas writes:
> But that leads me to a question - does the existing HashAggregate code
> make any attempt to obey work_mem?
No.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
Alex Hunsaker writes:
> FWIW i just tested this with ~100 clients doing begin; ALTER TABLE
> test_lock ADD COLUMN commit; here is the timing. Is there some other
> concern that im not seeing?
The situation where someone quickly acquires the lock isn't much of an
issue, because they'll drop it a
hello everybody,
from my side the goal of this discussion is to extract a consensus so
that we can go ahead and implement this issue for 8.5.
our customer here needs a solution to this problem and we have to come
up with something which can then make it into PostgreSQL core.
how shall we proce
On Wed, May 13, 2009 at 06:29:41AM +0200, Pavel Stehule wrote:
> 2009/5/13 Joshua Tolley :
> > On Tue, May 12, 2009 at 11:20:14PM +0200, Pavel Stehule wrote:
> >> this patch has some bugs but it is good prototype (it's more stable
> >> than old patch):
> >
> > I'm not sure if you're at the point th
2009/5/13 Joshua Tolley :
> On Wed, May 13, 2009 at 06:29:41AM +0200, Pavel Stehule wrote:
>> 2009/5/13 Joshua Tolley :
>> > On Tue, May 12, 2009 at 11:20:14PM +0200, Pavel Stehule wrote:
>> >> this patch has some bugs but it is good prototype (it's more stable
>> >> than old patch):
>> >
>> > I'm
Hi,
I have a script that automatically generates the SQL to create some
views. I'd like it to check whether its generated SQL matches the SQL
returned by "select definition from pg_views where...". I've guessed
most of the rules just by looking at the output, but I was surprised
to find that som
Hi,
I'm having 'service' issues too:
Windows XP SP3
user account used for service is not a member of admin group.
Errors starting service, but dbengine is started and available.
If i try to stop/start with the pgctl batch files created during install,
same type of problem...
PC had 8.2-5.1 ins
On May 13, 11:31 am, Kev wrote:
> Hi,
>
> I have a script that automatically generates the SQL to create some
> views. I'd like it to check whether its generated SQL matches the SQL
> returned by "select definition from pg_views where...". I've guessed
> most of the rules just by looking at the
Kevin Field wrote:
> One other thing I'm just curious about, "!=" gets replaced with
> "<>"...how come? (Feels more VB-ish than C-ish, so I was surprised
> that that would be the official/preferred reconstruct)
"<>" is the SQL standard operator. "!=" is a PostgreSQL extension,
for the co
Kevin Field wrote:
One other thing I'm just curious about, "!=" gets replaced with
"<>"...how come? (Feels more VB-ish than C-ish, so I was surprised
that that would be the official/preferred reconstruct)
<> is the official SQL standard notation for "not equals", AFAIK. != is not.
Kev writes:
> ... I was surprised
> to find that some of my views of the form:
> select.from b left join a on a.id=b.id
> ...were being translated to this:
> SELECT..FROM (B LEFT JOIN a ON ((a.id = b.id)))
> ...before being stored in the table pg_views is derived from. My
> su
Heikki Linnakangas writes:
> I don't think we're going to get this to work reliably without extending
> the interface between the backend and restore_command. We've discussed
> many methods and there's always some nasty corner-case like that.
> I think we should leave back-branches as is, and g
On Wed, 2009-05-13 at 13:01 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > I don't think we're going to get this to work reliably without extending
> > the interface between the backend and restore_command. We've discussed
> > many methods and there's always some nasty corner-case like
Simon Riggs writes:
> I will set-up pg_standby as an external module and we can change it from
> there. No more discussions-for-8.4 and I can update as required to
> support each release. So let's just remove it from contrib and be done.
Huh? The proposed fix involves a backend change, so I don'
Simon Riggs wrote:
I will set-up pg_standby as an external module and we can change it from
there. No more discussions-for-8.4 and I can update as required to
support each release. So let's just remove it from contrib and be done.
Counterthoughts?
We're in Beta. You can't just go yanking
Tom Lane wrote:
Heikki Linnakangas writes:
I don't think we're going to get this to work reliably without extending
the interface between the backend and restore_command. We've discussed
many methods and there's always some nasty corner-case like that.
I think we should leave back-branches a
On Wed, 2009-05-13 at 14:14 -0400, Andrew Dunstan wrote:
> pg_standby is useful and needs to be correct. And its existence as a
> standard module is one of the things that has made me feel confident
> about recommending people to use the PITR stuff. I'll be very annoyed if
> it were to get pull
On Wed, May 13, 2009 at 03:12:51PM +0200, Pavel Stehule wrote:
> 2009/5/13 Joshua Tolley :
> > On Wed, May 13, 2009 at 06:29:41AM +0200, Pavel Stehule wrote:
> >> 2009/5/13 Joshua Tolley :
> >> > On Tue, May 12, 2009 at 11:20:14PM +0200, Pavel Stehule wrote:
> >> >> this patch has some bugs but it
On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
> I think we should fix it for 8.4.
Agreed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Simon Riggs wrote:
On Wed, 2009-05-13 at 13:01 -0400, Tom Lane wrote:
Heikki Linnakangas writes:
Does someone want to take a stab at writing a patch for that?
No, not if there is a likelihood the work would be wasted.
There always is.
(I would've wrote the patch myself right away, but I'm
Andrew Dunstan wrote:
We're in Beta. You can't just go yanking stuff like that. Beta testers
will be justifiably very annoyed.
Please calm down.
pg_standby is useful and needs to be correct. And its existence as a
standard module is one of the things that has made me feel confident
about r
On Wed, 2009-05-13 at 14:14 -0400, Andrew Dunstan wrote:
> pg_standby is useful and needs to be correct.
My suggestion was designed to provide this. A misunderstanding.
> And its existence as a
> standard module is one of the things that has made me feel confident
> about recommending people
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Does this conclusion mean that changing pg_standby is no longer
>> on the table for 8.4? It certainly smells more like a new feature
>> than a bug fix.
> This whole thing can be considered to be a new feature. It's working as
> designed. But peopl
Heikki Linnakangas writes:
> That's a lot more drastic change to make in beta. Besides, the proposed
> fix required backend changes. I think we should keep it in contrib. (At
> least for this release: If we get more integrated replication options in
> 8.5, that would be a good time to move pg_s
Tom Lane wrote:
Heikki Linnakangas writes:
That's a lot more drastic change to make in beta. Besides, the proposed
fix required backend changes. I think we should keep it in contrib. (At
least for this release: If we get more integrated replication options in
8.5, that would be a good ti
On Wed, 2009-05-13 at 14:53 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> Does this conclusion mean that changing pg_standby is no longer
> >> on the table for 8.4? It certainly smells more like a new feature
> >> than a bug fix.
>
> > This whole thing can be cons
Simon Riggs wrote:
On Wed, 2009-05-13 at 14:53 -0400, Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Does this conclusion mean that changing pg_standby is no longer
on the table for 8.4? It certainly smells more like a new feature
than a bug fix.
This whole thing can be considere
Hello,
thank you for posting the paper, it was quite interesting to read. I
think it would be a good idea to give the two-phase optimization a try.
As far as I know and understand the current (geqo) optimizer source,
many important parts are already there. For example, we can calculate
the costs of
Alvaro Herrera writes:
> It seems that if you load libxml into a backend for whatever reason (say
> you create a table with a column of type xml) and then create a plperlu
> function that "use XML::LibXML", we get a segmentation fault.
I've applied a patch for this in HEAD. It fixes the reported
On Wed, May 13, 2009 at 4:14 PM, Tobias Zahn wrote:
> Hello,
> thank you for posting the paper, it was quite interesting to read. I
> think it would be a good idea to give the two-phase optimization a try.
> As far as I know and understand the current (geqo) optimizer source,
> many important part
On Wed, 2009-05-13 at 15:05 -0400, Andrew Dunstan wrote:
> Frankly, if anything it should move from contrib to the core proper. I
> regard it as an essential utility, not an optional extra.
I like that idea.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Supp
On Wed, 2009-05-13 at 21:26 +0300, Heikki Linnakangas wrote:
> This whole thing can be considered to be a new feature.
recovery.conf will contain a new optional parameter:
recovery_end_command (string)
This parameter specifies a shell command that will be executed once only
at the end of reco
Simon Riggs writes:
> recovery_end_command is performed *after* the UpdateControlFile() once
> the we are DB_IN_PRODUCTION.
Hmm, shouldn't it be after the last checkpoint but before we go to
DB_IN_PRODUCTION? I have to admit I've not been following this closely
though, so I may be missing someth
On Wed, 2009-05-13 at 16:47 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > recovery_end_command is performed *after* the UpdateControlFile() once
> > the we are DB_IN_PRODUCTION.
>
> Hmm, shouldn't it be after the last checkpoint
Definitely.
> but before we go to DB_IN_PRODUCTION?
I thin
On May 13, 12:41 pm, kevin.gritt...@wicourts.gov ("Kevin Grittner")
wrote:
> Kevin Field wrote:
> > One other thing I'm just curious about, "!=" gets replaced with
> > "<>"...how come? (Feels more VB-ish than C-ish, so I was surprised
> > that that would be the official/preferred reconstruct)
On May 13, 12:52 pm, t...@sss.pgh.pa.us (Tom Lane) wrote:
> Kev writes:
> > ... I was surprised
> > to find that some of my views of the form:
> > select.from b left join a on a.id=b.id
> > ...were being translated to this:
> > SELECT..FROM (B LEFT JOIN a ON ((a.id = b.id)))
> > ..
On Wed, 13 May 2009, Kevin Field wrote:
Or would the only way to do this be to actually create a view and then
call pg_get_viewdef() and then delete the view?
Just make it a temporary view and then it drops when the session ends.
Here's a working shell example that transforms a view into the
Cristina M escreveu:
> - for table t2(l_orderkey int, l_partkey int, l_quantiy, l_tax,
> l_extendedprice, l_discount) I got an error of 42 %.
>
I suspect you have NULLs in your table; they're stored as bitmaps, so they use
little space.
--
Euler Taveira de Oliveira
http://www.timbira.com/
Cristina M wrote:
> I posted to the general list, and didn't receive any replies.
> Therefore, I am trying this list now, hopefully this is the right
> mailing list for this type of questions.
>
> I am trying to compute the no of pages of a table. I am using the formula :
>
> pages = ( columns w
On Wed, May 13, 2009 at 6:08 AM, Cristina M wrote:
> Hello,
> I posted to the general list, and didn't receive any replies. Therefore, I
> am trying this list now, hopefully this is the right mailing list for this
> type of questions.
> I am trying to compute the no of pages of a table. I am using
Hi all,
Attached is a patch to fix a command line example in charset.sgml.
I hope it is correct.
[]s
--
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
fix_typo_lc_collatein_charset_sgml.patch.bz2
Description: application
Dickson S. Guedes wrote:
Hi all,
Attached is a patch to fix a command line example in charset.sgml.
No, the options really are called LC_COLLATE and LC_CTYPE now. They were
renamed on 6th of April, just before beta1
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Se
"wjzeng" wrote:
> In pgsql/src/interfaces/libpq/fe-exec.c, there are two variables:
> -
> static int static_client_encoding = PG_SQL_ASCII;
> static bool static_std_strings = false;
>
> If enable_thread_safety is "no", how to insure libpq(dll/so) for
> thread-safety?
Use PQescape[Str
51 matches
Mail list logo
