Re: [HACKERS] experimental: replace s_lock spinlock code with pthread_mutex on linux

On Wed, Jun 27, 2012 at 12:58:47AM +0200, Nils Goroll wrote: > So it looks like using pthread_mutexes could at least be an option on Linux. > > Using futexes directly could be even cheaper. Note that below this you only have the futex(2) system call. Futexes require all counter manipulation to ha

Re: [HACKERS] Schema version management

Robert, thank you for keeping this thread alive. Hopefully some more will join the discussion. I'm still hopeful the community can manage to agree upon acceptable tradeoffs and work-arounds to make this possible. I think the benefits clearly outweighs the minor issues of filenames, dumping order

Re: [HACKERS] new --maintenance-db options

Tom Lane writes: Amit Kapila writes: > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane >>> The implementation I've wanted to see for some time is that you can >>> start a standalone backend, but it speaks FE/BE protocol to its caller >>> (preferably over pipes, so that there is

[HACKERS] plpython issue with Win64 (PG 9.2)

Hi, On Windows 7 64bit, plpython is causing server crash with the following test case i.e. CREATE PROCEDURAL LANGUAGE 'plpython3u'; > CREATE OR REPLACE FUNCTION pymax (a integer, b integer) > RETURNS integer > AS $$ > if a > b: > return a > return b > $$ LANGUAGE plpython3u; > SELECT py

Re: [HACKERS] experimental: replace s_lock spinlock code with pthread_mutex on linux

>> Using futexes directly could be even cheaper. > Note that below this you only have the futex(2) system call. I was only referring to the fact that we could save one function and one library call, which could make a difference for the uncontended case. -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] [PATCH 01/16] Overhaul walsender wakeup handling

On Tuesday, June 26, 2012 04:06:08 PM Andres Freund wrote: > On Tuesday, June 26, 2012 04:01:26 PM Robert Haas wrote: > > On Fri, Jun 22, 2012 at 12:35 PM, Andres Freund > > wrote: > > >> Can you elaborate on that a bit? What scenarios did you play around > > >> with, and what does "win" mean in

Re: [HACKERS] [v9.3] Row-Level Security

On Jun27, 2012, at 07:18 , Kohei KaiGai wrote: > The problem is the way to implement it. > If we would have permission checks on planner stage, it cannot handle > a case when user-id would be switched prior to executor stage, thus > it needs something remedy to handle the scenario correctly. > Inst

Re: [HACKERS] Posix Shared Mem patch

On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane wrote: > Robert Haas writes: >> So, here's a patch.  Instead of using POSIX shmem, I just took the >> expedient of using mmap() to map a block of MAP_SHARED|MAP_ANONYMOUS >> memory.  The sysv shm is still allocated, but it's just a copy of >> PGShmemHead

Re: [HACKERS] proof concept - access to session variables on client side

2012/6/27 Tom Lane : > Pavel Stehule writes: >>> Another thing I don't care for is the unannounced protocol extension. > >> yes, it needs protocol extension and increasing version too. But I >> don't afraid about dissynchronisation - server doesn't send 'v' >> message when client doesn't support i

Re: [HACKERS] Posix Shared Mem patch

On Wed, Jun 27, 2012 at 3:50 AM, Tom Lane wrote: > "A.M." writes: >> On 06/26/2012 07:30 PM, Tom Lane wrote: I solved this via fcntl locking. > >>> No, you didn't, because fcntl locks aren't inherited by child processes. >>> Too bad, because they'd be a great solution otherwise. > >> You cla

Re: [HACKERS] plpython issue with Win64 (PG 9.2)

On 27/06/12 11:51, Asif Naeem wrote: Hi, On Windows 7 64bit, plpython is causing server crash with the following test case i.e. CREATE PROCEDURAL LANGUAGE 'plpython3u'; CREATE OR REPLACE FUNCTION pymax (a integer, b integer) RETURNS integer AS $$ if a> b: return a return b $$ LA

Re: [HACKERS] pg_terminate_backend for same-role

