I would be *very* concerned that system time is not a guaranteed
monotonic entity. Surely a counter or other internally managed mechanism
would be a better solution.
Furthermore, what would be the ramifications of master and slave system
times being out of sync?
Finally what if system time
Andrew Dunstan wrote:
I am constantly running into this:
Q. Does PostgreSQL have full text indexing?
A. Yes it is in contrib.
Q. But that isn't part of core.
A. *sigh*
Where on the website can I see what plugins are included with
PostgreSQL?
Where on the website can I see the Official
I'd like to see still more evidence that it's a problem before we start
changing that piece of code. It has served us well for years.
Bruce Momjian wrote:
Is there a TODO here?
---
Heikki Linnakangas wrote:
Pavan
Hi,
Alvaro Herrera wrote:
Yeah. For what I need, the launcher just needs to know when a worker
has finished and how many workers there are.
Oh, so it's not all that less communication. My replication manager also
needs to know when a worker dies. You said you are using a signal from
Hi,
Jan Wieck wrote:
The replication system I have in mind will have another field type of
the balance nature, where it will never communicate the current value
but only deltas that get applied regardless of the two timestamps.
I'd favor a more generally usable conflict resolution function
Jan Wieck wrote:
But it is a datum that needs to be collected at the moment where
basically the clog entry is made ... I don't think any external module
can do that ever.
How atomic does it need to be? External modules can register callbacks
that get called right after the clog update and
The CONNECT BY patch from evgen potemkin has been ported to pg 8.2...
and it's now in BSD License...
I will test it on our test environement
Le jeudi 25 janvier 2007 à 11:08 +, Gregory Stark a écrit :
Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
it quite
Hi,
Nice proposal. I'd support that enhancement and could make use of such
triggers in Postgres-R as well, at least to provide these triggers to
the user.
Jan Wieck wrote:
Good question. I don't know. I'd rather error on the safe side and make
it multiple states, for now I only have Normal
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm afraid the bug has been there for ages, but the 90%-fillfactor on
rightmost page patch made it much more likely to get triggered.
But that patch has been there for ages too; the only new thing in 8.2 is
that the fillfactor is
On Thu, 2007-01-25 at 22:19 -0500, Jan Wieck wrote:
The idea is to clone an existing serializable transactions snapshot
visibility information from one backend to another. The semantics would
be like this:
backend1: start transaction;
backend1: set transaction isolation level
Jan Wieck [EMAIL PROTECTED] writes:
backend1: select publish_snapshot(); -- will block
backend2: start transaction;
backend2: set transaction isolation level serializable;
backend2: select clone_snapshot(pid); -- will unblock backend1
It seems simpler to have a
Jan, et. al.,
On Jan 26, 2007, at 2:37 AM, Naz Gassiep wrote:
I would be *very* concerned that system time is not a guaranteed
monotonic entity. Surely a counter or other internally managed
mechanism would be a better solution.
As you should be concerned. Looking on my desk through the
On 1/26/2007 2:37 AM, Naz Gassiep wrote:
I would be *very* concerned that system time is not a guaranteed
monotonic entity. Surely a counter or other internally managed mechanism
would be a better solution.
Such a counter has only local relevance. How do you plan to compare
the two separate
On Thu, 2007-01-25 at 18:16 -0500, Jan Wieck wrote:
To provide this data, I would like to add another log directory,
pg_tslog. The files in this directory will be similar to the clog, but
contain arrays of timestamptz values. On commit, the current system time
will be taken. As long as
On 1/26/2007 8:06 AM, Gregory Stark wrote:
Jan Wieck [EMAIL PROTECTED] writes:
backend1: select publish_snapshot(); -- will block
backend2: start transaction;
backend2: set transaction isolation level serializable;
backend2: select clone_snapshot(pid); -- will unblock backend1
On 1/26/2007 8:26 AM, Simon Riggs wrote:
On Thu, 2007-01-25 at 18:16 -0500, Jan Wieck wrote:
To provide this data, I would like to add another log directory,
pg_tslog. The files in this directory will be similar to the clog, but
contain arrays of timestamptz values. On commit, the current
I've just read a paper that says PostgreSQL doesn't do this. My reading
of the code is that we *do* evaluate the HAVING clause prior to
calculating the aggregates for it. I thought I'd check to resolve the
confusion.
- - -
If not, it seems fairly straightforward to push down some or all of a
Ühel kenal päeval, R, 2007-01-26 kell 12:25, kirjutas Simon Riggs:
On Thu, 2007-01-25 at 22:19 -0500, Jan Wieck wrote:
The idea is to clone an existing serializable transactions snapshot
visibility information from one backend to another. The semantics would
be like this:
Heikki Linnakangas wrote:
I'd like to see still more evidence that it's a problem before we start
changing that piece of code. It has served us well for years.
So the TODO could be investigate whether caching pg_clog and/or
pg_subtrans in local memory can be useful for vacuum performance.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Peter Eisentraut replied:
The harm here is that under undefined circumstances a dump file
will not be a proper and robust representation of the original
database, which would add significant confusion and potential for error.
What
On Fri, 2007-01-26 at 16:09 +0200, Hannu Krosing wrote:
Ühel kenal päeval, R, 2007-01-26 kell 12:25, kirjutas Simon Riggs:
Two questions:
- why does it have to block? I don't see any reason - the first process
can begin doing useful work. The second process might fail or itself be
Markus Schiltknecht wrote:
Hi,
Alvaro Herrera wrote:
Yeah. For what I need, the launcher just needs to know when a worker
has finished and how many workers there are.
Oh, so it's not all that less communication. My replication manager also
needs to know when a worker dies. You said you
On Fri, 2007-01-26 at 16:09 +0200, Hannu Krosing wrote:
Ühel kenal päeval, R, 2007-01-26 kell 12:25, kirjutas Simon Riggs:
Great idea. It can also be used by pg_dump to publish its snapshot so
that we can make VACUUM continue to process effectively while it pg_dump
is running.
Do you
* Jan Wieck ([EMAIL PROTECTED]) wrote:
On 1/26/2007 2:37 AM, Naz Gassiep wrote:
I would be *very* concerned that system time is not a guaranteed
monotonic entity. Surely a counter or other internally managed mechanism
would be a better solution.
Such a counter has only local relevance.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm still wondering why the bug isn't seen in 8.1.
The hardcoded fillfactor was 90% when building an index, and that's
still the default. However, when inserting to an existing index, the
fillfactor on the rightmost page was 2/3.
Stephen Frost wrote:
I'd also suggest you look into Lamport timestamps... Trusting the
system clock just isn't practical, even with NTP. I've developed
(albeit relatively small) systems using Lamport timestamps and would be
happy to talk about it offlist. I've probably got some code I could
I wrote:
Tom Lane wrote:
I think parseTypeString() may be the thing to use. It's what plpgsql
uses...
OK, I'll see what I can do.
see attached patch. If this is OK I will apply it and also fix pltcl
and plpython similarly, mutatis mutandis.
cheers
andrew
Index:
Simon Riggs [EMAIL PROTECTED] writes:
I've just read a paper that says PostgreSQL doesn't do this. My reading
of the code is that we *do* evaluate the HAVING clause prior to
calculating the aggregates for it. I thought I'd check to resolve the
confusion.
- - -
If not, it seems fairly
Andrew Dunstan [EMAIL PROTECTED] writes:
see attached patch. If this is OK I will apply it and also fix pltcl
and plpython similarly, mutatis mutandis.
Looks alright as far as it goes, but I'd suggest making one additional
cleanup while you're in there: get rid of the direct syscache access
On Fri, 2007-01-26 at 15:22 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I've just read a paper that says PostgreSQL doesn't do this. My reading
of the code is that we *do* evaluate the HAVING clause prior to
calculating the aggregates for it. I thought I'd check to
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
To see what's going on, I added some logs to the split code to print out
the free space on both halves as calculated by findsplitloc, and the
actual free space on the pages after split. I'm seeing a discrepancy of
4 bytes on the
On Thu, 2007-01-25 at 16:20 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
A simpler, alternate proposal is to allow the user to specify whether a
functional index is transformable or not using CREATE or ALTER INDEX,
with a default of not transformable. That then leaves the
Simon Riggs wrote:
On Fri, 2007-01-26 at 15:22 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I've just read a paper that says PostgreSQL doesn't do this. My reading
of the code is that we *do* evaluate the HAVING clause prior to
calculating the aggregates for it. I
Heikki Linnakangas [EMAIL PROTECTED] writes:
IMHO the right fix is to modify PageGetFreeSpace not to do the
subtraction, it's a hack anyway, but that means we have to go through
and fix every caller of it. Or we can add a new PageGetReallyFreeSpace
function and keep the old one for
On 1/26/2007 9:38 AM, Stephen Frost wrote:
* Jan Wieck ([EMAIL PROTECTED]) wrote:
On 1/26/2007 2:37 AM, Naz Gassiep wrote:
I would be *very* concerned that system time is not a guaranteed
monotonic entity. Surely a counter or other internally managed mechanism
would be a better solution.
Simon Riggs [EMAIL PROTECTED] writes:
If there's clear benefit and a clear way forward, then we might just be
OK for 8.3. If not, I'll put this back on the shelf again in favour of
other ideas.
I think this is still a long way off, and there are probably more useful
things to work on for 8.3.
Simon Riggs [EMAIL PROTECTED] writes:
I've just read a paper that says PostgreSQL doesn't do this.
What does he mean by that exactly, and which PG version is he looking
at? As Greg notes, we do know how to push down non-aggregated
conditions, but I'm not sure that's what he's thinking of.
On Fri, 2007-01-26 at 11:16 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I've just read a paper that says PostgreSQL doesn't do this.
What does he mean by that exactly, and which PG version is he looking
at? As Greg notes, we do know how to push down non-aggregated
On 1/26/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Heikki Linnakangas wrote:
I'd like to see still more evidence that it's a problem before we start
changing that piece of code. It has served us well for years.
So the TODO could be investigate whether caching pg_clog and/or
pg_subtrans in
[EMAIL PROTECTED] (Markus Schiltknecht) writes:
Nice proposal. I'd support that enhancement and could make use of such
triggers in Postgres-R as well, at least to provide these triggers to
the user.
Jan Wieck wrote:
Good question. I don't know. I'd rather error on the safe side and
make it
[EMAIL PROTECTED] (Gregory Stark) writes:
Jan Wieck [EMAIL PROTECTED] writes:
backend1: select publish_snapshot(); -- will block
backend2: start transaction;
backend2: set transaction isolation level serializable;
backend2: select clone_snapshot(pid); -- will unblock
Pavan Deolasee wrote:
On 1/26/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Heikki Linnakangas wrote:
I'd like to see still more evidence that it's a problem before we start
changing that piece of code. It has served us well for years.
So the TODO could be investigate whether caching
Simon Riggs [EMAIL PROTECTED] writes:
No, that would break MVCC. But we may have done lots of updates/deletes
that are *not* visible to any Snapshot, yet are not yet removable
because they are higher than OldestXmin but we don't know that because
previously the Snapshot details were not
On Fri, 2007-01-26 at 10:58 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
If there's clear benefit and a clear way forward, then we might just be
OK for 8.3. If not, I'll put this back on the shelf again in favour of
other ideas.
I think this is still a long way off, and
Hannu Krosing [EMAIL PROTECTED] writes:
Ãhel kenal päeval, N, 2007-01-25 kell 22:19, kirjutas Jan Wieck:
The cloning process needs to make sure that the clone_snapshot() call is
made from the same DB user in the same database as corresponding
publish_snapshot() call was done.
Why ?
On 1/26/07, Alvaro Herrera [EMAIL PROTECTED] wrote:
Maybe have the bgwriter update hint bits as it evicts pages out of the
cache? It could result in pg_clog read traffic for each page that needs
eviction; not such a hot idea.
I thought once we enhance clog so that there are no clog reads,
On Fri, 2007-01-26 at 07:46 -0800, Joshua D. Drake wrote:
Care to share the paper in general? It might be beneficial for all of us.
I'll ask the author, but don't expect an immediate response.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Hm, I had hoped that the DB2/ANSI syntax would only require making WITH a
fully reserved word, and not the other tokens it uses. Certainly for
non-recursive queries that's the case as the only other token it uses is AS
which is already a fully reserved word.
However to fully support the DB2/ANSI
On Fri, 2007-01-26 at 11:36 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
No, that would break MVCC. But we may have done lots of updates/deletes
that are *not* visible to any Snapshot, yet are not yet removable
because they are higher than OldestXmin but we don't know that
Tom Lane [EMAIL PROTECTED] writes:
set_current_snapshot() would have to sanity check that the xmin of the new
snapshot isn't older than the current globaloldestxmin.
That would solve the backend to backend IPC problem nicely.
But it fails on the count of making sure that globaloldestxmin
Alvaro Herrera [EMAIL PROTECTED] writes:
Pavan Deolasee wrote:
It would also be interesting to investigate whether early setting of
hint bits can reduce subsequent writes of blocks. A typical case would
be a large table being updated heavily for a while, followed by SELECT
queries. The SELECT
On 1/26/2007 12:22 PM, Simon Riggs wrote:
On Fri, 2007-01-26 at 11:36 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
No, that would break MVCC. But we may have done lots of updates/deletes
that are *not* visible to any Snapshot, yet are not yet removable
because they are higher
Woah, I just realized it's much worse than that. I think the syntax in the
ANSI is not parsable in LALR(1) at all. Note the following:
WITH RECURSIVE foo (a,b) AS (subq) SEARCH BREADTH FIRST BY a,b,c(x,z),d(y,z) AS
(subq) SELECT ...
To determine whether c is the name of a new with list element
On 1/26/2007 11:58 AM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
On 1/26/2007 8:06 AM, Gregory Stark wrote:
It seems simpler to have a current_snapshot() function that returns an bytea
or a new snapshot data type which set_current_snapshot(bytea) took to change
your snapshot. Then
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Peter Eisentraut replied:
The harm here is that under undefined circumstances a dump file
will not be a proper and robust representation of the original
database, which would add significant confusion and potential for error.
What undefined
Gregory Stark wrote:
Woah, I just realized it's much worse than that. I think the syntax in the
ANSI is not parsable in LALR(1) at all. Note the following:
WITH RECURSIVE foo (a,b) AS (subq) SEARCH BREADTH FIRST BY a,b,c(x,z),d(y,z) AS
(subq) SELECT ...
To determine whether c is the name of a
On 1/26/07, Tom Lane [EMAIL PROTECTED] wrote:
I think what he's suggesting is deliberately not updating the hint bits
during a SELECT ...
No, I was suggesting doing it in bgwriter so that we may not need to that
during
a SELECT. Of course, we need to investigate more and have numbers to
Checked it against HEAD and 8.2:
postgres=# select 1, 1, 1 union select * from (select 2, null, 2) two;
ERROR: failed to find conversion function from unknown to integer
Jan
--
#==#
# It's easier to get forgiveness for being
On Wed, Jan 24, 2007 at 07:30:05PM -0500, Tom Lane wrote:
Kenneth Marshall [EMAIL PROTECTED] writes:
Not that I am aware of. Even extending the relation by one additional
block can make a big difference in performance
Do you have any evidence to back up that assertion?
It seems a bit
Dear Developers,
Thanks for your answers. I didn't know about
generate_series, but it looks to be exactly what
I was suggesting.
Regards,
Sorin Schwimmer
Do you Yahoo!?
Everyone is raving about the all-new
Andrew Dunstan [EMAIL PROTECTED] writes:
Can you post the rules you have so far that you're playing around with? (Also
maybe the rules from the standard - I don't have a copy handy).
This is the best compromise I've come up with so far. It makes CYCLE a
reserved word and requires a CYCLE
Folks,
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..
Regards,
Gevik
---(end of broadcast)---
TIP 5: don't forget to increase
Jan Wieck [EMAIL PROTECTED] writes:
Checked it against HEAD and 8.2:
postgres=# select 1, 1, 1 union select * from (select 2, null, 2) two;
ERROR: failed to find conversion function from unknown to integer
It's always done that. The SQL spec would tell you that you have to
cast the null to
On Fri, Jan 26, 2007 at 05:10:01PM +, Gregory Stark wrote:
However to fully support the DB2/ANSI syntax we would definitely have an
ambiguity and I think we would have to make CYCLE a fully reserved word
which seems like a much bigger concession than WITH. Observe the following
case:
On 1/26/2007 3:41 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Checked it against HEAD and 8.2:
postgres=# select 1, 1, 1 union select * from (select 2, null, 2) two;
ERROR: failed to find conversion function from unknown to integer
It's always done that. The SQL spec would tell
On Fri, Jan 26, 2007 at 09:34:10PM +0100, Gevik Babakhani wrote:
Folks,
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..
Err, pthreads is a threads library for Unix, I don't
Hi list,
I am using pg_dump and pg_restore to backup and restore a database but
there is something
that I believe is missing from the restore process:
an option in pg_restore to exclude a schema from being dropped when -c
option is defined.
And here is why:
Suppose that I have a database
Hi everyone,
I have a problem with one of my costomers.
I made a program that uses a PostgreSQL (win32) database to save its data.
My customer claims that he lost lots of data reguarding his own clients
and that those data had surely been saved on the database.
My first guess is that he is the
pthreads in needed to buold PG in vc++ 2005
please read pgsql/src/tools/msvc/README
Have a nice day.
On Fri, 2007-01-26 at 21:47 +0100, Martijn van Oosterhout wrote:
On Fri, Jan 26, 2007 at 09:34:10PM +0100, Gevik Babakhani wrote:
Folks,
I would like to build pg on VC2005. How do I use
Ok, looking at your example:
WITH RECURSIVE foo (a,b) AS (subq) SEARCH BREADTH FIRST BY a,b , c(x,z),d(y,z)
AS (subq) SELECT ...
What you're trying to say is that the c is a with list element,
not a cycle column. But the parser will see that as soon as it hits
the open parenthesis, since a
On Jan 25, 2007, at 10:33 AM, Ray Stell wrote:
On Thu, Jan 25, 2007 at 08:04:49AM -0800, Joshua D. Drake wrote:
It really depends on the system. Most of our systems run anywhere
from
10-25ms. I find that any more than that, Vacuum takes too long.
How do you measure the impact of setting
Martijn van Oosterhout wrote:
On Fri, Jan 26, 2007 at 09:34:10PM +0100, Gevik Babakhani wrote:
Folks,
I would like to build pg on VC2005. How do I use pthreads that is
mentioned in the README file. Do I need the DLL? Sources? LIB?
Where do I install or copy them..
Err, pthreads is a
On Jan 25, 2007, at 6:26 PM, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote:
On 1/25/07, Jim C. Nasby [EMAIL PROTECTED] wrote:
decibel=# select box '((0,0),(2,2))' ~ point '(1,1)';
ERROR: operator does not
Martijn van Oosterhout kleptog@svana.org writes:
Er, CYCLE isn't a binary operator, and users can't make binary
operators that are words, so I'm not sure of the problem here.
Well, the problem typically is not being able to tell whether an
operator is supposed to be infix or postfix; hence
Kostis Mentzelos [EMAIL PROTECTED] writes:
Now, to backup the database I choose to create 2 scripts, BackupData.sh
to backup all small tables and BackupHist.sh to backup history tables.
When I call pg_restore -c to restore data tables, pg_restore report a
failure because it is trying to
On Fri, 2007-01-26 at 12:43 -0500, Jan Wieck wrote:
There is a flaw in that theory. If you have a single LTR, then each
subsequent transactions xmin will be exactly that one, no?
You got me. My description was too loose, but you also got the rough
picture. We'll save the detail for another
On Jan 26, 2007, at 9:31 AM, Tom Lane wrote:
If you wanted to be a bit more ambitious maybe you could change the
fact
that this code is throwing away typmod, which means that declarations
like varchar(32) would fail to work as expected. Perhaps it
should be
fixed to save the typmods
On Jan 26, 2007, at 5:13 AM, Markus Schiltknecht wrote:
In Postgres-R, I mostly use the terms 'local' and 'remote'.
Note that those terms only make sense if you limit yourself to
thinking the master is pushing data out to the slave...
I think it'd make the most sense if the name reflected
On Jan 25, 2007, at 5:33 PM, Jan Wieck wrote:
A new per session GUC variable, restricted to superusers, will
define if the session is in origin or replica mode.
It would be nice if we had a separate role for replication services
so that we weren't exposing superuser so much. IIRC Oracle
BluDes wrote:
I made a program that uses a PostgreSQL (win32) database to save its data.
What version of PostgreSQL is this?
My customer claims that he lost lots of data reguarding his own clients
and that those data had surely been saved on the database.
My first guess is that he is the one
On 1/26/2007 4:39 PM, Jim Nasby wrote:
On Jan 26, 2007, at 5:13 AM, Markus Schiltknecht wrote:
In Postgres-R, I mostly use the terms 'local' and 'remote'.
Note that those terms only make sense if you limit yourself to
thinking the master is pushing data out to the slave...
I think it'd
Simon Riggs [EMAIL PROTECTED] writes:
You got me. My description was too loose, but you also got the rough
picture. We'll save the detail for another day, but we all know its a
bridge we will have to cross one day, soon. I wasn't meaning to raise
this specific discussion now, just to say that
On 1/26/2007 4:40 PM, Jim Nasby wrote:
On Jan 25, 2007, at 5:33 PM, Jan Wieck wrote:
A new per session GUC variable, restricted to superusers, will
define if the session is in origin or replica mode.
It would be nice if we had a separate role for replication services
so that we weren't
On 1/26/2007 4:47 PM, Jan Wieck wrote:
On 1/26/2007 4:39 PM, Jim Nasby wrote:
On Jan 26, 2007, at 5:13 AM, Markus Schiltknecht wrote:
In Postgres-R, I mostly use the terms 'local' and 'remote'.
Note that those terms only make sense if you limit yourself to
thinking the master is pushing
If data are deleted then they are still stored in database until VACUUM
cleans them. You can look by some hex viewer, if you see some know text
data there. Or I think there is also some tool which dump tuple list
from pages.
You can also see deleted data if you change current transaction ID.
Jan Wieck [EMAIL PROTECTED] writes:
On 1/26/2007 4:39 PM, Jim Nasby wrote:
Also, if enums will be in 8.3, perhaps they can be used instead of
char?
I don't like this one. It makes it impossible to provide patches,
enabling this replication system on older Postgres releases. And you
know
Jan Wieck [EMAIL PROTECTED] writes:
On 1/26/2007 4:40 PM, Jim Nasby wrote:
It would be nice if we had a separate role for replication services
so that we weren't exposing superuser so much.
So you think about another flag in pg_shadow? Would work for me.
How exactly would such a role
I thought that the following todo item just barely missed 8.2:
Allow a warm standby system to also allow read-only statements [pitr]
This is useful for checking PITR recovery.
I assume it's not on this list either because it is already complete and
slated for 8.3, or it is going to take too
Rick Gigger [EMAIL PROTECTED] writes:
I thought that the following todo item just barely missed 8.2:
Allow a warm standby system to also allow read-only statements [pitr]
No, it's a someday-wishlist item; the work involved is not small.
regards, tom lane
On 1/26/2007 5:09 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
On 1/26/2007 4:40 PM, Jim Nasby wrote:
It would be nice if we had a separate role for replication services
so that we weren't exposing superuser so much.
So you think about another flag in pg_shadow? Would work for
On Jan 26, 2007, at 2:22 AM, BluDes wrote:
I have a problem with one of my costomers.
I made a program that uses a PostgreSQL (win32) database to save
its data.
My customer claims that he lost lots of data reguarding his own
clients and that those data had surely been saved on the
Henry B. Hotz: GSSAPI authentication method for C (FE/BE) and Java
(FE).
Magnus Haglander: SSPI (GSSAPI compatible) authentication method for
C (FE) on Windows.
(That fair Magnus? Or you want to volunteer for BE support as well?)
GSSAPI isn't much more than a functional replacement for
Jim Nasby wrote:
On Jan 26, 2007, at 9:31 AM, Tom Lane wrote:
If you wanted to be a bit more ambitious maybe you could change the fact
that this code is throwing away typmod, which means that declarations
like varchar(32) would fail to work as expected. Perhaps it should be
fixed to save the
In testing the new autovac facility, I noticed this log in the
EXEC_BACKEND (on Linux) scenario (I pressed Ctrl-C only once):
DEBUG: postmaster received signal 2
LOG: received fast shutdown request
LOG: aborting any active transactions
FATAL: terminating connection due to administrator
BluDes wrote:
Hi everyone,
I have a problem with one of my costomers.
I made a program that uses a PostgreSQL (win32) database to save its
data.
My customer claims that he lost lots of data reguarding his own
clients and that those data had surely been saved on the database.
My first guess is
Rick Gigger [EMAIL PROTECTED] writes:
I thought that the following todo item just barely missed 8.2:
Allow a warm standby system to also allow read-only statements [pitr]
This is useful for checking PITR recovery.
No, nobody worked on it prior to 8.2. Afaik there's still nobody working on
BluDes [EMAIL PROTECTED] writes:
My customer claims that he lost lots of data reguarding his own clients and
that those data had surely been saved on the database.
Has this Postgres database been running for a long time? There is a regular
job called VACUUM that has to be run on every table
Rick Gigger [EMAIL PROTECTED] writes:
I thought that the following todo item just barely missed 8.2:
Allow a warm standby system to also allow read-only statements [pitr]
This is useful for checking PITR recovery.
No, nobody worked on it prior to 8.2. Afaik there's still nobody working on
Tom Lane [EMAIL PROTECTED] writes:
search clause ::=
SEARCH recursive search order SET sequence column
and so CYCLE would come *after* SET sequence column not before it.
Ah, thanks, I had glossed right over the SET sequence column bit. The SET
that I had was the SET cycle column which
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'd like to see still more evidence that it's a problem before we start
changing that piece of code. It has served us well for years.
What I see here is mostly evidence suggesting that we should consider
raising
1 - 100 of 109 matches
Mail list logo
