On Mon, 2010-09-20 at 22:42 +0100, Thom Brown wrote:
> On 20 September 2010 22:14, Robert Haas wrote:
> > Well, if you need to talk to "all the other standbys" and see who has
> > the furtherst-advanced xlog pointer, it seems like you have to have a
> > list somewhere of who they all are.
>
> Whe
On 21/09/10 04:18, Josh Berkus wrote:
... or did we just forget to remove it?
Backwards-compatibility? ;-) There hasn't been any pressing reason to
remove it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On 21/09/10 16:14, Mark Kirkwood wrote:
I've been having a look at this guy, trying to get a handle on how
much down time it will save.
As a quick check, I tried upgrading a cluster with a 1 non default db
containing a scale 100 pgbench schema:
- pg_upgrade : 57 s
- pgdump/pg_restore
Robert Haas writes:
> I suppose you already know my votes, but here they are again just in case.
> ...
> Centralize.
> ...
> All the build products in a normal build.
I don't understand your preference for this together with a centralized
ignore file. That will be completely unmaintainable IMNSH
I suppose you already know my votes, but here they are again just in case.
On Tue, Sep 21, 2010 at 12:00 AM, Tom Lane wrote:
> 1. Whether to keep the per-subdirectory ignore files (which CVS
> insisted on, but git doesn't) or centralize in a single ignore file.
Centralize.
> 2. Whether to have
On Mon, Sep 20, 2010 at 11:55 PM, Heikki Linnakangas
wrote:
> It doesn't feel right to always accept PQputCopyData in COPY OUT mode,
> though. IMHO there should be a new COPY IN+OUT mode.
>
> It should be pretty safe to add a CopyInOutResponse message to the protocol
> without a protocol version b
On Tue, Sep 21, 2010 at 9:48 AM, fazool mein wrote:
> Hi,
>
> I want to shut down the server under certain conditions that can be checked
> inside a backend process. For instance, while running symmetric replication,
> if the primary dies, I want the the walreceiver to detect that and shutdown
> t
On Mon, Sep 20, 2010 at 10:57:00PM -0400, Robert Haas wrote:
> 2010/9/3 Hans-Jürgen Schönig :
> > On Sep 2, 2010, at 1:20 AM, Robert Haas wrote:
> >> I agree. Explicit partitioning may open up some additional
> >> optimization possibilities in certain cases, but Merge Append is
> >> more general an
I've been having a look at this guy, trying to get a handle on how much
down time it will save.
As a quick check, I tried upgrading a cluster with a 1 non default db
containing a scale 100 pgbench schema:
- pg_upgrade : 57 s
- pgdump/pg_restore : 154 s
So, a reasonable saving all up
Back here I asked what we were going to do about .gitignore files:
http://archives.postgresql.org/pgsql-hackers/2010-08/msg01232.php
The thread died off when the first git conversion attempt crashed and
burned; but not before it became apparent that we didn't have much
consensus. It seemed that th
Magnus Hagander writes:
> Ok, I've pushed a new repository to both gitmaster and the
> postgresql-migration.git mirror, that has this setting.
> NOTE! Do a complete wipe of your repository before you clone this
> again - it's a completely new repo that will have different SHA1s.
AFAICT this versi
2010/9/3 Hans-Jürgen Schönig :
> On Sep 2, 2010, at 1:20 AM, Robert Haas wrote:
>> I agree. Explicit partitioning may open up some additional optimization
>> possibilities in certain cases, but Merge Append is more general and
>> extremely valuable in its own right.
>
> we have revised greg's won
... or did we just forget to remove it?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
On Mon, Sep 20, 2010 at 1:45 PM, Markus Wanner wrote:
> Hm.. I see. So in other words, you are saying
> min_spare_background_workers isn't flexible enough in case one has
> thousands of databases but only uses a few of them frequently.
Yes, I think that is true.
> I understand that reasoning and
Hi,
I want to shut down the server under certain conditions that can be checked
inside a backend process. For instance, while running symmetric replication,
if the primary dies, I want the the walreceiver to detect that and shutdown
the standby. The reason for shutdown is that I want to execute so
On Mon, Sep 20, 2010 at 5:42 PM, Thom Brown wrote:
> On 20 September 2010 22:14, Robert Haas wrote:
>> Well, if you need to talk to "all the other standbys" and see who has
>> the furtherst-advanced xlog pointer, it seems like you have to have a
>> list somewhere of who they all are.
>
> When the
Dan S wrote:
> Well I guess one would like some way to find out which statements
> in the involved transactions are the cause of the serialization
> failure and what programs they reside in.
Unless we get the conflict list optimization added after the base
patch, you might get anywhere from on
On 20 September 2010 22:14, Robert Haas wrote:
> Well, if you need to talk to "all the other standbys" and see who has
> the furtherst-advanced xlog pointer, it seems like you have to have a
> list somewhere of who they all are.
When they connect to the master to get the stream, don't they in
eff
On Mon, Sep 20, 2010 at 4:10 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> So the "wait forever" case is, in my opinion,
>> sufficient to demonstrate that we need it, but it's not even my
>> primary reason for wanting to have it.
>
> You're talking about standby registration on the maste
On Mon, Sep 20, 2010 at 20:05, Magnus Hagander wrote:
> On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander wrote:
>> On Mon, Sep 20, 2010 at 19:49, Tom Lane wrote:
>>> Magnus Hagander writes:
On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
> Please fix and re-run.
>>>
Uh, what the h
Hi,
I'm somewhat sorry to have to play this game, as I sure don't feel
smarter by composing this email. Quite the contrary.
Robert Haas writes:
> So the "wait forever" case is, in my opinion,
> sufficient to demonstrate that we need it, but it's not even my
> primary reason for wanting to have
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> This is not even close to matching the tarballs :-(. Seems to be a
> >> locale problem: the diffs look like
> >>
> >> 1c1
> >> < /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008/09/05
> >> 18:25:16 tgl Exp $ */
> >> -
Well I guess one would like some way to find out which statements in the
involved transactions are the cause of the serialization failure and what
programs they reside in.
Also which relations were involved, the sql-statements may contain many
relations but just one or a few might be involved in t
Peter Eisentraut writes:
> On mån, 2010-09-20 at 15:09 -0400, Tom Lane wrote:
>> I wouldn't be against that necessarily if we were
>> keeping the keywords and not getting rid of them. But since we are
>> going to get rid of them going forward, I think what we want this
>> conversion to do is mat
On 09/20/2010 09:06 PM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
http://lists.nongnu.org/archive/html/info-cvs/2004-07/msg00106.html
is what I'm refering too and what the debian people provided a patch to
work around for(starting with1:1.12.9-17 in 2005) - nut sure why you are
not seeing it
On mån, 2010-09-20 at 15:09 -0400, Tom Lane wrote:
> I wouldn't be against that necessarily if we were
> keeping the keywords and not getting rid of them. But since we are
> going to get rid of them going forward, I think what we want this
> conversion to do is match what's in the historical tarba
Bruce Momjian writes:
> Tom Lane wrote:
>> This is not even close to matching the tarballs :-(. Seems to be a
>> locale problem: the diffs look like
>>
>> 1c1
>> < /* $PostgreSQL: pgsql/contrib/citext/citext.sql.in,v 1.3 2008/09/05
>> 18:25:16 tgl Exp $ */
>> ---
> /* $PostgreSQL: pgsql/contrib
Stefan Kaltenbrunner writes:
> http://lists.nongnu.org/archive/html/info-cvs/2004-07/msg00106.html
> is what I'm refering too and what the debian people provided a patch to
> work around for(starting with1:1.12.9-17 in 2005) - nut sure why you are
> not seeing it...
Hm, that is talking about th
Tom Lane wrote:
> Magnus Hagander writes:
> > Since there haven't been any commits in cvs during the day, the test
> > conversoin I created after lunch should be identical to a new one I'd
> > run now, so let's use that one :-)
>
> This is not even close to matching the tarballs :-(. Seems to be
On 09/20/2010 08:33 PM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
On 09/20/2010 08:21 PM, Tom Lane wrote:
Well, I'm testing with an unmodified copy of 1.12.13, and I got output
matching our historical tarballs. So I'm blaming debian for this one.
As far as I know magnus is using a debia
Stefan Kaltenbrunner writes:
> On 09/20/2010 08:21 PM, Tom Lane wrote:
>> Well, I'm testing with an unmodified copy of 1.12.13, and I got output
>> matching our historical tarballs. So I'm blaming debian for this one.
> As far as I know magnus is using a debian based CVS server for his
> testin
On 09/20/2010 08:21 PM, Tom Lane wrote:
Stefan Kaltenbrunner writes:
On 09/20/2010 08:05 PM, Magnus Hagander wrote:
debian applies a patch to change it. If I set DateStyle=old in
CVSROOT/config, cvs export behaves sanely. I'll re-run with that
setting.
actually as I understand it the behavi
On Monday 20 September 2010 20:22:55 Tom Lane wrote:
> Andres Freund writes:
> > On Monday 20 September 2010 20:15:50 Tom Lane wrote:
> >> BTW, while poking around in this morning's attempt I noticed
> >> .git/description, containing
> >>
> >> Unnamed repository; edit this file 'description' to n
Magnus Hagander writes:
> On Mon, Sep 20, 2010 at 20:15, Tom Lane wrote:
>> BTW, while poking around in this morning's attempt I noticed
>> .git/description, containing
>>
>> Unnamed repository; edit this file 'description' to name the repository.
> That said, where was it set to that? A locall
Andres Freund writes:
> On Monday 20 September 2010 20:15:50 Tom Lane wrote:
>> BTW, while poking around in this morning's attempt I noticed
>> .git/description, containing
>>
>> Unnamed repository; edit this file 'description' to name the repository.
>>
>> No idea if this is shown anywhere or i
Stefan Kaltenbrunner writes:
> On 09/20/2010 08:05 PM, Magnus Hagander wrote:
>> debian applies a patch to change it. If I set DateStyle=old in
>> CVSROOT/config, cvs export behaves sanely. I'll re-run with that
>> setting.
> actually as I understand it the behaviour changed in cvs 1.12.x and
>
Dan S wrote:
> I wonder if the SSI implementation will give some way of detecting
> the cause of a serialization failure.
> Something like the deadlock detection maybe where you get the
> sql-statements involved.
I've been wondering what detail to try to include. There will often
be three tra
On Mon, Sep 20, 2010 at 20:15, Tom Lane wrote:
> BTW, while poking around in this morning's attempt I noticed
> .git/description, containing
>
> Unnamed repository; edit this file 'description' to name the repository.
>
> No idea if this is shown anywhere or if there is any practical way to
> chan
On Monday 20 September 2010 20:15:50 Tom Lane wrote:
> BTW, while poking around in this morning's attempt I noticed
> .git/description, containing
>
> Unnamed repository; edit this file 'description' to name the repository.
>
> No idea if this is shown anywhere or if there is any practical way to
BTW, while poking around in this morning's attempt I noticed
.git/description, containing
Unnamed repository; edit this file 'description' to name the repository.
No idea if this is shown anywhere or if there is any practical way to
change it once the repo's been published. Might be an idea to s
On 09/20/2010 08:05 PM, Magnus Hagander wrote:
On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander wrote:
On Mon, Sep 20, 2010 at 19:49, Tom Lane wrote:
Magnus Hagander writes:
On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
Please fix and re-run.
Uh, what the heck. I ran the exact same co
On 09/20/2010 08:06 PM, Kevin Grittner wrote:
> Obviously, if there were a dynamic way to add to the entries as
> needed, there would be one less setting (hard-coded or GUC) to worry
> about getting right. Too low means transactions need to be
> canceled. Too high means you're wasting space which
On Mon, Sep 20, 2010 at 20:07, Tom Lane wrote:
> Magnus Hagander writes:
>> debian applies a patch to change it.
>
> [ rolls eyes... ] Thank you, debian.
Indeed.
For the archives, that's DateFormat=old, not DateStyle. Oops.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.
Magnus Hagander writes:
> debian applies a patch to change it.
[ rolls eyes... ] Thank you, debian.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ha
Markus Wanner wrote:
> I'm wondering how you want to implement the memory allocation part
Based on the feedback I've received, it appears that the only sane
way to do that in the current shared memory environment is to
allocate a fixed size of memory to hold these entries on postmaster
startup
On Mon, Sep 20, 2010 at 7:57 PM, Magnus Hagander wrote:
> On Mon, Sep 20, 2010 at 19:49, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
Please fix and re-run.
>>
>>> Uh, what the heck. I ran the exact same command as last time.. Hmm:
>>> Stefa
Magnus Hagander writes:
> Correct, I'm in en_US. I'm trying a "cvs export" in "C" now to see
> exaclty what changes.
> Hmm
> Nope, doesn't seem to change. I just set my LANG=C, and ran a "cvs
> export". but it comes back with "-" in the dates, so it seems to not
> care about that.
I thought "cvs
On Mon, Sep 20, 2010 at 19:49, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
>>> Please fix and re-run.
>
>> Uh, what the heck. I ran the exact same command as last time.. Hmm:
>> Stefan rbeooted the machine in between, I wonder if that changed
>> so
Hi !
I wonder if the SSI implementation will give some way of detecting the cause
of a serialization failure.
Something like the deadlock detection maybe where you get the sql-statements
involved.
Best Regards
Dan S
On 09/20/2010 06:09 PM, Kevin Grittner wrote:
> Yeah, I mostly followed that thread. If such a feature was present,
> it might well make sense to use it for this; however, I've got
> enough trouble selling the SSI technology without making it
> dependent on something else which was clearly quite c
Magnus Hagander writes:
> On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
>> Please fix and re-run.
> Uh, what the heck. I ran the exact same command as last time.. Hmm:
> Stefan rbeooted the machine in between, I wonder if that changed
> something.
I'm not sure we ever checked that. My compari
Robert,
On 09/20/2010 06:57 PM, Robert Haas wrote:
> Gee, that doesn't seem slow enough to worry about to me. If we
> suppose that you need 2 * CPUs + spindles processes to fully load the
> system, that means you should be able to ramp up from zero to
> consuming every available system resource i
On Mon, Sep 20, 2010 at 19:34, Tom Lane wrote:
> Magnus Hagander writes:
>> Since there haven't been any commits in cvs during the day, the test
>> conversoin I created after lunch should be identical to a new one I'd
>> run now, so let's use that one :-)
>
> This is not even close to matching th
On 09/20/2010 01:16 PM, Mark Wong wrote:
On Mon, Sep 20, 2010 at 9:42 AM, Andrew Dunstan wrote:
On 09/20/2010 12:24 PM, Mark Wong wrote:
On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjianwrote:
Well, I can run tests for folks before they apply a patch and "red" the
build farm. I can also
Magnus Hagander writes:
> Since there haven't been any commits in cvs during the day, the test
> conversoin I created after lunch should be identical to a new one I'd
> run now, so let's use that one :-)
This is not even close to matching the tarballs :-(. Seems to be a
locale problem: the diffs
Magnus Hagander wrote:
> Hi!
>
> CVS has been frozen, and all commit access locked out.
>
> Since there haven't been any commits in cvs during the day, the test
> conversoin I created after lunch should be identical to a new one I'd
> run now, so let's use that one :-)
>
> So I've moved it in pl
On Mon, Sep 20, 2010 at 9:42 AM, Andrew Dunstan wrote:
>
>
> On 09/20/2010 12:24 PM, Mark Wong wrote:
>>
>> On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian wrote:
>>>
>>> Well, I can run tests for folks before they apply a patch and "red" the
>>> build farm. I can also research fixes easier becau
On Mon, Sep 20, 2010 at 11:30 AM, Markus Wanner wrote:
> Well, Apache pre-forks 5 processes in total (by default, that is, for
> high volume webservers a higher MinSpareServers setting is certainly not
> out of question). While bgworkers currently needs to fork
> min_spare_background_workers proce
Greetings,
After watching a database import go abysmally slow on a pretty beefy
box with tons of RAM, I got annoyed and went to hunt down why in the
world PG wasn't using but a bit of memory. Turns out to be a well
known and long-standing issue:
http://www.mail-archive.com/pgsql-hacker
Hi!
CVS has been frozen, and all commit access locked out.
Since there haven't been any commits in cvs during the day, the test
conversoin I created after lunch should be identical to a new one I'd
run now, so let's use that one :-)
So I've moved it in place. It's on
http://git.postgresql.org/gi
Tom Lane wrote:
> There's nothing vestigial about SHM_QUEUE --- it's used by the
> lock manager. But it's intended to link together structs whose
> existence is managed by somebody else.
Yep, that's exactly my problem.
> I'm not excited about inventing an API with just one use-case;
> it's
On Mon, 2010-09-20 at 12:35 -0400, Tom Lane wrote:
> "Kevin Grittner" writes:
> > Simon Riggs wrote:
> >> My understanding is that we used to have that and it was removed
> >> for the reasons Heikki states. There are still vestigial bits
> >> still in code.
>
> There's nothing vestigial about SH
On 09/20/2010 12:24 PM, Mark Wong wrote:
On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian wrote:
Well, I can run tests for folks before they apply a patch and "red" the
build farm. I can also research fixes easier because I am using the OS,
rather than running blind tests. I am just telling
On Mon, Sep 20, 2010 at 12:24 PM, Mark Wong wrote:
> On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian wrote:
>> Andrew Dunstan wrote:
>>>
>>>
>>> On 09/18/2010 10:22 AM, Bruce Momjian wrote:
>>> > Dave Page wrote:
>>> >> On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote:
>>> >>> FYI, I have co
"Kevin Grittner" writes:
> Simon Riggs wrote:
>> My understanding is that we used to have that and it was removed
>> for the reasons Heikki states. There are still vestigial bits
>> still in code.
There's nothing vestigial about SHM_QUEUE --- it's used by the lock
manager. But it's intended to
On 20/09/10 19:04, Kevin Grittner wrote:
Heikki Linnakangas wrote:
In the SSI patch, you'd also need a way to insert an existing
struct into a hash table. You currently work around that by using
a hash element that contains only the hash key, and a pointer to
the SERIALIZABLEXACT struct. It is
On Fri, 2010-09-17 at 18:22 +0900, Fujii Masao wrote:
> On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
> wrote:
> > That said, there's a few small things that can be progressed regardless of
> > the details of synchronous replication. There's the changes to trigger
> > failover with a signal,
Simon Riggs wrote:
> My understanding is that we used to have that and it was removed
> for the reasons Heikki states. There are still vestigial bits
> still in code.
>
> Not exactly impressed with the SHM_QUEUE stuff though, so I
> appreciate the sentiment that Kevin expresses.
So, if I just
On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian wrote:
> Andrew Dunstan wrote:
>>
>>
>> On 09/18/2010 10:22 AM, Bruce Momjian wrote:
>> > Dave Page wrote:
>> >> On Fri, Sep 17, 2010 at 10:02 PM, Bruce Momjian wrote:
>> >>> FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
>>
On Mon, 2010-09-20 at 18:37 +0300, Heikki Linnakangas wrote:
> > SHM_QUEUE objects provide the infrastructure for maintaining a
> > shared memory linked list, but they don't do anything about the
> > allocation and release of the space for the objects. So it occurs
> > to me that I'm using an HTA
Heikki Linnakangas writes:
> It doesn't feel right to always accept PQputCopyData in COPY OUT mode,
> though. IMHO there should be a new COPY IN+OUT mode.
Yeah, I was going to make the same complaint. Breaking basic
error-checking functionality in libpq is not very acceptable.
> It should be p
Markus Wanner wrote:
> On 09/20/2010 05:12 PM, Kevin Grittner wrote:
>> SHM_QUEUE objects provide the infrastructure for maintaining a
>> shared memory linked list, but they don't do anything about the
>> allocation and release of the space for the objects.
>
> Did you have a look at my dynshme
Heikki Linnakangas wrote:
> In the SSI patch, you'd also need a way to insert an existing
> struct into a hash table. You currently work around that by using
> a hash element that contains only the hash key, and a pointer to
> the SERIALIZABLEXACT struct. It isn't too bad I guess, but I find
> i
Kevin,
On 09/20/2010 05:12 PM, Kevin Grittner wrote:
> SHM_QUEUE objects provide the infrastructure for maintaining a
> shared memory linked list, but they don't do anything about the
> allocation and release of the space for the objects.
Did you have a look at my dynshmem stuff? It tries to solv
On 20/09/10 18:12, Kevin Grittner wrote:
On the Serializable Snapshot Isolation thread, Heikki pointed out a
collection of objects in an HTAB which didn't really need its key on
VirtualTransactionId, but there isn't really any other useful key,
either. One of these objects may live and die, seei
On 20 September 2010 16:54, Andrew Dunstan wrote:
>
>
> On 09/20/2010 10:29 AM, Colin 't Hart wrote:
>>
>> Hi,
>>
>> Back in 2002 these were proposed, what happened to them?
>>
>> http://archives.postgresql.org/pgsql-sql/2002-09/msg00406.php
>
>
> 2002 is a long time ago.
> I think to_d
Hi,
On 09/18/2010 05:21 AM, Robert Haas wrote:
> Wow, 100 processes??! Really? I guess I don't actually know how large
> modern proctables are, but on my MacOS X machine, for example, there
> are only 75 processes showing up right now in "ps auxww". My Fedora
> 12 machine has 97. That's includi
On the Serializable Snapshot Isolation thread, Heikki pointed out a
collection of objects in an HTAB which didn't really need its key on
VirtualTransactionId, but there isn't really any other useful key,
either. One of these objects may live and die, seeing use from
multiple processes, without eve
On 09/18/2010 05:43 AM, Tom Lane wrote:
> The part of that that would worry me is open files. PG backends don't
> have any compunction about holding open hundreds of files. Apiece.
> You can dial that down but it'll cost you performance-wise. Last
> I checked, most Unix kernels still had limited
On 17/09/10 12:22, Fujii Masao wrote:
On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
wrote:
That said, there's a few small things that can be progressed regardless of
the details of synchronous replication. There's the changes to trigger
failover with a signal, and it seems that we'll nee
On 09/20/2010 10:29 AM, Colin 't Hart wrote:
Hi,
Back in 2002 these were proposed, what happened to them?
http://archives.postgresql.org/pgsql-sql/2002-09/msg00406.php
2002 is a long time ago.
Also I note:
co...@ruby:~/workspace/eyedb$ psql
psql (8.4.4)
Type "help" for help.
Hi,
Back in 2002 these were proposed, what happened to them?
http://archives.postgresql.org/pgsql-sql/2002-09/msg00406.php
Also I note:
co...@ruby:~/workspace/eyedb$ psql
psql (8.4.4)
Type "help" for help.
colin=> select to_date('731332', 'YYMMDD');
to_date
1974-02-01
(1 row)
I wrote:
> Heikki Linnakangas wrote:
>
>> ISTM you never search the SerializableXactHash table using a hash
>> key, except the one call in CheckForSerializableConflictOut, but
>> there you already have a pointer to the SERIALIZABLEXACT struct.
>> You only re-find it to make sure it hasn't gone aw
Hi.
I'm trying to migrate an application off an existing Full Text Search engine
and onto PostgreSQL .. one of my main (remaining) headaches are the
fact that PostgreSQL treats _ as a seperation charachter whereas the existing
behaviour is to "not split". That means:
testdb=# select ts_debug('dat
On Mon, Sep 20, 2010 at 8:50 AM, Simon Riggs wrote:
> Please respond to the main point: Following some thought and analysis,
> AFAICS there is no sensible use case that requires standby registration.
I disagree. You keep analyzing away the cases that require standby
registration, but I don't bel
On 20/09/10 15:50, Simon Riggs wrote:
On Mon, 2010-09-20 at 15:16 +0300, Heikki Linnakangas wrote:
On 20/09/10 12:17, Simon Riggs wrote:
err... what is the difference between a timeout and stonith?
STONITH ("Shoot The Other Node In The Head") means that the other node
is somehow disabled so t
On Mon, 2010-09-20 at 15:16 +0300, Heikki Linnakangas wrote:
> On 20/09/10 12:17, Simon Riggs wrote:
> > err... what is the difference between a timeout and stonith?
>
> STONITH ("Shoot The Other Node In The Head") means that the other node
> is somehow disabled so that it won't unexpectedly come
On 20/09/10 12:17, Simon Riggs wrote:
err... what is the difference between a timeout and stonith?
STONITH ("Shoot The Other Node In The Head") means that the other node
is somehow disabled so that it won't unexpectedly come back alive. A
timeout means that the slave hasn't been seen for a wh
On Mon, Sep 20, 2010 at 1:07 AM, Tom Lane wrote:
> Robert Haas writes:
>> In view of the foregoing problems, I'd like to propose adding a new
>> system view, tentatively called pg_comments, which lists all of the
>> comments for everything in the system in such a way that it's
>> reasonably possi
On Sun, Sep 19, 2010 at 18:52, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 09/19/2010 12:25 PM, Tom Lane wrote:
>>> # We don't want to change line numbers, so we simply reduce the keyword
>>> # string to the file pathname part. For example,
>>> # $PostgreSQL: pgsql/src/port/unsetenv.c,v 1.12
On Mon, 2010-09-20 at 09:27 +0300, Heikki Linnakangas wrote:
> On 18/09/10 22:59, Robert Haas wrote:
> > On Sat, Sep 18, 2010 at 4:50 AM, Simon Riggs wrote:
> >> Waiting might sound attractive. In practice, waiting will make all of
> >> your connections lock up and it will look to users as if thei
Tom Lane writes:
> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
>> Where does PGXS makefile get /usr/share/doc/pgsql/contrib directory
>> from?
>
>> While building 3rd party RPMs using PGXS, even if I specify docdir in
>> Makefile, README.* files are installed to this directory, which breaks
>> par
Hi,
On 09/17/2010 01:56 PM, Fujii Masao wrote:
And standby registration is required when we support "wait forever when
synchronous standby isn't connected at the moment" option that Heikki
explained upthread.
That requirement can be reduced to say that the master only needs to
known how many
You seem to be working for EnterpriseDB, which is a company specializing on
postgres. So how does EnterpriseDB sell the advanced server? By modifying
it, I guess! So that is something similar I want to do. Getting a few
dollars for some hard work is not bad for me. Plus I love to find new
things, s
On Mon, Sep 20, 2010 at 7:48 AM, Vaibhav Kaushal
wrote:
> May be this is the wrong place to ask the question. Still, answer me if
> someone can or please redirect me to some place where it can be answered. My
> questions are:
>
> 1. PostgreSQL can be distributed freely according to the license ter
95 matches
Mail list logo