On Tue, Jun 26, 2012 at 10:58 PM, Robert Haas wrote: > On Thu, Mar 29, 2012 at 3:04 AM, Daniel Farina wrote: >> On Mon, Mar 26, 2012 at 12:14 AM, Jeff Davis wrote: >>> On Tue, 2012-03-20 at 01:38 -0700, Daniel Farina wrote: On Thu, Mar 15, 2012 at 9:39 PM, Fujii Masao wrote: > On Fri,

Re: [HACKERS] [v9.3] Row-Level Security

2012/6/27 Florian Pflug : > On Jun27, 2012, at 07:18 , Kohei KaiGai wrote: >> The problem is the way to implement it. >> If we would have permission checks on planner stage, it cannot handle >> a case when user-id would be switched prior to executor stage, thus >> it needs something remedy to handl

Re: [HACKERS] [PATCH] Lazy hashaggregate when no aggregation is needed

Sorry about the delay in answering. I have been swamped with non-PG related things lately. On Tue, Jun 26, 2012 at 11:08 PM, Robert Haas wrote: > On Fri, Jun 22, 2012 at 10:12 AM, Robert Haas wrote: >> On Tue, Jun 19, 2012 at 5:41 AM, Etsuro Fujita >> wrote: I'm confused by this remark, be

Re: [HACKERS] [v9.3] Row-Level Security

On Wed, Jun 27, 2012 at 7:21 AM, Florian Pflug wrote: > On Jun27, 2012, at 07:18 , Kohei KaiGai wrote: >> The problem is the way to implement it. >> If we would have permission checks on planner stage, it cannot handle >> a case when user-id would be switched prior to executor stage, thus >> it ne

Re: [HACKERS] pg_terminate_backend for same-role

On Wed, Jun 27, 2012 at 8:13 AM, Magnus Hagander wrote: >> I went ahead and committed this. >> >> I kinda think we should back-patch this into 9.2.  It doesn't involve >> a catalog change, and would make the behavior consistent between the >> two releases, instead of changing in 9.1 and then chang

[HACKERS] Reporting hba lines

When debugging strange and complex pg_hba lines, it can often be quite useful to know which line is matching a particular connection that failed for some reason. Because more often than not, it's actually not using the line in pg_hba.conf that's expected. The easiest way to do this is to emit an e

Re: [HACKERS] [v9.3] Row-Level Security

2012/6/27 Robert Haas : > On Wed, Jun 27, 2012 at 7:21 AM, Florian Pflug wrote: >> On Jun27, 2012, at 07:18 , Kohei KaiGai wrote: >>> The problem is the way to implement it. >>> If we would have permission checks on planner stage, it cannot handle >>> a case when user-id would be switched prior to

Re: [HACKERS] Reporting hba lines

Le mercredi 27 juin 2012 14:54:15, Magnus Hagander a écrit : > When debugging strange and complex pg_hba lines, it can often be quite > useful to know which line is matching a particular connection that > failed for some reason. Because more often than not, it's actually not > using the line in pg_

Re: [HACKERS] Posix Shared Mem patch

Magnus Hagander writes: > On Wed, Jun 27, 2012 at 3:50 AM, Tom Lane wrote: >> I wonder whether this design can be adapted to Windows?  IIRC we do >> not have a bulletproof data directory lock scheme for Windows. >> It seems like this makes few enough demands on the lock mechanism >> that there ou

Re: [HACKERS] Visual Studio 2012 RC

On 10.06.2012 11:41, Magnus Hagander wrote: On Sun, Jun 10, 2012 at 3:16 AM, Brar Piening wrote: Magnus Hagander wrote: I don't have too much hope for them actually changing it - they seem hell-bent on forcing everybody into metro, and this seems to be yet another way to do that. But we can a

Re: [HACKERS] Posix Shared Mem patch

Robert Haas writes: > On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane wrote: >> Would Posix shmem help with that at all? Why did you choose not to >> use the Posix API, anyway? > It seemed more complicated. If we use the POSIX API, we've got to > have code to find a non-colliding name for the shm,

Re: [HACKERS] Posix Shared Mem patch

All, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane wrote: > >> Would Posix shmem help with that at all? Why did you choose not to > >> use the Posix API, anyway? > > > It seemed more complicated. If we use the POSIX API, we've got

