On Sat, Jan 27, 2007 at 12:11:59AM +, Gregory Stark wrote:
> If this isn't run for a very long time (how long depends on how busy the
> database is, but even on extremely large databases it's usually a matter of
> months, on more normal databases it would be years) then very old records seem
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The strange thing is that we're seeing a "forked a new backend" line
> _after_ the shutdown signal was received.
No, nothing surprising about that if you had clients that might try to
connect at that time. The "canAcceptConnections" test doesn't occur
Gregory Stark <[EMAIL PROTECTED]> writes:
> Having fixed that everything works fine with SET and WITH being reserved
> keywords. You didn't mean to say I should be able to leave WITH unreserved did
> you?
I think we'd decided that was a lost cause, unless you see a way?
> Of course that was the e
Andrew Dunstan wrote:
> Bruce Momjian wrote:
> > OK, what is the TODO wording?cheers
> >
>
>
> Something like:
>
> Enforce typmod for function inputs, function results and parameters for
> spi_prepare'd statements called from PLs.
Added.
--
Bruce Momjian [EMAIL PROTECTED]
Enterprise
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
> If anyone is interested I currently have working-but-incomplete
> patches to support SASL in C. I've decided not to finish and submit
> them because the glue code to make configuration reasonable, and to
> allow use of existing Postgres password d
Bruce Momjian wrote:
OK, what is the TODO wording?cheers
Something like:
Enforce typmod for function inputs, function results and parameters for
spi_prepare'd statements called from PLs.
cheers
andrew
---(end of broadcast)---
TIP 3: Hav
Can we add a link to the doxygen web site from our site:
http://www.postgresql.org/developer/coding
link to:
http://www.mcknight.de/pgsql-doxygen/cvshead/html/
It seems like a useful resource.
---
=?ISO-8
OK, what is the TODO wording?
---
Andrew Dunstan wrote:
> 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
Can I get a TODO on this?
---
Jim Nasby wrote:
> On Jan 25, 2007, at 6:26 PM, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> >> On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote:
> >>> On 1/25/07, Jim C.
Pavan Deolasee wrote:
> 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 ne
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 NUM_CL
"Tom Lane" <[EMAIL PROTECTED]> writes:
> ::=
> SEARCH SET
>
> and so CYCLE would come *after* "SET " not before it.
Ah, thanks, I had glossed right over the "SET " bit. The SET
that I had was the "SET " which remains after the CYCLE keyword.
> It looks to me like we'd have to promote S
"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 work
"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 tab
"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 work
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
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 command
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
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 Ker
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 database.
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
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
--
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 l
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 rol
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
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. B
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 dat
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 expo
"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 sa
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 mak
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 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 even
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 w
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 along
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 d
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 t
Martijn van Oosterhout 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 keywords that can
te
On Jan 25, 2007, at 6:26 PM, Tom Lane wrote:
Martijn van Oosterhout 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 exist: box ~ point
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, pthread
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 i
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 ,
not a . But the parser will see that as soon as it hits
the open parenthesis, since a is always just a column
name.
Al
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
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 o
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 wi
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
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 t
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
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 nu
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 your
"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
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 Ya
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 seem
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 bein
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 pr
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
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 y
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 it has to
scan
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
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.
"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 glob
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 k
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/A
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
--
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 you could use tables or out-of-ba
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>>> For Postgres-R, I'm currently questioning if I shouldn't merge the
>>> replication manager process with the postmaster. Of course, that would
>>> violate the "postmaster does not touch shared memory" constraint.
>>
>> I
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 NUM_CLOG_BUFFERS, rather than anyt
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,
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.
> W
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 wa
"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
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 whe
[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(); -- will unb
[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
>>
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
"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 "und
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
"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.
"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
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.
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 com
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 aggregate
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 lea
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 ri
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'
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 acces
"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 seem
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: src/pl/plperl/plpe
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
sh
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 w
* 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" rel
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.
>
> D
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
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
>
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".
Ü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:
> >
>
-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 "undef
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
HAV
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 sy
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(); -- will unblock backend1
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 a
1 - 100 of 114 matches
Mail list logo
