Samantha Atkins shaped electrons to ask:
>
> What do you consider the most logical, one database per user?
>
> - samantha
Perhaps a schema per user ? Then you can have the common tables (look up
values, whatever) in the public schema. Each user gets a schema that has all of
the tables they sha
Samantha Atkins wrote:
On Oct 29, 2007, at 10:14 AM, Richard Huxton wrote:
Samantha Atkins wrote:
First on prepared statements:
1) If I am using the libpq are prepared statements tied to a
connection? In other words can I prepare the statement once and use
it on multiple connections?
Pe
On Oct 29, 2007, at 10:14 AM, Richard Huxton wrote:
Samantha Atkins wrote:
First on prepared statements:
1) If I am using the libpq are prepared statements tied to a
connection? In other words can I prepare the statement once and
use it on multiple connections?
Per session (connection).
Samantha Atkins wrote:
First on prepared statements:
1) If I am using the libpq are prepared statements tied to a
connection? In other words can I prepare the statement once and use it
on multiple connections?
Per session (connection).
Temporary tables etc. are the same.
2) What is the lo
On Mon, Oct 29, 2007 at 09:52:55AM -0700, Samantha Atkins wrote:
> First on prepared statements:
>
> 1) If I am using the libpq are prepared statements tied to a
> connection? In other words can I prepare the statement once and use
> it on multiple connections?
Yes they are, and no, you can't.
On Mon, 29 Oct 2007 09:52:55 -0700
Samantha Atkins <[EMAIL PROTECTED]> wrote:
> First on prepared statements:
>
> 1) If I am using the libpq are prepared statements tied to a
> connection?
Yes.
> In other words can I prepare the statement once and use
> it on multiple connections?
No.
>
On Wednesday 1 August 2007 Gregory Stark's cat, walking on the keyboard,
wrote:
> You're right, the index contains pointers to *every* version of the tuple.
> So in a regular SELECT statement you don't need to look at the update chain
> at all.
>
> The main use of the update chain is when you wan
"Luca Ferrari" <[EMAIL PROTECTED]> writes:
> Thanks fot these details. Now a few other questions come into my mind (I hope
> not to bother you guys!).
>
> In chapter 49 of the documentation (index access) I read that an index stores
> pointers to any version of the tuple that is present in the
On Friday 27 July 2007 Alvaro Herrera's cat, walking on the keyboard, wrote:
> Consider an open cursor; you open it and leave it there. Then you
> delete something from the table. Then you read from the cursor. The
> deleted row must be in the cursor.
Thanks fot these details. Now a few other q
Luca Ferrari wrote:
> Thanks all for your comments. Just another little hint here (sorry for
> trivial
> questions):
>
> if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tuple)))
> {
> if (tuple->t_infomask & HEAP_IS_LOCKED)
> return
Thanks all for your comments. Just another little hint here (sorry for trivial
questions):
if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(tuple)))
{
if (tuple->t_infomask & HEAP_IS_LOCKED)
return true;
if (Hea
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What's going on here is that we use Xmax not only for storing "this
> transaction deleted the row" but also for storing "this transaction
> locked the row". So the row is not really deleted at all. The
> IS_LOCKED bit tells you whether the row is locke
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> > Just for confirmation: the relfrozenxid of a fresh table is the xid of the
>> > transaction that created it, isn't it?
>>
>> Yes, easily enough checked:
>>
>> postgres=# create table xyz (i integer);
>> CREATE TABLE
>> p
Luca Ferrari wrote:
> On Wednesday 25 July 2007 Gregory Stark's cat, walking on the keyboard, wrote:
> > If you really want to understand how snapshots work at this level you could
> > read (slowly -- it's pretty dense stuff) through
> > src/backend/utils/time/tqual.c:HeapTupleSatisfiesMVCC()
>
>
On Wednesday 25 July 2007 Gregory Stark's cat, walking on the keyboard, wrote:
> If you really want to understand how snapshots work at this level you could
> read (slowly -- it's pretty dense stuff) through
> src/backend/utils/time/tqual.c:HeapTupleSatisfiesMVCC()
Ok, I need a little hint here:
Gregory Stark wrote:
> > Just for confirmation: the relfrozenxid of a fresh table is the xid of the
> > transaction that created it, isn't it?
>
> Yes, easily enough checked:
>
> postgres=# create table xyz (i integer);
> CREATE TABLE
> postgres=# select xmin,relfrozenxid from pg_class where re
"Luca Ferrari" <[EMAIL PROTECTED]> writes:
>> If you really want to understand how snapshots work at this level you could
>> read (slowly -- it's pretty dense stuff) through
>> src/backend/utils/time/tqual.c:HeapTupleSatisfiesMVCC()
>
> I don't find it, I think you mean HeapTupleSatisfiesNow and
Thanks Gregory, thanks Simon.
I'm trying to read the tqual.c source file to better understand.
On Wednesday 25 July 2007 Gregory Stark's cat, walking on the keyboard, wrote:
> If you really want to understand how snapshots work at this level you could
> read (slowly -- it's pretty dense stuff) thr
On Tue, 2007-07-24 at 19:51 +0200, Luca Ferrari wrote:
> Now, for subtrans the xid is laizyly obtained, due to efficiency purposes.
> But
> in such way subtrans xid should be greater than each other xid of concurrent
> (main) transactions. If the subtrans inserts a record is the subtrans xid
>
"Luca Ferrari" <[EMAIL PROTECTED]> writes:
> In short each transaction with xmin<=xid<=xmax can see such tuple,
> otherwise it cannot (of course beeing xmin and xmax different transtaction
> from xid and beeing committed), isn't it?
No, it's more complicated than that. We can't simply compare x
Marco Colombo wrote:
> I'll try that out. Maybe my ideas are so far from the truth that I'm
> having a hard time in explaing them to people who actually know how
> things work. I'll be back with results. Meanwhile, thanks for your time.
I think I finally got it.
Segment 34 in my pg_xlog got archi
Tom Lane wrote:
> Marco Colombo <[EMAIL PROTECTED]> writes:
>> Good to know, thanks. I think I'll experiment a bit with
>> archive_command. My point was that since I know (or better assume) that
>> old segments are going to stay in my pg_xlog for *days* before getting
>> recycled,
>
> On what do y
Marco Colombo <[EMAIL PROTECTED]> writes:
> Good to know, thanks. I think I'll experiment a bit with
> archive_command. My point was that since I know (or better assume) that
> old segments are going to stay in my pg_xlog for *days* before getting
> recycled,
On what do you base that assumption?
Richard Huxton wrote:
> It calls archive_command on the just-filled one.
Good to know, thanks. I think I'll experiment a bit with
archive_command. My point was that since I know (or better assume) that
old segments are going to stay in my pg_xlog for *days* before getting
recycled, just copying th
Hi,
The procedure you followed is for online backups. The backups are useless
unless you set archive_command in your postgresql.conf file. This command
will copy the filled transaction log to a directory where you specified in
your archive_command. The PG won't write to transaction logs unless it
Marco Colombo wrote:
Mmm, sorry I'm not sure I'm following here. Maybe I should provide some
background. In my pg_xlog directory I see five files, WAL segments, I
suppose. Only one (as I expected) is begin currently used, the others
are old (one a couple of days old).
When PG performs a switch f
Tom Lane wrote:
> No. You have to have an actual archive_command script copying the WAL
> segments somewhere else when told to. An asynchronous copy of the xlog
> directory will be nothing but garbage, because we recycle WAL segments
> as fast as we can (ie, as soon as the archive_command claims
On 14.05.2007 16:54, Marco Colombo wrote:
I have a few questions on backuping a PostgreSQL server (lets say
anything 8.x.x). I've read "Continuous Archiving and Point-In-Time
Recovery (PITR)" in the manual I'm still missing something...well
actually I think I don't but I've been debating on this
Marco Colombo <[EMAIL PROTECTED]> writes:
> Am I right in assuming that the following procedure is ok?
> 1) issue pg_start_backup();
> 2) copy (or tar or cpio) the data dir, w/o pg_xlog/
> 3) issue pg_stop_backup();
> 4) copy (or tar or cpio) pg_xlog/ contents.
No. You have to have an actual arc
Nis Jorgensen wrote:
> Martijn van Oosterhout wrote:
>
> > I beleive there is a regexp_replace. In psql, if you type \df you get a
> > list of all defined functions. The docs have info too.
>
> The function is confusingly not mentioned in the documentation under
> "String Functions and Operators"
Martijn van Oosterhout wrote:
# select replace('aac','a','b');
replace
-
bbc
(1 row)
So replace(str, '\r', '\\r') should work
Perfect, thanks.
I guess I'm blind, I didn't see this in the docs. :)
-Jon
--
-**-*-*---*-*---*-*---*-*-*-*---*-*---*-*-*-*-*---
Jo
Martijn van Oosterhout wrote:
> I beleive there is a regexp_replace. In psql, if you type \df you get a
> list of all defined functions. The docs have info too.
The function is confusingly not mentioned in the documentation under
"String Functions and Operators", but only under "Pattern Matching"
On Thu, Jun 15, 2006 at 11:51:21AM -0300, Jon Lapham wrote:
> So, as I understand it (please correct me if I'm wrong), UNIX uses a
> "newline" (or \n), Mac uses "carriage return" (or \r) and Win/DOS uses
> \r\n.
Correct.
> 1) Does anyone know why the "id" column is not visible for the final
>
Stephan Szabo wrote:
On Fri, 21 Apr 2006, Alban Hertroys wrote:
Stephan Szabo wrote:
SQL> CREATE TABLE ltree_test (path ltree PRIMARY KEY REFERENCES
ltree_test(path));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"ltree_test_pkey" for table "ltree_test"
CREATE TABLE
SQL> INSE
On Fri, 21 Apr 2006, Alban Hertroys wrote:
> Stephan Szabo wrote:
> >>SQL> CREATE TABLE ltree_test (path ltree PRIMARY KEY REFERENCES
> >>ltree_test(path));
> >>NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> >>"ltree_test_pkey" for table "ltree_test"
> >>CREATE TABLE
> >>SQL> INS
Is it really necessary to insert an 'empty' record for the root node?
The 'a' record from my experiments seems to be quite suited for the
task, unless I'm missing something.
The root should be and it will be unremovable, because of foreign keys. But it
can be, of course, not empty.
alter
Stephan Szabo wrote:
SQL> CREATE TABLE ltree_test (path ltree PRIMARY KEY REFERENCES
ltree_test(path));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"ltree_test_pkey" for table "ltree_test"
CREATE TABLE
SQL> INSERT INTO ltree_test VALUES ('a'::ltree);
INSERT 84117368 1
SQL> INSE
On Fri, 21 Apr 2006, Alban Hertroys wrote:
> Teodor Sigaev wrote:
> >> Maybe something along the lines of the following is possible?:
> >
> > Exact, it's for what ltree was developed.
>
> Cool, looks like it is what I need then.
>
> > contrib_regression=# select 'a.b.c' <@ 'a.b'::ltree;
> > ?colu
Teodor Sigaev wrote:
We've been experimenting with a table containing a branch 'a', 'a.b'
and 'a.b.c', but deleting 'a.b' didn't cause a constraint violation.
SQL> CREATE TABLE ltree_test (path ltree PRIMARY KEY REFERENCES
ltree_test(path));
Sorry, only by using triggers on insert/delete/
We've been experimenting with a table containing a branch 'a', 'a.b' and
'a.b.c', but deleting 'a.b' didn't cause a constraint violation.
SQL> CREATE TABLE ltree_test (path ltree PRIMARY KEY REFERENCES
ltree_test(path));
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"ltree_t
Teodor Sigaev wrote:
Maybe something along the lines of the following is possible?:
Exact, it's for what ltree was developed.
Cool, looks like it is what I need then.
contrib_regression=# select 'a.b.c' <@ 'a.b'::ltree;
?column?
--
t
(1 row)
How would you use this to constrain a
That's the "classical" way, which is also used in our current
implementation with integers instead of ltrees, but it's not very easy
to query efficiently (at least ordering seems to remain a problem).
That (with integer ids) is classic way to support graph structure, ltree was
develop speciall
On Fri, Dec 30, 2005 at 06:21:28PM +0530, surabhi.ahuja wrote:
> I am working with PostgerSQL 8.0.0.
> where can i find the startup scripts for the same.
Well, it's been in contrib/strat-scripts since 8.0.0 so you should find
it there.
> One more thing,
> I could not understand this:
> number of
On Thu, Dec 29, 2005 at 03:40:11PM +0530, surabhi.ahuja wrote:
> pidof of doesnt work ?
Given the number of processes is going to be at least 3+number of
connections, how is pidof going to know which one you mean? Answer: it
doesn't, so you end up killing a random one.
> which startup script are
On Thu, Dec 29, 2005 at 03:09:52PM +0530, surabhi.ahuja wrote:
> I have a few questions:
> 1. what is pg_xlog
> someone told me that i can move pg_xlog to a different parttion in order to
> boost the performance? Does it work and how
Yes, it works. How? By moving the directory (while the postmas
45 matches
Mail list logo
