Hi there,
I just wanted to try the PITR feature in beta and got it working somehow.
However I think the docs on this point are still not sufficient enough.
We have to assume that people will have a closer look at the backup/recovery
documentation as soon as 8.0 ships, because we're kinda heavily
Simon,
thanks for that quick and detailed answer.
On Fri, Nov 05, 2004 at 05:42:01PM +0100, [EMAIL PROTECTED] wrote:
The sample file gives additional information, just as occurs with
pg_hba.conf. I don't see any need to replicate the sample file in the
docs, do you?
Well, maybe one could add
Hi,
On Fri, Nov 05, 2004 at 10:26:55PM +, Simon Riggs wrote:
That is exactly the situation Timelines are designed to avoid. This
should not have happened. What leads you to think it has? My guess is
that it has not. If it has, its a bug.
Hmm. I did the following:
- I recovered to one
Hi,
On Sat, Nov 06, 2004 at 11:13:34AM +, Simon Riggs wrote:
The timeline code only comes into effect when you request an archive
recovery. If you do not, it has no way of knowing it should have.
Ok. However these details should be added to the docs as well.
At least a short warning should
On Sat, Nov 06, 2004 at 07:17:29PM +, Simon Riggs wrote:
Once you have brought up a database in timeline N+1, you can't use it as
the base to recover to a point in timeline N because the data file
contents cannot be trusted to be identical to the way they were in
timeline N.
You
Hi,
this query makes postmaster (beta4) die with signal 11:
(echo CREATE TABLE footest(;
for i in `seq 0 66000`; do
echo col$i int NOT NULL,;
done;
echo PRIMARY KEY(col0));) | psql test
ERROR: tables can have at most 1600 columns
LOG: server process (PID 2140)
On Tue, Nov 23, 2004 at 10:33:50AM -0500, Tom Lane wrote:
We do need to do something about the fact that EXECUTE can't access
plpgsql variables, though I'm afraid that fixing that is going to
require a rather complete overhaul of plpgsql :-(. But it needs one
anyway.
Why do you think that it
Hi,
I have a 7.4.3 installation where a small plperl function seems to have
side-effects. In the example below I run an ordinary SELECT first, nothing
special with the table. Thereafter I call the plperl function and then I
rerun the SELECT query. This time it doesn't return the expected result.
Hi,
there's a topic that comes up from time to time on the lists, the problem
that pgsql functions get planned only once and thereafter the same query
plan is used until server shutdown or explicit recreation of the function.
I'd like to implement a way of automatic function replanning. I can
The TODO list contains some items concerning the CIDR/INET datatype.
* %Prevent INET cast to CIDR if the unmasked bits are not zero, or
zero the bits
I added a function for this cast (which zeroes the bits) but then the
opr_sanity regression test failed because there is a cast from INET - CIDR
On Sat, Jan 07, 2006 at 12:50:23PM -0500, Tom Lane wrote:
Joachim Wieland [EMAIL PROTECTED] writes:
Actually both types are not binary compatible, since they have a
type component that is either 0 or 1, depending on whether it is of type
INET or CIDR.
The whole question
to easily check
what is where defined and how... What do you think?
doxygen can also produce a pdf but I haven't succeeded in doing that so far,
pdflatex keeps bailing out. Has anybody else succeeded building this yet?
Joachim
--
Joachim Wieland
some de facto rules about comments to get most
of the matches: For example a comment starting on column 0 of the line is
probably one you're looking for vs. one that has some whitespace at the
beginning is not.
Of course this would still need manual review for every file.
Joachim
--
Joachim
on at the moment. So it
might get more concise but we'll have to play around with it to see what is
useful and what isn't.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B ICQ: 37225940
20002
to be mirrored and should be recreated on every webserver? We might need
one copy for the last version of every major release as well as one for
cvs. The latter should get updated regularly of course but I figure it would
be sufficient to do that once a week...
Joachim
--
Joachim Wieland
header and footer as well. The
postgresql logo on top would be nice but the navigation menu on the left has
to be sacrificed for more space.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B ICQ
I wonder if there is a policy on when schema-qualified names should be used
in ereport/elog messages.
At the moment this doesn't seem to be consistent, even within the same
command:
template1=# VACUUM verbose t;
INFO: vacuuming public.t
[...]
template1=# VACUUM verbose tv;
WARNING: skipping
On Mon, Jan 30, 2006 at 05:10:03PM -0500, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Joachim Wieland wrote:
I wonder if there is a policy on when schema-qualified names should
be used in ereport/elog messages.
If it's not too hard to do, I would add the schema name
On Tue, Jan 31, 2006 at 01:46:42PM -0500, Tom Lane wrote:
The direction that we ought to be going in is to add separate fields to
error reports that contain just the names of the relevant objects (without
any other decoration). This is needed anyway to allow client-side
programs to extract
dependencies
- SET DEFAULT forbidden, issues a hint to DROP DEFAULT first
Is it also desired to convert an int column to a serial column?
(moving to -hackers)
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B
to the configuration re-read at SIGHUP?
Right, and it is something we have needed to fix for a while.
I'm working on this one.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B ICQ: 37225940
20002 Donostia
The documentation for the .pgpass file seems to be incorrect with respect to
unix domain sockets.
There's also a user comment saying that:
http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html
The documentation suggests that the hostname part of .pgpass can be set to
localhost to
a server restarted.
Does anybody work on it?
I have a patch that seems to work, it could need some more testing however.
I'll send it to you per PM.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
C/ Usandizaga 12 1°B
I'd like to know what exactly is to be done for this TODO-item
o Allow customization of the known set of TZ names (generalize the
present australian_timezones hack)
The most recent mail in the archives about this subject seems to be:
Martijn,
On Fri, May 26, 2006 at 03:03:15PM +0200, Martijn van Oosterhout wrote:
I think you may be thinking of yet a separate TODO item, which is to
be able to use the zic timezone names in timestamptz input, viz
'2006-05-24 21:11 Americas/New_York'::timestamptz
But names like 'IST'
Can someone please explain why in include/utils/datetime.h (struct datetkn)
there is a check for _AIX that either initializes a char* pointer or a char
array? Is there any advantage of a char-array except for warnings of some
compilers if the initilization string is too long?
Apart from that I
I looked into the timezone specifications and basically extracted a list of
existing offsets from the zic database.
My proposed format for the timezone files is something like this:
HADT -32400 D # Hawaii-Aleutain Daylight Time
# (America/Adak)
HAST -36000#
Giampaolo,
On Sun, Jun 18, 2006 at 01:26:21AM +0200, Giampaolo Tomassoni wrote:
Or... Can I put a custom variable in pgsql.conf?
Like that you mean?
custom_variable_classes = 'identify'# list of custom variable classnames
identify.id = 42
template1=# show identify.id;
On Mon, Jul 24, 2006 at 07:09:17PM +0200, Peter Eisentraut wrote:
Am Montag, 24. Juli 2006 16:55 schrieb Stephen Frost:
#2: That variable can *not* be changed by a reload.
Notice-level message is sent to the log notifying the admin that the
change requested could not be performed.
On Mon, Jul 24, 2006 at 10:55:47AM -0400, Stephen Frost wrote:
#2: That variable can *not* be changed by a reload.
Notice-level message is sent to the log notifying the admin that the
change requested could not be performed. This change could be
either a revert to reset-value
Hi,
what do people think about this TODO item:
o Merge hardwired timezone names with the TZ database; allow either
kind everywhere a TZ name is currently taken
I think it is kind of done. The hardwired timezone names are no longer
hardwired and the America/New_York syntax is
On Tue, Jul 25, 2006 at 10:37:20PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I'll take a whack at that patch this evening PDT or tomorrow evening
at the latest. We're too late in the cycle to go over this, but maybe
we can figure out a way to have this data read from
...).
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
to select what test should be run? Maybe no tcp
connections by default but with an additional make-target checktcp?
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
it is in. Doesn't the backend
regression test (using psql) suffer from the same problem with libpq?
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
---(end
directorymake[4]: *** [all] Error 2
You don't have ecpg/test/connect/ ?
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/ecpg/test/connect/
Joachim
--
Joachim Wieland [EMAIL PROTECTED
to `#line 1 sql3types.h' as well but I think this is
acceptable.
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
Index: pg_regress.sh
as the table is concerned, I think we agreed on removing the list
(that has been inaccurate since long anyway) and tell people to check out
the system view.
Joachim
--
Joachim Wieland [EMAIL PROTECTED
docs ... we should probably
remove both of those in favor of recommending people look at the
views.
I did the basic documentation work in catalogs.sgml for these views,
but Appendix B still needs an update. Joachim, you were going to do
that, right?
Thats right.
Joachim
--
Joachim Wieland
On Mon, Sep 18, 2006 at 01:13:45PM +0200, Peter Eisentraut wrote:
Joachim Wieland is in the process of reworking the original feature patch
(resetting commented out parameters) in a much more compact form. But it
turns out that there are a couple of very tricky situations involving custom
from the view
completely or add another boolean column has_leapsecs or similar?
Removing them seems not to be the right idea because you can say:
select now() at time zone 'Mideast/Riyadh87';
Joachim
--
Joachim Wieland [EMAIL PROTECTED
ecpg-check manually? Which test hangs?
Joachim
--
Joachim Wieland [EMAIL PROTECTED]
GPG key available
---(end of broadcast)---
TIP 6: explain
... FAILED (log, output)
testing pgtypeslib/num_test.pgc... FAILED (output)
testing pgtypeslib/num_test2.pgc ... FAILED (output)
All should be fine now. I tested successfully with both cygwin and MinGW.
Joachim
--
Joachim Wieland
On Tue, Oct 03, 2006 at 12:27:47AM -0700, Jeremy Drake wrote:
On Tue, 3 Oct 2006, Magnus Hagander wrote:
Funky.
Can you try having it run the dumpbin command into a tempfile, and then
open-and-read that tempfile, to see if that makes a difference?
(Assuming you know enough perl to do
On Wed, Oct 04, 2006 at 06:15:31AM -0400, Bruce Momjian wrote:
Michael Meskes wrote:
Is there a way to make pgindent skip a directory? It seems it has
changed all expected file in ecpg's regression suite. So we see a lot of
differences now.
Sure a directory can be skipped. I am confused
We still need to decide what to do with queue full situations in the proposed
listen/notify implementation. I have a new version of the patch to allow for a
variable payload size. However, the whole notification must fit into one page so
the payload needs to be less than 8K.
I have also added the
On Sat, Nov 14, 2009 at 11:06 PM, Merlin Moncure mmonc...@gmail.com wrote:
The old method (measured on a 4 core high performance server) has
severe scaling issues due to table bloat (we knew that):
./pgbench -c 10 -t 1000 -n -b listen.sql -f notify.sql
run #1 tps = 1364.948079 (including
On Thu, Nov 19, 2009 at 1:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
4) Allow readers to read uncommitted notifications as well.
The question that strikes me here is one of timing --- apparently,
readers will now have to check the queue *without* having
On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
There will now be a nonzero chance
of transactions failing at commit because of queue full. If the
chance is large this will be an issue. (Is it sane to wait for
the queue to be drained?)
Exactly. The whole idea of putting
On Thu, Nov 19, 2009 at 1:51 PM, Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
And in addition i don't like the idea of having the sender sitting
around until there's room for more messages in the queue, because some
very old backends didn't remove the stuff from the same.
The only
On Thu, Nov 19, 2009 at 6:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, ignoring 2PC for a moment, I think the patch suffers from a little
race condition:
Session 1: BEGIN;
Session 1: INSERT INTO foo ..;
Session 1: NOTIFY 'foo';
Session 1: COMMIT -- commit begins
On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Note that we don't preserve notifications when the database restarts.
But 2PC can cope with restarts. How would that fit together?
The notifications are written to the state file at prepare. They can
Hi Jeff,
the current patch suffers from what Heikki recently spotted: If one
backend is putting notifications in the queue and meanwhile another
backend executes LISTEN and commits, then this listening backend
committed earlier and is supposed to receive the notifications of the
notifying backend
On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We are using NOTICE, not NOTIFY, assuming that we use anything at all
(which I still regard as unnecessary). Please stop injecting confusion
into the discussion.
Attached is a minimal POC patch that allows to cancel an idle
On Sun, Dec 27, 2009 at 10:42 PM, Simon Riggs si...@2ndquadrant.com wrote:
Thanks for the report. I'll see about a fix.
In the end we are about to use SIGINT for two use cases:
- cancel an idle transaction
- cancel a running query
Previously a backend that was DoingCommandRead == true didn't
On Wed, Dec 30, 2009 at 12:28 AM, Simon Riggs si...@2ndquadrant.com wrote:
I had to write an additional function AbortAnyTransaction() which
aborts all transactions and subtransactions and leaves the transaction
in the aborted state, is there an existing function to do this?
On Tue, Dec 29, 2009 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This seems like a fairly bad idea. One of the intended use-cases is to
be able to manually kill -INT a misbehaving backend. Assuming that
there will be valid info about the signal in shared memory will break
that.
I never
On Thu, Dec 31, 2009 at 3:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
This patch extends SIGINT to allow cancellation of transactions while
idle in both HS and normal mode. It also changes the standard message
reported on an idle transaction in aborted state to 'IDLE in
transaction
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would recommend we make SIGINT do cancel-anything, and handle
everything else via SIGUSR1, including CancelRequest. I'm not going to
do that; I'm going to make HS conflict resolution work, which means
putting in enough
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
CancelRequest's behaviour currently equates to SIGINT, so
processCancelRequest() can only use SIGINT if SIGINT's behaviour remains
same.
I would recommend we make SIGINT do cancel-anything, and handle
everything else
On Thu, Dec 31, 2009 at 6:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
Building racy infrastructure when it can be avoided with a little care
still seems not to be the best path to me.
Doing that will add more complexity in an area that is hard to test
effectively. I think the risk of
On Thu, Jan 7, 2010 at 4:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
As there were so many boolean SomethingCancelPending variables I changed them
to be bitmasks and merged all of them into a single variable.
This seems like a truly horrid idea, because
On Thu, Jan 7, 2010 at 3:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-01-07 at 14:45 +0100, Joachim Wieland wrote:
I have reworked Simon's patch a bit and attach the result.
Oh dear, this is exactly what I've been working on...
Sorry, as you have posted a first patch some days
On Thu, Jan 7, 2010 at 7:12 PM, Tom Lane t...@sss.pgh.pa.us wrote:
As far as I can think at the moment, the best you can do is throw the
elog(ERROR), and if control gets out to the error recovery block in
PostgresMain, you can force a transaction abort there. In other words,
pretty much the
The attached patch implements the idea of Heikki / Simon published in
http://archives.postgresql.org/pgsql-hackers/2009-11/msg00271.php
Since nobody objected to the idea in general, I have implemented it.
As this is not currently used anywhere it doesn't give immediate benefit, it
is however a
Hi Jeff,
thanks a lot for your review. I will reply to your review again in
detail but I'd like to answer your two main questions already now.
On Tue, Jan 19, 2010 at 8:08 AM, Jeff Davis pg...@j-davis.com wrote:
* AsyncCommitOrderLock
I believe this needs a re-think. What is the real purpose
On Wed, Jan 20, 2010 at 1:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I guess Joachim is trying to provide a similar guarantee for the new
implementation, but I'm not clear on why it would require locking.
The new implementation is broadcast and ISTM it shouldn't require the
modifying
On Wed, Jan 20, 2010 at 5:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In that case I think you've way overcomplicated matters. Just deliver
the notification. We don't really care if the listener gets additional
notifications; the only really bad case would be if it failed to get an
event that
On Wed, Jan 20, 2010 at 11:08 PM, Jeff Davis pg...@j-davis.com wrote:
Yes. That is the case with the existing implementation as well, no?
We don't consider sending notifies until transaction end, so anything
that commits during the xact in which you UNLISTEN will get dropped.
Only if the
On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis pg...@j-davis.com wrote:
Here's the problem as I see it:
You are writing a lot of true facts but I miss to find a real
problem... What exactly do you see as a problem?
The only time you are writing problem is in this paragraph:
However, there's
On Wed, Feb 3, 2010 at 2:05 AM, Jeff Davis pg...@j-davis.com wrote:
Thanks, very well spotted... Actually the same is true for LISTEN... I
have reworked the patch to do the changes to listenChannels only in
the post-commit functions.
I'm worried that this creates the opposite problem: that a
On Mon, Feb 8, 2010 at 6:07 PM, David E. Wheeler da...@kineticode.com wrote:
On Feb 8, 2010, at 5:15 AM, Magnus Hagander wrote:
The text is about 180Kb. PostgreSQL takes ~40 seconds without the
patch, ~36 seconds with it, to extract the match from it. Perl takes
0.016 seconds.
Obviously we
We want to teach people that Hot Standby and Streaming Replication are
two different features. However, Streaming Replication calls its main
parameter standby_mode which reminds more of Hot Standby than of
Streaming Replication.
People could also run a warm standby without streaming replication,
On Wed, Feb 10, 2010 at 12:16 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao masao.fu...@gmail.com wrote:
Yeah, even if primary_conninfo is not given, the standby tries to invoke
walreceiver by using the another connection settings (environment variables
or defaults). This is intentional behavior, and would make the setup of
On Fri, Feb 12, 2010 at 8:59 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Agreed. I've changed it now so that if primary_conninfo is not set, it
doesn't try to establish a streaming connection. If you want to get the
connection information from environment variables, you
On Mon, Feb 15, 2010 at 3:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure how probable it is that applications might be coded in a
way that relies on the properties lost according to point #2 or #3.
Your observations are all correct as far as I can tell.
One question regarding #2: Is a
On Sun, Feb 14, 2010 at 11:44 PM, Simon Riggs si...@2ndquadrant.com wrote:
Next set of questions
* Will this work during Hot Standby now? The barrier was that it wrote
to a table and so we could not allow that. ISTM this new version can and
should work with Hot Standby. Can you test that and
On Mon, Feb 15, 2010 at 1:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-02-15 at 12:59 +0100, Joachim Wieland wrote:
I have tested it already. The point where it currently fails is the
following line:
qe-xid = GetCurrentTransactionId();
That's a shame. So it will never
On Tue, Feb 16, 2010 at 6:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Another possibility is to force a ProcessIncomingNotifies scan to occur
before we reach ReadyForQuery if we sent any notifies in the
just-finished transaction --- but that won't help if there are
uncommitted messages in front
On Tue, Feb 16, 2010 at 1:31 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane wrote:
We could adopt the historical policy of sending self-notifies
pre-commit, but that doesn't seem tremendously appetizing from the
standpoint of transactional integrity.
But one traditional
This one is for the maintainers of the various postgresql interfaces:
With the new listen/notify implementation we can send a payload along
with the notification. This has been in the protocol already since
years and there is no change needed for libpq. However we need to
adapt the various
On Tue, Feb 16, 2010 at 11:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
[ listen/notify patch ]
I found a number of implementation problems having to do with wraparound
behavior and error recovery. I think they're all fixed, but any
remaining bugs
On Sun, Feb 28, 2010 at 2:54 PM, Greg Stark gsst...@mit.edu wrote:
Really? I think we get lots of suprised wows from the field from the
idea that a long-running read-only query can cause your database to
bloat. I think the only reason that's obvious to us is that we've been
grappling with that
On Sun, Feb 28, 2010 at 8:47 PM, Josh Berkus j...@agliodbs.com wrote:
1) Automated retry of cancelled queries on the slave. I have no idea
how hard this would be to implement, but it makes the difference between
writing lots of exception-handling code for slave connections
(unacceptable) to
On Sat, Mar 20, 2010 at 5:02 AM, Bruce Momjian br...@momjian.us wrote:
Interestingly the 9.0 release notes contain 201 items, while the 8.4
release notes contained 314 items.
Is the following pg_dump change covered by the release notes? I
couldn't find it. It was the last committed patch from
On Mon, Mar 29, 2010 at 12:32 AM, Robert Haas robertmh...@gmail.com wrote:
Per previous discussion, PFA a patch to change the maximum number of
keys for a syscache from 4 to 5.
http://archives.postgresql.org/pgsql-hackers/2010-02/msg01105.php
This is intended for application to 9.1, and is
People have been talking about a parallel version of pg_dump a few
times already. I have been working on some proof-of-concept code for
this feature every now and then and I am planning to contribute this
for 9.1.
There are two main issues with a parallel version of pg_dump:
The first one is
On Sat, Apr 3, 2010 at 9:02 PM, Robert Haas robertmh...@gmail.com wrote:
On Apr 3, 2010, at 11:13 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
The following messages from the postgres catalog either appear to be
internal errors that should be marked
I'd like to revive the discussion about offering another compression
algorithm than zlib to at least pg_dump. There has been a previous
discussion here:
http://archives.postgresql.org/pgsql-performance/2009-08/msg00053.php
and it ended without any real result. The results so far were:
- There
On Fri, Apr 9, 2010 at 5:51 AM, Greg Stark gsst...@mit.edu wrote:
Linking against as an option isn't nearly as bad since the user
compiling it can choose whether to include the restricted feature or
not. That's what we do with readline. However it's not nearly as
attractive when it restricts
On Tue, May 11, 2010 at 10:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I don't think we want to include all timezone names in the default
config, timezone abbreviations aren't always unique for example. But we
should include PKST because we already include PKT; it would
On Wed, May 12, 2010 at 12:39 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
Good we have found that inconsistency now, so let's add PKST.
OK, done. BTW, I notice that PKT was labeled (not in zic), which
is not the case, per this discussion. I seem to recall
On Thu, May 17, 2007 at 10:14:45PM +0200, Magnus Hagander wrote:
IIRC, Joachim had started working on the ecpg part. (Which is one of the
reasons I haven't looked at it myself yet)
Joachim, did you ever get anywhere with that?
I have ecpg tests somehow running under msvc but there are still
On Thu, Jun 14, 2007 at 08:17:05AM -0400, Andrew Dunstan wrote:
Maybe it uses a different CVS or something. Who knows? Aren't our diffs
supposed to be done ignoring whitespace?
pg_init() in pg_regress_ecpg.c has:
/* no reason to set -w for ecpg checks, except for when on windows */
Hi all,
this is a reply to the following post:
http://archives.postgresql.org/message-id/7867.1219793...@sss.pgh.pa.us
which is also a TODO item:
[E] Incomplete itemRevise the src/timezone/tznames abbreviation files:
* to add missing abbreviations
* to find abbreviations that can be
Hi,
the attached patch addresses the performance issues of the
authorization related views from information_schema (BUG #4596). It
implements what Tom suggests in
http://archives.postgresql.org/pgsql-bugs/2008-12/msg00144.php
In the cases that I have tested both the new and the old view return
On Thu, Nov 12, 2009 at 1:04 AM, Andrew Chernow a...@esilo.com wrote:
I think a bsearch would be needed. Very busy servers that make heavy use of
notifies would be quite a penalty.
In such an environment, how many relations/channels is a backend
typically listening to?
Do you have average /
On Thu, Nov 12, 2009 at 2:12 AM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Does it cope with the case where a trigger is doing NOTIFY, and you do
a whole-table update, therefore dumping potentially millions of
notifications in at once?
(for example a rare maintenance operation on a
On Thu, Nov 12, 2009 at 4:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
One possible solution would be to write to the queue before committing
and adding the TransactionID. Then other backends can check if our
TransactionID has successfully committed or not. Not sure if this is
worth the overhead
1 - 100 of 197 matches
Mail list logo
