Hi,
Is there any way to keep each database in separate partition ie)
separate folder for each database.
I would like to do the dabase level backup in storage side, for that If
I am able to separate the database in folderwise, I can allocate
separate partition for each database. Then I can take
Nagalingam, Karthikeyan wrote:
Hi,
Is there any way to keep each database in separate partition ie)
separate folder for each database.
I would like to do the dabase level backup in storage side, for that
If I am able to separate the database in folderwise, I can allocate
separate partition
On Thu, Mar 12, 2009 at 04:18:50PM +0530, Nagalingam, Karthikeyan wrote:
> Is there any way to keep each database in separate partition ie)
> separate folder for each database.
>
> I would like to do the dabase level backup in storage side, for that If
> I am able to separate the database in fo
Thanks karsten.
Anybody have production setup with diff database in diff folder ie) diff
partition. Please provide the details if possible help me with diaghram.
Regards
Karthikeyan.N
-Original Message-
From: Karsten Hilbert [mailto:karsten.hilb...@gmx.net]
Sent: Thursday, March 12,
Is there a reliable way to find out the (Unix) PID associated with a
database handle generated by Perl DBI's database connection?
TIA!
Kynn
In response to Kynn Jones :
> Is there a reliable way to find out the (Unix) PID associated with a database
> handle generated by Perl DBI's database connection?
You can ask the pg_stat_activity - View, column procpid.
HTH, Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 01
On Thu, Mar 12, 2009 at 03:13:13PM +0100, A. Kretschmer wrote:
> In response to Kynn Jones :
> > Is there a reliable way to find out the (Unix) PID associated with a
> > database
> > handle generated by Perl DBI's database connection?
>
> You can ask the pg_stat_activity - View, column procpid.
pg clients communicate on 5432 so a simple search on 5432 will yield the pid
e.g.
netstat -aon | grep 5432
Martin
__
Disclaimer and confidentiality note
Everything in this e-mail and any attachments relates to the official business
of Sender. This
In response to Martin Gainty :
> pg clients communicate on 5432 so a simple search on 5432 will yield the pid
> e.g.
> netstat -aon | grep 5432
Thats no useful:
- you can't do that from the client (across the network)
- you can't see which pid has a particular client
Regards, Andreas
--
Andrea
I am confronting a design decision involving null values and I
cannot seem to discern which way to go. Therefore, I would like
some commentary based on real world experience.
The basic issue is episodic duration, expressed as columns named
dt_effective_from and dt_superseded_after. Both are dat
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Is there a reliable way to find out the (Unix) PID associated with a
> database handle generated by Perl DBI's database connection?
$dbh->{pg_pid}
- --
Greg Sabino Mullane g...@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200903121
James B. Byrne wrote:
> The basic issue is episodic duration, expressed as columns named
> dt_effective_from and dt_superseded_after. Both are datetime types
> containing values normalized to utc. You see where this is going.
>
> The issue is what to enter when the value is known to be unknown,
Both ways will work.
Setting the superseded_after to a far off future will work but will have
to set to a real date when it actual does become superseded.
The same is true for nulls It boils down to how you and the users want
to look at the data.
To me to get the all the records that has n
On Wednesday 11 March 2009, Glen Parker wrote:
> We have yet to recover from a PG disaster. We back up every night, and
> never use the back ups for anything. To me, it seems perfectly
> reasonable to get a quicker back up every night, with the remote
> possibility of ever having to pay the pric
In response to "James B. Byrne" :
>
> The basic issue is episodic duration, expressed as columns named
> dt_effective_from and dt_superseded_after. Both are datetime types
> containing values normalized to utc. You see where this is going.
>
> The issue is what to enter when the value is known
On Thu, 2009-03-12 at 11:32 -0400, James B. Byrne wrote:
> The basic issue is episodic duration, expressed as columns named
> dt_effective_from and dt_superseded_after. Both are datetime types
> containing values normalized to utc. You see where this is going.
I assume you're concern is NULL fo
Hi,
Maybe you can use something like the following:
test=# select * from t1;
t
---
'leas':4 'return':2
'leas':2 'found':1 'address':5 'hardwar':4 '65.110.236.113':6
'00':3 '17':4 '1d':7 '27'
Hi
I've installed the postgresql in my computer but i've forgotten my password.
i've tried everything, i've been in your page that requires a e-mail to send
information to reset the password but i never get the e-mail so
far.(http://www.postgresql.org/community/lostpwd)
i've tried to make a new u
On 12/03/2009 16:51, André Silva wrote:
> I've installed the postgresql in my computer but i've forgotten my
> password.
Do you mean the password for the super-user account in PostgreSQL itself
(usually "postgres")? - or the password for the user account on the
machine under which PostgreSQL runs
André Silva wrote:
Hi
I've installed the postgresql in my computer but i've forgotten my password.
i've tried everything, i've been in your page that requires a e-mail to
send information to reset the password but i never get the e-mail so
far.(http://www.postgresql.org/community/lostpwd)
i've
André Silva wrote:
> Hi
> I've installed the postgresql in my computer but i've forgotten my password.
> i've tried everything, i've been in your page that requires a e-mail to send
What have you tried exactly? And what error-messages you got?
> information to reset the password but i never ge
On Thu, 12 Mar 2009, Andreas Kretschmer wrote:
I've installed the postgresql in my computer but i've forgotten my password.
i've tried everything, i've been in your page that requires a e-mail to send
i've tried to make a new username but the ones that i've tried already exist.
What can i do?
Tom Lane wrote:
Glen Parker writes:
Tom Lane wrote:
... AFAICS what
Glen is proposing is to not WAL-log index changes, and with that any
crash no matter how minor would have to invalidate indexes.
Nooo...! This has nothing to do with WAL logging index changes.
How so? In any PITR-based
Tom Lane wrote:
Glen Parker writes:
We have yet to recover from a PG disaster. We back up every night, and
never use the back ups for anything. To me, it seems perfectly
reasonable to get a quicker back up every night, with the remote
possibility of ever having to pay the price for it.
Wh
On 12/03/2009 19:56, Rich Shepard wrote:
> will allow this. If the machine runs Microsoft, I've no idea at all
Start Menu
-> Administrative Tools
-> Computer Management
-> Local Users & Groups
-> Users
...then right-click on the user, and select "Set password".
Ray.
---
On Thu, 2009-03-12 at 12:59 -0700, Glen Parker wrote:
> Tom Lane wrote:
> > Glen Parker writes:
> >> We have yet to recover from a PG disaster. We back up every night, and
> >> never use the back ups for anything. To me, it seems perfectly
> >> reasonable to get a quicker back up every night,
Scott Marlowe wrote:
That's two people now who have called the idea "silly" without even a hint
of a supporting argument. Why would it be "silly" to improve the
performance of a highly valuable tool set without compromising its utility?
Because it's the size of the WAL files that kills most pe
Raymond O'Donnell wrote:
On 12/03/2009 19:56, Rich Shepard wrote:
will allow this. If the machine runs Microsoft, I've no idea at all
Start Menu
-> Administrative Tools
-> Computer Management
-> Local Users & Groups
-> Users
...then right-click on the user, and se
Glen Parker escribió:
> I've re-read my original email and I just can't see how anybody got the
> idea I was suggesting to not WAL record index changes.
The subject says that.
> That would be insanity IMO.
Agreed :-)
--
Alvaro Herrerahttp://www.CommandPromp
Hi,
I'm setting up a replacement standby server. I've had this working
before until the old standby server lost a drive array and a
motherboard. So, my process was working. On the other hand, the old
slave was debian etch, with a backported 8.2 release, and the new one
is ubuntu 8.04.
On Thu, March 12, 2009 12:00, Richard Huxton wrote:
> James B. Byrne wrote:
>> The basic issue is episodic duration, expressed as columns named
>> dt_effective_from and dt_superseded_after. Both are datetime
>> types containing values normalized to utc.
>
> If it's unknown use null.
>
>> in some
Assume that I have the following database:
Database:mydb
Schema: mydb_schema
Tables:mydb_table1
mydb_table2
mydb_table3
I create a role: Create Role dbuser LOGIN;
mydb=# grant all privileges on mydb_schema.mydb_table1 to dbuser;
mydb=# g
On Mar 12, 2009, at 5:50 PM, James B. Byrne wrote:
...
and c.date_effective_from >=
and c.date_superseded_after <=
Have I understood things aright?
The one problem I foresee is that changes to the commodity_tax_rates
table may not reflect in transaction dates that have passed. What
Jack W wrote:
I also find that if I only grant privileges on database to dbuser as
below, without granting privileges on Schema and table to dbuser,
dbuser still can not do SELECT on the tables.
mydb=# grant all privileges on Database mydb to dbuser;
Is there any simple way to grant All priv
Eric Soroos writes:
> 2009-03-12 13:40:18 PDT LOG: starting archive recovery
> 2009-03-12 13:40:18 PDT LOG: restore_command = "/usr/lib/postgresql/
> 8.2/bin/pg_standby -l -d -k 100 -r 2 -s 2 -w 0 -t /tmp/pgsql.trigger.
> 5432 /data/pg/repl-db3 %f %p 2>> standby.log"
> 2009-03-12 13:40:18 PDT
Glen Parker writes:
> I've re-read my original email and I just can't see how anybody got the
> idea I was suggesting to not WAL record index changes.
Mainly because the idea doesn't seem to make sense unless that's part
of the package. If you don't cut index changes out of the WAL load
then th
Alan Hodgson writes:
> I have done PITR recoveries (unfortunately). The log replay time dwarfs the
> time it takes to copy the index files back over (it is, honestly, slower
> than the original transactions were).
Yeah :-( ... the problem is that recovery is serialized while the
original transa
Tom Lane wrote:
Glen Parker writes:
Mainly because the idea doesn't seem to make sense unless that's part
of the package. If you don't cut index changes out of the WAL load
then the savings on the base backup alone aren't going to be all that
exciting when you consider the total cost of PITR ba
On Thu, Mar 12, 2009 at 3:45 PM, John R Pierce wrote:
> Jack W wrote:
>
>>
>> I also find that if I only grant privileges on database to dbuser as
>> below, without granting privileges on Schema and table to dbuser, dbuser
>> still can not do SELECT on the tables.
>> mydb=# grant all privileges o
2) What file is not found? It sorta looks like the pg_standby
binary, but I'm not sure that I believe that.
Permissions problems on some containing directory, perhaps?
It's the same directory as the postgresql binaries, and they all have
sane
permissions. (root:root, 755). Ls finds it,
Do I really need 4 indexes per column to handle the 4 combinations of
{equality,like/regexp} x {unfolded,casefolded} in a UTF-8 encoded
database?
I have a column that I'd like to be able to search with equality and
regexp (or like), optionally casefolded. The database is UTF-8 encoded.
The table a
On Thursday 12 March 2009 5:00:39 pm Jack W wrote:
> On Thu, Mar 12, 2009 at 3:45 PM, John R Pierce wrote:
> > Jack W wrote:
> >> I also find that if I only grant privileges on database to dbuser as
> >> below, without granting privileges on Schema and table to dbuser, dbuser
> >> still can not do
On Mar 12, 2009, at 5:15 PM, Reece Hart wrote:
Do I really need 4 indexes per column to handle the 4 combinations of
{equality,like/regexp} x {unfolded,casefolded} in a UTF-8 encoded
database?
I have a column that I'd like to be able to search with equality and
regexp (or like), optionally cas
On Thu, 2009-03-12 at 17:15 -0700, Reece Hart wrote:
> Jeff Davis gave me a tip to use text_pattern_ops on indexes to speed up
> regexp and like; that worked beautiful. But I discovered a caveat that
> t_p_o apparently doesn't handle equality. Thus, I think I need distinct
> indexes for the 4 cases
On Thu, 2009-03-12 at 18:02 -0700, Jeff Davis wrote:
> It looks like an index using text_pattern_ops can be used for equality
> (see my test case below).
Odd. I can't reproduce your test case. I noticed that I edited out the
version and platform from my OP. (A: 8.3.6, x86_64 linux). You're on
8.3.
On Thu, 2009-03-12 at 17:32 -0700, Steve Atkins wrote:
> If A=B then lower(A) = lower(B), and if A like B then lower(A) like
> lower(B).
>
> So, if nothing else, you could rewrite "where alias = 'Foo'" as
> "where lower(alias) = lower('Foo') and alias='Foo'" and take advantage
> of the lower()
46 matches
Mail list logo
