Le vendredi 31 octobre 2008, Tom Lane a écrit :
With the attached patch, SQL functions support returning the results of
INSERT/UPDATE/DELETE RETURNING clauses.
Thanks for your work and for having considered user whining in-passing! :)
--
dim
signature.asc
Description: This is a digitally
On Sun, 2008-11-02 at 17:10 -0800, Josh Berkus wrote:
Greg Smith wrote:
-Stepping back a bit from this particular code, is something in Python
like this ever going to be appropriate to ship as a contrib module?
I think python should be as good as any relatively widespread language.
Unless
On Sat, 2008-11-01 at 22:02 -0400, Greg Smith wrote:
Possible feedback topics:
-Setting the next round of values requires asking the user for some input
before making recommendations. Is it worth building a curses-based
interface to updating the values? That would be really helpful for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
Somehow, prevent infinite loops doesn't seem like justification for
refuse to deal with a situation that the software creates automatically.
They ought to be willing to burrow more than one level ... see any Unix
kernel's treatment
Hi,
Brendan Jurd submitted a patch to add a pg_typeof() builtin function:
http://archives.postgresql.org/pgsql-patches/2008-09/msg00029.php
I've reviewed the patch and it looks fine. An updated version is
attached, having made these changes:
1) Rebased to current CVS head
2) func.sgml:
Hello Stephen,
Stephen Frost wrote:
This has been fixed in the attached patch.
Cool, thanks.
If you could work on the documentation, that'd be great!
I'll give it a try.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Bruce Momjian wrote:
KaiGai Kohei wrote:
I've updated my patches, it contains a few bugfixes.
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1168.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1168.patch
[3/6]
Bruce Momjian wrote:
Russell Smith wrote:
Alvaro Herrera wrote:
PoolSnoopy wrote:
***PUSH***
this bug is really some annoyance if you use automatic build environments.
I'm using phpunit to run tests and as soon as postgres is involved the php
cli environment segfaults at the end. this
Greg Smith wrote:
On Sun, 2 Nov 2008, Josh Berkus wrote:
I'd start with command-line switches, e.g.
config --memory=32GB --type=DW --size=500GB --connections=20
That seems reasonable, I think I'll push a fancier UI on the backburner
then and just spec out an options interface like this
Hannu Krosing wrote:
If you do a python version, others will write versions in other
languages.
Yeah, if python is not accepted as contrib, then it can probably be
rewritten in C once it has stabilized enough.
It could. The question is if it makes sense to write something like this
in C,
On Thu, 2008-10-23 at 09:57 +0100, Simon Riggs wrote:
On Thu, 2008-10-23 at 09:09 +0300, Heikki Linnakangas wrote:
However, we require that in b-tree vacuum, you take a cleanup lock on
*every* leaf page of the index, not only those that you modify. That's a
problem, because there's no
On Mon, Nov 03, 2008 at 10:02:24AM -0300, Alvaro Herrera wrote:
David Fetter wrote:
However, there are little lacunæ like this:
SELECT * FROM show_qual() s(a)
WHERE A NOT IN (
SELECT 'foo' UNION ALL SELECT 'bar'
);
a
(NOT (hashed subplan))
This
Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
Since we require every process to map the shared memory region to the same
address, we don't need the MAKE_PTR/OFFSET code that was needed when that
was not the case. This patch makes shared memory pointers just like
regular
Alvaro Herrera [EMAIL PROTECTED] writes:
David Fetter wrote:
However, there are little lacunæ like this:
SELECT * FROM show_qual() s(a)
WHERE A NOT IN (
SELECT 'foo' UNION ALL SELECT 'bar'
);
a
(NOT (hashed subplan))
This little lacuna seems to say that if you
David Fetter wrote:
I understand that a full implementation of SQL/MED will involve just
about every part of PostgreSQL, but we've got a case of le mieux est
l'enemi du bien with this contrived example, which I included so
people could be fully informed when using this very helpful new
Pavel Stehule wrote:
Hello
I am testing PostgreSQL on Federa 10. There is Perl 5.10. After
successful compilation I got error
CREATE LANGUAGE plperl;
ERROR: could not oad library /plperl.so: ... undefined
symbol: boot_DynaLoader
Regards
Pavel Stehule
Please send the build log
Simon Riggs [EMAIL PROTECTED] writes:
VACUUM with a btree index proceeds like this:
1. Scan table
2. Remove rows from btree identified in (1)
3. Remove rows from heap identified in (1)
The purpose of the additional locking requirements during (2) for btrees
is to ensure that we do not fail
David Fetter [EMAIL PROTECTED] writes:
Left out are the very large benefits that, for example,
dblink gets for free.
I take it that works reliably isn't a property you think dblink
needs to have.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hannu Krosing escreveu:
On Sat, 2008-11-01 at 22:02 -0400, Greg Smith wrote:
Possible feedback topics:
-Setting the next round of values requires asking the user for some input
before making recommendations. Is it worth building a curses-based
interface to updating the values? That
I wrote:
... I'm not even real sure what
all the issues would be, but I'm pretty sure that subplans are just the
tip of the iceberg.
Another issue is that ruleutils responds to column aliasing, as indeed
it must to generate correct output for rules:
regression=# explain select * from tenk1 a
David Fetter wrote:
However, there are little lacunæ like this:
SELECT * FROM show_qual() s(a)
WHERE A NOT IN (
SELECT 'foo' UNION ALL SELECT 'bar'
);
a
(NOT (hashed subplan))
This little lacuna seems to say that if you pass the wrong query to
dblink, it
On 2008-11-02, at 02:02, Greg Smith wrote:
Possible feedback topics:
-Setting the next round of values requires asking the user for some
input before making recommendations. Is it worth building a curses-
based interface to updating the values? That would be really
helpful for people
There are several macros like DatumGetInt and so on. See postgres.h for details.
Zdenek
Zhe He napsal(a):
I met a problem with parsing Datum,
is there any good way to parse this
kind of value? Because I want to get
the value in an attribute of a table.
In TupleTableSlot, there is a
Hannu Krosing wrote:
On Tue, 2008-10-28 at 22:37 -0300, Alvaro Herrera wrote:
If you mean that we're duplicating the effort that's already going
elsewhere, my opinion is yes, we are.
duplicating the effort is not always a bad thing. I was mostly
suggesting to watch discussions and dig
On Mon, 2008-11-03 at 10:07 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
VACUUM with a btree index proceeds like this:
1. Scan table
2. Remove rows from btree identified in (1)
3. Remove rows from heap identified in (1)
The purpose of the additional locking
Simon Riggs [EMAIL PROTECTED] writes:
Are you happy with my optimisation that if a page needs to be read in,
we just skip it and pretend we did read-pin-unpin on it?
If it's not in buffers then it cannot be pinned, so I concur that that
is safe.
regards, tom lane
--
Euler Taveira de Oliveira wrote:
Alvaro Herrera escreveu:
So I gave up waiting for someone else to do the reloptions patch for
autovacuum and started work on it myself. What I soon discovered is
that on first blush it seems a lot easier than I had expected.
Sorry about that. :( I was
Alvaro Herrera [EMAIL PROTECTED] writes:
We now have two very similar doubly-linked list implementations. Should
we take one of them out?
If you're thinking of dllist, it has considerably different implementation
assumptions.
regards, tom lane
--
Sent via
Hi,
With the new request-based pgstat reading mechanism, it is easy to fix
an autovacuum bug. Basically for an autovac worker the delay is
reduced, so that the data is very fresh. Patch attached.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL
Alvaro Herrera [EMAIL PROTECTED] writes:
With the new request-based pgstat reading mechanism, it is easy to fix
an autovacuum bug. Basically for an autovac worker the delay is
reduced, so that the data is very fresh. Patch attached.
It would be nice if the patch didn't render the adjacent
Hello
I am testing PostgreSQL on Federa 10. There is Perl 5.10. After
successful compilation I got error
CREATE LANGUAGE plperl;
ERROR: could not oad library /plperl.so: ... undefined
symbol: boot_DynaLoader
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list
On Mon, 2008-11-03 at 18:33 +1100, Brendan Jurd wrote:
If I'm grokking the thread, it looks like Tom suggested a substantial
change in the approach (targetting per-index correlation rather than
per-column) [1], and although you agreed with the spirit of his
suggestion[2], there hasn't been a
Greg Smith wrote:
One of the long-terms goals I'm working toward is wrapping a wizard
interface around the tuning guidelines described by
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server now that
those have gone through a fair amount of peer review. Attached is a
first simple
On Nov 3, 2008, at 1:28 AM, Kurt Harriman wrote:
2) func.sgml: clarifying that the function returns an OID rather
than a string
Actually, it returns a regtype, no?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, 3 Nov 2008, Hannu Krosing wrote:
And I'd suggest you use wxPython for GUI part if you want a relatively
modern look.
wxPython is GPL licensed and not popular enough to be available on a lot
of systems already. I've spent enough time fighting with installing
wxWidgets (for pgAdmin)
David E. Wheeler escribió:
On Nov 3, 2008, at 1:28 AM, Kurt Harriman wrote:
2) func.sgml: clarifying that the function returns an OID rather
than a string
Actually, it returns a regtype, no?
Yes -- regtype, which is an OID alias type.
--
Alvaro Herrera
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 3, 2008, at 1:28 AM, Kurt Harriman wrote:
2) func.sgml: clarifying that the function returns an OID rather
than a string
Actually, it returns a regtype, no?
I thought the description was good, because it emphasizes that the
result is-a OID;
On Nov 3, 2008, at 10:02 AM, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 3, 2008, at 1:28 AM, Kurt Harriman wrote:
2) func.sgml: clarifying that the function returns an OID rather
than a string
Actually, it returns a regtype, no?
I thought the description was good,
David E. Wheeler escribió:
Well, as someone who was until recently unfamiliar with regtypes, and
who thinks of an OID as essentially just a number, I would find it very
useful if the description indicated that, as a regtype, the return value
could be used as either an OID or as string.
Kurt Harriman [EMAIL PROTECTED] writes:
Brendan Jurd submitted a patch to add a pg_typeof() builtin function:
http://archives.postgresql.org/pgsql-patches/2008-09/msg00029.php
I've reviewed the patch and it looks fine. An updated version is
attached, having made these changes:
Applied,
On Nov 3, 2008, at 10:52 AM, Alvaro Herrera wrote:
Give this a read
http://www.postgresql.org/docs/8.3/static/datatype-oid.html
Yeah.
Maybe we should link to this page in the pg_typeof() description.
Also,
perhaps this page needs more examples.
Yes, both of those would help a lot, I
Alvaro Herrera wrote:
Simon Riggs wrote:
[Also there is a comment saying this is a bug in autovacuum.c
Are we thinking to go production with that phrase in the code?]
Yeah, well, it's only a comment ;-) The problem is that a worker can
decide that a table needs to be vacuumed, if
=48b73ee574779a14a3c36d373d8544d59a5b8b46
Regards,
--
Hitoshi Harada
window_functions.delta.patch.20081103
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
With the new request-based pgstat reading mechanism, it is easy to fix
an autovacuum bug. Basically for an autovac worker the delay is
reduced, so that the data is very fresh. Patch attached.
It would be nice if the patch didn't
David E. Wheeler [EMAIL PROTECTED] writes:
On Nov 3, 2008, at 10:52 AM, Alvaro Herrera wrote:
Maybe we should link to this page in the pg_typeof() description.
Also,
perhaps this page needs more examples.
Yes, both of those would help a lot, I think.
Feel free to send in a docs patch ...
Simon Riggs wrote:
Even better idea: just use the InRecovery flag. Patch enclosed.
Applied, thanks.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list
KaiGai Kohei wrote:
I just looked over the patch. This new version with row-level SQL
security has certainly reduced the SE-Linux-specific part, which is
good.
It was interesting how you implemented SQL-level column-level
permissions:
CREATE TABLE customer (
cid
Kris Jurka [EMAIL PROTECTED] writes:
Attached are two and a half fixes for problems in psql's
describeOneTableDetails function.
Applied, thanks.
3) When describing a sequence it queries the sequence by name and was not
schema qualifying it which is necessary when describing objects not in
Hi all, I'm new in list
I have seen this on the todo list GRANT/REVOKE
Allow GRANT/REVOKE permissions to be applied to all schema objects
with one command The proposed syntax is: GRANT SELECT ON ALL TABLES IN
public TO phpuser; GRANT SELECT ON NEW TABLES IN public TO phpuser;
is there anyone
Big thanks for review.
Robert Haas napsal(a):
I tried to apply this patch to CVS HEAD and it blew up all over the
place. It doesn't seem to be intended to apply against CVS HEAD; for
example, I don't have backend/access/heap/htup.c at all, so can't
apply changes to that file.
You need to
I wonder if pg_typeof() should be marked stable instead of immutable?
Its results certainly depend on the contents of system catalogs ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
I wonder if pg_typeof() should be marked stable instead of immutable?
Its results certainly depend on the contents of system catalogs ...
makes sense.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Zdenek Kotala [EMAIL PROTECTED] writes:
I attach patch which cleans up code around PageGetTempPage. These changes
were
discussed here:
http://archives.postgresql.org/pgsql-hackers/2008-08/msg00102.php
Applied with a minor change: instead of inventing
Page PageGetTempPage(Page page,
=?ISO-8859-1?Q?Sebastian_B=F6hm?= [EMAIL PROTECTED] writes:
Am 03.11.2008 um 12:06 schrieb Richard Huxton:
It's not possible to have a LOCK statement outside of a
transaction. It's just not meaningful to have a transaction that only
has a LOCK statement in it.
as postgres does not warn you
On Mon, 2008-11-03 at 12:42 -0500, Greg Smith wrote:
On Mon, 3 Nov 2008, Hannu Krosing wrote:
And I'd suggest you use wxPython for GUI part if you want a relatively
modern look.
wxPython is GPL licensed and not popular enough to be available on a lot
of systems already.
Wikipedia says
On Mon, 2008-11-03 at 06:41 +, Simon Riggs wrote:
On Mon, 2008-11-03 at 12:16 +1300, Mark Kirkwood wrote:
Trying out a few different scenarios I ran across this:
CONTEXT: xlog redo update: rel 1663/16384/16397; tid 9614/62; new 158828/59
DEBUG: start recovery xid = 7002 lsn =
On 2008-10-31, Gianni Ciolli [EMAIL PROTECTED] wrote:
following the useful feedback that we received from this list, we
would like to submit the patch for Bitmap Indexes for the november
CommitFest (joint work of me with Gabriele Bartolini, starting from
Gavin Sherry's patch).
I skimmed
Robert Haas wrote:
The attached patch allows uuid_in() to parse a wider variety of
variant input formats for the UUID data type, per the TODO named in
the subject line.
I have committed your patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
I met some problem with get date type value
from a table. I have a Datum which stores this
value as an integer and I want to get its date
value. Is there anyway that I can print it out?
Best Regards,
Zhe HE
TEL: (001) 646-789-3008
Address:965 Amsterdam Avenue,
New York, NY 10025
Master
On Mon, 2008-11-03 at 17:37 -0500, Greg Stark wrote:
Secondly the locking seems to be a bit overoptimistic. I'm pretty sure
you have to take an exclusive lock on an index page any time you make
any data modifications in index pages -- even if you're just setting a
bit and not moving any data
What do you want to print? The integer value or the date string like
29-01-2008. Use the date_out function to convert your value to date.
--Imad
On Tue, Nov 4, 2008 at 10:19 AM, Zhe He [EMAIL PROTECTED] wrote:
Hi,
I met some problem with get date type value
from a table. I have a Datum which
On Mon, 2008-11-03 at 23:28 +, Simon Riggs wrote:
On Mon, 2008-11-03 at 17:37 -0500, Greg Stark wrote:
Secondly the locking seems to be a bit overoptimistic. I'm pretty sure
you have to take an exclusive lock on an index page any time you make
any data modifications in index pages --
I looked at that aspect of the patch specifically a few weeks back while
checking for possible issues with Hot Standby. IIRC the patch is fairly
careful with locking and uses Exclusive locks extensively throughout. I
looked at both the theory and the implementation. Unless Gianni changed
Emmanuel Cecchet wrote:
Here is the latest patch and the regression tests for the temp tables
and 2PC issue.
This fails:
postgres=# begin;
BEGIN
postgres=# CREATE TEMPORARY TABLE temp1 (id int4);
CREATE TABLE
postgres=# PREPARE TRANSACTION 'foo';
PREPARE TRANSACTION
postgres=# CREATE
Hannu Krosing [EMAIL PROTECTED] writes:
On Sat, 2008-11-01 at 06:13 +0200, Hannu Krosing wrote:
This version is quite rough, though passes tests here.
I will clean it up more during commitfest.
probably still more things to do
The status of this patch isn't clear --- are you still working
Michael Meskes [EMAIL PROTECTED] writes:
I finally have a working version. Please have a look at the attached files
including a changed version of gram.y and and automatically created version of
preproc.y. To recreate just run awk -f parse.awk gram.y preproc.y.
Ping? I've been expecting a
--On Donnerstag, Oktober 30, 2008 21:24:08 +0100 Bernd Helmle
[EMAIL PROTECTED] wrote:
Note that i'm still working on this (for example, RETURNING is missing
yet), As always, discussion welcome ;)
This new version implements RETURNING support for implicit view update
rules and does some
On Mon, 2008-11-03 at 16:53 -0700, Vladimir Sitnikov wrote:
The major thing there is to get the modifications right. There is no
much sense in reviewing wrong code against locking issues.
I didn't say there were no other bugs, nor would I know, only that I had
reviewed the locking issues
BTW: is there a framework to test recovery related features?
The only idea I could take from the top of my head is to comment out all the
page writes and leave only WAL logging. Then crash database at random and
verify if the index still performs as expected.
Regards,
Vladimir Sitnikov
On Tue, Nov 4, 2008 at 6:12 AM, Enrico Pirozzi [EMAIL PROTECTED] wrote:
Hi all, I'm new in list
Hi Enrico,
Just a heads-up, the Postgres hackers have just started on the final
commitfest (patch review phase) for the 8.4 development cycle, so at
the moment everyone is busy reviewing patches
That's a good point. We throw error for DECLARE CURSOR outside a
transaction block, since it's obviously a mistake. I wonder whether
we shouldn't equally throw error for LOCK outside a transaction block.
I can sort of imagine some corner cases where
lock-and-immediately-release would be
On Tue, Nov 4, 2008 at 4:21 AM, Jeff Davis [EMAIL PROTECTED] wrote:
We don't want to hold anything up, so feel free to move on to another
patch. If you still have time to review when we have a better patch,
we'd appreciate your feedback even if it's too late for 8.4.
No worries, thanks Jeff.
Robert Haas [EMAIL PROTECTED] writes:
That's a good point. We throw error for DECLARE CURSOR outside a
transaction block, since it's obviously a mistake. I wonder whether
we shouldn't equally throw error for LOCK outside a transaction block.
Objections anyone?
No, I've been bitten by
You need to apply also two other patches:
which are located here:
http://wiki.postgresql.org/wiki/CommitFestInProgress#Upgrade-in-place_and_related_issues
I moved one related patch from another category here to correct place.
Just to confirm, which two?
Robert Haas [EMAIL PROTECTED] writes:
Really, what I'd ideally like to see here is a system where the V3
code is in essence error-recovery code. Everything should be V4-only
unless you detect a V3 page, and then you error out (if in-place
upgrade is not enabled) or jump to the appropriate
Hello, Saito-san:
Hiroshi Saito [EMAIL PROTECTED] wrote:
next patch is this.
I'm reviewing your patch and cleanup some parts:
- Avoid casting to LPWSTR.
- Use pre-defined MAX_L10N_DATA instead of STRLEN_MAX.
I'll send a new version.
BTW, we convert strings multiple times in the function.
We already do check the page version on read-in --- see PageHeaderIsValid.
Right, but the only place this is called is in ReadBuffer_common,
which doesn't seem like a suitable place to deal with the possibility
of a V3 page since you don't yet know what you plan to do with it.
I'm not quite sure
Bruce Momjian wrote:
KaiGai Kohei wrote:
I just looked over the patch. This new version with row-level SQL
security has certainly reduced the SE-Linux-specific part, which is
good.
It was interesting how you implemented SQL-level column-level
permissions:
CREATE TABLE customer (
Hi Heikki,
Emmanuel Cecchet wrote:
Here is the latest patch and the regression tests for the temp tables
and 2PC issue.
This fails:
postgres=# begin;
BEGIN
postgres=# CREATE TEMPORARY TABLE temp1 (id int4);
CREATE TABLE
postgres=# PREPARE TRANSACTION 'foo';
PREPARE TRANSACTION
postgres=#
Zdenek,
It seems like there is general agreement that this patch needs some
changes before being considered for application. Is that correct?
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php
Are you planning to send a new version for this CommitFest, or is this
8.5 material at
On Fri, Oct 31, 2008 at 07:48, David Fetter [EMAIL PROTECTED] wrote:
Please find attached a patch which works in PL/Perl, the work having
been done by Andrew (RhodiumToad) Gierth. It's not clear to me how
this would be generally surface-able to SQL, though. Any ideas?
I was assigned to
On Thu, Oct 30, 2008 at 05:16, Tom Lane [EMAIL PROTECTED] wrote:
David Fetter [EMAIL PROTECTED] writes:
On Wed, Oct 29, 2008 at 10:23:36PM -0400, Tom Lane wrote:
I would argue that it's already designed wrong if there's need for
PL-specific implementation effort.
I'm not sure how else to do
On Thu, Oct 9, 2008 at 03:06, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Thanks for your reviewing, Alex.
I applied your comments to my patch.
Sorry for the late reply! Somehow I missed this, saw it on the commit
fest wiki :)
*custom_guc_flags-0828.patch
My only other concern is the changes
Hi all,
Is there any way to print out the stack trace of the current location?
I am looking for something like print_stack_trace(); that I can insert in
arbitrary location in the code.
Thank you,
Regards,
Bramandia R.
Bramandia Ramadhana wrote:
Is there any way to print out the stack trace of the current location?
Not sure if Postgres has something in the utils for that.
You can use backtrace() in glibc. Solaris 9 libc has printstack(). Not
sure what's available for Windows.
I am looking for something like
On Thu, Sep 18, 2008 at 6:03 AM, Ron Mayer
[EMAIL PROTECTED] wrote:
The attached patch
(1) adds a new GUC called IntervalStyle that decouples interval
output from the DateStyle GUC, and
(2) adds a new interval style that will match the SQL standards
for interval
While doing some tests yesterday I ran into the situation where the
standby database would appear to go back into 'warm' mode after it was
restarted. The set of steps to reproduce the behaviour is:
1/ Setup master and replica with replica using pg_standby
2/ Initialize pgbench schema with size
Just a heads-up, the Postgres hackers have just started on the final
commitfest (patch review phase) for the 8.4 development cycle, so at
the moment everyone is busy reviewing patches that have already been
submitted.
Yes I know that :)
So, don't take it personally if nobody gets back to
On Tue, 2008-11-04 at 18:33 +1300, Mark Kirkwood wrote:
Another corner case:
1/ Setup master and replica with replica using pg_standby
2/ Create a new database (I used 'bench')
3/ Initialize the pgbench schema of size 100 in 'bench' (just to ensure
the logs with the db creation get
postgres=# select version();
version
--
PostgreSQL 8.3.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.3.2 20080917 (Red Hat 4.3.2-4)
On Tue, 2008-11-04 at 18:33 +1300, Mark Kirkwood wrote:
While doing some tests yesterday I ran into the situation where the
standby database would appear to go back into 'warm' mode after it was
restarted. The set of steps to reproduce the behaviour is:
1/ Setup master and replica with
Another corner case:
1/ Setup master and replica with replica using pg_standby
2/ Create a new database (I used 'bench')
3/ Initialize the pgbench schema of size 100 in 'bench' (just to ensure
the logs with the db creation get archived)
3/ Attempt to connect to 'bench' on the replica
Head
On Mon, 2008-11-03 at 23:28 +, Simon Riggs wrote:
On Mon, 2008-11-03 at 17:37 -0500, Greg Stark wrote:
There are a lot of comments in the code which imply that vacuuming is
not implemented but in fact from what I can see it is -- sort of. It
does rewrite the bitmap in bmbulkdelete
On Tue, Nov 4, 2008 at 12:30 AM, imad [EMAIL PROTECTED] wrote:
What do you want to print? The integer value or the date string like
29-01-2008. Use the date_out function to convert your value to date.
--Imad
On Tue, Nov 4, 2008 at 10:19 AM, Zhe He [EMAIL PROTECTED] wrote:
Hi,
I met some
On Mon, 2008-11-03 at 19:07 -0500, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On Sat, 2008-11-01 at 06:13 +0200, Hannu Krosing wrote:
This version is quite rough, though passes tests here.
I will clean it up more during commitfest.
probably still more things to do
The
95 matches
Mail list logo
