Heyho!
On Monday 01 March 2010 17.04:46 Tom Lane wrote:
table
> > values ( ts timestamp, source integer, value float );
> > [...] partial index on "(source, ts) where ts > '2009-01-01'"?
> The planner is reasonably smart about deductions involving combinations
> of btree-indexable operators. It
"Ed L." writes:
> On Monday 01 March 2010 @ 17:57, Tom Lane wrote:
>> BTW, there seems to be some other contributing factor here
>> besides the weird username, because I don't see any looping
>> when I try CREATE USER "@". What's your platform exactly,
>> and what type of filesystem is $PGDATA on
On Monday 01 March 2010 @ 18:29, Tom Lane wrote:
> "Ed L." writes:
> > That did the trick. Thank you very much, Sensei.
>
> I'd still like to know about platform etc. I see that we
> shouldn't be allowing a username to trigger @-file expansion,
> but even with that it's not clear how it turne
On Monday 01 March 2010 @ 17:57, Tom Lane wrote:
> "Ed L." writes:
> >> Correction. Here's the line:
> >> "@" "" "" "agent_group"
> >
> > It is the first line in the pg_auth file.
>
> BTW, there seems to be some other contributing factor here
> besides the weird username, because I don't see an
"Ed L." writes:
> That did the trick. Thank you very much, Sensei.
I'd still like to know about platform etc. I see that we shouldn't be
allowing a username to trigger @-file expansion, but even with that
it's not clear how it turned into an infinite loop; and as I said,
I can't reproduce that
On Monday 01 March 2010 @ 17:58, Tom Lane wrote:
> "Ed L." writes:
> > Killed the stuck postmaster with sigkill, edited the file,
> > restarted postmaster, and it re-wrote the file with the
> > bogus entry. I don't have any superuser sessions open. Is
> > there another route?
>
> What you're go
"Ed L." writes:
> Killed the stuck postmaster with sigkill, edited the file,
> restarted postmaster, and it re-wrote the file with the bogus
> entry. I don't have any superuser sessions open. Is there
> another route?
What you're going to need to do is stop the postmaster, start
a standalone
"Ed L." writes:
>> Correction. Here's the line:
>> "@" "" "" "agent_group"
> It is the first line in the pg_auth file.
BTW, there seems to be some other contributing factor here besides
the weird username, because I don't see any looping when I try
CREATE USER "@". What's your platform exactly
On Monday 01 March 2010 @ 17:36, Ed L. wrote:
> On Monday 01 March 2010 @ 17:26, Tom Lane wrote:
> > "Ed L." writes:
> > > On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> > >> "Ed L." writes:
> > >>> There is one, looks like a typo got in. How do I fix
> > >>> it?
> > >>
> > >> Hmm, a user na
On Monday 01 March 2010 @ 17:26, Tom Lane wrote:
> "Ed L." writes:
> > On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> >> "Ed L." writes:
> >>> There is one, looks like a typo got in. How do I fix it?
> >>
> >> Hmm, a user named @, or what?
> >
> > Yes, a bogus user:
> >
> > "@" "" ""
>
> Mp
On Monday 01 March 2010 @ 17:25, Ed L. wrote:
> On Monday 01 March 2010 @ 17:23, Ed L. wrote:
> > On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> > > "Ed L." writes:
> > > > On Monday 01 March 2010 @ 17:15, Tom Lane wrote:
> > > >> u...@host shouldn't be a problem, but if there were an
> > > >>
"Ed L." writes:
> On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
>> "Ed L." writes:
>>> There is one, looks like a typo got in. How do I fix it?
>>
>> Hmm, a user named @, or what?
> Yes, a bogus user:
> "@" "" ""
Mph. We really ought to fix things so that a quoted @ doesn't get taken
as
On Monday 01 March 2010 @ 17:23, Ed L. wrote:
> On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> > "Ed L." writes:
> > > On Monday 01 March 2010 @ 17:15, Tom Lane wrote:
> > >> u...@host shouldn't be a problem, but if there were an @
> > >> by itself or starting a token, it might possibly cause
On Monday 01 March 2010 @ 17:18, Tom Lane wrote:
> "Ed L." writes:
> > On Monday 01 March 2010 @ 17:15, Tom Lane wrote:
> >> u...@host shouldn't be a problem, but if there were an @ by
> >> itself or starting a token, it might possibly cause
> >> something like this.
> >
> > There is one, looks li
On Monday 01 March 2010 @ 16:49, Tom Lane wrote:
>
> Oh, for some reason I thought it was sitting idle. That
> sounds more like an infinite loop. Try reattaching to the
> postmaster, confirm the stack trace, and then see how many
> times you can do "fin" before it doesn't return control.
>
"Ed L." writes:
> On Monday 01 March 2010 @ 17:15, Tom Lane wrote:
>> u...@host shouldn't be a problem, but if there were an @ by
>> itself or starting a token, it might possibly cause something
>> like this.
> There is one, looks like a typo got in. How do I fix it?
Hmm, a user named @, or wha
On Monday 01 March 2010 @ 17:15, Tom Lane wrote:
> "Ed L." writes:
> > On Monday 01 March 2010 @ 16:57, Tom Lane wrote:>
> >
> >> Now that I look more closely at those line numbers, it
> >> looks like the thing thinks it is processing an include
> >> file. Are there any @ signs in your global/pg_
"Ed L." writes:
> On Monday 01 March 2010 @ 16:57, Tom Lane wrote:>
>> Now that I look more closely at those line numbers, it looks
>> like the thing thinks it is processing an include file. Are
>> there any @ signs in your global/pg_auth file?
> Yes, indeed, there are many. My user names are
On Monday 01 March 2010 @ 16:57, Tom Lane wrote:>
> Now that I look more closely at those line numbers, it looks
> like the thing thinks it is processing an include file. Are
> there any @ signs in your global/pg_auth file?
Yes, indeed, there are many. My user names are "u...@host" form,
and
"Ed L." writes:
> #4 0x00531ee8 in next_token (fp=0x10377ae0, buf=0x7fff32230e60 "",
> bufsz=4096) at hba.c:128
> #5 0x00532233 in tokenize_file (filename=0x10359b70 "global",
> file=0x10377ae0, lines=0x7fff322310f8, line_nums=0x7fff322310f0) at hba.c:232
> #6 0x005322
"Ed L." writes:
> Also seeing lots of postmaster zombies (190 and growing)...
Yeah, that and the lack of service for new connections would both be
expected if the postmaster is stuck. And the autovac worker start
failures, too. There's only one bug here.
> While new connections are hanging, to
On Monday 01 March 2010 @ 16:03, Ed L. wrote:
> On Monday 01 March 2010 @ 15:59, Ed L. wrote:
> > > This just happened again ~24 hours after full reload from
> > > backup. Arrrgh.
> > >
> > > Backtrace looks the same again, same file, same
> > > __read_nocancel(). $PGDATA/global/pg_auth looks fin
On Monday 01 March 2010 @ 15:59, Ed L. wrote:
> > This just happened again ~24 hours after full reload from
> > backup. Arrrgh.
> >
> > Backtrace looks the same again, same file, same
> > __read_nocancel(). $PGDATA/global/pg_auth looks fine to me,
> > permissions are 600, entries are 3 or more do
On Monday 01 March 2010 @ 15:46, Ed L. wrote:
> On Monday 01 March 2010 @ 15:41, Ed Loehr (LoehrTech.com) wrote:
> > "Ed L." writes:
> > > (gdb) bt
> > > #0 0x00346f8c43a0 in __read_nocancel () from
> > > /lib64/libc.so.6 #1 0x00346f86c747 in
> > > _IO_new_file_underflow () from /lib64/l
On Monday 01 March 2010 @ 15:41, Ed Loehr (LoehrTech.com) wrote:
> "Ed L." writes:
> > (gdb) bt
> > #0 0x00346f8c43a0 in __read_nocancel () from
> > /lib64/libc.so.6 #1 0x00346f86c747 in
> > _IO_new_file_underflow () from /lib64/libc.so.6 #2
> > 0x00346f86d10e in _IO_default_uflow_i
On Mon, 2010-03-01 at 14:43 -0400, Marc G. Fournier wrote:
> First, thanks for the pointer to the Check_postgres stuff, definitely alot
> of good stuff in there ... but ... that is a totally different beast then
> I'm looking at from Cacti (or, so I believe) ... for instance,
> Check_posgres:dat
Greg, before I start hacking away at it, do you have any examples of using
check_postgres_dbstats with cacti? rather not recreate teh wheel is
someone has already done it ...
thx ...
On Sat, 27 Feb 2010, Greg Smith wrote:
Marc G. Fournier wrote:
We are mainly a nagios / cacti environment
First, thanks for the pointer to the Check_postgres stuff, definitely alot
of good stuff in there ... but ... that is a totally different beast then
I'm looking at from Cacti (or, so I believe) ... for instance,
Check_posgres:database_size will alert me if I go over X size, which is
useful bu
Darryl Pye writes:
> I am having some problems with prepared statements.
> Somehow I have 2 orphan prepared statements in one of my databases.
I think you are confusing prepared statements with prepared
transactions.
> I have tried Deallocate All and Discard All, no joy.
ROLLBACK PREPARED is
Adrian von Bidder writes:
> Given a (big [1]) table
> values ( ts timestamp, source integer, value float );
> [under what conditions] will the opitmizer be smart enough to make use of a
> partial index on "(source, ts) where ts > '2009-01-01'"? (Queries will have
> a date restriction but not
Szymon Guz writes:
> W dniu 1 marca 2010 09:40 użytkownik Grzegorz JaÅkiewicz
> napisaÅ:
>> don't use 'NOT EXISTS', as this will be damn slow. Use LEFT JOIN.
> Right, LEFT JOIN should be faster (with proper indices even much faster).
Converting NOT EXISTS into an outer join is a manual applic
Hi,
I am having some problems with prepared statements.
Somehow I have 2 orphan prepared statements in one of my databases.
I have tried Deallocate All and Discard All, no joy.
If I try to change the table structures that where involved in the prepared
statements or any of its inherite
Hi ,
i want to develop an index for a special problem.
The postgres docs shows the necessary bits in
http://www.postgresql.org/docs/8.4/interactive/indexam.html
especially paragraph 50.2 "Index Access Method Functions".
Now my question: can i use the (documented) Server Programming
> Generally speaking you don't want to make per-user entries in
> pg_hba.conf; it's just too much of a PITA for maintenance, unless
> you really need different auth mechanisms for different users.
> I'd suggest using "all" for the hba database and user columns whenever
> possible. If you want con
In response to AI Rumman :
> How to find the current transaction id of the database?
select txid_current()
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99
--
Sent via pgsq
How to find the current transaction id of the database?
Hi Terry,
On Sunday 28 February 2010 22.56:41 Terry wrote:
> I am looking for a way to copy all the data from one table to another
> on a regular basis, every 5 minutes let's say.
>
> INSERT INTO table2 SELECT * FROM table1;
Why do you want this? Is it necessary for the data in table2 to appear
Heyho!
Given a (big [1]) table
values ( ts timestamp, source integer, value float );
[under what conditions] will the opitmizer be smart enough to make use of a
partial index on "(source, ts) where ts > '2009-01-01'"? (Queries will have
a date restriction but not necessarily the exact "> 2009
W dniu 1 marca 2010 09:40 użytkownik Grzegorz Jaśkiewicz
napisał:
> don't use 'NOT EXISTS', as this will be damn slow. Use LEFT JOIN.
>
>
Right, LEFT JOIN should be faster (with proper indices even much faster).
don't use 'NOT EXISTS', as this will be damn slow. Use LEFT JOIN.
40 matches
Mail list logo