Re: [HACKERS] Posix Shared Mem patch

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Right, but does it provide honest protection against starting two > postmasters in the same data directory? Or more to the point, > does it prevent starting a new postmaster when the old postmaster > crashed but there are still orphaned backends making chan

[HACKERS] Re: [PATCH 07/16] Log enough data into the wal to reconstruct logical changes from it if wal_level=logical

On 13.06.2012 14:28, Andres Freund wrote: @@ -2584,6 +2610,73 @@ l1: rdata[1].buffer_std = true; rdata[1].next = NULL; + /* +* XXX: We could decide not to log changes when the origin is not the +* local node, that sho

Re: [HACKERS] Reporting hba lines

Magnus Hagander writes: > When debugging strange and complex pg_hba lines, it can often be quite > useful to know which line is matching a particular connection that > failed for some reason. Because more often than not, it's actually not > using the line in pg_hba.conf that's expected. > The eas

Re: [HACKERS] Reporting hba lines

On Wed, Jun 27, 2012 at 3:55 PM, Tom Lane wrote: > Magnus Hagander writes: >> When debugging strange and complex pg_hba lines, it can often be quite >> useful to know which line is matching a particular connection that >> failed for some reason. Because more often than not, it's actually not >> u

Re: [HACKERS] Posix Shared Mem patch

On Wed, Jun 27, 2012 at 3:40 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Jun 27, 2012 at 3:50 AM, Tom Lane wrote: >>> I wonder whether this design can be adapted to Windows?  IIRC we do >>> not have a bulletproof data directory lock scheme for Windows. >>> It seems like this makes f

Re: [HACKERS] warning handling in Perl scripts

On 06/24/2012 04:05 PM, Robert Haas wrote: On Sun, Jun 24, 2012 at 2:40 PM, Peter Eisentraut wrote: Every time I make a change to the structure of the catalog files, genbki.pl produces a bunch of warnings (like "Use of uninitialized value in string eq at genbki.pl line ..."), and produces cor

Re: [HACKERS] Reporting hba lines

Magnus Hagander writes: > On Wed, Jun 27, 2012 at 3:55 PM, Tom Lane wrote: >> BTW, are you sure that auth_failed is only called in cases where >> an hba line has already been identified? Even if true today, >> it seems fairly risky to assume that. > It is true today, but yes, it might be safe t

[HACKERS] Regarding WAL Format Changes

While reading patch-1 ( 1-use-uint64-got-segno.patch) of WAL Format Changes(http://archives.postgresql.org/message-id/4FDA5136.6080206@enterpris edb.com), I had few observations which are summarized below: 1. Function head

Re: [HACKERS] Posix Shared Mem patch

Magnus Hagander writes: > On Wed, Jun 27, 2012 at 3:40 PM, Tom Lane wrote: >> AFAIR we basically punted on those problems for the Windows port, >> for lack of an equivalent to nattch. > No, we spent a lot of time trying to *fix* it, and IIRC we did. OK, in that case this isn't as interesting as

Re: [HACKERS] Reporting hba lines

On Wed, Jun 27, 2012 at 4:14 PM, Tom Lane wrote: > Magnus Hagander writes: >> On Wed, Jun 27, 2012 at 3:55 PM, Tom Lane wrote: >>> BTW, are you sure that auth_failed is only called in cases where >>> an hba line has already been identified?  Even if true today, >>> it seems fairly risky to assum

Re: [HACKERS] Posix Shared Mem patch

On Wed, Jun 27, 2012 at 9:44 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane wrote: >>> Would Posix shmem help with that at all?  Why did you choose not to >>> use the Posix API, anyway? > >> It seemed more complicated.  If we use the POSIX API, we've got

Re: [HACKERS] Reporting hba lines

Magnus Hagander writes: > On Wed, Jun 27, 2012 at 4:14 PM, Tom Lane wrote: >> cases where people are modifying the wrong hba file.  Can we show >> the source text of the hba line? > We don't currently keep the full source text around - but we certainly > could do that if we wanted to. If we're

Re: [HACKERS] Posix Shared Mem patch

On Wed, Jun 27, 2012 at 9:52 AM, Stephen Frost wrote: > What this all boils down to is- can you have a shm segment that goes > away when no one is still attached to it, but actually give it a name > and then detect if it already exists atomically on startup on > Linux/Unixes?  If so, perhaps we co

Re: [HACKERS] Regarding WAL Format Changes

On 27.06.2012 17:14, Amit Kapila wrote: 1. Function header for following functions still contains referece to log, seg a. InstallXLogFileSegment() b. RemoveOldXlogFiles() c. XLogFileCopy() d. XLogGetLastRemoved() e. UpdateLastRemovedPtr() f. RemoveOldXlogFiles() Thanks,

[HACKERS] Re: [COMMITTERS] pgsql: Move WAL continuation record information to WAL page header.

On 27.06.2012 17:53, Andres Freund wrote: I had noticed one thing when reviewing the patches before: @@ -717,6 +719,15 @@ XLogInsert(RmgrId rmid, uint8 info, XLogRecData *rdata) booldoPageWrites; boolisLogSwitch = (rmid == RM_XLOG_ID&& info == XLOG_SWITCH); uint8

Re: [HACKERS] warning handling in Perl scripts

On Jun 27, 2012, at 4:07 PM, Andrew Dunstan wrote: > I realise I'm late to this party, but I'm with Robert. The root cause of the > errors should be fixed. > > That's not to say that making warnings fatal might not also be a good idea as > a general defense mechanism. ISTM that if they are fat

Re: [HACKERS] foreign key locks

Excerpts from Kevin Grittner's message of mié jun 27 08:40:58 -0400 2012: > Alvaro Herrera wrote: > > > here's fklocks v14, which also merges to new master as there were > > several other conflicts. It passes make installcheck-world now. > > Recent commits broke it again, so here's a rebased

Re: [HACKERS] Regarding WAL Format Changes

Excerpts from Heikki Linnakangas's message of mié jun 27 10:56:13 -0400 2012: > On 27.06.2012 17:14, Amit Kapila wrote: > >For the above 2 changed error messages, 'log segment' is used for > > filename. > >However all similar changes has 'log file' for filename. There are some > > places

Re: [HACKERS] Regarding WAL Format Changes

On Wed, Jun 27, 2012 at 11:56 PM, Heikki Linnakangas wrote: > On 27.06.2012 17:14, Amit Kapila wrote: >> >> 1. Function header for following functions still contains referece to log, >> seg >>    a. InstallXLogFileSegment() >>    b. RemoveOldXlogFiles() >>    c. XLogFileCopy() >>    d. XLogGetLast

Re: [HACKERS] [v9.3] Row-Level Security

On Jun27, 2012, at 15:07 , Kohei KaiGai wrote: > Probably, PlannedStmt->invalItems allows to handle invalidation of > plan-cache without big code changes. I'll try to put a flag of user-id > to track the query plan with RLS assumed, or InvalidOid if no RLS > was applied in this plan. > I'll investi

Re: [HACKERS] [COMMITTERS] pgsql: Move WAL continuation record information to WAL page header.

On Wednesday, June 27, 2012 05:09:46 PM Heikki Linnakangas wrote: > On 27.06.2012 17:53, Andres Freund wrote: > > I had noticed one thing when reviewing the patches before: > > > > @@ -717,6 +719,15 @@ XLogInsert(RmgrId rmid, uint8 info, XLogRecData > > *rdata) > > > > booldoPageWrit

Re: [HACKERS] Regarding WAL Format Changes

On 27.06.2012 18:55, Fujii Masao wrote: On Wed, Jun 27, 2012 at 11:56 PM, Heikki Linnakangas wrote: On 27.06.2012 17:14, Amit Kapila wrote: 1. Function header for following functions still contains referece to log, seg a. InstallXLogFileSegment() b. RemoveOldXlogFiles() c. XLogFi

Re: [HACKERS] Regarding WAL Format Changes

Heikki Linnakangas writes: >> So is there any particular reason for it? > Not really. There are several messages that use "log file %s", and also > several places that use "log segment %s" Should we make it consistent > and use either "log segment" or "log file" everywhere? +1 for uniformity.

Re: [HACKERS] [ADMIN] pg_basebackup blocking all queries with horrible performance

On Thu, Jun 21, 2012 at 3:18 AM, Robert Haas wrote: > On Wed, Jun 20, 2012 at 7:18 AM, Magnus Hagander wrote: > You agreed to add something like NOSYNC option into START_REPLICATION > command? I'm on the fence. I was hoping somebody else would chime in with an opinion as w

Re: [HACKERS] Regarding WAL Format Changes

On Thu, Jun 28, 2012 at 1:13 AM, Heikki Linnakangas wrote: > On 27.06.2012 18:55, Fujii Masao wrote: >> >> On Wed, Jun 27, 2012 at 11:56 PM, Heikki Linnakangas >>  wrote: >>> >>> On 27.06.2012 17:14, Amit Kapila wrote: 1. Function header for following functions still contains refer

Re: [HACKERS] [ADMIN] pg_basebackup blocking all queries with horrible performance

On 27 June 2012 18:24, Fujii Masao wrote: > will never become sync standby even > if their name is in synchronous_standby_names. I don't understand why you'd want that. What is wrong with removing the name from synchronous_standby_names if you don't like it? --  Simon Riggs  

Re: [HACKERS] Posix Shared Mem patch

On Jun 27, 2012, at 7:34 AM, Robert Haas wrote: > On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane wrote: >> Robert Haas writes: >>> So, here's a patch. Instead of using POSIX shmem, I just took the >>> expedient of using mmap() to map a block of MAP_SHARED|MAP_ANONYMOUS >>> memory. The sysv shm is

Re: [HACKERS] Patch: add conversion from pg_wchar to multibyte

On Thu, May 24, 2012 at 12:04 AM, Alexander Korotkov wrote: > Thanks. I rewrote inverse conversion from pg_wchar to mule. New version of > patch is attached. Review: It looks to me like pg_wchar2utf_with_len will not work, because unicode_to_utf8 returns its second argument unmodified - not, as

Re: [HACKERS] Uh, I change my mind about commit_delay + commit_siblings (sort of)

On Sat, Jun 2, 2012 at 10:44 AM, Kevin Grittner wrote: > Tom Lane  wrote: >> Simon Riggs  writes: >>> On 31 May 2012 15:00, Tom Lane  wrote: If we want to finish the beta cycle in a reasonable time period and get back to actual development, we have to refrain from adding more possib

Re: [HACKERS] Uh, I change my mind about commit_delay + commit_siblings (sort of)

On 27 June 2012 23:01, Robert Haas wrote: > 1. Are there any call sites from which this should be disabled, either > because the optimization won't help, or because the caller is holding > a lock that we don't want them sitting on for a moment longer than > necessary?  I think the worst case is th

[HACKERS] pg_signal_backend() asymmetry

Hi all, I have one nitpick related to the recent changes for pg_cancel_backend() and pg_terminate_backend(). If you use these functions as an unprivileged user, and try to signal a nonexistent PID, you get: ERROR: must be superuser or have the same role to cancel queries running in other serve

Re: [HACKERS] WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink

On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas wrote: > On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila wrote: >> To achieve the same in dblink, we need to parse the passed connection string >> and check if it contains fallback_application_name, if yes then its okay, >> otherwise we need to append f

[HACKERS] We probably need autovacuum_max_wraparound_workers

Folks, Yeah, I can't believe I'm calling for *yet another* configuration variable either. Suggested workaround fixes very welcome. The basic issue is that autovacuum_max_workers is set by most users based on autovac's fairly lightweight action most of the time: analyze, vacuuming pages not on th

Re: [HACKERS] WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink

On Wed, Jun 27, 2012 at 9:57 PM, Shigeru HANADA wrote: > On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas wrote: >> On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila wrote: >>> To achieve the same in dblink, we need to parse the passed connection string >>> and check if it contains fallback_application

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

Josh Berkus writes: > Yeah, I can't believe I'm calling for *yet another* configuration > variable either. Suggested workaround fixes very welcome. > The basic issue is that autovacuum_max_workers is set by most users > based on autovac's fairly lightweight action most of the time: analyze, > va

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

On Jun 27, 2012, at 22:00, Josh Berkus wrote: > Folks, > > Yeah, I can't believe I'm calling for *yet another* configuration > variable either. Suggested workaround fixes very welcome. > > The basic issue is that autovacuum_max_workers is set by most users > based on autovac's fairly lightweig

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

> I think what you've really got here is inappropriate autovacuum cost > delay settings, and/or the logic in autovacuum.c to try to divvy up the > available I/O capacity by tweaking workers' delay settings isn't working > very well. It's hard to propose improvements without a lot more detail > th

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

Josh, all, * Josh Berkus (j...@agliodbs.com) wrote: > Yeah, I can't believe I'm calling for *yet another* configuration > variable either. Suggested workaround fixes very welcome. As I suggested on IRC, my thought would be to have a goal-based system for autovacuum which is similar to our goal-b

Re: [HACKERS] Server crash while trying to fetch EXPLAIN query results with a cursor

Rushabh Lathia writes: > Above testcase endup with server crash. Crash is due to following assert > into ScanQueryForLocks() > Assert(parsetree->commandType != CMD_UTILITY); Meh, yeah, more fallout from the CREATE TABLE AS representation change. > PFA patch for the same. Applied with some edito

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

Josh Berkus writes: >> I think what you've really got here is inappropriate autovacuum cost >> delay settings, and/or the logic in autovacuum.c to try to divvy up the >> available I/O capacity by tweaking workers' delay settings isn't working >> very well. It's hard to propose improvements withou

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

Stephen Frost writes: > * Josh Berkus (j...@agliodbs.com) wrote: >> Yeah, I can't believe I'm calling for *yet another* configuration >> variable either. Suggested workaround fixes very welcome. > As I suggested on IRC, my thought would be to have a goal-based system > for autovacuum which is si

Re: [HACKERS] Regarding WAL Format Changes

From: Heikki Linnakangas [mailto:heikki.linnakan...@enterprisedb.com] Sent: Wednesday, June 27, 2012 8:26 PM On 27.06.2012 17:14, Amit Kapila wrote: >> 2. @@ -2680,8 +2645,8 @@ InstallXLogFileSegment(uint32 *log, uint32 *seg, >> char *tmppath, >> LWLockRelease(ControlFil

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

On Wed, Jun 27, 2012 at 11:38 PM, Tom Lane wrote: > Stephen Frost writes: >> * Josh Berkus (j...@agliodbs.com) wrote: >>> Yeah, I can't believe I'm calling for *yet another* configuration >>> variable either.  Suggested workaround fixes very welcome. > >> As I suggested on IRC, my thought would b

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

Robert Haas writes: > For example, suppose that 26 tables each of which is 4GB in size are > going to simultaneously come due for an anti-wraparound vacuum in 26 > hours. For the sake of simplicity suppose that each will take 1 hour > to vacuum. What we currently do is wait for 26 hours and then

Re: [HACKERS] Posix Shared Mem patch

On Wed, Jun 27, 2012 at 9:44 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane wrote: >>> Would Posix shmem help with that at all?  Why did you choose not to >>> use the Posix API, anyway? > >> It seemed more complicated.  If we use the POSIX API, we've got

Re: [HACKERS] pl/perl and utf-8 in sql_ascii databases

Hello, thank you for your sugestion. > > I agree. That is the fundamental question. I've coded just for my > > fun but I don't see not so much signicance to do that. We might > > omit the test for this which is non-ciritical and corner cases. > > We need these tests to work on Windows too, so fa

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

On Thu, Jun 28, 2012 at 12:51 AM, Tom Lane wrote: > Robert Haas writes: >> For example, suppose that 26 tables each of which is 4GB in size are >> going to simultaneously come due for an anti-wraparound vacuum in 26 >> hours.  For the sake of simplicity suppose that each will take 1 hour >> to va

Re: [HACKERS] We probably need autovacuum_max_wraparound_workers

Robert Haas writes: > It's just ridiculous to assert that it doesn't matter if all the > anti-wraparound vacuums start simultaneously. It does matter. For > one thing, once every single autovacuum worker is pinned down doing an > anti-wraparound vacuum of some table, then a table that needs an >

Re: [HACKERS] WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink

From: Robert Haas [mailto:robertmh...@gmail.com] Sent: Thursday, June 28, 2012 7:46 AM On Wed, Jun 27, 2012 at 9:57 PM, Shigeru HANADA wrote: > On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas wrote: >> Indeed reparsing connection string is not cheap, but dblink does it for >> checking password req